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[begin delete] would[end delete] need to satisfy 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
[begin change][end change]1.) Conformance Level: One of the following levels of conformance is met in full. [2220]
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: 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.
The first requirement deals with the levels of conformance. They explain that no conformance is possible without at least satisfying all of the Level A success criteria either with a Web page or with a conforming alternate version of the Web page.
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 is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.
Note: 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.
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.
[2259]
Note 1: Because of conformance requirement 5, a whole page may conform even 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.
Note 2: It is possible to include non-conforming content. See Understanding Conformance Requirement 5.
Understanding Requirement 3
3.) Accessibility-Supported Technologies Only: Only [begin delete]documented [end delete]accessibility-supported Web technologies are relied upon to [begin add]satisfy the[end add] [begin delete] meet[end delete] success criteria. Any information or functionality that is implemented in technologies that are not accessibility supported must also be available via technologies that are accessibility supported. [begin add](See Understanding accessibility support.) [2276] [end add]
This conformance requirement is explained below under Understanding Accessibility Support.
Understanding Requirement 4
[begin change][end change]4.) Complete processes: When a series of Web pages present sequential steps that need to be completed in order to accomplish an activity, all Web pages in the series conform at a particular level. (Conformance is not possible at any level if all pages in the sequence do not conform at that level.)
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) must conform in order for any page that is part of the sequence 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 5
5.) Non-Interference: If Web 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. [begin delete]Specifically: [end delete] [begin add]Specifically, the Web page as a whole continues to meet the conformance requirements under all of the following conditions:[end add]
[begin add][end add]
when any (non accessibility-supported) technology is turned on in a user agent, and
when it is turned off in a user agent, and
when it is not supported by a user agent
[begin add][end add]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 criterion because they deal with things that could interfere with overall use of the page: 1.4.2 - Audio Control, 2.1.1 - Keyboard, 2.3.1 - Three Flashes or Below Threshold, and 2.2.2 - Pausing
[begin delete][end delete]
No Keyboard Trap: If focus can be moved to technologies that are not accessibility supported using a keyboard interface, then focus can be moved away from that content using only a keyboard interface, and the method for doing so is described before the content is encountered and in a way that meets all Level A success criteria.
Three Flashes or Below Threshold: To minimize the risk of seizures due to photosensitivity, content does not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds (see Success Criterion 2.3.1).
Non support: The content continues to meet the conformance requirements when the (non accessibility-supported) technology is turned on, turned off, or is not supported by a user agent.
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.
Note 1: 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.).
Note 2: Conformance claims are not usually located on each Web page within the scope of conformance.
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 provide more accessible content or 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
Examples of Required Components of Conformance Claims
Example 1: On 20 September 2008, all Web pages at http://www.example.com conform to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/. Level A conformance.
The documented set of accessibility-supported content technologies relied upon for this claim is a subset of ISA- AsCTset#1-2008 at http://ISA.example.gov/AsCTsets/AS2-2008.
Example 2: (using a regular expression) On 12 August 2008, pages matching the pattern http://www.example.com/(marketing|sales|contact)/.* conform to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/. Level AA conformance.
The technologies that this content "relies upon" is: XHTML 1.0 Transitional, CSS 2.0 and JavaScript 1.2.
Example 3: (using boolean logic) On 6 July 2008, http://example.com/ AND NOT (http://example.com/archive/ OR http://example.com/publications/archive/) conforms to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/. Level AA conformance.
The documented set of accessibility-supported content technologies relied upon for this claim includes XHTML 1.0 and SMIL from ISA- AsCTset#1-2008 at http://ISA.example.gov/AsCTsets/AS2-2008.
Examples of Conformance Claims including optional components
Example 1: On 5 May 2008, the page "G7: An Introduction" http://telcor.example.com/nav/G7/intro.html conforms to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/. Level AA conformance.
The following additional success criteria have also been met: 1.1.2, 1.2.5, and 1.4.3.
The documented set of accessibility-supported content technologies used for this claim is AsCTset#1-2006 at http://UDLabs.org/AsCTset#1-2006.html.
The technologies that this content "relies upon" is: XHTML 1.0 (Strict), and Real Video.
The technologies that this content "uses but does not rely upon" are: JavaScript 1.2, CSS2.
Example 2: On 21 June 2008, all content beginning with the URI http://example.com/nav and http://example.com/docs conform to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/. Level AAA conformance.
The documented set of accessibility-supported content technologies used for this claim is SMITH- AsCTset#2-2008 at http://smithreports.example.com/AsCTsets/AS2-2008.
The technologies that this content "relies upon" are: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, JPEG, PNG.
The user agents, including assistive technologies, that this content has been tested with can be found at http://example.com/docs/WCAG20/test/technologies.html.
Example 3: On 23 March 2008, all content available on the server at http://www.wondercall.example.com conforms to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/. Single-A conformance.
The technology that this content "relies upon" is: HTML 4.01.
The technologies that this content "uses but does not rely upon" are: CSS2, and gif.
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.
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:
[end add]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).
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:
[end add]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
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 use that technology or feature; whether the success criterion requires skills that could reasonably be achieved by the content creators (that is, the knowledge and skill to do this could be acquired with between 1 hour and a week's training).
[end delete]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 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).
[end delete]All success criteria must also be testable. This is important since otherwise it would not be possible to determine whether one met or failed to meet the success criteria. The success criteria can be either machine or human testable (or a combination of both) as long as it is possible to determine whether a success criterion has been satisfied with a high level of confidence.
[end delete]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:
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.
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.
New technologies won't be supported in older assistive technologies
Clearly, a new technology can not be supported by all past assistive technologies, so requiring that a technology be supported by all assistive technologies is not possible.
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 can not 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).
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
[begin add]To qualify as an accessibility-supported Web content technology (or feature of a technology), both of the following must be true for a Web content technology (or feature): [2174]
[end add][begin add]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
The Web content technology must have accessibility-supported user agents that are available to users. This means that at least one of the following is true:
The technology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS);
OR
The technology is supported in a widely-distributed plug-in that is also accessibility supported;
OR
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
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.
[begin add]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".)
[end add][begin add]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 3 (Accessibility-Supported Technologies) and Conformance Requirement 5 (Non-Interference) are met.
[end add]Note 3: When a Web Technology is "accessibility supported," it does not imply that the entire technology must be 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." [begin add]Pages conform to WCAG only if aspects or features of the technology that are accessibility supported can be relied upon to meet WCAG requirements. [2174] [end add]
[begin add]Note 4: When citing technologies that have multiple versions, the version(s) supported should be specified.
[end add][begin add]Note 5: The easiest way to be sure that the 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.) [2273] Some authors, companies or others may wish to document and use their own lists of accessibility-supported technologies. However, all technologies on the list must meet the definition of accessibility supported content technologies above. [2219]
[end add]
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.
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 can not 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
- [begin change]
version that
[end change]conforms at the designated level, and
provides all of the same information and functionality in the same human language, and
is as up to date as the non-conforming content, and
for which one of the following is true:
the conforming version can be reached from the non-conforming page via an accessibility supported mechanism, or
the non-conforming version can only be reached from the conforming version, or
the non-conforming version can only be reached from a conforming page that also provides a mechanism to reach the conforming version
[begin change]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.
[end change]Note 2: The alternate version does not need to be matched page for page with the original (e.g. the alternative to a page may consist of multiple pages).
Note 3: If multiple language versions are available, then conforming 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 must be fully conformant in order to meet conformance requirement 1.
Note 5: Alternate versions should not be confused with supplementary information, which support the original page and enhance comprehension.
Note 6: 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.
Sufficient Techniques for Providing Conforming Alternative Versions of Web pages.
Each numbered item below represents a technique or combination of techniques that the WCAG Working Group deems sufficient for providing conforming alternate versions.
- [begin delete]
Ensuring that the only way to get to an inaccessible version is from a link from the accessible version
[end delete] Using environment variables to ensure that the only way to access non-conforming content is from conforming content (future link)
- [begin add]
Using Metadata to allow location of Alternative Version from URI of Non-conforming Page (future link)
[end add]
Additional Techniques (Advisory) for providing conforming alternative versions of Web pages
Providing reciprocal links between conforming and non-conforming versions (future link)
Excluding non-conforming content from search results (future link)
Providing style switchers (future link)
Using content negotiation (future link)
Providing user settings as a way to store preferences (future link)
- [begin delete]
Using noframes (future link)
[end delete] - [begin delete]
Using noscript (future link)
[end delete] - [begin delete]
Using a fallback mechanism for applets (if applet not a relied on accessibility-supported content technology, need alternative mechanism for functionality) (future link)
[end delete] - [begin delete]
Using only technologies which are accessibility supported at the conformance level claimed (future link)
[end delete]
Examples of Conforming Alternate Versions
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 accessibility-supported content technologies. [begin delete]The requirements for each version were carefully documented, and both versions were available from the same URI, making it easy for each location to choose the version best suited to their needs.[end delete][begin add]The two versions link to each other. [2359] [end add]
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.
Understanding "Web Page"
The definition of a Web Page is:
- Web page
[begin add]a non-embedded resource that is referenced by a URI plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent [end add] [begin delete]a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it[end delete] [1948]
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://mail.example.com, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the 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 about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.
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.