RE: RE Checkpoint 3.4 again

Jo, and others -

I agree with your sentiments. I think this provision will really scare
people away. In my experience, just presenting the WCAG to clients and other
developers is difficult. Some people are downright upset about "being told
what I can and can't do". While this is a knee jerk reaction, and such
reactions shouldn't inform what the WCAG is doing, it's a reality
nonetheless and must be addressed.

While I like much of Anne's rewriting of the point, I don't think the
success criteria are success criteria - they're bullet items that tell me
what I have to do. As I read over 3.4 again last night and tried to envision
applying 3.4 to it, I was at a complete loss.

I think what we are talking about with 3.4 is reinventing language -
introducing a hieroglyphic system to the Internet to enable better
understanding and use of information. Great, perfect, I'm all for that - the
world wide web is about the world, not about folks that can read and
understand English text. 

But I've been using the Internet in various forms since the introduction of
the acoustic modem way back in the 1970s, and I wouldn't have the foggiest
idea of how to implement 3.4 even on my home page.

As a developer and product manager my excitement over the "hieroglyphic web"
is exciting because it means the use of XML and XLST. Heck, with a little
time we could probably accomplish this with XHTML and CSS. How do I know if
the images I'm using are going to effectively communicate my idea? 

Greg's point that 
<quote>
one of the underlying principles of the WAI and the W3C is that web is
about choices -- no one can possibly presume to speak for another user and
accurately articulate what constitutes "accessibility" for that
individual... 
</quote>

is really pertinent here. This removes choice and enforces the
designer/developer to assume he/she can understand how someone else
understands, perceives and integrates information.



Joel Sanda 
Product Manager
-------------------------------------------------------www.eCollege.com
eCollege
joels@ecollege.com
> p. 303.873.7400 x3021
> f.  303.632.1721 


-----Original Message-----
From: Jo Miller [mailto:jo@bendingline.com]
Sent: Wednesday, August 01, 2001 12:42 PM
To: w3c-wai-gl@w3.org
Subject: Re: RE Checkpoint 3.4 again


Like many others in the group, I have grave misgivings about 3.4 in 
its current wording. Many of my objections and concerns have been 
stated so eloquently by others this week (Joe, Matt, Kynn, Greg, 
Joel) that I will not reiterate them here.

I think this guideline, as it is now written, will confound users of 
the guidelines, raise more problems that it solves, and resist the 
formulation of meaningful success criteria. I also think the 
elimination of the phrase "where it will facilitate comprehension," 
present in version 1, is a step in the wrong direction and makes the 
guideline too vague to be useful, no matter what supplemental 
material we provide. If 3.4 is to be included in an upcoming public 
draft of 2.0, I would strongly prefer to see this clause restored. It 
communicates more accurately and comprehensibly what I take (from 
Kynn's remarks and others') to be the intent behind the guideline.

I have also long been curious about why the strongest advocates of 
3.4 have not yet tried to implement its recommendations on any of the 
W3C pages. It would be a useful exercise. Do we plan to publish a 
public draft next week that includes 3.4 but contains no images or 
other non-text content?

I will quote Greg's recent post, in which I believe he crystallized 
well one of the central philosophical issues:

<greg>
>
>my point is, why force illustrations down individuals' throats when they
>either: (a) can't use them; (b) don't want to download them; or (c) just
>isn't interested in them?  instead of insisting that all content be
>illustrated, why not fight for implementations of mechanisms (such as
>those extant in the XML world) which enable the importation of iconic
>material into non-illustrated materials -- especially those that might be
>able to perform the task through automated look-ups, as thumb-nailed by
>kynn and al, or through an assertion language, such as RDF, which would
>allow you (anne) to make assertions about non-illustrated content, which
>could be transformed (using XSLT) into the illustrated document instance
>you desire...
>
>anne, no one is saying "don't use illustrations" -- what i and joe and
>others are saying is "give the user the choice, and use markup that
>enables look-ups and substitutions, transformations and annotations, so
>that graphics can be added to content even when they aren't extant in the
>document source of the document being rendered"
>
>one of the underlying principles of the WAI and the W3C is that web is
>about choices -- no one can possibly presume to speak for another user and
>accurately articulate what constitutes "accessibility" for that
>individual...  in my opinion, the advocates of an illustrated web would be
>better served working with the evaluation and repair group on assertion
>languages and transformation engines than tilting at the windmill of
words...
</greg>

