Request for Review: WCAG 2.0 Working Draft

Here are my responses to your three formal questions, plus a few "other
issues" at the end...

***Question 1.  In general, is this WCAG 2.0 Working Draft easy to
understand?  Please identify sections or phrases that are difficult to
understand.  Please suggest alternative wording for us to consider.

Answer 1a. I agree in principle with creating a technology-neutral WCAG
2.0, i.e., not HTML-specific. In doing so, however, I think it's also
important that the guidelines and checkpoints in and of themselves be
meaningful, without necessarily referring to the techniques documents or
even to the success criteria. I suspect that it will not be uncommon for
the checkpoints to be cited apart from their context in the WCAG 2.0
document, and many end users will refer to these abridged documents. Or,
many users will refer to the actual WCAG 2.0, but as busy people they
will only skim the guidelines and checkpoints, not read all the detail.
Maybe a usability test is in order: present target users with the
checkpoints out of context, and assess whether they understand them.  

Answer 1b. Specific comments regarding vague checkpoint language from my
perspective: 

 - Checkpoint 1.5,"Provide information needed for unambiguous decoding
of the characters and words in the document". I had a difficult time
decoding this checkpoint into something unambiguous. Without reading
success criteria, I never would have guessed that this checkpoint refers
to natural language. Perhaps the solution is to mention some of the
specifics (e.g., natural language, abbreviations and acronyms, etc.)
within the language of the actual checkpoint.  

 - Checkpoint 2.1, "Ensure that all of the functionality of the content
is operable through character input to the content or user agent." Maybe
what confuses me here is the prepositional phrase on the end. Is it
necessary? What else would a user be providing character input into
other than the content, user agent, or both?  As I think about it
though, I'm confused by this entire checkpoint. Is this not placing an
emphasis on character-accessibility over mouse accessibility? Why not
"device-independence"? 

 - Checkpoint 3.1, "Provide structure within content". I'm having a hard
time envisioning a document that has no structure. Do you mean
"appropriate structure", "proper structure", "specification-supported
structure", or something else entirely?  

 - Checkpoint 5.4 "Ensure that user interfaces are accessible or provide
an accessible alternative". All content has a user interface, which
makes this checkpoint redundant. Should be "custom user interface". 
   
Answer 1c. As a normative document, the WCAG 2.0 should restrict itself
to normative content. Definitions, Benefits, and Examples sections, if
informative rather than normative should be extracted from this document
and referenced via hyperlink. As is, there is too much
informative/clarifying content within each guidelines' definition - It's
difficult to appreciate the document's structure. 

Answer 1d. There are some simple language issues that I think make WCAG
2.0 difficult to read currently.

  - Ambiguous use of terms that have multiple meanings
The only example of this is the use of "form" in Guideline 1: 
"Ensure that all intended function and information can be presented in
form(s) that can be perceived... " Since "form(s)" has a specific
technological meaning, a suitable replacement word should be used here.
Possible alternatives: 
"...presented in ways that can be perceived..." 
"...presented such that they can be perceived..."

   - Use a language style that is consistent between WCAG 1.0 and 2.0.
In 1.0, checkpoints were stated as imperatives, which I think is more
direct language, and easier to read. Users will commonly be consulting
WCAG 2.0 as a "how to" document, so expressing particularly the success
criteria using "how to" language will match users' expectations. For
example: 

Rather than...
"You will have successfully met Checkpoint 1.5 at the Minimum Level if: 
 1. text in the content is provided in Unicode or sufficient information
is provided so that it will be automatically mapped back to Unicode."

Use...
"To meet Checkpoint 1.5 at the Minimum Level:
 1. Provide content text in Unicode or provide sufficient information so
that it will be automatically mapped back to Unicode." 

  - Check subject-verb agreement. I don't think this is a common
problem, but Checkpoint 5.3, minimum success criteria #1 has as subject
"the technology or combination of technologies", which is a singular
subject, so items 1(a) through 1(e) should reflect this, i.e., use
"supports device independence" rather than "support device
independence". 
 

***Question 2.  The priority structure of this WCAG 2.0 Working Draft
differs from WCAG 1.0.   Is this structure easy to understand?  Would it
be effective?

