IBM comments on 11 March 2004 public draft

Here are the IBM comments on the 11 March 2004 public draft of WCAG 2.0

Front matter - add the following links in the section where the links to
"this version", "latest version", and "previous version" are.
   - Errata: The Comm Team policy is now that errata and translations links
   must appear in at least the head of the document.
   [1] Example of errata & translations in top matter of W3C spec
   http://www.w3.org/TR/P3P/

   - Related Documents: There needs to be a link to a related documents
   "page", that can change so as WAI documents are added or rearranged, you
   have a place to go to find out how they are related.  As techniques,
   checklist format versions, and other guidelines documents are added,
   this "related docs" page could sort them all out and present them is a
   logical manner and not depend on the reader to have to read and gather
   bits and pieces along the way from each WAI recommendation to construct
   the organization and relationships.

   - Table of Contents: A link on the top of the page that "skips over" all
   the top matter and gets to the table of contents is needed.  Everyone is
   equally hindered by having to page down and tab forever to get to the
   main content which begins with the Table of contents of the
   recommendation.

Introduction, Purpose, 1st paragraph - Remove the sentences about
accessibility to a variety of Web-enabled devices. This is a benefit of
accessibility but it should not be discussed in the first paragraph of the
document. It can be covered later or left to EO to promote.

Guideline 1.1, Benefits - the first bullet implies that providing text
equivalents helps people who have trouble reading text. This is not
applicable to this guideline which is about providing access to "non-text"
content. People who have trouble reading "text" are not the people who have
trouble with "non-text" content.

Guideline 1.1, Example 1 - How the screen reader identifies links is
irrelavant to this example which is about providing alt text. Rewording
propsal: "An image of a right pointing arrow is used to link to the next
slide in a slide show. The text equivalent is "Next slide". When screen
reader users hear this as a link, they should understand that this link
advances to the next slide in the slide show."