Anne responds:
<anne>
         About adding illustrations, they will be there to provide a 
choice to the user. Those users who don't want them can turn them 
off, but those who want them cannot turn them on if they aren't there 
to begin with.
</anne>


Anne, are you saying that web pages should be optimized for people 
with certain types of learning or cognitive disabilities, and that 
those who do not need or want the extra graphics should disable all 
images in their browsers (which currently do not allow images on a 
page to be turned on and off selectively)? I hope that I have 
misconstrued your meaning here--perhaps you are talking about linking 
to non-text content.

If this group publishes certain guidelines that sound as if they were 
written by Diana Moon Glampers, the Handicapper General in Kurt 
Vonnegut's short story "Harrison Bergeron," then I think the 
community of web authors and developers would be justified in taking 
all our guidelines with a grain of salt. (The spectre of Diana Moon 
Glampers hovers even more disturbingly around 3.3 in its current 
wording, but that's a subject for another post.)

Questions:
What specific disabilities are we trying to address with 3.4? For 
instance, is a native Russian speaker with limited knowledge of 
English considered disabled? Do screen readers and talking browsers 
give insufficient assistance to people affected by dyslexia or 
illiteracy? Are we mainly looking at a group of cognitive 
disabilities that prevent people from processing and understanding 
language, be it written or spoken? Or are we attempting in all of 
Guideline 3 to move beyond disability and device and address general 
principles of usability and effective communication? Forgive me, I'm 
sure you've covered these questions ad nauseam before I started 
reading the archives. However, if the intent of the guideline is not 
clear to someone (like me) who has not been part of the discussion 
for the previous two years, then that's a sign that the guideline, as 
currently written, isn't clear enough. (In this regard, a pair of 
relatively new eyes can be useful.)

Practical concerns:
I would add, as a sighted person and an erstwhile designer, that the 
prospect of the ghastly clip-art, inappropriate illustrations, 
bloated graphics, fractured layouts, and incomprehensible, pixellated 
eyesores that this requirement might unleash on the web makes me want 
to curl up under my desk and weep. Creating meaningful illustrations 
(not to mention sounds and other multimedia) that are optimized for 
the web requires specialized skills and, in most cases, expensive 
software. People without access to these resources who attempt to 
conform to 3.4 will in many cases produce pages that are bloated, 
broken, or inaccessible to many or all users. Now, before anyone 
jumps on me and says I am putting the needs of web authors ahead of 
the needs of learning-disabled children, I'm not. I do think the 
practical issues of implementation, consequences, and possible net 
effects deserve more discussion and thought, however. That is one 
reason I suggested that proponents of 3.4 take a pass at illustrating 
the guidelines with non-text content, as a useful exercise. By 
insisting on non-text supplements (I will not say "equivalents," 
because that's inaccurate) for most or all text content, are we 
formulating a guideline that only professional designers, and not 
amateur web authors, can really be expected to conform to?  And if 
so, are we comfortable with that?

I concur with Matt and Kynn here [1] that the checkpoint structure 
may be hindering our ability to communicate good rules-of-thumb and 
principles. We all agree that illustrating concepts where possible is 
a good practice to be encouraged.

Note:
While I was writing this, a message came in from Charles pointing to 
a page in which he had taken a stab at illustrating the guidelines. 
First of all, Charles, thank you for undertaking this task. You have 
a lovely voice and can record sound files for me any time! 
Unfortunately I did have some end-user problems with the non-text 
content on several of my browsers. A report follows if you're 
interested.

Report: My first attempt to load the page froze my browser (IE 5.0 
Mac) and crashed my iBook. After rebooting, I visited the page in 
Opera and was able to see the image and hear the sound. Then I 
visited again in IE Mac and got no crash, but no image either 
(normally I can view .pngs inline). Neither IE Mac nor Netscape Mac 
displayed the image or the fallback link to the image. In IE for 
Windows, I saw the image inline but got a plugin error message 
presumably related to the sound file. Netscape/Windows failed to 
display the sound file's icon properly and gave a plug-in error as 
well, but it did provide the correct link to view the image on a 
separate page. So I am no longer in danger of wandering into the 
men's area of the mosque.

[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/0317.html
--
Jo Miller
jo@bendingline.com

Received on Wednesday, 1 August 2001 15:01:56 UTC