Note: This draft includes a number of proposed editorial changes, links to unresolved issues and, references to recent proposals and comments. The presentation of this document has been augmented to identify changes from a previous version. Two kinds of changes are highlighted: [begin proposed] proposed text [end proposed], and [begin current] current working draft text [end current].



Requirements for WCAG 2.0 Checklists and Techniques

Editor's Draft 20 May 2005

This version:
Latest version:
Previous version:
Michael Cooper, Watchfire


Overview of changes:

  1. reformatted Definitions section so output results in a definitions list

  2. de-capitalized "Success Criterion" throughout

  3. added/updated some editorial notes

  4. updated requirements for checklists


This is a W3C Working Draft produced by the Web Content Accessibility Guidelines Working Group (WCAG WG). It describes requirements for Checklists and Techniques described by the Web Content Accessibility Guidelines 2.0 (WCAG 2.0). These requirements are related to but different from Requirements for WCAG 2.0 in that "Requirements for WCAG 2.0 Checklists, Techniques, and Test Files" specifies requirements for the technology-specific documents produced by the WCAG WG while "Requirements for WCAG 2.0" specifies general requirements for the general usability of documents produced by the WCAG WG. The Working Group encourages feedback about these requirements as well as participation in the development of WCAG 2.0 by people who have experience creating Web content that conforms to Web Content Accessibility Guidelines 1.0.

Editorial Note: Based on the above paragraph, it looks like requirements for the "guide" documents belong in requirements for WCAG 2.0. Requirements for the guide docs have not yet been drafted, but should be covered someplace.

Status of this Document

This document is for review by the WCAG WG and is subject to change without notice. This document has no formal standing within W3C. Please consult the group's home page and the W3C technical reports index for information about the latest publications by this group.

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.

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 was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing [and excluding] a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.

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.

This document describes requirements for creating Checklists and Techniques for the Web Content Accessibility Guidelines 2.0. It is a draft document that does not fully represent the consensus of the group at this time. Consensus is expected to be achieved shortly and work on creating the Techniques documents to proceed.

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


The Web Content Accessibility Guidelines 2.0 creates a technology-independent set of Web accessibility guidelines by providing a set of high-level guidelines, and providing technology-specific information in auxiliary documents that are more frequently updated and may be non-normative. This document sets forth requirements for providing those documents, as summarized in Priorities and Techniques. Specifically, this set of requirements fulfills WCAG 2.0 Requirements to provide technology-specific Checklists and technology-specific Application Information.

While the WCAG Working Group intends to provide techniques for a variety of technologies, there is not a mandate to provide techniques for all technologies. W3C policy prohibits work on proprietary technologies, and it is not expected that the working group will have resources to provide techniques for every other technology in use on the Web. Additionally, while there will be an effort to provide comprehensive overviews of available techniques for which the WCAG Working Group does provide techniques, there is no guarantee that every possible means of satisfying the success criteria will be inventoried. Therefore, the techniques must be viewed only as example techniques which clarify the guidelines and describe common ways to conform to WCAG 2.0. It is possible to conform to the guidelines without following the techniques provided by the WCAG Working Group. Nevertheless, these techniques should represent the best available knowledge and serve as solid guidance for most implementors.

This document describes requirements both for the source files used to store techniques and for the documents that will be generated from the source files. The source files will likely only be viewed for editing purposes and will exist in the best format and organization that fulfills the requirements (i.e., they are not likely to be available in HTML for general use). From these sources files we intend to generate a variety of views (see Appendix A Output Formats). Each view may have its own requirements. The three views currently under discussion are comprehensive Techniques (3 Techniques Requirements), Checklists (4 Checklist Requirements), and Test Files (4.2 Test Cases).

Other W3C groups have expressed interest in using the schema that is developed. Developers of non-W3C technologies may use the schema to publish their own techniques documents that show how to use their technologies to conform to WCAG 2.0. Therefore, while the Techniques documents are specifically created to meet WCAG 2.0 requirements, the structure is intended to be generalizable to other working groups and technologies.

Table of Contents


1 Definitions


Either Machine Testable or Reliably Human Testable.

Machine Testable

There is a known algorithm (regardless of whether that algorithm is known to be implemented in tools) that will determine, with complete reliability, whether the technique has been implemented or not.

Note: Probabilistic algorithms are not sufficient.

[end chg]
Reliably Human Testable

The technique can be tested by human inspection and it is believed that at least 80% of knowledgeable human evaluators would agree on the conclusion. Tests performed by people who understand the guidelines should yield the same results when testing the same content for the same success criteria. The use of probabilistic machine algorithms may facilitate the human testing process, but this does not make it machine testable.