Guideline 1.2, Level 1 success criteria - Ordering and rewording
suggestions

   1. (previously # 2) Synchronized captions are provided for all
   significant dialogue and sounds (no need to specify "in time-dependent
   material". This guideline only applies to time-dependent material.)

   2. (previously # 1) In audio-visual media, synchronized audio
   descriptions of visual events that are not evident from the audio are
   provided.

   3. Remove. Points 1 and 2 above should specify "synchronized" because
   the guideline itself specifies "synchronized". The exception is not
   needed because if the content is audio only and not time sensitive, it
   does not meet the definition of time-dependent and this guideline does
   not apply to it.

   4. What is the need for a specific success criteria addressing realtime
   video with audio? Success criteria above already require captions
   whether it is realtime or not. Are we trying to say audio descriptions
   for visual events are NOT required for real time video with audio? If
   so, then the audio description success criteria can be reworded as "In
   audio-visual media that is not realtime, synchronized audio descriptions
   of visual events that are not evident from the audio are provided."

   5. Either remove this success criteria or change the definition of
   time-dependent presentation in the glossary. Web content that is
   non-interactive video only does not meet the current definition of
   time-dependent presentation.

Guideline 1.2, Level 2 success criteria - The Level 1 success criteria
already require synchronized captions for real-time audio with video. What
is the additional requirement here? The editorial note does not seem to
apply to anything at this level. The note is talking about audio
descriptions but the success criteria is about captions.

Guideline 1.2, Benefits - There is a Note in the informative section that
has hidden success criteria in it. ("Where possible (especially for
education and training materials), provide content so that it does not
require tracking multiple simultaneous events with the same sense, or, give
the user the ability to freeze the video so that captions can be read
without missing the video.") This should either be removed or made into a
Level 3 success criteria.

Guideline 1.2, Examples - Example 3 is a different version of Example 3
under guideline 1.1.

Guideline 1.3, Level 1 success criteria - as currently written, simple text
files would not conform to WCAG 2.0 even though they might be quite
accessible. The level 1 success criteria should be limited to those things
which, if not identified semantically, really do create a barrier to
accessing the Web site. Two things that definitely require semantic
information are tables and labels for form controls. There may be others
but paragraphs, headings, lists, and emphasis should not be required at
Level 1. These should be Level 2 requirements.

Guideline 1.3, Benefits, last bullet - need to describe how this guideline
benefits people with cognitive, physical, hearing, and visual disabilities.

Guideline 1.4, Level 1 success criteria, note - rewording suggestion:
"Images of text that meets guideline 1.1 should satisfy this criterion."

Guideline 1.5 - the Level 3 success criteria address background sounds in
an "auditory presentation" but we have no success criteria that address
background audio of a Web site; that is, a Web site that plays music or
some other type of audio as background to the visual presentation. Screen
reader users will have a very hard time listening to the page while the
background audio is playing. Shouldn't there be a requirement that this
type of audio can be disabled by the user? I think it might actually belong
under guideline 1.3. The background audio is part of the presentation and
it should be separable from the information, functionality, and structure.
Proposal for Level 1 success criteria: "Users can disable background audio
that automatically plays when a Web site is accessed."

Guideline 2.1, example 2, second unnumbered list item - the Web content
should be operable via the keys on the cell phone keypad, regardless of
whether or not the cell phone supports the attachment of an optional
keyboard. A better example here might be a PDA device that is usually
operated via a stylus but has an optional keyboard that can be attached.
The Web content should be operable using the attached keyboard. In this
example and all of the others listed under Example 2, it is ambiguous what
the content author's responsibility is here. For example, a Palm Pilot
supports an attached keyboard but I think the Palm OS only supports data
entry via the keyboard, not navigation. If the Palm OS and browser don't
support navigation via the optional keyboard, it is impossible for the
content author to provide this function. These examples should either be
clarified as to the content author's responsibility or removed altogether.

Guideline 2.2 - is "time limits on their reading" meant to include server
timeouts? In general, server administrators, not content authors, control
server timeouts. Propose rewording this guideline as "Allow users to
control time limits on reading or interaction that are part of the
functionality of the content unless specific real-time events or rules of
competition make such control impossible."

Guideline 2.2, Level 1 success criteria - we should not provide success
criteria for scenarios that are excluded by the Guideline itself. The
fourth and fifth sub-bullets concern time limits that are due to real-time
events or competition. The Guideline excludes these types of time limits
with the phrase "...unless specific real-time events or rules of
competition make such control impossible."

Guideline 2.2, Benefits - Benefits are written as issues instead of
benefits. Proposed rewording of first benefit: "People with reading
disabilities, cognitive disabilities, and learning disabilities who may
need more time to read and comprehend written text will be given additional
time to read the information."  Proposed rewording of 2nd bullet: "People
with physical disabilities can have sufficient time to process and read
information before it is refreshed."

Guideline 2.2, Examples of content that must meet the success criteria,
last sub-bullet - "shutdown or deactivation of a resource if activity is
not received in a set amount of time" sounds like server timeouts which are
not under the control of the content. Remove or reword.

Guideline 2.3, Level 1 success criteria - not only should the content be
marked, there should be a way for the user to avoid seeing it. Proposed
rewording: "Content that violates General Flash Threshold or Red Flash
Threshold is identitified prior to its appearance in a way that allows the
user to suppress its appearance."

Guideline 2.3, Level 1, 2, and 3 success critera - Threshold definitions
should be moved to the glossary terms and the success criteria should link
to the glossary.

Guideline 2.4, Level 2 success criteria - # 1 and # 2 are very document
centric and will be difficult or impossible for Web applications to
implement. For example, a table of contents implies that the user can
access all content in any order. In Web applications, it is not always
possible to access all function in any order.

Guideline 2.4, Level 3 success criteria # 4, sub-bullet e - Remove. This is
already covered by guideline 1.3, Level 1b

Guideline 2.4, Benefits, first bullet, first sub-bullet & third sub-bullet
- since the function described is currently only possible with assistive
technology, suggest combining these two bullets and rewording as:
"Assistive technology used by people with physical and vision disabilities
can provide users with the ability to jump from header to header to get an
overview or to more quickly "skim" to the section they are interested in."

Guideline 3.1 - what if a particular technology doesn't support the
requirements defined in the success criteria? For example, if PDF doesn't
have a way to identify abbreviations and acronyms programmatically, does
that mean it is impossible for a PDF document that contains abbreviations
or acronyms to conform to WCAG Level 1?

Guideline 3.1, Level 1 success criteria, # 2 - The real problem with
acronyms and abbreviations is how the speech synthesizers speak the
acronym, not so much how it is expanded.  A subcommittee/WG needs to be
established to identify the various scenarios and apply some logic as to
what the author should do, what the AT/browser should do, what the
synthesizer should do, and what the user should do.  For example, the
author can expand the acronym VoiceXML to "voice extendable markup
language", and the user can choose to expand to hear the full expansion,
but how does the user get to hear Voice X.M.L. instead of "voiceexmuhl"?
How the acronym is pronounced should be part of aural cascading style
sheets, which is not well defined in this scenario.

Guideline 3.1, Level 3 success criteria, # 4 - The Strategies for Reducing
the Complexity of Content is a very large section that is disruptive to the
reading of the document. These should be moved to an appendix with a link
from the success criteria to the appendix.

Guideline 3.1, Level 3 success criteria, Strategies for Reducing the
Complexity of Content, Alternative representations, second sub-bullet - The
definition of non-text content provided in the glossary includes "text in
images" and "ASCII art". I don't think that is what we are recommending
here. We should just specify the types of non-text content we are
recommending. Proposal: images, animations, audio, video, multimedia

Guideline 3.1, Benefits, first sub-bullet - "When editing content,
authoring tools can switch between appropriate spelling dictionaries"
should be removed. WCAG 2.0 is about making content accessible to people
with disabilities. It's not about ease of authoring.

Guideline 3.1, Benefits, second and third sub-bullets - these do not
explain how this requirement helps people with disabilities. It should
either be reworded or removed. I'm not an expert on this but I suspect that
the problem for people with cognitive disabilities is not that they are not
familiar with a particular abbreviation or acronym but that even if they
know what it is, they somehow can't understand it when they see it written.

Guideline 3.2, Level 1 success criteria - "extreme change of context" is
not really defined in the glossary. There are simply 3 examples provided.
In the first example, "opening a new browser window", I am not familar with
any way that an author could do this that would not be programmatically
identified. In the last two examples, identifiy speaker changes in an
auditory presentation and in captions, I don't know of any way in which to
do this where it could be programmatically identified. So, of the 3
examples provided, one is always conforming and the other two can never
conform.

Guideline 3.2, Level 2 success criteria, # 1 - would navigation bars that
expand to display sub-topics conform to this requirement?

Guideline 3.2, Level 2 success criteria, # 5 - The user agent, not the
content author, should be responsible for warning of extreme changes in
context before they happen. When user agents implement the function, the
user gets the benefit on all sites, not just on sites where the author has
implemented the feature.

Guideline 3.2, Benefits, second bullet, second sub-bullet - using captions
to note changes in speaker can't be programmatically identified.

Guideline 3.2, Example 3 - this is an example of NOT meeting the
checkpoint. Proposed rewording: "Frames are included in the page history so
that the browser's Back button can be used to return to a previous frame."

Guideline 4.1, Example 3 - this example seems more appropriate now for
guideline 4.2.

Guideline 4.2, Level 1 success criteria, # 2 - "If the custom user
interfaces" should be reworded "If the programmatic user interfaces" for
consistency with the first sentence.

Guideline 4.2, Level 2 success criteria - this seems too undefined to be a
success criteria. For example, guideline 2.1 requires the functionality of
the content to simply be operable via a keyboard. Would this success
criteria require that access keys always be defined on HTML Web sites since
they are an accessibility feature of HTML? Another example is that of
guideline 3.1, level 2 success criteria, # 4 which requires that all
foreign language passages or phrases be identified. 3.1 L2 #4 clearly does
not require individual foreign words to be identified but would 4.2 L2 #1
require this simply because HTML allows individual words to have the "lang"
attribute?

Glossary - The "Glossary of terms" should not be part of the
recommendation, but kept in a separate doc such as the techniques.  The
"common WAI glossary" just needs to include the definitions that the WG
proposes.  The process is key here, that the terms be considered as part of
the WCAG recommendation up to the "proposed recommendation" step, where the
terms and definitions are "removed" from the recommendation and "ensured"
as part of the common glossary for all WAI documents.

Glossary, "extreme changes in context" - the first bullet should read
simply "opening a new browser window". That is the definition of an extreme
change in context whether it is expected or not. Our guideline is that this
change should be done in a predictable way so that it is not unexpected.
The second bullet should simply read "a change of speaker in an auditory
presentation". Again, that is the definition of the extreme change in
context. The advice to provide a caption or visual cue so that the user
understands it is the success criteria. Also, it is unclear how the "common
user actions" and "common responses to user actions" relate to the
definition of "extreme changes in context".

Andi
andisnow@us.ibm.com
IBM Accessibility Center
http://www.ibm.com/able

Received on Tuesday, 25 May 2004 13:04:40 UTC