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].
Regards,
- Judy Brewer, EOWG Chair
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.
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.
GENERAL CLARITY:
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).
CONFORMANCE MODEL & EXPLANATION:
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
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
--
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