Copyright ©2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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 W3C Working Draft produced by the Web Content Accessibility Guidelines Working Group. The purpose of this document is to outline the requirements for the next version of the Web Content Accessibility Guidelines. 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 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.
WCAG 2.0 will include requirements for:
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 ERT and 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. 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 ATAG 1.0, the WCAG Curriculum, U.S. Government Section 508 Guidelines, AERT, Bobby, etc. Therefore, a revision of WCAG 1.0 must not completely change the definition of accessible content but clarify the complexities and fix the specifics.
The following are statements that the WCAG Working Group has reached consensus on 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 -That what we develop should be usable by people who are writing regulations or requirements or policies (government, company, agency etc.) This is not the only group - but it is one group we need to address.
R2 - That our guidelines should not necessarily be directly usable or adoptable as regulations
R3 -That our guidelines should have a "harmonizing" effect on regulations -- so that they cause regulations to be written so that they are similar and create similar or at least compatible demands on companies and individuals who must follow the regulations or standards or policies.
N1 -that technology specific checkpoints should be normative
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)
N-8If 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.
N-9 Our normative portions would (as qualified) apply to sites in general. Our informative portions can give information that may apply to sites in general or to special targeted sites as long as they are clearly labeled.
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 - we 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. (i.e. if you do them you comply. You would not have to do anything not in the list of success criteria.)
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 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 go with 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 an "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 anyway. Need to ask"If this done, is some group being 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 then need to have practical techniques and criteria. We will expend our best effort to identify techniques, criteria and examples that would cover the greatest range possible.