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

DRAFT!! EOWG comments on WCAG 2.0 24 June 2003 WD

From: Judy Brewer <jbrewer@w3.org>
Date: Fri, 29 Aug 2003 09:14:30 -0400
Message-Id: <5.1.0.14.2.20030827141042.05135490@localhost>
To: EOWG <w3c-wai-eo@w3.org>

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

..........

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 29 
August 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 Working Draft 
dated 24 June 2003. 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.


1. Generated views: Ensure that sub-set views retain context of entire 
document. For subset views (e.g., listing guidelines and checkpoints but 
not impact statements) include a reminder of the other views that are 
available, so that if someone generates a subset & hands it to someone 
else, the other person realizes that there is information beyond the 
information in the version that they were given). Perhaps the top of each 
generated sub-set document could have a list of what's in the full view.

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

3. Presentation: 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 better idea of how 
the document works for different audiences.

4. Presentation: Provide separate concise and expanded TOC's 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.

5. Table of Contents: Instead of linking entire checkpoints in TOC, add & 
link the checkpoint ID or target text (but with most words written out, 
rather than uncommon abbreviations)

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

7. Order: Provide clearer context for the paragraph on "Designing 
Accessible Web Content." Currently it is unclear where it fits in the 
structure of the document.

8. Order: Under "Conformance, Conformance Claims" switch #s 3 & 4. 
(Currently 2 is Core, 3 is Entended, 4 is Core+. Should be 2. Core, 3. 
Core+, 3. Extended.) Eliminate 1 so that the numbers match the conformance 
claim options.

9. Navigation: Improve navigation within document. Consider adding "Back to 
Contents" throughout; e.g., before each XYZ heading level.

10. Clarity: Review wording of checkpoints to ensure that they are stated 
in ways that are no more complex than necessary. Problems encountered 
included: inconsistent voice (active/passive); inconsistent number 
(singular/plural); awkward wording; use of terms that would be difficult to 
translate. 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.

11. Clarity. Clarify the "how to read this document" section to 
differentiate what is in this document vs what is in other related 
documents; also include explanations of success criteria, definitions, 
benefits, and examples. 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 is success criteria, definitions, benefits, and examples. 
Success criteria is..."

12. Clarity: Either introduce and define the "best practices" items better, 
or leave them out of the document.

13. Clarity: Provide something like an "Impact Matrix" for WCAG 2.0. 
(Perhaps this is a user-customizeable "view" (subset from XML) that lists 
the "benefits" currently in WCAG 2.0 Working Draft.)

14. Clarity: Clarify that "Best Practices" is not another conformance level.

15. Choice of terms: Reconsider the terms "Core" and "Extended". 
Conceptually and semantically, the use of the word "Extended" would 
indicate an extension of a core checkpoint, which is not the case.

16. Definitions: Define "normative" and "non-normative." Many readers do 
not know what these mean in general, nor what they mean specifically in the 
context of this document, and the terms are key to understanding the document.

17. Definitions: Define "Core" and "Extended" (or whichever words are used 
to define priorities or categories of checkpoints) in two ways: 1. as 
glossary definition, particularly to help translators (as EOWG members said 
these words are difficult to translate), 2. what they mean for 
accessibility (e.g., like Priorities 1, 2, 3 were specified in WCAG1.0) 
Answer the question: Does "Core" provide decent accessibility (e.g., is it 
roughly equal to Priorities 1 & 2 from WCAG1.0, as opposed to just P1)?

18. Consistency: In reviewing document, there was some confusion caused by 
the inconsistent wording in the "Overview of Design Principles" and the 
Guidelines themselves. Consider making the wording the same in both places.

19. Referencing EOWG work: Refer to the WAI Resource page instead of the 
EOWG home page.

20. Introduction: Streamline the mini-business case to briefly mention the 
issues and point to the specific WAI reference that covers the topic(s) and 
just give a hint of what rationales and resources people can find 
elsewhere. Also, rewrite the "Designing Accessible Web content" section to 
be more careful about subtleties; for example, "Accessible Web content 
benefits a variety of people, not just people with disabilities" sounds 
like it belittles people with disabilities. When discussing user needs, 
emphasize "here are a few scenarios, by no means an exhaustive list of the 
variations and types of disabilities and needs..."

21. Conformance model: Yes it is useful to provide a middle level between 
Core and Extended (the current "Core+" - but with different terminology). 
It is probably not feasible to require a complex statement about what the 
middle level is (i.e., which Extended checkpoints are met). Encourage 
detailed reporting of which Extended checkpoints are met in the best 
possible way for accessibility (e.g., metadata) by providing a model for 
doing so. Perhaps make that reporting an Extended Checkpoint (i.e., a 
checkpoint that says the level of conformance to WCAG is specific in the 
metadata).



-- 
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, 29 August 2003 09:14:59 GMT

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