Understanding Conformance

What does conformance mean?

Conformance to a standard means that you meet or satisfy the 'requirements' of the standard. In WCAG 2.0 the 'requirements' are the Success Criteria. To conform to WCAG 2.0, you need to satisfy the Success Criteria , that is, there is no content which violates the Success Criteria..

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.0 has three levels of conformance, and therefore, three levels of Success Criteria.

Understanding Conformance Requirements

There are five requirements that must be met in order for content to be classified as 'conforming' to WCAG 2.0. 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.

Understanding Requirement 1

1. Conformance Level: One of the following levels of conformance is met in full.

• Level A: 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.

• Level AA: 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.

• Level AAA: 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.

Note 1: Although conformance can only be achieved at the stated levels, authors are encouraged to satisfy and report progress toward meeting success criteria from all levels beyond the achieved level of conformance.

Note 2: 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.

Understanding Requirement 2

2. 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.

Note 1: For the purpose of determining conformance, a conforming alternative to part of a page's content is considered part of the page when the alternative content is obtainable directly from the page, e.g., a long description.

Note 2: Web pages that cannot conform due to content outside of the author's control may consider a Statement of partial conformance.

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.

Understanding Requirement 3

3. 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.)

Example: 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.

Understanding Requirement 4

4. Accessibility-Supported Technologies Only: Only accessibility supported technologies are relied upon to satisfy the success criteria. Any information or functionality that is implemented in technologies that are not accessibility supported are also be available via technologies that are accessibility supported. (See Understanding accessibility support.)

This conformance requirement is explained below under Understanding Accessibility Support.

Understanding Requirement 5

5. Non-Interference: If technologies that are not accessibility supported are used on a page, or accessibility-supported technologies 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 all of the following conditions:

1. when any technology that is not accessibility-supported is turned on in a user agent, and

2. when it is turned off in a user agent, and

3. when it is not supported by a user agent

Note: The following success criteria all apply to full pages including technologies that are not accessibility supported or relied upon to meet the other success criteria because they deal with things that could interfere with overall 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.

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.

Understanding Conformance Claims

It is not required to make any conformance claim in order to conform. If one does make a claim, however, the rules must be followed.

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.

Information about any additional steps taken that go beyond the Success Criteria

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.

Use of metadata to report conformance claims

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 the will be documented here.

Examples of Conformance Claims

Techniques for Conformance Claims

Understanding Levels of Conformance

First, there are a number of conditions that must be met for a Success Criterion to be included at all. These include:

1. All Success Criteria must be important access issues for people with disabilities that address problems beyond the usability problems that might be faced by all users. In other words, the access issue must cause a proportionately greater problem for people with disabilities than it causes people without disabilities in order to be considered an accessibility issue (and covered under these accessibility guidelines).

2. All Success Criteria must also be testable. This is important since otherwise it would not be possible to determine whether a page met or failed to meet the Success Criteria. The Success Criteria can be tested by a combination of machine and human evaluation as long as it is possible to determine whether a Success Criterion has been satisfied with a high level of confidence.

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:

• whether the Success Criterion is essential (in other words, if the Success Criterion isn't met, then even assistive technology can't make content accessible)

• whether it is possible to satisfy the Success Criterion for all Web sites and types of content that the Success Criteria would apply to (e.g. different topics, types of content, types of Web technology)

