W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > September 2003

EOWG comments on WCAG 2.0 24 June 2003 Working Draft

From: Judy Brewer <jbrewer@w3.org>
Date: Thu, 25 Sep 2003 13:28:26 -0400
Message-Id: <>
To: public-comments-wcag20@w3.org

EOWG Comments on Web Content Accessibility Guidelines 2.0 24 June 2003 
Working Draft

The Education and Outreach Working Group (EOWG) offers the following 
comments on the Web Content Accessibility Guidelines 2.0 24 June 2003 
Working Draft [1].

These comments derive from discussions held at EOWG teleconferences on 8, 
15, 22, and 29 August, and 12 September, and were based on EOWG discussion 
questions [2].


- Judy Brewer, EOWG Chair


1. Start providing different views (guidelines + checkpoints statements & 
explanations; checkpoints statements + benefits; checkpoints & success 
criteria; etc.; checkpoints grouped by core and extended, etc.) as of the 
next public working draft, so that reviewers can get a better idea of how 
the document works for different audiences. In particular, be sure to 
include a "benefits" or "impact matrix" view.

2. For subset views (e.g., views listing only certain elements of the 
overall document, as described above) include a reminder of the other views 
that are available, so that if someone generates a subset, prints it, & 
hands it to someone else, the other person realizes that there is 
information beyond the information in the printed version that they were 
given. Perhaps the top of each generated sub-set document could have a list 
of what is in the full view.

3. Start breaking the working draft document up into modules, as of the 
next public working draft, in addition to making it available in a single 
run-on HTML file, so that reviewers can get a better idea of how well the 
document's presentation works.

4. The Abstract should be an abstract of the document, rather than a 
description of history & goals.

5. Provide both concise and expanded Tables of Contents, as of the next 
public working draft, so that people can better judge the usability and 
presentation of the document while it is under development.

