- From: Andi Snow-Weaver <andisnow@us.ibm.com>
- Date: Tue, 29 Oct 2002 17:41:09 -0600
- To: w3c-wai-gl@w3.org
- Cc: "Phill Jenkins" <pjenkins@us.ibm.com>
Here are the IBM comments on the WCAG 2.0 Public Draft, dated 22 August
2002.
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
meat - the Table of contents of the recommendation.
Checkpoint 1.1
Minimum success criteria
- There should not be a success criteria for non-text content that
"cannot be expressed in words". Checkpoint 1.1 begins with the phrase
"For all non-text content that CAN be expressed in words". Worded
this way, the checkpoint does not apply to "non-text content that
canNOT be expressed in words".
- the sub-bullet under item 2 seems to belong with item 1. Item 2
states that non-text content that cannot be expressed in words should
have a descriptive label as its text equivalent. The sub-bullet goes
on to say that the text equivalent should fulfill the same function,
present all the intended information, and achieve the same function
as the non-text content. How is this possible if the non-text content
cannot be expressed in words in the first place.
Level 2 success criteria
- this criteria should be moved to Level 3.
Definition of Non-text content
- The focus of this checkpoint should be about the content, not the
method delivered. Applets and "programmatic objects" should be
removed from the definition of non-text content because they are the
delivery method and are covered in checkpoint 5.4. If applets or
programmatic objects "deliver" non-text content such as graphics,
audio, or video, then that non-text content should have a text
equivalent - transcripts for audio, captions and descriptions for
video, etc. Scripts should also be removed because they deliver
content. The content delivered is what needs to be part of the
success criteria no matter how it is delivered.
Checkpoint 1.2
Level 2 success criteria
- item #1 should be moved to Level 3
- Item 3 ends with the phrase "... view only the captions, the
captions with the audio, or both together." "Both together" is the
same as "the captions with the audio". It should be: "only the
captions, only the audio, or both together".
Benefits
- The Note ends with a sentence that sounds like a success criteria:
"Where possible, provide content so that it does not require dual,
simultaneous attention or so that it gives the user the ability to
effectively control/pause different media signals."
Checkpoint 1.4
Minimum success criteria
- Both items include the phrase "seriously interfere". This is very
subjective. It sounds like rationale, not success criteria.
- The requirement at this level should be that the author should
implement the content using methods that allow the user to turn off
the background image or turn off background audio.
Level 2 success criteria
- there should be no criteria at this level. These should be moved to
level 3.
- A simulator for "major types of color blindness" is a testing tool,
not a success criteria. The guidelines should specify the exact
criteria to be met similar to the one defined in level 3 for
background sounds in audio content.. A simulator may exist or may be
developed that automates the process of evaluating against the
success criteria but but the tool itself should not be the success
criteria.
Level 3 success criteria
- the criteria at this level should result in a choice of either you
don't have background images/audio or your images/audio meet criteria
that are not a problem (pass color blind criteria, background sounds
at least 20 db lower than foreground content, etc.)
- for the audio criteria, is there a time consideration here? For
example, if the background sound is not 20 db lower than the
foreground content but it only lasts for a second, is that a problem?
Checkpoint 1.5
We believe the levels of success criteria for this checkpoint should
fall along the lines of 1 - the content is encoded properly, 2 - the
language of the page is identified, 3 - you expand on abbreviations,
acronyms, passages that need more explanation. In this scheme,
Level 1 is okay
Level 2 success criteria should be moved to Level 3
Level 3 success criteria should be moved to Level 2
However, 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 U.M.L. instead of "voiceuml"? How the acronym
is pronounced should be part of aural cascading style sheets, which
is not well defined in this scenario.
Checkpoint 2.1
Definitions
- The Character input definition refers to a character set called the
W3C Character Model. Are the tab and arrow keys part of this
character set?
- Need to link to where this character model is defined.
Checkpoint 2.2
Minimum success criteria
- we should not provide success criteria for scenarios that are
excluded by the checkpoint itself
- Item 1d concerns time limits that are due to real-time events.
The checkpoint excludes these types of time limits with the phrase
"...unless control is not possible due to the nature of real-time
events"
- Item 1e concerns time limits that are part of competitive
activity. The checkpoint excludes these types of time limits with
the phrase "... unless control is not possible due to the nature
of .... competition".
Checkpoint 2.3
Minimum success criteria
- Since all success criteria must be testable, and item 1b implies
that 1a cannot be tested, item 1a should not be included as a success
criteria.
- Also, what is the rationale for specifying the range between 3 and
49? Section 508 specifies a range between 2 and 55. We don't know the
rationale for that either but do we have specific reasons for making
WCAG different?
Level 2 success criteria
- Items # 1 and # 2 should be moved to Level 3.
Checkpoint 3.1
Level 2 success criteria
- probably not possible to determine whether you have done what is
"possible". May be okay to do what you think is "appropriate". This
criteria is very subjective, however.
- this criteria should be moved to Level 3.
Level 3 success criteria
- item # 2 on diagram is just repeating the checkpoint. What is the
criteria that makes a diagram have structure? reading order?
Checkpoint 3.3
Minimum success criteria
- Item 1 would be clearer if we said "three or more layers" instead
of "more than two layers"
Checkpoint 3.4
Level 2 success criteria
- this criteria should be moved to Level 3.
Checkpoint 3.5
Level 2 success criteria
- this criteria should be moved to Level 3.
Definitions
- Under the mechanisms that cause 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 guideline is that there should be a
caption or visual cue so that the user understands it.
Benefits
- the user agent knows when it is opening a new window and can inform
the user. HPR does this. IE can be configured to do it. The author
should only be required to code it correctly.
- The "Note" seems like a further elaboration of the first benefit
bullet. It should be incorporated into that bullet.
Examples
- Example 3 is an example of NOT meeting the checkpoint. It should be
removed or reworked to be an example of meeting the checkpoint.
Checkpoint 3.6
Graceful recovery should be removed from the checkpoint or defined in
the definitions section.
Level 2 success criteria
- this criteria should be moved to Level 3.
Level 3 success criteria
- Item 4b ends with the phrase "in advance". In advance of what?
- It seems like some of these criteria are error prevention and
recovery methods that would have to be used in order to claim success
criteria at Level 2.
Checkpoint 4.1
Partial list of items being explored
- In Item 10, find a better example than "haven't seen you in a
coon's age"
There is a lot of work going on in the working group attempting to
define objective criteria for this checkpoint. It seems that the working
group has been wrestling with this for a long time. Perhaps it is time
to set a deadline for completing this. If the working group cannot reach
consensus on objective success criteria by the end of the deadline, this
checkpoint should be removed or moved to an informative section.
Checkpoint 4.2
As for Checkpoint 4.1 above, we recommend that the working group set a
deadline for developing objective success criteria for this checkpoint.
If the working group cannot reach consensus on objective success
criteria by the end of the deadline, this checkpoint should be removed
or moved to an informative section.
The definition of non-text content does not fit what we mean by non-text
content in this checkpoint. It makes it sound like we are recommending
that people supplement text with ASCII art, for example. Do we really
mean illustrations here? We used that term in the informative note on
this checkpoint.
We need more rationale here as to why adding non-text content to text is
a good idea.
Checkpoint 4.3
Minimum success criteria
- Item 1 says acronyms and abbreviations should be defined the first
time they appear. Does this mean the first time they appear on a page
or on a site?
Checkpoint 5.1
Minimum success criteria
- items #2 and #3 are not needed here. Checkpoint 5.4 covers
programmatic interfaces.
- minimum success criteria - what does it mean in item 3 to use
accessibility features if available? If accessibility features are
not available, can I use the technology or not?
- in answer to the question asking if protocols are relavant to this
checkpoint, yes "protocols" are relevant and should be included.
Examples
- In Example 2, "Java program" should be "Java applet"
Checkpoint 5.2
Minimum success criteria
- Item 2 needs to be clarified. If I declare that scripts and style
sheets are part of my baseline, are they above it or below it?
Perhaps this can be clarified by expanding the example.
- the term "technology" needs to be defined along with adding and
defining "platform"
- does the baseline include platform, language? i.e. what are the
user agent requirements that need to be documented? could be useful
in documenting the "configuration" that is accessible
- the success criteria really have nothing to do with designing for
backward compatibility
- Level 1 is "declaring" your configuration.
- Level 2 is testing your baseline.
- Level 3 is that it works in a text only browser.
Checkpoint 5.3
This is an important consideration but should not be a checkpoint. If
you meet all the checkpoints, then you have obviously done this. If you
haven't, then what difference does this make?
Checkpoint 5.4
This checkpoint is about making the user interface operable and would be
better organized as part of guideline 2.
Glossary
1. 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" are
part of the common glossary for all WAI documents.
Andi
andisnow@us.ibm.com
IBM Accessibility Center
(512) 838-9903, http://www.ibm.com/able
Internal Tie Line 678-9903, http://w3.austin.ibm.com/~snsinfo
Received on Tuesday, 29 October 2002 18:39:59 UTC