All WCAG 2 success criteria are written as testable criteria for objectively determining if content satisfies them. Testing the success criteria would involve a combination of automated testing and human evaluation. The content should be tested by those who understand how people with different types of disabilities use the Web.
Testing and testable in the context refer to functional testing, that is verifying that the content functions as expected, or in this case, that it satisfies the success criteria. Although content may satisfy all success criteria, the content may not always be usable by people with a wide variety of disabilities. Therefore, usability testing is recommended, in addition to the required functional testing. Usability testing aims to determine how well people can use the content for its intended purpose. It is recommended that users with disabilities be included in test groups when performing usability testing.
Conformance to a standard means that you meet or satisfy the 'requirements' of the standard. In WCAG 2 the 'requirements' are the success criteria. To conform to WCAG 2, you need to satisfy the success criteria, that is, there is no content which violates the success criteria.
This means that if there is no content to which a success criterion applies, the success criterion is satisfied.
Most standards only have one level of conformance. In order to accommodate different situations that may require or allow greater levels of accessibility than others, WCAG 2 has three levels of conformance, and therefore, three levels of success criteria.
There are five requirements that must be met in order for content to be classified as 'conforming' to WCAG 2. This section provides brief notes on those requirements. This section will be expanded over time to address questions that may arise or to provide new examples of ways to meet the different conformance requirements.
Conformance Level: One of the following levels of conformance is met in full.
- For Level A conformance (the minimum level of conformance), the Web page satisfies all the Level A success criteria, or a conforming alternate version is provided.
- For Level AA conformance, the Web page satisfies all the Level A and Level AA success criteria, or a Level AA conforming alternate version is provided.
- For Level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA success criteria, or a Level AAA conforming alternate version is provided.
Although conformance can only be achieved at the stated levels, authors are encouraged to report (in their claim) any progress toward meeting success criteria from all levels beyond the achieved level of conformance.
It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.
The first requirement deals with the levels of conformance. It basically says that all information on a page conforms or has a conforming alternate version that is available from the page. The requirement also explains that no conformance is possible without at least satisfying all of the Level A success criteria.
The note points out that authors are encouraged to go beyond conformance to a particular level and to complete, and report if they desire, any progress toward higher levels of conformance.
See also Understanding Conforming Alternate Versions which includes techniques for providing Conforming Alternate Versions.
Full pages: Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.
For the purpose of determining conformance, alternatives to part of a page's content are considered part of the page when the alternatives can be obtained directly from the page, e.g., a long description or an alternative presentation of a video.
Authors of Web pages that cannot conform due to content outside of the author's control may consider a Statement of Partial Conformance.
A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.
This provision simply requires that the whole page conform. Statements about "part of a page conforming" cannot be made.
Sometimes, supplemental information may be available from another page for information on a page. The longdesc attribute in HTML is an example. With longdesc, a long description of a graphic might be on a separate page that the user can jump to from the page with the graphic. This makes it clear that such content is considered part of the Web page, so that requirement #2 is satisfied for the combined set of Web pages considered as a single Web page. Alternatives can also be provided on the same page. For example creating an equivalent to a user interface control.
Because of conformance requirement 5, a whole page may conform even if parts of the page use non accessibility-supported content technologies as long as they do not interfere with the rest of the page and all information and function is available elsewhere on or from the page.
It is possible to include non-conforming content. See Understanding Conformance Requirement 5.
Complete processes: When a Web page is one of a series of Web pages presenting a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), all Web pages in the process conform at the specified level or better. (Conformance is not possible at a particular level if any page in the process does not conform at that level or better.)
An online store has a series of pages that are used to select and purchase products. All pages in the series from start to finish (checkout) conform in order for any page that is part of the process to conform.
This provision prevents a Web page that is part of a larger process from being considered conforming if the process overall is not. This would prevent a shopping site from being classified as conforming if the checkout or other features of the site that are part of the shopping and buying process do not conform.
Only Accessibility-Supported Ways of Using Technologies: Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported. (See Understanding accessibility support.)
This conformance requirement is explained below under Understanding Accessibility Support.
Non-Interference: If technologies are used in a way that is not accessibility supported, or if they are used in a non-conforming way, then they do not block the ability of users to access the rest of the page. In addition, the Web page as a whole continues to meet the conformance requirements under each of the following conditions:
- when any technology that is not relied upon is turned on in a user agent,
- when any technology that is not relied upon is turned off in a user agent, and
- when any technology that is not relied upon is not supported by a user agent
In addition, the following success criteria apply to all content on the page, including content that is not otherwise relied upon to meet conformance, because failure to meet them could interfere with any use of the page:
- 1.4.2 - Audio Control,
- 2.1.2 - No Keyboard Trap,
- 2.3.1 - Three Flashes or Below Threshold, and
- 2.2.2 - Pause, Stop, Hide.
If a page cannot conform (for example, a conformance test page or an example page), it cannot be included in the scope of conformance or in a conformance claim.
This basically says that technologies that are not accessibility supported can be used, as long as all the information is also available using technologies that are accessibility supported and as long as the non-accessibility-supported material does not interfere.
Technologies that are not accessibility supported can be used, or technologies that are accessibility supported can be used in a non conforming manner, as long as all the information is also available using technologies that are accessibility supported, in a manner that does conform, and as long as the non-accessibility-supported material does not interfere.
There are four provisions that particularly deal with issues of interference with use of the page. These four are included in a note here. A note on each of the provisions indicates that these success criteria need to be met for all content including content created using technologies that are not accessibility supported.
A Web page incorporates a new interactive graphic technology called "ZAP". Although ZAP is not accessibility-supported, the information that is presented in ZAP is also presented on the page in HTML, so ZAP is not relied upon. So, this page would pass conformance requirement #1. However, if the user tries to tab through the ZAP content, the focus drops into the ZAP object and gets stuck there. Once inside, there is nothing the user can do to get the focus back out. So keyboard users cannot use the bottom half of the page. The ZAP content also is continually flashing brightly at different rates and doesn't stop. So, people with attention deficit are distracted and those with photosensitive seizure disorders may have seizures. Conformance requirement #5 prevents situations like these from being possible on a conforming page.
It is not required to make any conformance claim in order to conform. If one does make a claim, however, all the information required in a conformance claim must be provided. There are a number of ways this information can be provided.
Schema.org provides one such option for including discovery metadata within a Web page. A set of descriptive accessibility properties is available under the CreativeWork type which, among other uses, provides the ability to include a summary of the overall accessibility of the page (e.g., the WCAG conformance claim), describe the accessible features of the content (e.g., availability of alternative text, extended descriptions and captions), and alert users to potential hazards (e.g., flashing). This information can be embedded in the page using any of RDFa, JSON and microdata. More information about these properties and their expected values is also available on the Web Schemas wiki.
Here is a claim which has been enhanced with schema.org metadata:
<div typeof="WebPage" vocab="http://schema.org/">
<p property="accessibilitySummary">On 23 March 2009, all content available on
the server at <a
href="http://www.wondercall.example.com">http://www.wondercall.example.com</a>
conforms to Web Content Accessibility Guidelines 2.0 at <a
href="https://www.w3.org/TR/2008/REC-WCAG20-20081211/"
>https://www.w3.org/TR/2008/REC-WCAG20-20081211/</a>.
Single-A conformance.</p>
<ul>
<li>The technology that this content "<a>relies upon</a>" is:
HTML 4.01.</li>
<li>The technologies that this content "<strong>uses but does not rely
upon</strong>" are: CSS2, and gif.</li>
<li>This content was tested using the following user agents and assistive
technologies: Firefox 1.5 on Windows Vista with Screenreader X 4.0,
Firefox 1.5 on Windows XP SP 2 with Screenreader X 3.5, IE 6.0 on Windows
2000 SP4 with Screenreader Y 5.0, IE 6.0 on Windows 2000 SP4 with
Screenreader Z 2.0, and Firefox 1.5 on Windows XP SP2 with Screenreader
X 4.0, Safari 2.0 with OS X 10.4.</li>
</ul>
<p>This page includes both <span property="accessMode" content="textual">text</span>
and <span property="accessMode" content="visual">images</span>.
<span property="accessibilityFeature" content="alternativeText">Alternative
text</span> is included for all image content and <span
property="accessibilityFeature" content="longDescription">long
descriptions</span> are also provided for images that require more
than simple alternate text. All content is available in text, which
can be accessed by assistive technology.</p>
</div>
Sometimes, one may want to make a claim for just the content that was added after a certain date. Or, one may want to claim WCAG 1.0 conformance for content up to a date and WCAG 2.0 for content that was created or modified after that date. There are no prohibitions in WCAG 2.0 to any of these practices as long as it is clear which pages are claiming conformance to which version of WCAG.
When talking about technologies that are "relied upon," we're talking about Web content technologies (HTML, CSS, JavaScript, etc.), not user agents (browsers, assistive technologies, etc.).
Conformance claims are not usually located on each Web page within the scope of conformance.
When an author makes a decision to use a third party implementation, they should choose products that meet WCAG requirements. If all content on a page, including third party content, meets all WCAG success criteria then the page conforms to WCAG. However, if the page does not conform to WCAG only for reasons that are legitimately outside the author's control then the author can make a claim of partial conformance. It is important to recognize that this is a statement of non-conformance and there are users who may not be able to access some of the content this page.
One reason that content may be outside the author's control is because it is being provided by a third party (blogs, portals, news sites). Web pages may also include content via third party libraries, plugins, or widgets.
Be sure to monitor any content that can change without approval from the web page author, as a page which once conformed may suddenly fail to conform. If it is not possible to monitor and repair the third party content, it is necessary to identify the non-conforming parts of the page for users. If the rest of the web page conforms to WCAG, such a page qualifies for a statement of partial conformance, third party content.
One of the optional components of a conformance claim is "Information about any additional steps taken that go beyond the success criteria to enhance accessibility." This can include additional success criteria that have been met, advisory techniques that were implemented, information about any additional protocols used to aid access for people with particular disabilities or needs, etc. Any information that would be useful to people in understanding the accessibility of the pages may be included.
The most useful way of attaching conformance claims to content would be to do so in standard machine readable form. When this practice is widespread, search tools or special user agents will be able to make use of this information to find and provide content that is more accessible or so the user agents can adjust to the content. There are a number of metadata based options under development for making claims, and authors and tool developers are encouraged to support them.
In addition, metadata can be used to report conformance to individual success criteria once Level A conformance has been achieved.
There are also programmatic reporting formats such as Evaluation and Report Language (EARL) that are being developed that could provide machine readable formats for detailed conformance information. As the reporting formats are formalized and support for them develops, they will be documented here.
On 20 September 2009, all Web pages at http://www.example.com conform to Web Content Accessibility Guidelines 2.0 at https://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level A conformance.
(using a regular expression) On 12 August 2009, pages matching the pattern http://www.example.com/(marketing|sales|contact)/.* conform to Web Content Accessibility Guidelines 2.0 at https://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level AA conformance.
(using boolean logic) On 6 January 2009, http://example.com/ AND NOT (http://example.com/archive/ OR http://example.com/publications/archive/) conforms to Web Content Accessibility Guidelines 2.0 at https://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level AA conformance.
On 5 May 2009, the page "G7: An Introduction" http://telcor.example.com/nav/G7/intro.html conforms to Web Content Accessibility Guidelines 2.0 at https://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level AA conformance.
On 21 June 2009, all content beginning with the URI http://example.com/nav and http://example.com/docs conform to Web Content Accessibility Guidelines 2.0 at https://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level AAA conformance.
On 23 March 2009, all content available on the server at http://www.wondercall.example.com conforms to Web Content Accessibility Guidelines 2.0 at https://www.w3.org/TR/2008/REC-WCAG20-20081211/. Single-A conformance.
First, there are a number of conditions that must be met for a success criterion to be included at all. These include:
The success criteria were assigned to one of the three levels of conformance by the working group after taking into consideration a wide range of interacting issues. Some of the common factors evaluated when setting the level included:
Many of the success criteria deal with providing accessibility through assistive technologies or special accessibility features in mainstream user agents (for example, a 'show captions' option in a media player). That is, the success criteria require that something be done in the Web content that would make it possible for assistive technologies to successfully present the content's information to the user. For example, a picture that you were supposed to click on to go to a topic would not be accessible to a person who was blind unless text alternatives for the picture were provided in a way that user agents including assistive technologies can find and display them. The key here is that the text alternative must be included in a way that user agents including assistive technologies can understand and use – in a way that is "Accessibility Supported."
Another example would be a custom control that is included on a Web page. In this case, a standard user agent would not ordinarily be able to present an alternative to the user. If, however, information about the control including its name, role, value, how to set it etc. are provided in a way that assistive technologies can understand and control them, then users with assistive technologies will be able to use these controls.
When new technologies are introduced, two things must happen in order for people using assistive technologies to be able to access them. First, the technologies must be designed in a way that user agents including assistive technologies could access all the information they need to present the content to the user. Secondly, the user agents and assistive technologies may need to be redesigned or modified to be able to actually work with these new technologies.
"Accessibility Supported" means that both of these have been done and that the technology will work with user agents and assistive technologies.
This topic raises the question of how many or which assistive technologies must support a Web technology in order for that Web technology to be considered "accessibility supported". The WCAG Working group and the W3C do not specify which or how many assistive technologies must support a Web technology in order for it to be classified as accessibility supported. This is a complex topic and one that varies both by environment and by language. There is a need for an external and international dialogue on this topic. Some notes to help in understanding and exploring this topic are:
Accessibility support of Web technologies varies by environment
Accessibility support of Web technologies varies by language (and dialect)
New technologies won't be supported in older assistive technologies
Support for a single older assistive technology is usually not sufficient
Currently assistive technology that is affordable by the general public is often very poor
The Working Group, therefore, limited itself to defining what constituted support and defers the judgment of how much, how many, or which AT must support a technology to the community and to entities closer to each situation that set requirements for an organization, purchase, community, etc.
The Working Group encourages more discussion of this topic in the general forum of society since this lack of generally available yet robust assistive technologies is a problem that affects users, technology developers and authors negatively.
Basically, a Web content technology is "accessibility supported" when users' assistive technologies will work with the Web technologies AND when the accessibility features of mainstream technologies will work with the technology. Specifically, to qualify as an accessibility-supported technology, the following must be true for a technology:
accessibility supported
Individual authors will not usually be able to do all of the testing necessary to determine which ways of using which Web technologies are actually supported by which versions of assistive technologies and user agents. Authors may therefore rely on publicly documented compilations that document which assistive technologies support which ways of using which Web technologies. By public, we do not mean that the compilation and its documentation are necessarily generated by a public agency, only that they are available to the public. Anyone can create publicly documented compilations of "Web Technology Uses and their Accessibility Support." People may create compilations and give them names that authors can refer to them by. As long as they are publicly documented, authors or customers etc. can easily select uses that meet their needs. Customers or others can pick technologies that fit their environment or language at any point in time and specify those to be used in creating their content. Authors are strongly encouraged to use sources that have an established reputation for accuracy and usefulness. Technology developers are strongly encouraged to provide information about the accessibility support for their technologies. The Working Group anticipates that only documents that provide accurate information and benefit both authors and users will achieve market recognition in the long term.
There is no requirement in WCAG that a publicly documented compilation be used or that only technology uses from such a compilation be used. The publicly documented compilations are described only as a method to make an otherwise critical, but somewhat complicated, aspect of conformance easier for authors who are not themselves experts on assistive technology support (or who just don't have the time to keep up with advances in mainstream and assistive technology support for each other).
Authors, companies or others may wish to create and use their own compilations of accessibility-supported technology uses and this is allowed in meeting WCAG. Customers, companies or others may, however, specify that technology uses from a custom or public compilation be used. See Documenting Accessibility Support for Uses of a Web Technology.
Examples of ways in which a conformance claim might document its accessibility support include:
Several success criteria require that content (or certain aspects of content) can be "programmatically determined." This means that the content is authored in such a way that user agents, including assistive technologies, can access the information.
In order for content created with Web technologies (such as HTML, CSS, PDF, GIF, MPEG, etc.) to be accessible to people with different types of disabilities, it is essential that the technologies used work with the accessibility features of browsers and other user agents, including assistive technologies. In order for something to meet a success criterion that requires it to be "programmatically determined," it would need to be implemented using a technology that has assistive technology support.
Content that can be "programmatically determined" can be transformed (by user agents including AT) into different sensory formats (e.g., visual, auditory) or styles of presentation need by individual users. If existing assistive technologies cannot do this, then the information cannot be said to be programmatically determined.
The term was created in order to allow the working group to clearly identify those places where information had to be accessible to assistive technologies (and other user agents acting as accessibility aids) without specifying exactly how this needed to be done. This is important because of the continually changing nature of the technologies. The term allows the guidelines to identify what needs to be "programmatically determined" in order to meet the guidelines, and then have separate documents (the How to Meet, Understanding, and Technique documents), which can be updated over time, list the specific techniques that will work and be sufficient at any point in time based on user agent and assistive technology support.
"Accessibility supported" relates to support by user agents (including assistive technologies) of particular ways of using Web technologies. Uses of Web technologies that are accessibility supported will work with assistive technologies and access features in mainstream user agents (browsers and players etc.).
"Programmatically determined" relates to the information in Web Content. If technologies that are accessibility supported are used properly, then assistive technologies and user agents can access the information in the content (i.e., programmatically determine the information in the content) and present it to the user.
The two concepts work together to ensure that information can be presented to the user by user agents including assistive technologies. Authors must rely only on uses of technologies that are accessibility-supported — and must use them properly in order for the information to be programmatically determinable — and hence presentable, by assistive technologies and user agents to users with disabilities.
Conformance requirement #1 allows non-conforming pages to be included within the scope of conformance as long as they have a "conforming alternate version". The conforming alternative version is defined as:
conforming alternate version
This ensures that all of the information and all of the functionality that is on the pages inside of the scope of conformance is available on conforming Web pages.
Authors relying on conforming alternate versions must make end users aware that a conforming alternate version is available. This may be accomplished by providing a link to a more accessible version, identified clearly by link text. Alternatively a link to instructions may be provided which documents how to access a more accessible version as well as the specific ways the alternate version is more accessible (e.g. a "high contrast version").
Why does WCAG permit conforming alternate versions of Web pages to be included in conformance claims? That is, why include pages that do not satisfy the success criteria for a conformance level in the scope of conformance or a claim?
For a variety of reasons, it may not be possible to modify some content on a Web page. For instance,
A concern when permitting Web pages that do not satisfy the success criteria is that people with disabilities will encounter these non-conforming pages, not be able to access their content, and not be able to find the “conforming alternate version." A key part of the alternate versions provision, therefore, is the ability to find the conforming page (the alternate version) from the non-conforming page when it is encountered. The conformance requirement that permits alternate pages, therefore, also requires a way for users to find the accessible version among the alternate versions.
Note that providing an alternate version is a fallback option for conformance to WCAG and the preferred method of conformance is to make all content directly accessible.
The most important part of providing a conforming alternate version is providing a mechanism to find it from the non-conforming version. A number of different methods for doing this have been identified since particular techniques may not always be possible for specific technologies or situations. For example, if the author has control of the server there are some powerful techniques that will allow users to always have the choice up front. In many cases however the author may not have control of the services on their Web server. In these cases other techniques are provided. A link on the non-conforming page is another powerful technique but not all non-conforming technologies support hypertext links.
Below are the techniques that have been identified to date. We expect that additional techniques will also be developed over time and they will be added here as they arise and the support for these approaches by user agents including assistive technologies can be demonstrated. For example a developer of a new technology that some assistive technologies cannot access might build in a feature that would allow those technologies to automatically present a link to users that could take them to an alternate version.
Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see , particularly the "Other Techniques" section.
An intranet site with multiple versions.
A large company was concerned that the use of emerging Web technologies on an intranet site might limit their ability to address the needs of diverse office locations that have different technology bases and individual employees who use a wide variety of user agents and assistive technologies. To address these concerns, the company created an alternate version of the content that met all Level A success criteria using a more limited set of uses of accessibility-supported content technologies. The two versions link to each other.
An informational site ensuring backward compatibility.
An information site covers a wide variety of subjects and wants to enable visitors to quickly find the topics they are looking for. To do this, the site has implemented an interactive menu system that is only supported in the most recent version of two popular user agents. To ensure that visitors who do not use these specific user agents are still able to effectively use the site, a navigation mechanism that does not depend on the interactive menu system is presented to user agents that do not support the newer technology.
The definition of a Web Page is:
web page
It is important to note that, in this standard, the term "Web page" includes much more than static HTML pages. The term 'Web Page' was used in these guidelines to allow the guidelines to be more understandable. But the term has grown in meaning with advancing technologies to encompass a wide range of technologies, many of which are not at all 'page-like'. It also includes the increasingly dynamic Web pages that are emerging on the Web, including "pages" that can present entire virtual interactive communities. For example, the term "Web page" would include an immersive interactive movie-like experience that you find at a single URI.
A text alternative is text that is used in place of non-text content for those who cannot view the non-text content. Non-text content includes such things as pictures, charts, applets, audio files, etc. People who cannot see for example would not be able to see information presented in a picture or chart. A text alternative is therefore provided that allows the user to be able to convert the information (the text) into speech. In the future, having the information in text also makes it possible to translate the information into sign language, into pictures, or into a simpler form of writing.
In order for people with disabilities to be able to use this text - the text must be "programmatically determinable." This means that the text must be able to be read and used by the assistive technologies (and the accessibility features in browsers) that people with disabilities use.
It must also be possible for people using assistive technologies to find these text alternatives when they encounter non-text content that they cannot use. To accomplish this, we say that the text must be "programmatically associated" with the non-text content. This means that the user must be able to use their assistive technology to find the alternative text (that they can use) when they land on the non-text content (that they can't use).