The purpose of this document is to describe both the overall structure of the WCAG guidelines and supporting documents and to provide specifications and instructions to guide in their creation. This document is currently a proposal, but once approved by the working group, would be used by individual teams and task forces within the working group to guide their work. It will be amended as appropriate, but will be the guiding document representing the plan and structure as agreed to by the working group.
The WCAG Guidelines and supporting documents consist of the following 7 types of documents.
5 of the above 7 document types are atomic in nature. That is, they are not monolithic documents, but individual smaller documents, each focused on a specific sub item from the document above it (e.g. a single success criterion, technique, or test). The 2 exceptions are the Checklist (which is actually a piece of the Guidelines) and the Application Note Documents.
NOTE: We will be preparing just a single Annotated Checklist and a single Application Note (on Forms) in order to show how the needs addressed by these types of docs can be met – and to take the pressure off of the other documents to meet those needs so the documents can make it through review.
The WCAG 2.0 Guidelines are the only normative publications in the WCAG 2.0 document set. As such, they are the only document that creates requirements. The requirements in the WCAG 2.0 document can be found in the success criteria.
All success criteria must be reliably testable (either by machine or human with high inter rater reliability). To have ‘high inter rater reliability’ they must be objective enough that a supermajority of people who are knowledgeable would make the same judgment of pass/fail for a piece of content.
Each success criterion in WCAG 2.0 links to a Guide Document that provides additional information on the success criteria including the intent of the criterion and the currently documented techniques available for addressing it.
There is a separate Guide Document for each success criterion. The purpose is not to define the success criterion. That must be done by the normative sections of the guidelines document. Rather, it is to help people who are less familiar with the WCAG understand the needs being addressed by the SC and the different techniques that are known and documented that might be used to meet the SC.
It is critical that the language in the Guide Documents not interpret the success criteria nor define what compliance would mean. This would make the documents normative meaning that content would need to comply with them to claim conformance to WCAG 2.0. If these documents are to become normative, they would need to go through the W3C process of review and approval to become W3C Recommendations each time they were to be updated.
The Guide Documents would, however, list known and documented techniques that could be used to satisfy the success criterion when using different technologies. That is, they would list and link to techniques that are known to be sufficient to satisfy the success criteria.
The Guide Documents for each success criteria may also include additional advisory information that goes beyond what is required by the success criterion. This information will be clearly identified as advisory and would be in a special section of the Guide Document.
In addition to the Guide Document for each success criterion, there is also an additional Guide Document for each guideline. This Guide Document contains any additional advisory information that is related to the Guideline – but not tied to any specific Success Criteria. This guide doc has a slightly different form since it only contains information on optional or advisory techniques.
The parts of a Guide Document (for success criterion) are :
{Lists techniques or combinations of techniques that are known and documented and that the WCAG feels are sufficient to meet the success criterion. Generic strategies are used in place of technology specific techniques. the technology specific form for each generic strategy is then listed below.
For example, for
“For all non-text content that is used to convey information, text alternatives identify the non-text content and convey the same information.”
The following are known to be sufficient
OPTION 1:
Using a short text alternative and not using placeholder text
Then under technology independent techniques you would find the technique “not using placeholder text”
Under technology specific HTML you would find the HTML technique for “short text alternative”
{Lists technology independent techniques with link to their descriptions}
{example of tech indep technique.
{Lists technology specific techniques that map to the generic techniques described above.
{example
The current template for the Guide Documents can be found at: http://www.w3.org/WAI/GL/2005/08/wcag-templates/guide-doc.htm.
[A collection of all Guide Documents will be available as a single document. It would consist of just a page or so of front-matter and then a concatenation of individual Guide Documents for each of the success criteria and Guideline Advisory Material. ]
Each technique listed in a Guide Document is described in its own individual techniques document.
Information about whether an individual technique or set of related techniques is sufficient to satisfy a success criterion is provided only in the Guide doc for that success criterion. Techniques documents will not discuss any technique in terms of conformance (i.e., terms such as “required,” “optional,” “sufficient,” and “advisory” will not appear in the technology-specific techniques documents. This will avoid creating the misleading impression that the techniques documents are normative.
The techniques docs describe the techniques, but do not make any claims about their being required or not required to meet an SC or a guideline (or WCAG 2.0 as a whole). They also do not make statements about being sufficient for an SC. That information is contained in the Guide Doc (and perhaps also in an annotated checklist – that would draw the sufficiency (individually or in combination with other techniques) from the Guide Doc for the SC.
The parts of a techniques document are
The current template for the Techniques Docs can be found at: http://www.w3.org/WAI/GL/2005/08/wcag-templates/techniques.html
[A collection of all technique documents will be available as a single document. The techniques in the compilation would not be organized or grouped - just assembled in a flat listing of all documented techniques. It would consist of a page or so of front-matter and then a concatenation of individual Technique Docs. It is likely that collections will (also) be organized by technology].
Each test is in its own document except where grouping tests facilitates their understanding or where a technique requires multiple tests {though this should be looked at carefully to be sure they aren’t multiple techniques or measures}.
Tests do not themselves prove conformance to the WCAG 2.0 as a whole or even conformance to a success criterion. They are tests of whether a particular technique has been done properly. Passing a test may mean that a technique was successfully used. If (and only if) that technique is sufficient for meeting the SC would the SC be satisfied.
Note, however, that failing an individual test does not mean that the SC was not met. There may be other techniques that might be used to meet a given success criterion. Or, the content may also be available in a multiple forms one of which does meet the success criterion.
Note also that many tests are for techniques that are not part of any set that is sufficient to meet a Success Criteria. They may instead be associated with advisory techniques. In these cases, it is possible to test whether the technique has been implemented, but the result would have no effect on conformance to WCAG 2.0 (though it may be required by a customer or helpful in identifying specific user agent support issues).
The parts of a test document are:
The current template for the Test Note Docs can be found at: http://www.w3.org/WAI/GL/2005/08/wcag-templates/tests.html
[A collection of all test documents will be available as a single document. It would not have any structure other than to have a page or so of front matter and then a concatenation of individual test documents. These test collections will probably be organized by technology. ]
There are different ways the WCAG 2.0 documents can be used.
One would be to pick up the guidelines and read through them. For more information on any success criterion, the individual would click on the “ How to” link. This will take them to the guide document where they can:
Since the techniques are only listed by name in this document, users who want more information would activate the link for the technique (the technique name) and it would jump them into a document that describes just that technique.
If they wanted to know how to test for this technique, they would look in the ‘tests for this technique” section of the techniques document. By clicking on any test listed there – they would jump to a document that describes just that test.
The person starts with an annotated checklist. This checklist is for HTML and CSS. For each SC it lists the techniques or combination of techniques (by name) that would satisfy that SC. If they want more information on a technique, they can click on its name in the Annotated Checklist. This will jump the person to the techniques doc for that technique. (this could be done for both techniques that meet an SC and techniques that are just advisory).
Again, if they wanted to know how to test for this technique, they would look in the ‘tests for this technique” section of the techniques document. By clicking on any test listed there – they would jump to a document that describes just that test.
The user wants to known how to do FORMs properly. This involves different scattered SC from different guidelines. This user would turn to the FORMS Application Notes that would provide an overview of accessible forms plus lists of relevant success criteria and applicable techniques.