Answer 2a. Many web content developers and policy makers are looking for
a binary set of guidelines - either it's accessible, or it isn't. The
WCAG 1.0 priority structure led to much confusion as users tried to
grapple with whether "accessible" meant Priority 1, 2 or 3. The Access
Board, when questioned as to which of their standards is most important,
consistently assumes the position that "all are equal". Given the
current working draft, I think WCAG 2.0 could possibly attain a binary
set of success criteria. 

Of the 21 checkpoints, only 15 have any Level 2 success criteria, and of
these, eight are simply "statements of conformity" (see answer 2b). Only
nine checkpoints have Level 3 success criteria, and only five have any
content under the "additional ideas" heading. 

Arguments against a priority structure: 
 - Confuses the audience: Many Web content developers and policy makers
want a binary set of guidelines
 - Too many unfilled holes. All of this missing data makes the document
appear to be incomplete. 
 - Too subjective. I personally think Level 3 and some of the
"additional ideas" under both Checkpoints 3.1 and 3.2 should be minimum
standards. Others will probably feel similarly about other standards. 

Answer 2b. Many of the Level 2 success criteria call for the site having
a statement of checkpoint-specific conformity. Checkpoints 2.3 and 4.2
call for two statements. If a site seeks Level 2 compliance, it could
potentially have to include ten separate statements of conformity, which
I think is overkill. I realize statements of conformity provide
measurable criteria on checkpoints that may otherwise be difficult to
measure. However, I think measurability in this case may come at the
expense of true accessibility. Whether or not a site claims to be
accessible has nothing to do with whether it is in fact accessible.
Therefore, I don't think statements of conformity belong in a set of
guidelines where the primary function is to provide a working definition
of "Web accessibility". 


***Question 3.  If your site already uses WCAG 1.0, do you think it
would be difficult to migrate from WCAG 1.0 to WCAG 2.0? What would make
it easier?  Please note that supporting documents, such as
technology-specific techniques documents, are not yet available.

Answer 3a. You could more closely match the presentation of the two
versions, e.g., by drawing boxes around guidelines. 


***Other Issues: 

 - Checkpoint 2.3 re. screen flicker. How problematic would it be to
extend the high end of the dangerous flicker rate to 55Hz, rather than
49Hz, in order to be consistent with Sec 508 standards? 

 - Speaking of consistency with Sec 508 standards, one of the Sec 508
standards is "Skip Navigational Links", which corresponds with
checkpoint 13.6 in WCAG 1.0. According to the Checkpoint Mapping Between
WCAG 1.0 and WCAG 2.0 Working Draft, this checkpoint maps to "Core
Techniques", and otherwise does not appear in the actual normative
document. I think this is a critical accessibility issue, and should
have a presence either as a checkpoint under Guideline 3 ("Navigable"),
or at least as a Minimum Criterion, perhaps under checkpoint 3.3.   

 - Checkpoint 3.6 re. minimizing error, Minimum level success criteria:
"If an error is detected, feedback is provided to the user identifying
the error". Since a common current problem is the use of inaccessible
client-side scripting techniques for form validation, perhaps this
should state the obvious, e.g., "...feedback is provided to the user
identifying the error in a way that is [accessible/perceivable in
accordance with Guideline 1/something similar]".
 
- Checkpoint 4.2 - "Supplement text with non-text content". Will a
text-only site now fail to attain Minimum Level compliance? Assuming
that for many/most sites the answer is No, I think exception language
needs to appear in the checkpoint itself. However, the exception
language in the minimum level success criteria ("...where they felt it
was appropriate" is I think weak compared with the language used in WCAG
1.0, checkpoint 14.2 ("... where it will facilitate comprehension of the
page"). 

- Checkpoint 4.2 Examples 3 and 5 - This may seem trivial, but there is
no mention that the child in Example 3 received permission to display
the bicycle plant's company logo, nor that Grandpa in Example 5 received
permission to include a short music clip, assuming the clip is stored
locally. In recommending that Web content developers include graphics
where they previously would not have done so, there is potential for
inadvertently facilitating an increase in copyright violations. You
should avoid language that in any way justifies this, even in examples
or other supporting documentation.   
 
- Checkpoint 5.2 - Add "metadata" to definitions.
 

Terry Thompson
AccessIT
National Center on Accessible Information Technology in Education
The University of Washington
Email: tft@u.washington.edu
Voice: 206-221-4168
TTY: 206-685-3648
Fax: 206-221-4171
Web: www.washington.edu/accessit

Received on Monday, 21 October 2002 17:49:30 UTC