• whether the Success Criterion requires skills that could reasonably be achieved by the content creators (that is, the knowledge and skill to meet the Success Criteria could be acquired in a week's training or less)

• whether the Success Criterion would impose limits on the "look & feel" and/or function of the Web page. (limits on function, presentation, freedom of expression, design or aesthetic that the Success Criteria might place on authors)

• whether there are no workarounds if the Success Criteria is not met

Understanding Accessibility Support

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.

Level of Assistive Technology Support Needed for "Accessibility Support"

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 dialog on this topic. Some notes to help in understanding and exploring this topic are:

1. Accessibility support of Web technologies varies by environment

   • In a company where all employees are provided with particular user agents and assistive technologies, Web technologies may need to only be supported by those user agents and older assistive technologies.

   • Content posted to the public Web may need to work with a broader range of user agents and assistive technologies.

2. Accessibility support of Web technologies varies by language (and dialect)

   • There are different levels of older assistive technologies support in different languages and even countries. Some environments or countries may provide free assistive technologies.

3. New technologies won't be supported in older assistive technologies

   • Clearly, a new technology cannot be supported by all past assistive technologies, so requiring that a technology be supported by all assistive technologies is not possible.

4. Support for a single older assistive technology is usually not sufficient

   • Support by just one assistive technology (for a given disability) would not usually be enough, especially if most users who need it in order to access content do not have and cannot afford that assistive technology. The exception here would be information distributed to company employees only where they all have one assistive technology (of that type).

5. Currently assistive techology that is affordable by the general public is often very poor

   • Creating content that can't be used by the general pubic with disabilities should be avoided. In many cases, the cost of assistive technologies is too high for users who need it. Also, the capabilities of free or low cost AT is often so poor today that Web content cannot be realistically restricted to this lowest (or even middle) common denominator. This creates a very difficult dilemma that needs to be addressed.

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 consumers, technology developers and authors negatively.

Technical Definition of "Accessibility Support"

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

supported by users' assistive technologies as well as the accessibility features in browsers and other user agents

To qualify as an accessibility-supported Web content technology (or feature of a technology), both 1 and 2 must be satisfied for a Web content technology (or feature):

1. The Web content technology must be supported by users' assistive technology (AT). This means that the technology has been tested for interoperability with users' assistive technology in the human language(s) of the content,

   AND

2. The Web content technology must have accessibility-supported user agents that are available to users. This means that at least one of the following four statements is true:

   1. The technology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS);

      OR

   2. The technology is supported in a widely-distributed plug-in that is also accessibility supported;

      OR

   3. The content is available in a closed environment, such as a university or corporate network, where the user agent required by the technology and used by the organization is also accessibility supported;

      OR

   4. The user agent(s) that support the technology are accessibility supported and are available for download or purchase in a way that:

      • does not cost a person with a disability any more than a person without a disability and

      • is as easy to find and obtain for a person with a disability as it is for a person without disabilities.

Note 1: 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. (See Level of Assistive Technology Support Needed for "Accessibility Support".)

Note 2: Web technologies that are not accessibility supported can be used as long as they are not relied upon and the page as a whole meets the conformance requirements including Conformance Requirement 4: Accessibility-Supported Technologies Only and Conformance Requirement 5: Non-Interference are met.

Note 3: When a Web Technology is "accessibility supported," it does not imply that the entire technology is supported. Most technologies lack support for at least one feature. When documenting "accessibility support" for a technology, the support for specific aspects, features, and extensions should be cited if the technology as a whole is not accessibility supported. A profile of a technology may be used to give a name to the set of aspects, features, or extensions of a technology that are "accessibility supported." Pages conform to WCAG only if aspects or features of the technology that are accessibility supported can be relied upon to meet WCAG requirements.

Note 4: When citing Web content technologies that have multiple versions, the version(s) supported should be specified.

Note 5: The easiest way to be sure that the Web content technologies and features being used and relied upon are accessibility supported is to use technologies from documented lists of accessibility supported Web content technologies. (See Understanding Documented lists of Web technologies with Accessibility Support.) Some authors, companies or others may wish to document and use their own lists of accessibility-supported Web content technologies. However, all technologies on the list would need to meet the definition of accessibility supported Web content technologies above.

Understanding Documented lists of Web technologies with Accessibility Support

