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.
At the end of each guideline, there is also a sentence that says "In addition to the above success criteria there are additional, optional, strategies for making content more accessible by [insert phrase about what the guideline is about- for example "...providing text alternatives for all non-text content."] They can be found at {start link} Additional, optional, strategies for guideline [insert guideline number]{\end link}.
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 :
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 information would be included in this section:
The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.1 L1 SC1.
Instructions: Select the situation below that matches your content. Beneath it, are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.
Situation A: If all information in non-text content can be conveyed in a short description, the following would be sufficient:
Providing a text alternative AND Providing short text alternatives (using a technology-specific technique listed below)
Situation B: If all information in non-text content can not be conveyed in a short description (e.g. a chart or diagram), the following would be sufficient:
Providing a text alternative AND Providing long descriptions (using a technology-specific technique listed below) AND one of the following:
Technology-Specific Techniques for 1.1 L1 SC1
Under technology-specific techniques, you would find techniques for providing short text alternatives and long descriptions in HTML.
{NOTE 1: For each success criterion (Guide doc) there must be a least one option listed as being a way the working group feels that the success criterion can be met}
{NOTE 2: An author can use another technique that may be sufficient - but was not known or documented by the working group. A technique does not need to be known by WG to be sufficient. Using techniques known and believed by the WG to be sufficient can have more face validity if challenged. Any author can deem any technique they think of as being sufficient. If an author makes a claim of conformance, then that is in fact what they have done (claimed that what they did was sufficient to meet all the success criteria). Now if they have poor judgment and it isn't really sufficient, then someone may call them on it. In that case they would be in better shape if they had the W3C judgment as to what was sufficient than if they relied on their own judgment. But even the working group's judgments could be called into question in a court and overturned. We do not make laws or regulations. Just a standard. And only our Guideline is normative. Not the Guide Docs. Note that the version of our Guide Docs that is available when the WCAG 2.0 is approved will have special significance since it was available for those who approved the Guidelines at the time that the guidelines were approved.}
The current template for the Guide Documents can be found at: http://www.w3.org/WAI/GL/WCAG20/templates/guide-doc.htm. An example guide document for 1.1 L1 SC1 is also available.
Note: 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 is available. can be found at: http://www.w3.org/WAI/GL/WCAG20/templates/techniques.html
Note: 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 documents can be found at: http://www.w3.org/WAI/GL/WCAG20/templates/tests.html
Note: 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.
We often talk about whether a company can claim this or that. In fact, a company can claim anything they wish. Someone can challenge that claim but it would not be W3C since a standards organization usually does not get involved in enforcing standard conformance. If someone else challenged the author then the author would have to defend their claim in whatever jurisdiction the challenge was made in. Generally if they make a defense, it wouldn't be to us. So we don't get to agree or disagree (unless the court or purchasing agent asks us. In that case we would have to ask Judy / Tim if the WC3 wants to get into acting as expert witness in these things.) The author can still claim anything they want unless a court says it is fraud or the break some other law - in which case that law would stop them, not something we write or do. What we write or do may be used by others, including regulatory and legal entities. So we want to be very careful what we write. And the value of what we write will be because of any credibility we do or don't have.