index.html
21.1 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en_US"><head><meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" /><title>Requirements for WCAG 2.0 Checklists and Techniques</title><style type="text/css">
code { font-family: monospace; }
div.constraint,
div.issue,
div.note,
div.notice { margin-left: 2em; }
li p { margin-top: 0.3em;
margin-bottom: 0.3em; }
div.exampleInner pre { margin-left: 1em;
margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
border-top-width: 4px;
border-top-style: double;
border-top-color: #d3d3d3;
border-bottom-width: 4px;
border-bottom-style: double;
border-bottom-color: #d3d3d3;
padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
</style><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" /></head><body><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home" /></a></p>
<h1><a id="title" name="title" />Requirements for WCAG 2.0 Checklists and Techniques</h1>
<h2><a id="w3c-doctype" name="w3c-doctype" />W3C Working Draft 07 February 2003</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2003/WD-wcag2-tech-req-20030207/">http://www.w3.org/TR/2003/WD-wcag2-tech-req-20030207/</a></dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/TR/wcag2-tech-req/">http://www.w3.org/TR/wcag2-tech-req/</a></dd><dt>Editor:</dt><dd>Michael Cooper, Watchfire <a href=""><michaelc@watchfire.com></a></dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2003 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.lcs.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p></div><hr /><div>
<h2><a id="abstract" name="abstract" />Abstract</h2><p>This is a W3C Working Draft produced by the <a href="http://www.w3.org/WAI/GL/">Web Content Accessibility Guidelines Working
Group</a> (WCAG WG). It describes requirements for Checklists and Techniques described by the <a href="http://www.w3.org/TR/WCAG20/">Web Content Accessibility Guidelines 2.0</a> (WCAG 2.0). These requirements are related to but different from <a href="http://www.w3.org/TR/wcag2-req/">Requirements for
WCAG 2.0</a> in that "Requirements for WCAG 2.0 Checklists and Techniques"
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. </p></div><div>
<h2><a id="status" name="status" />Status of this Document</h2><p>This section describes the status of this document at the time of its publication. Other documents may supersede this document. The <a href="http://www.w3.org/TR/wcag2-tech-req/">latest status of this document series</a> is maintained at the W3C.</p><p>Send comments about this document to the <a href="mailto:w3c-wai-gl@w3.org">Web Content Accessibility Guidelines Working Group mailing list</a>. The <a href="http://lists.w3.org/Archives/Public/w3c-wai-gl/">archives for this list</a> are publicly available.</p><p>Patent disclosures relevant to this specification may be found on the WCAG
Working Group's <a href="http://www.w3.org/WAI/GL/disclosures.html">patent
disclosure page</a> in conformance with W3C policy.</p><p>This document has been produced as part of the W3C <a href="/WAI/">Web Accessibility
Initiative</a> (WAI). The goals of the WCAG WG are discussed in the <a href="/WAI/GL/new-charter-2000.html">Working Group charter</a>. The WCAG WG is part of the <a href="/WAI/Technical/Activity">WAI Technical Activity</a>.</p><p>This document describes requirements for creating Checklists and Techniques
for the <a href="http://www.w3.org/TR/WCAG20">Web Content Accessibility Guidelines 2.0</a>. 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.</p><p>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 <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p></div><div class="toc">
<h2><a id="contents" name="contents" />Table of Contents</h2><p class="toc">1 <a href="#intro">Introduction</a><br />2 <a href="#defs">Definitions</a><br />3 <a href="#req-gen">General Requirements</a><br /> 3.1 <a href="#uses">Intended Uses</a><br /> 3.2 <a href="#scope">Scope of Documents</a><br /> 3.3 <a href="#structure">Structure</a><br /> 3.4 <a href="#relations-to-gl">Relation to WCAG 2.0</a><br />4 <a href="#req-techs">Techniques Requirements</a><br />5 <a href="#req-checklists">Checklist Requirements</a><br /></p>
<h3><a id="appendices" name="appendices" />Appendices</h3><p class="toc">A <a href="#outputs">Output Formats</a><br />B <a href="#fields">Fields</a><br />C <a href="#schema">Techniques Schema</a><br /></p></div><hr /><div class="body"><div class="div1">
<h2><a id="intro" name="intro" />1. Introduction</h2><p>The <a href="http://www.w3.org/WAI/GL/WCAG20/">Web Content Accessibility Guidelines 2.0</a> 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 <a href="http://www.w3.org/WAI/GL/WCAG20/#priorities-techs">Priorities and Techniques</a>. Specifically, this set of requirements fulfills <a href="http://www.w3.org/TR/wcag2-req/">WCAG 2.0 Requirements</a> to provide technology-specific Checklists and technology-specific Application Information.</p><p>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 <a href="#outputs"><b>A. Output Formats</b></a>). Each view may have its own requirements. The two views currently under discussion are comprehensive Techniques (<a href="#req-techs"><b>4. Techniques Requirements</b></a>) and Checklists (<a href="#req-checklists"><b>5. Checklist Requirements</b></a>). </p><p>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.</p></div><div class="div1">
<h2><a id="defs" name="defs" />2. Definitions</h2><p>[<a title="Testable" id="testable" name="testable">Definition</a>: <b>Testable</b>: Either <a title="Machine Testable" href="#machinetestable">Machine Testable</a> or <a title="Reliably Human Testable" href="#humantestable">Reliably Human Testable</a>.]</p><p>[<a title="Machine Testable" id="machinetestable" name="machinetestable">Definition</a>: <b>Machine Testable</b>: 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. Probabilistic algorithms are not sufficient.]</p><p>[<a title="Reliably Human Testable" id="humantestable" name="humantestable">Definition</a>: <b>Reliably Human Testable</b>: 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.]</p><p>[<a title="Not Reliably Testable" id="untestable" name="untestable">Definition</a>: <b>Not Reliably Testable</b>: 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.]</p></div><div class="div1">
<h2><a id="req-gen" name="req-gen" />3. General Requirements</h2><div class="div2">
<h3><a id="uses" name="uses" />3.1. Intended Uses</h3><ul><li><p>Techniques must be usable by a variety of audiences. Audiences that have been identified include</p><ul><li><p>Content developers</p></li><li><p>User agent developers</p></li><li><p>Evaluation tool developers</p></li><li><p>Authoring tool developers</p></li><li><p>Assistive technology developers</p></li><li><p>Training material developers</p></li><li><p>Guidelines developers</p></li><li><p>Operating System developers</p></li></ul></li><li><p>Source files must be structured in such a way that multiple views can be achieved. A list of specific views is provided in <a href="#outputs"><b>A. Output Formats</b></a>. Some views may be targeted to specific audiences and other views may be appropriate for multiple audiences.</p></li></ul></div><div class="div2">
<h3><a id="scope" name="scope" />3.2. Scope of Documents</h3><ul><li><p>Techniques should be grouped by particular technologies to which they apply (e.g., HTML, CSS, SVG, ECMAScript). </p></li><li><p>Core Techniques - a separate group of techniques that are not related to a specific technology - may be included.</p></li><li><p>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. </p><div class="note"><p class="prefix"><b>Note:</b></p><p>There is not consensus about whether it should be permissable to create techniques for technologies that cannot meet the minimum Success Criteria of the guidelines even in combination with other technologies.</p></div></li><li><p>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. </p></li><li><p>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., 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.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>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.</p></div></li><li><p>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. </p></li><li><p>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.</p></li></ul></div><div class="div2">
<h3><a id="structure" name="structure" />3.3. Structure</h3><ul><li><p>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 <a href="#schema"><b>C. Techniques Schema</b></a>.</p></li><li><p>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.</p></li><li><p>Each technique must be assigned a unique identifier to enable machine-readable
conformance statements.</p></li><li><p>Structure should be general enough that it can be used by groups outside
the WAI domain.</p></li><li><p>It must be possible for Techniques documents to be localized.</p></li><li><p>It must be possible to provide techniques that are applicable to specific
locales, but are not relevant in other locales.</p></li></ul></div><div class="div2">
<h3><a id="relations-to-gl" name="relations-to-gl" />3.4. Relation to WCAG 2.0</h3><ul><li><p>Each technique must map to a specific WCAG 2.0 Success Criterion or Additional
Idea by URI and number for clarity and to enable auto generation of hybrid
Guidelines/Techniques documents.</p></li><li><p>There may be multiple techniques for each Success Criterion or Additional
Idea, clearly stated that they are alternate techniques.</p></li><li><p>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.
</p></li></ul></div></div><div class="div1">
<h2><a id="req-techs" name="req-techs" />4. Techniques Requirements</h2><p>The following points are mandatory requirements for Techniques.</p><ul><li><p>Techniques related to Success Criteria must be <a title="Testable" href="#testable">testable</a>. Guidance about
testing methods may be provided.</p></li><li><p>Positive test cases must be provided for testable Techniques. Negative test cases should
be provided when possible.</p></li><li><p>Techniques related to Additional Ideas should be testable when possible
but may be <a title="Not Reliably Testable" href="#untestable">not reliably testable</a>. There must be a declaration of the testability of the
Technique.</p></li><li><p>Example implementations or descriptions of implementations should be provided
for untestable Techniques where possible.</p></li><li><p>Techniques should include descriptions, commentary, implementation notes,
links to resources or training materials, etc. to contain information not
part of the structured data.</p></li></ul></div><div class="div1">
<h2><a id="req-checklists" name="req-checklists" />5. Checklist Requirements</h2><p>The following points are mandatory requirements for Checklists.</p><ul><li><p>Technology-specific Checklists must include technology-specific
checklist items that address every Success Criterion in the guidelines.
Checklist items for success criteria that include an "or" statement should have
all related provisions included in one technology-specific checklist item.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>Normally, a Checklist view will include content drawn from techniques for multiple technologies described as in <a href="#scope"><b>3.2. Scope of Documents</b></a>. Each Success Criterion would be met by techniques drawn from one or more of the technologies 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.</p></div></li><li><p>Each Success Criterion addressed in a Checklist must 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 must be listed all together in
a single Checklist item as an "OR" proposition.</p></li><li><p>Checklists must be constructed such that all items in the
checklist for a given success criterion must be marked true in order for the content to be declared conformant at
any conformance level.</p></li><li><p>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. </p></li><li><p>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 listed separately.</p></li></ul></div></div><div class="back"><div class="div1">
<h2><a id="outputs" name="outputs" />A. Output Formats</h2><p>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.</p><p>The following output
formats have been identified and it must be possible to generate each of these
documents.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>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.</p></div><ul><li><p>Checklists </p><ul><li><p>List Techniques by Success Criterion to which they apply</p></li><li><p>Specify the Techniques as true/false statement</p></li><li><p>Implementation of the Techniques in the Checklist must be sufficient
to provide complete implementation of the Success Criterion.</p></li></ul></li><li><p>Unabridged Techniques documents</p></li><li><p>Test files </p><ul><li><p>Small files that provide single positive or negative examples of each Technique.</p></li><li><p>Contribute to test suites for Evaluation and Repair tools, Authoring tools, and User Agents.</p></li><li><p>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. </p></li></ul></li><li><p>Techniques by conformance level</p></li><li><p>Techniques by technology version</p></li><li><p>Techniques by implementation status</p></li></ul></div><div class="div1">
<h2><a id="fields" name="fields" />B. Fields</h2><p>The following granualar units of information have been identified to meet the
requirements above.</p><p>[To be provided]</p></div><div class="div1">
<h2><a id="schema" name="schema" />C. Techniques Schema</h2><p>[To be provided]</p></div></div></body></html>