Requirements for WCAG 2.0 Techniques

Draft Version 0.3
2 January 2003
Authors: Michael Cooper
Contributors: Wendy Chisholm, Gregg Vanderheiden, Jason White

Introduction

[preamble text]

Requirements

• Intended uses
  • Techniques must be structured in such a way that multiple views can be achieved. A list of specific views is provided in the section "Output Formats".
  • Techniques must be usable by a variety of audiences, including in particular
    • Content developers
    • User agent developers
    • Evaluation tool developers
    • Authoring tool developers
    • Assistive technology developers
    • Other?
• 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 it fully implements 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.
• Scope of documents
  • Each set of Techniques must apply to a distinct technology (e.g., HTML, CSS, SVG, ECMAScript).
  • There must be a separate Core Techniques document that will provide information that is too specific for WCAG but not related to a specific technology, such as:
    • Mapping to Unicode
    • Media equivalents for multimedia
    • Clear and simple writing (4.1)
    • Supplementing with non-text content (4.2)
    • Summaries and definitions (4.3)
    • Others?
  • 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.
• Testability
  • Techniques related to Success Criteria must be testable. Guidance about testing methods may be provided.
  • Positive and negative test cases must be provided for testable techniques.
  • Techniques related to Additional Ideas should be testable when possible but may be untestable. There must be a declaration of the testability of the Technique.
  • Example implementations should be provided for untestable Techniques where possible.
• 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 Appendix C: 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.).
  • Each Technique must be assigned a unique identifier to enable machine-readable conformance statements.
• 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.
• Techniques should include descriptions, commentary, implementation notes, links to resources or training materials, etc. to contain information not part of the structured data.

Appendix A: Output formats

The Techniques are designed to meet a number of roles. 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.

• Checklists
  • List Techniques by Success Criterion to which they apply
  • Specify the Techniques as true/false statement
  • Implementation of the Techniques in the Checklist must be sufficient to provide complete implementation of the Success Criterion.
• Unabridged Techniques documents
• Test files
  • Granular files that provide positive or negative examples of each Technique.
  • Serve as a complete test suite for ER, AU, and UA tools.
  • A manifest file that provides machine-readable metadata about the techniques covered by each test file and whether it is a positive or negative test case.
• Techniques by conformance level
• Techniques by technology version
• Techniques by implementation status
• Test suite of positive and negative test cases

Appendix B: Fields

The following granualar units of information have been identified to meet the requirements above.

[To be provided]

Note: this section may not be needed. But it does provide documentation that bridges the requirements and the Schema.

Appendix C: XML DTD/Schema for Techniques

[To be provided]