[end chg]
Not Reliably Testable

The technique is subject to human inspection but it is not believed that at least 80% of knowledgeable human evaluators would agree on the conclusion.

Testable Statement

An assertion of the proper application of a technique that can be evaluated as either passed or failed.

Test Case

A collection of information and test files associated with the verification of a single testable statement.

Test File

A discrete unit representing by specific example a pass or fail condition of a testable statement.

Positive Test

A test file that demonstrates the proper application of a technique. If a technique's requirement is to avoid a certain practice, a postive test case may represent the absence of a feature.

Negative Test

A test file that demonstrates improper application of a technique. If a technique's requirement is to avoid a certain practice, a negative test case may represent the presence of the feature to be avoided.


A technique or set of techniques that fulfill the requirements of a success criterion without additional requirements.


A technique or set of techniques that is not necessary to fulfill the requirements of a success criterion, but provide an accessibility benefit.

[end chg]
Not Recommended

A technique demonstrating uses of technology that negatively impact an author's ability to meet a success criterion.

[end chg]

2 General Requirements

2.1 Intended Uses

  • Techniques must be usable by a variety of audiences. Audiences that have been identified include

    • Content developers

    • User agent developers

    • Evaluation tool developers

    • Authoring tool developers

    • Assistive technology developers

    • Training material developers

    • Guidelines developers

    • Operating System developers

  • Source files must be structured in such a way that multiple views can be achieved. A list of specific views is provided in Appendix A Output Formats. Some views may be targeted to specific audiences and other views may be appropriate for multiple audiences.

2.2 Structure

  • Techniques must be highly structured and largely machine manipulable. It is expected that they will exist in XML files conforming to the DTD/Schema in Appendix B Techniques Schema.

  • Techniques documents must be versioned in such a way that updates to the documents do not break interdependencies that may exist among multiple documents (e.g., on General techniques, HTML dependent on CSS, etc.). Versioning can be based on revision dates of specific documents.

  • [begin proposed]

    Each technique must be assigned a unique identifier to enable referencing from other deliverables and customized output formats.

    [end proposed]
  • [begin current]

    Each technique must be assigned a unique identifier to enable machine-readable conformance statements.

    [end current]
  • Structure should be general enough that it can be used by groups outside the WAI domain.

  • It must be possible for Techniques documents to be localized.

  • It must be possible to provide techniques that are applicable to specific locales, but are not relevant in other locales.

2.3 Relation to WCAG 2.0

  • Each technique must map to a specific WCAG 2.0 success criterion by URI and number for clarity and to enable auto generation of hybrid Guidelines/Techniques documents.

  • There may be multiple techniques for each success criterion, clearly stated that they are alternate techniques. Such techniques have an OR relationship with each other.

  • Each technique must state whether its implementation fully conforms to the success criterion, and if not, provide references to other techniques (in the same or other Techniques documents) needed to achieve full conformance. Such techniques have an AND relationship with each other.

  • A set of techniques whose implementation fulfills a success criterion is considered "Sufficient" for the success criterion.

  • Techniques may be "Optional". Implementation of an optional technique does not fulfill the requirements of a success criterion but has an identifiable benefit with respect to the intent of the success criterion.

2.4 Baseline

  • Techniques must provide information about baselines for which they are intended.

  • [begin proposed]

    For a given baseline, a technique may be sufficient (possibly when in combination with other techniques), optional, or not recommended. Optional and not recommended techniques are documented if they are considered sufficient when different user agent assumptions are made.

    [end proposed]

Editorial Note: @@ link to definition of baseline

3 Techniques Requirements