Because individual authors will not usually be able to do all of the research necessary to determine which features of which Web technologies are actually supported by which versions of assistive technologies and user agents, authors will usually rely on public documented lists of Web technologies that document which assistive technologies support which features of which Web technologies. By public, we only mean that the list and its documentation are public. Anyone can create a publicly documented list of "Web Technologies and their Accessibility Support." People may create recommended "documented lists of technologies" and give them a name (e.g. the XYZ Accessibility Coalition's 2007 Supported Technologies List) that authors can use. As long as they are publicly documented, authors or customers etc. can easily select lists that meet their needs. Customers or others can pick lists 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 choose lists that have an established reputation for accuracy and usefulness. Developers are strongly encouraged to provide information about the accessibility support for their technologies. The Working Group anticipates that only lists 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 public documented list be used or that only technologies from such a list be used. The public documented lists 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 lists of accessibility-supported technologies and this is allowed in meeting WCAG. Customers, companies or others may however specify that technologies from a custom or public list be used.See Appendix B Documenting Accessibility Support for a Web Technology.

Understanding "Programmatically Determined"

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, Flash 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 Quick Reference, 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" vs. "Programmatically Determined"

"Accessibility supported" relates to Web technologies. 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 use accessibility-supported technologies and features — and 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.

Understanding Conforming Alternate Versions

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

version that

1. conforms at the designated level, and

2. provides all of the same information and functionality in the same human language, and

3. is as up to date as the non-conforming content, and

4. for which at least one of the following is true:

   1. the conforming version can be reached from the non-conforming page via an accessibility supported mechanism, or

   2. the non-conforming version can only be reached from the conforming version, or

   3. the non-conforming version can only be reached from a conforming page that also provides a mechanism to reach the conforming version

Note 1: In this definition, "can only be reached" means that there is some mechanism, such as a conditional re-direct, that prevents a user from "reaching" (loading) the non-conforming page unless the user had just come from the specified page.

Note 2: The alternate version does not need to be matched page for page with the original (e.g. the conforming alternate version may consist of multiple pages).

Note 3: If multiple language versions are available, then conforming alternate versions are required for each language offered.

Note 4: Alternate versions may be provided to accommodate different technology environments or user groups. Each version should be as conformant as possible. One version would need to be fully conformant in order to meet conformance requirement 1.

Note 5: The conforming alternative version does not need to reside within the scope of conformance as long as it is as freely available as the non-conforming version.

Note 6: Alternate versions should not be confused with supplementary content , which support the original page and enhance comprehension.

Note 7: Setting user preferences within the content to produce a conforming version is an acceptable mechanism for reaching another version as long as the method used to set the preferences is accessibility supported.

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.

Why permit alternate versions?

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?

• Sometimes, pages use technologies that are not yet accessibility supported. When a new technology emerges, assistive technology support may lag behind, or may only be available to some target audiences. So authors may not be able to rely on the new technology for all users. However, there may be other benefits to using the new technology, e.g. better performance, a wider range of modalities available, etc. The alternate version requirement allows authors to include such Web pages in their Web site by providing an accessible alternative page in technologies that are accessibility supported. Users for whom the new technology is adequately supported get the benefits of the new version. Authors who look ahead to future accessibility support can satisfy the Success Criteria now with the alternate version page, and also work with the other page to build in future access when assistive technology (AT) support is available.

• For a variety of reasons, it may not be possible to modify some content on a Web page. For instance,

  • It may be critical to include an exact visual copy of a document for legal or historical reasons

  • The Web page may be included in a site but the site owner may not have the legal rights to modify the content on the original page

  • The company many not legally be able to remove, or alter in any way, something that was previously posted.

  • An author may not have permission to alter a document from another department, agency, or company

• Sometimes, the best experience for users with certain types of disabilities is provided by tailoring a Web page specifically to accommodate that disability. In such a situation, it may not be possible or practical to make the Web page accommodate all disabilities by satisfying all of the Success Criteria. The alternate versions requirement permits such specialized pages to be included within a conformance claim as long as there is a fully conformant 'alternate version' page.

• Many sites which are committed to accessibility have large quantities of legacy documents. While the information has been made available in accessible formats, there would be significant institutional resistance and procedural obstacles to removing these files en mass. Some organizations, especially governmental bodies, give precedence to traditional print-oriented processes. Even as these organizations have adapted to Internet publishing and embraced the need for accessible formats, they still retain a paper mindset and often insist on formats designed for hard copy as the "primary" version (even for documents that are only ever "published" electronically). Although the Working Group feels these approaches should be deprecated it does not feel they can be forbidden so long as accessible versions are readily available.

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.

Techniques for Providing a Conforming Alternate Version

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.

Understanding "Web Page"

The definition of a Web Page is:

Web page

a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent

Note 1: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.

Note 2: For the purposes of conformance with these guidelines, a resource must be "non-embedded" within the scope of conformance to be considered a Web page.

Example 1: A Web resource including all embedded images and media.

Example 2: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://example.com/mail, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.

Example 3: A customizable portal site, where users can choose content to display from a set of different content modules.

Example 4: When you enter "http://shopping.example.com/" in your browser, you enter a movie-like interactive shopping environment where you visually move around in a store dragging products off of the shelves around you and into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.This might be a single page Web site or just one page within a Web site.

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.