Copyright ©2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This is a W3C Working Draft produced by the Web Content Accessibility Guidelines Working Group (WCAG WG). The purpose of this document is to outline the requirements for Web Content Accessibility Guidelines 2.0. The Working Group encourages feedback about these requirements as well as participation in the development of the revision by people who have experience trying to create Web content that conforms to WCAG 1.0.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.
Send comments about this document to the Web Content Accessibility Guidelines Working Group mailing list. The archives for this list are publicly available.
This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals of the WCAG WG are discussed in the Working Group charter. The WCAG WG is part of the WAI Technical Activity.
Web Content Accessibility Guidelines 1.0 (WCAG 1.0) explains how to make Web content accessible to people with disabilities. It was written for Web content developers (page authors and site designers) and developers of authoring tools. The primary goal of WCAG 1.0 is to promote accessibility. However, following the guidelines in WCAG 1.0 will also make Web content more available to all users.
Since the release of WCAG 1.0 as a W3C Recommendation in May 1999, the WCAG WG has received feedback about the usability, understandability, and applicability of the suite of documents. This feedback is driving the development of WCAG 2.0 and is captured as the Requirements for WCAG 2.0 (this document).
The goal of WCAG 2.0 is the same as 1.0: to promote accessibility of Web content. The other goals listed in this document are:
WCAG 1.0 was written primarily for HTML documents. Authors trying to apply WCAG 1.0 to XML applications have had difficulty. Thus, WCAG 2.0 should be applicable across technologies such as:
WCAG 2.0 requirements should be expressed in generic terms so that they may apply to more than one markup language or content format.
WCAG 2.0 must clearly specify the minimal requirements necessary for conformance. Each requirement must be verifiable. The WG will provide resources to help readers evaluate conformance, such as technology-specific checklists, sample content, sample renderings (aural as well as graphical), and processes for determining conformance (e.g., in conjunction with the Evaluation and Repair Tools (ERT) and Education and Outreach (EO) WGs).
The deliverables must:
The structure of the deliverables must be simple and easy to use. As part of ensuring the usability of the deliverables, the WCAG WG will incorporate usability testing into the development process.
WCAG 2.0 deliverables must meet the needs of a variety of readers, including people who wish to:
The number, length, and organization of the deliverables must meet the different needs of these readers. The language used in the deliverables should be as easy as possible to translate into other languages and localized examples should be provided where possible. As part of ensuring that the diverse needs of readers are met, the WG will work closely with the Education and Outreach Working Group.
A number of other materials and tools reference WCAG 1.0, such as specifications, evaluation tools, authoring tools, and government and organizational policies. Therefore, WCAG 2.0 must not completely change the definition of accessible content.
The following are statements that the WCAG Working Group has reached consensus on as of the date of this document and will be using to build the new WCAG 2.0 Guidelines. The purpose of these statements is not to be comprehensive but to list those areas where there is agreement so that the group can better focus on areas where more discussion and development is required.
R1 - The technical requirements of WCAG 2.0 are driven by the needs of people with disabilities. However, the users of WCAG 2.0 are a wide audience, and the requirements it expresses must be in language that policy makers can understand, cite and adopt. While the WCAG WG does not set policy, harmonization of accessibility requirements helps drive demand for supporting implementations in Web applications.
N1 - [Deleted due to changes in structure]
N2 - we shouldn't be including anything (as normative) that we can't provide techniques and examples for.
N3 - [Deleted during consolidation.]
N4 - we shouldn't be including anything (as normative) that we can't provide success criteria for.
N5 - things that are normative must be testable. (Testable does not mean it must be machine testable).
N6 - that "testable by a tool" should NOT be required for normative items.
N7 - normative items should not be determined by how easy it is to test. (in time and effort) (Testability may be a criterion, but not ease of testing).
N8 - If techniques or examples for a normative checkpoint (guideline) are not generally applicable across web sites, then the checkpoint or guideline must be qualified/restricted to those conditions where the techniques would work.
N9 - Normative portions apply to sites in general. Most informative portions also apply to sites in general. However, some informative portions may apply only to specially targetted sites and those informative portions will be clearly labelled in the guidelines.
C1 - We want to have recognition for accomplishment beyond baseline.
C2 - It is good to have levels of conformance rather than just all or nothing.
C3 - There would be a "minimum standard" of accessibility. In order to assert any level of conformance (with WCAG 2.0) the content must meet this minimum standard which consists of a predetermined set of checkpoints. [refer to C8]
C4 - Should not be able to claim conformance by disability.
C5 - WCAG should provide a way for people to see impact of items for particular disabilities but it should not be used for conformance.
C6 - [Deleted during consolidation.]
C7 - The success criteria for a checkpoint must be sufficient; following the success criteria should be all that is needed to claim conformance to the checkpoint.
C8 - If the working group defines a core set of checkpoints which must be satisfied before any conformance claim can be made, these will constitute a minimum level of conformance (e.g. "Level A"). However, there is no agreement on whether, if checkpoints beyond the core set have been implemented, these need to be listed individually, with an "A+" conformance label associated with a list of additional checkpoints, or whether higher "discrete" levels of conformance (double-a, triple-a etc.) should be defined. [SEE C3]
M1 - It should be possible to use metadata, specifically the Evaluation and Report Language (EARL), to claim conformance, either alone or in conjunction with an automatically or manually generated human-readable conformance claim. The metadata must specify precisely to which checkpoints conformance is asserted (e.g., by checkpoint number)
M2 - It seems like a good idea to express conformance claims in machine-readable form, but we aren't sure if we should require it of all claims or suggest it be used.
M3 - There should be one or more standard human-readable conformance claims, with associated conformance logos, the details of which remain to be determined after other issues have been resolved.
M4 - It should be possible, but not required, that authors who (for reasons of site policy or other constraints) decide not to implement a particular checkpoint, be able to assert in the metadata that the non-implementation of that checkpoint is the result of a deliberate decision on the author's part. ( NOTE: This option is put forward as a solution to the "author's needs vs. user's needs" problem: instead of making policy determinations, the guidelines should provide this mechanism as a means by which authors can assert that they have (for reasons they consider legitimate) chosen not to implement a particular checkpoint; the question of whether those reasons are in fact legitimate is for legal and other policy-oriented bodies to determine and lies outside the scope of the guidelines.) ( NOTE2: This would not constitute or be a substitute for conformance - just a way to note why item was not conformed with.)
S1 - Serving content in different forms to meet different user needs and preferences is an acceptable way to comply with the guidelines, as long as the different forms:
Note: We will not make any assumptions in this Requirements document about the method that is used, whether it is content negotiation or a link. The issue of where and how the user sets their preferences is an item that has not been discussed.
B1 - Techniques should specify if particular browsers are needed or will not work with the technique. Or they should specify if they require particular technologies. e.g. You must have CSS2 support for this technique to work.
G1 - Our document should be written as clearly and simply as is appropriate for the content with links to definitions. We should use the clearest and simplest language that someone can propose as long as it is accurate.
G2 - Accessibility and usability are intertwined and vary between people and tasks. We think that our distinctions and decisions about normative or importance will be based on something other than categorizing them as "accessibility" or "usability" items.
G3 - User vs. user needs is something we need to look at on a case-by-case basis, but it is also a test we need to apply to every normative requirement. We need to ask ourselves, "If this is done, will some group be cut out?"
A1 - The Working Group acknowledges that accessibility to everyone is not possible. Our target is to make things as accessible to as many people as possible given the need to have practical techniques and criteria. We will make our best effort to identify techniques, criteria and examples that cover the greatest range possible.