3.1 Scope of Documents

  • Techniques should be grouped by particular technologies to which they apply (e.g., HTML, CSS, SVG, ECMAScript).

  • Each technique must clearly indicate what is required to conform to the success criterion to which it applies.

  • There should be a separate group of techniques that are not related to a specific technology, to describe accessibility practices at a level of detail not appropriate for the guidelines but common to multiple technologies. Requirements for these techniques are detailed below in 3.2 General Techniques.

  • Where technologies work together (e.g., HTML and CSS), relevant joint techniques must be presented with the host technology (e.g., HTML). If techniques do not involve interactions between the two technologies, they must be presented with their respective technology only.

    Note: There is not consensus about whether the working group will create techniques for technologies that cannot meet the minimum success criteria of the guidelines even in combination with other technologies.

  • Techniques must state to which versions of the technology they apply, i.e., describe a practice to avoid or follow. They may specify all versions, all versions prior to or later than a particular version, or enumerate particular versions.

  • For a given technology, it is not necessary to provide techniques for every success criterion if the criterion is not applicable to the technology, either because the technology is designed to be used with another technology (e.g., CSS with HTML) or because it is not possible to achieve full guideline conformance with the technology. In place of a technique there must be an indication that states whether the technology is intended to interact with other technologies to provide full guideline conformance, or whether it is not possible in that technology to achieve guideline conformance for that success criterion. In the latter case, outputs must prominently state that full guideline conformance is not possible with the technology.

    [begin current]

    Note: There is serious debate about whether it should be possible to create views which contain Checklist items related specifically to technologies that do not themselves fully support the guidelines. For example, it may be possible to create a Checklist devoted solely to CSS, but it is never possible to achieve full guideline conformance with CSS. It may be desirable to require that views for such technologies always include other technologies, such as HTML, that can result in complete guideline conformance when following the guidance of that view. It is expected that the process of developing techniques and views will help clarify and close this issue.

    [end current]
  • Techniques may describe practices that are not yet supported by user agents, authoring tools, etc. in order to provide guidance for tool developers. When possible techniques should also describe practices that work in contemporary tools.

    Editorial Note: This is related to baseline and needs to be adjusted when that is completed.

  • [begin proposed]

    For techniques in which current user agent support is known to be variable or otherwise relevant to the technique, information about user agent support should be provided. Additional user agent information may be provided in external resources or referenced from the technique.

    [end proposed]
  • Each technique must indicate the conditions under which it is applicable. Applicability conditions refer to the presence or absence of certain features relevant to the technique.

3.2 General Techniques


  • The General Techniques must offer concrete strategies that can be implemented in a wide variety of technologies to satisfy specific success criteria.

  • Each technique should provide at least one clear example. Examples, though sometimes of necessity implemented in a particular technology, do not specifically indicate proper use of that technology, but show a general concept.

  • Each general technique must be testable and provide a testable statement.

  • The General Techniques must be clearly written and have a reading level at or below 9th grade level (Flesch Reading Ease score 55 or higher).

  • The General Techniques must serve the same diverse audiences as the Guidelines.

  • Each General Technique must provide links to relevant technology-specific techniques.

  • The General Techniques document(s) must stand in clear relation to other documents in the WCAG 2.0 collection.

3.3 Technology Specific Techniques

The following points are requirements for Techniques.

  • Techniques related to success criteria must be testable and provide a testable statement. Guidance about testing methods may be provided.

  • Positive test cases must be provided for testable Techniques. Negative test cases should be provided when possible.

  • Techniques should include descriptions, commentary, implementation notes, links to resources or training materials, etc. that contain additional information that is not part of the structured data.

4 Checklist Requirements

[begin proposed]

4.1 Checklists

The following points are requirements for Checklists.

  • Checklists must provide a simple list of the success criteria in the guidelines in a form that they can be answered true or false.

  • At a minimum, checklists must include all level 1 success criteria.

  • Additional information related to each success criterion may be included to make it easier to undersand what is required at the technology-specific level to meet each criterion. Examples include:

    • information needed to understand how a criterion applies to different technologies or baselines

    • links to sufficient and optional techniques

    • links to related tests for the techniques

[end proposed]

4.2 Test Cases

The following points are requirements for Test Cases.

  • At least one test case should be provided for every technology-specific technique. Multiple test cases may be provided for a technique.

  • Metadata must exist about each test case detailing the following:

    • A testable statement that describes the issue to examine and can be answered as true or false.

    • Prerequisite tests that must be executed before the current test.

    • Conditional statements

      Note: Need more explanation here.

    • Test procedure.

    • Expected results.

    • Instructions for evaluator when test case passes.

    • Instructions for evaluator when test case fails.

    • Link to technique(s) the test case supports.

  • There must be at least two test files for every testable statement, one to test the pass condition and one to test the fail condition.

  • Test files should be granular, depending as little as possible on resources outside themselves.

  • Test files must be consistent with the examples in the techniques documents, i.e., test files should look like more complete examples of the brief examples already provided.

Appendix A Output Formats (Non-Normative)

Editorial Note: We may want to revisit this section and prioritize some of the options based on what is likely to be completed before CR.

The Techniques are designed to meet a number of needs. As documents are designed to work together, each view may be drawn from multiple source files. The number of possible output formats is therefore large and many views may be generated from the source files at request time.

The following output formats have been identified and it must be possible to generate each of these documents.

Note: This list is not yet complete. While it does not have to be for us to proceed with the work, the more complete it is the more likely we will be to not miss anything. Also, it is not clear whether this should be an Appendix (in which case it may be ok to view it as a growing list) or part of the requirements, in which case it probably does need to be considered complete at the time the requirements are ratified.

Appendix B Techniques Schema (Non-Normative)

The DTD for techniques is available at