Requirements for WCAG 2.0 Checklists and Techniques

1 Introduction

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 are possibly non-normative. This document sets forth requirements for providing those documents, summarized in Priorities and Techniques. Specifically, this set of requirements fulfills the WCAG 2.0 requirement to provide Technology-specific Checklists and Technology-specific Application Information.

These requirements describe a single type of document that can output information for various target audiences and purposes (see A Output Formats). As indicated above, however, two primary broad outputs are comprehensive techniques, and checklists. Requirements specific to these two outputs are grouped separately in 4 Techniques Requirements and 5 Checklist Requirements.

Other W3C groups have expressed interest in using the product of this work. It may be desirable for developers of non-W3C technologies that are WCAG-conformant to provide techniques for those technologies based on the same format for interoperability. 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.

2 Definitions

[Definition: Testable: Either Machine Testable or Reliably Human Testable.]

[Definition: Machine Testable: There is known to be an 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. Probabilistic algorithms are not sufficient.]

[Definition: 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. The use of probabilistic machine algorithms may facilitate the human testing process but this does not make it machine testable.]

[Definition: 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.]

3 General Requirements

3.1 Intended Uses

Techniques must be usable by a variety of audiences. Audiences that have been identified include
Techniques must be structured in such a way that multiple views can be achieved. A list of specific views is provided in A Output Formats. Some views may be targeted to specific audiences and other views may be appropriate for multiple audiences.

3.2 Scope of Documents

Each Techniques document must apply to a distinct technology (e.g., HTML, CSS, SVG, ECMAScript).
A separate Core Techniques document that will provide information that is too specific for WCAG but not related to a specific technology must be included.
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 the techniques for their respective technology only.
Techniques must state to which versions of the technology they apply, that is, describe a practice to avoid or that will have a positive accessibility impact. 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 Checkpoint if the Checkpoint is not applicable to the technology, either because the technology is designed to be used with another technology (e.g., HTML and CSS) 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 to achieve guideline conformance for the technology for that Success Criterion. In the latter case, outputs must prominently state that full guideline conformance is not possible with the technology.
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.
Information about user agent support for Techniques must be provided. At a minimum it is required to state whether the Technique is known to be implemented in any existing user agent. For Techniques in which current user agent support is known to be variable or otherwise relevant to the Technique, that information should also be provided. Additional user agent information may be provided in external resources.

3.3 Structure

Techniques must be highly structured and largely machine manipulable. It is expected that they will exist in XML documents conforming to the DTD/Schema in C 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 Core techniques, HTML dependent on CSS, etc.). Versioning can be based on revision dates of specific documents.
Each Technique must be assigned a unique identifier to enable machine-readable conformance statements.
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.

3.4 Relation to WCAG

Each technique must map to a specific WCAG Success Criterion or Additional Ideas 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 or Additional Ideas, clearly stated that they are alternate techniques.
Each technique must state whether its implementation fully meets the Success Criterion or Additional Ideas and if not provide references to other techniques (in the same or other Techniques documents) needed to complete the implementation.

4 Techniques Requirements

The following points are mandatory requirements for Techniques.

Techniques related to Success Criteria must be testable. 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 related to Additional Ideas should be testable when possible but may be not reliably testable. There must be a declaration of the testability of the Technique.
Example implementations or descriptions of implementations should be provided for untestable Techniques where possible.
Techniques should include descriptions, commentary, implementation notes, links to resources or training materials, etc. to contain information not part of the structured data.

5 Checklist Requirements

The following points address the requirement to create Checklists. While Techniques and Checklists are expected to be stored in the same document, they are separate enough to need separate requirements. The following points are mandatory requirements for Checklists.

Technology-specific Checklists must include technology-specific checklist items that address every Success Criterion in the guidelines. Checklist item for success criteria that include an "or" statement should have all related provisions included in one technology-specific checklist item.
Note:
Normally, a Checklist view will include content drawn from multiple Techniques document sources as described in 3.2 Scope of Documents. Each Success Criterion would be met by Techniques drawn from one or more of the source documents but not necessarily all. For example, a Checklist describing HTML and CSS may indicate that some Success Criteria are met by HTML and others by CSS.
Each success criterion addressed in a checklist needs to include a list of checklist items that are both necessary and sufficient to meet that success criterion. If there are multiple interchangeable techniques which could be used to achieve a success criterion, they need to be listed all together in a single Checklist item as an "OR" proposition.
Checklists should be constructed such that all items in the checklist for a given success criterion must be marked true in order for the content to conform at any conformance level.

If there are no techniques for a particular technology that address a specific success criterion, then a checklist item for that success criterion must be present and must include information stating that the content must also be provided in another form that meets all of Level 1 requirements.

Editorial note: Michael Cooper	2003-01-15
This relates to the open issue in 3.2 Scope of Documents that we haven't decided whether to permit Techniques documents to be created for technologies that cannot be WCAG conformant.

Checklist items are grouped according to the Checkpoint to which they apply and are ordered by their conformance level (Minimum, Level 2, and Level 3). Optional techniques should be presented in an "additional strategies" section and would be listed separately.

6 References

WCAG2: Web Content Accessibility Guidelines 2.0, B. Caldwell, W. Chisholm, J. White, G. Vanderheiden. World Wide Web Consortium, 25 January 2001, revised 22 August 2002.

Requirements for WCAG 2.0 Checklists and Techniques

W3C Working Draft 31 January 2003

Abstract

Status of this Document

Table of Contents

Appendices