6. Instead of linking the entire checkpoint text in the Table of Contents, 
add & link the checkpoint ID (as used in the matching table) or target text 
(but with most words in the ID written out, rather than using uncommon 

7. Don't repeat the words [CORE] and [EXTENDED] between each number and the 
text in the Table of Contents, since it is already indicated with a 
sub-section heading.

8. Provide a clearer heading or context for the paragraph on "Designing 
Accessible Web Content" which immediately precedes Guideline #1. Currently 
it is unclear where it fits in the structure of the document -- is it a 
final section in "Overview of Design Principles," or a lead-in to the 
guidelines themselves?

9. Consider adding "Back to Table of Contents" link throughout, for 
instance, before each heading level, to improve navigation.

10. Leave "Best Practices" out of the document if possible, and 
re-integrate any non-redundant information into other categories 
(definitions, examples, etc.). However, if leaving best practices in, 
present them more consistently, and avoid duplication between best 
practices, required success criteria, and examples. Introduce them properly 
in the introduction, and clarify that "Best Practices" is not an additional 
conformance level.

11. Make it easier to find specific accessibility topics within the 
document, for instance, by providing more links to the WCAG 1.0 to WCAG 2.0 
transition map, or consider adding mechanisms such as a topic index in 
which people could search for the kinds of terms that they think in terms 
of when actually designing sites, e.g. "navigation," "forms," etc.


12. Review wording of checkpoints to ensure that they are stated in ways 
that are no more complex than necessary. (EOWG did not reach consensus on 
specific suggestions here, but will send some of our observations about 
clarity & understandability of some of the checkpoint statements in a 
separate email to WCAG WG Chairs and Editors.)

13. Clarify the "how to read this document" section, to differentiate what 
is in this document vs. what is in other related documents. Include 
descriptions of each of the key elements of the document, e.g., success 
criteria, definitions, benefits, examples, and best practices (in the event 
that best practices remain in the document). For instance: "There are four 
Guidelines, which are principles of accessible Web design. Under each 
Guideline are the Checkpoints. The 18 Checkpoints are the focus of WCAG2.0. 
Under each Checkpoint are success criteria, definitions, benefits, and 
examples. Success criteria is... etc."

14. The descriptions of guidelines in the "Overview of Design Principles," 
and the individual guidelines themselves, should be made consistent; and 
the key terms used for the guideline level (e.g. perceivable, robust, etc.) 
must be defined very clearly, in order for the document to work when 
translated into other languages.

15. Send people to the WAI Resource page, instead of the EOWG home page, 
for supporting resources.

16. The paragraph in "Overview of Design Principles" which begins 
"Accessible Web content benefits a variety of people, not just people with 
disabilities" has several problems:
- the phrase "not just people with disabilities" sounds like it belittles 
the importance of accessibility for people with disabilities;
- the paragraph goes into more detail than seems appropriate for the 
guidelines document -- it sounds a little like a sales pitch in the middle 
of a technical standard -- consider instead referencing other WAI documents 
which address what the impact is on people with disabilities and additional 
reasons why accessibility is important.
- if still including a paragraph discussing user needs, emphasize "here are 
a few scenarios, by no means an exhaustive list of the variations and types 
of disabilities and needs..."
- intro and overview sections will also need a technical editor to look 
over them (though EOWG understands this may be at a later stage).


17. Better explain the transition between the normative content of WCAG 1.0 
and WCAG 2.0. Provide some explanation for the substantial change in the 
numbers of guidelines and checkpoints between the 1.0 and 2.0 versions. 
Also make sure that the terms "normative" and "non-normative" are clearly 
defined. Many readers do not know what these terms mean in general, nor 
what they mean specifically in the context of this document, nor in the 
transition between WCAG 1.0 and 2.0.

18. Reconsider the terms "Core" and "Extended". The use of the word 
"Extended" is read by some people as implying that an "extended" checkpoint 
is essentially a more rigorous version of a "core checkpoint," rather than 
being an unrelated accessibility provision which, if implemented, provides 
a higher degree of accessibility. In addition, it is unclear whether some 
extended checkpoints are more important, or might have more "weight," than 
others. (This is not necessarily a recommendation that "extended 
checkpoints" have some assigned weight, but a request to at least clarify 
if they do not.)

19. Provide two levels of definitions for the terms "core" and "extended" 
or whatever terms are chosen as final names for conformance levels: as 
clear definitions in a glossary format, to ensure the clearest possible 
translations into other natural languages; and in terms of their impact on 
assuring a given level of accessibility for people with disabilities. The 
description of their impact on assuring a given level of accessibility 
should include a description of their similarities with and/or differences 
from the priority and conformance levels in WCAG 1.0.

20. Under "Conformance, Conformance Claims" switch #s 3 & 4. (Currently #2 
is Core, #3 is Extended, and #4 is Core+, which is actually in between core 
& extended in terms of conformance level. Eliminate #1 so that the numbers 
match the conformance claim levels. [Note: even if the terms core/extended 
change, our comment about order of presenting the terms would still remain 
the same.]

21. The WCAG WG requested feedback on the conformance model. The EOWG had 
much discussion regarding the intermediate conformance level, but without 
consensus. Some representative, though conflicting, comments follow.
- It is useful to have some kind of intermediate level (such as the current 
"Core+") between Core and Extended, though the current terms are confusing.
- It is probably not realistic to expect complex statements from Web 
developers regarding the intermediate level (e.g., conformance on a 
check-point by check-point basis, per page or per site).
- If expecting Web developers to provide checkpoint-by-checkpoint 
conformance information, provide a best practice model, for instance in 
metadata, for detailed reporting of conformance.
- Perhaps if recommending checkpoint-by-checkpoint detailed reporting of 
conformance, make doing that an "extended" checkpoint (or whatever term is 
chosen for the higher conformance level).

[1] 24 June 2003 Working Draft, Web Content Accessibility Guidelines 2.0

[2] EOWG review questions:

Judy Brewer    +1.617.258.9741    http://www.w3.org/WAI
Director, Web Accessibility Initiative (WAI), World Wide Web Consortium (W3C)
MIT/LCS Room NE43-355, 200 Technology Square, Cambridge, MA,  02139,  USA
Received on Thursday, 25 September 2003 13:32:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:34 UTC