Re: My comments on WCAG 2.0 proposed draft

Aries,

The public comments list is not ignored. We use mail sent to that list to 
construct our issues list.  For example, here is one of your comments as it 
appears in bugzilla: http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=590

However, it is taking us a while to process comments and close issues.
--wendy

At 02:04 PM 12/9/2003, Arditi, Aries wrote:
>Hi all,
>
>Wendy Chisholm and Judy Brewer asked me to comment on this months ago, and 
>I posted it to the site they asked me to post it at.  Recently, someone 
>more savvy in the functioning of the WAI lists informed me that the list 
>is totally ignored.  So here, I repost it, in the hopes that it might be 
>helpful to someone, somewhere, some day....
>
>Aries Arditi
>Senior Fellow in Vision Science
>Lighthouse International
>
>Original Post:
>
>With respect to the June 24 WCAG 2.0 draft, I have a number of comments,
>detailed below.  First, however, I would like to congratulate the authors
>for taking on such a difficult task.  In particular, I'm delighted that the
>group is intending to broaden the scope of the guidelines to address a
>broader set of technologies.  To the extent that this broadening succeeds,
>its influence can go well beyond that of web content and authoring, and
>potentially guide the efforts of developers of assistive technology as well.
>
>
>Having said that, I believe also that the guidelines are in general less
>comprehensible (indeed, less accessible!) to the intended readership than
>were the version 1.0 guidelines, and that the lack of comprehensibility
>stems from the very abstraction of principles that was necessary for
>broadening to other technologies.  I believe these problems can be addressed
>and alleviated through the planned technology-specific checklists,
>especially if the checkpoints in the WCAG are cross referenced to technology
>specific guidelines. Apart from a few exceptions, I don't believe, however,
>that making the guidelines significantly easier to understand can be
>accomplished by simple rewriting.  Like a mathematics text in which axioms
>and theorems provide the foundation, and examples and problems the practical
>understanding, this may be a necessarily abstract document.
>
>The conformance structure of Core and Extended is fine, both easy to
>understand and potentially effective, provided more objective and
>quantitative methods of evaluating specific conformance to checkpoints can
>be developed.  But conformance to specific checkpoints is best evaluated in
>the context of specific technologies, where specific items are less open to
>braod interpretation.  Without technology specific checkpoints, I would
>imagine that squabbling and bickering over conformance will increase, and
>with more latitude to interpret the guidelines as they see fit, developers
>could claim more for less actual conformance.  So I would favor keeping the
>general structure of the draft as a kind of umbrella document, but
>instantiate the conformance checkpoints with technology-specific
>checkpoints.  Since the planned technology-specific checklists were not
>included in this draft, it's difficult to evaluate the conformance
>structure.  However, in theory, the structure seems fine to me.
>
>Developers at my organization do use the 1.0 WCAG, but much of their use is
>indirect---via automated tools to evaluate conformance.  Because web sites
>can be huge and dynamic, reliance on such tools is at least partially
>inevitable.  However, to the extent that the current document is even less
>specific than v1.0, I would see migration being difficult. Without
>technology-specific checklists, it is easy to imagine developers of
>evaluation and repair tools with widely disparate views of what constitutes
>conformance.  Again, I would prefer to view this draft as an umbrella
>document with more specifics to be incorporated as an essential component of
>the 2.0 WCAG recommendation.
>
>Here are some other specific comments, nearly all pertaining to Guidelines 1
>and 2:
>
>1. I didn't understand the designation of examples and benefits as
>"non-normative"  or "informative."  Are these terms lingo, or am I just
>being thick (or both)?
>
>2. Overview of Design Principles, last para before Note:
>
>This would better read, "Accessible web content can benefit people with as
>well as without disabilities." Accessible web content does not ALWAYS
>benefit people other than the disabled. High levels of magnification, for
>example, which can make things more accessible to people with low vision,
>can make documents more difficult to navigate.
>
>Delete next 2 sentences, which are superfluous since examples of accessible
>web content benefiting others is subsequently given (and giving wheelchair
>examples to the reader is tiresome---readers of the WCAG can, nearly 14
>years after the ADA, be assumed to understand general things about
>disabilities without being prompted to conjure up images of wheelchairs).
>
>3. User needs, first bullet:
>
>Change "via sound" to "visually."
>
>4. Definitions for checkpoint 1.1: text equivalent
>
>This is not a definition.  I would first define "text" as code representing
>written language, that is a one-to-one mapping of alphabetic and numeric
>symbols.  Then define "text-equivalent" as text that serves to communicate
>substantially equivalent content as another representation such as an image.
>
>5. Benefits of checkpoint 1.1, first bullet:
>
>add ", or otherwise transformed to different presentation format (e.g. font,
>text size)
>
>6. Checkpoint 1.5
>
>I believe that the benefit of adding structure to the document is that it
>allows assistive technologies more information about the document in order
>to tailor its presentation to the user's capabilities.  This checkpoint, as
>written, however, seems to focus on how document elements are rendered.  For
>example, the (sole) required success criterion refers to visual appearance
>or auditory characteristic.  The examples also are about how to render.
>That's not a WCAG issue, in my view.
>
>Also, who (or what) could judge whether structure "has been made perceivable
>to more people..."?  Compared to what? This is way too vague.
>
>7. Editorial Note (22 May 2003) regarding "additional items in 4/29 draft
>
>Yes, in my opinion, these should be moved to techniques.
>
>8.  Checkpoint 1.6
>
>This is very vaguely worded.  I would propose instead the following
>language:  "Where possible, use layered designs to allow selective
>presentation or blanking of visual or auditory elements, comprising, for
>example, foreground and background content."
>
>The sole success criterion for 1.6 is in terms only of visually imagery.  I
>would refer to layered auditory images, such as background music with a
>voice-over, to allow hearing-impaired user to remove the background music
>for greater clarity.
>
>Under best practice for 1.6 #1 and #2, what does "easily readable" mean?
>And to whom? This is not quantifiable.
>
>Also, who came up with the 20 dB (or 4 X louder) foreground/background audio
>figure?  Are there any data to back this up as being sufficient?
>
>It's true that there are no effective tests for visibility or readability
>that do not rely on standard human observers in terms of color or color
>contrast (the claims of some notwitstanding). The reasons for this include
>the fact that display devices and hardware used to drive them vary widely in
>peak luminance, color gamut, and linearity; viewing conditions of observers
>vary widely (ambient room lighting, presence of reflections from nearby
>windows, etc.); readability and visual discriminability also depend
>critically on the kinds of stimuli used.  A very low contrast text in a huge
>font may be as or more readable than a smaller font in very high contrast.
>Typography and image characteristics also go into the mix of important
>factors.  And let us not leave out the enormous variability in visual
>capacity of the visually-impaired population, some of whom will settle for
>no less than the blackest black against the whitest white. The long and
>short of it is that we simply do not have in the foreseeable future a good
>way to evaluate objectively things like accessibility of text contrast
>and/or color.  This is thus an issue in which, I believe, the best we can do
>(and thus the most we should do) is to suggest principles to follow to
>enhance accessibility.
>
>9. Examples of checkpoint 1.6 first bullet:
>
>What are the "standard foreground/background contrast requirements"? If
>there are any, please clarify (and cite).
>
>10. Required success criteria for checkpoint 2.2 #1:
>
>I would add the following bullet: "* or the user can control the
>presentation by eliciting phases sequentially via keystrokes."
>
>11. Checkpoint 2.3
>
>I would be very surprised if anyone could devise a substantive and effective
>test for flicker in machine readable format.  Here are some thought
>experiments:
>
>Consider a single pixel flickering in the 3-49Hz range on your screen right
>now.  Do you think you could detect it?  If so, do you think it could
>possibly cause a seizure in someone with photosensitive epilepsy?  You do?
>How about if that single pixel flickered by changing its intensity 1/256? or
>1/(256^3)?
>Still think so?
>
>How many phases (i.e. alternations) of light and dark constitute flicker in
>the 3-49 Hz range? What if I present a black dot for 1.5 seconds, then
>replace it by a white dot for 1.5 seconds?  Would you call that 3 Hz
>flicker?  In other words, how many "cycles" of the pattern do you require
>before you call it flicker?
>
>Here's a third: Mathematically the sum of leftward moving and rightword
>sinusoidal gratings is equal to a single stationary sinusoidal grating whose
>bars reverse in contrast.  Any single point in that pattern will flicker. Do
>we call that flicker or moving gratings?  Were we to analyze many moving
>patterns we would find that we could describe them mathematically in terms
>of flickering components. What if we have a video taken from a moving car or
>train that passes by a picket fence.  Will not there be some flicker in that
>video? Shall we ban all animations in the WCAG?
>
>It is likely that scientists will some day be able to better zero in on the
>specific visual causes of photosensitive epileptic seizures; presumably high
>contrast large field flicker poses a greater risk than do low contrast
>flickering single pixels.
>
>Until we know more, or until qualified experts on this condition weigh in,
>or credible scientific evidence is presented that better specifies the
>parameters of the flicker, I believe this checkpoint should be deleted.
>
>Thank you for the opportunity to comment on this draft.
>
>Aries Arditi, Ph.D.
>Senior Fellow in Vision Science
>Arlene R. Gordon Research Institute
>Lighthouse International
>111 East 59th Street
>New York, NY 10022
>
>Tel: +1 212 821 9500 (direct)
>Fax: +1 212 751 9667
><http://www.lighthouse.org/research_staff_arditi.htm>http://www.lighthouse.org/research_staff_arditi.htm
>
>
>**************************************************************************************************
>The contents of this email and any attachments are confidential.
>It is intended for the named recipient(s) only.
>If you have received this email in error please notify the system manager 
>or  the
>sender immediately and do not disclose the contents to anyone or make copies.
>
>** eSafe scanned this email for viruses, vandals and malicious content **
>**************************************************************************************************

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--

Received on Tuesday, 9 December 2003 14:30:17 UTC