W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > July to September 2003

DRAFT 2: EOWG comments on WCAG 2.0 24 June 2003 Working Draft

From: Judy Brewer <jbrewer@w3.org>
Date: Fri, 12 Sep 2003 00:50:03 -0400
Message-Id: <5.1.0.14.2.20030829091820.04d0e680@localhost>
To: EOWG <w3c-wai-eo@w3.org>

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

..........

DRAFT: The following comments are in draft form and do not yet represent 
the consensus of the EOWG. They are for discussion of the EOWG at the 12 
September 2003 teleconference, and are not for circulation.

..........

The Education and Outreach Working Group (EOWG) offers the following 
comments on the Web Content Accessibility Guidelines 2.0 24 June 2003 
Working Draft. These comments derive from discussions held at EOWG 
teleconferences on 8, 15, 22, and 29 August, and were based on EOWG 
discussion questions available at 
http://lists.w3.org/Archives/Public/w3c-wai-eo/2003JulSep/0058.html.

PRESENTATION & ORGANIZATION:

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 
abbreviations).

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.

GENERAL CLARITY:

11. Review wording of checkpoints to ensure that they are stated in ways 
that are no more complex than necessary. Problems encountered include: 
inconsistent voice (active/passive); inconsistent number (singular/plural); 
awkward wording; and use of terms that would be difficult to translate into 
other natural languages. Checkpoints which scored particularly low on 
clarity among at least some participants of EOWG include: 1.1, 1.2, 1.4. 
1.6, 2.4, 2.5, 3.4, 4.2, 4.3. See examples below, at [3].

12. 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 4 
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."

13. The descriptions of guidelines in the "Overview of Design Principles" 
and the individual guidelines themselves should be made consistent.

14. Refer to the WAI Resource page instead of the EOWG home page.

CONFORMANCE MODEL & EXPLANATION:

15. Define "normative" and "non-normative"and better explain the transition 
between normative content of WCAG 1.0 and WCAG 2.0 Many readers do not know 
what these mean in general, nor what they mean specifically in the context 
of this document, or in the transition between 1.0 and 2.0.

16. Reconsider the terms "Core" and "Extended". The use of the word 
"Extended" is read by some people as implying that an "extended" checkpoint 
is a more rigorous version of a "core checkpoint," rather than being an 
unrelated accessibility provision which, if implemented, provides a higher 
degree of accessibility.

17. Provide two levels of definitions for the terms "core" and "extended" 
or whatever the terms are chosen as 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 conformance levels in WCAG 1.0.

18. 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.]

19. [The EOWG had much discussion on the intermediate conformance level, 
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 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).

20. 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 approapriate for the 
guidelines document -- it sounds 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..."

[1] 24 June 2003 Working Draft, Web Content Accessibility Guidelines 2.0
http://www.w3.org/TR/2003/WD-WCAG20-20030624/

[2] EOWG review questions:
http://lists.w3.org/Archives/Public/w3c-wai-eo/2003JulSep/0058.html

[3] Examples of wording which makes the checkpoint statements difficult to 
read (presumably, some of these may be revised to be more easily 
understandable, without losing any of the intended meaning, while others 
may not be able to be written more clearly):
[examples to be discussed in EOWG meeting 12 September]


-- 
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 Friday, 12 September 2003 00:51:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 10:33:36 GMT