- From: Judy Brewer <jbrewer@w3.org>
- Date: Fri, 12 Sep 2003 00:50:03 -0400
- 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 UTC