The presentation of this document has been augmented to identify changes from a previous version. Three kinds of changes are highlighted: [begin add] new, added text [end add], [begin change] changed text [end change], and [begin delete] deleted text [end delete].
[contents]
This document is also available in these non-normative formats:
Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Web Content Accessibility Guidelines 2.0 (WCAG 2.0) covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech difficulties, photosensitivity and combinations of these. Following these guidelines will also make your Web content more accessible to the vast majority of users, including some older users. These guidelines however are not able to address the needs of all people with disabilities.
WCAG 2.0 success criteria are written as testable statements that are not technology-specific. Guidance about satisfying the success criteria in specific technologies as well as general information about interpreting the success criteria are provided in separate documents. An Overview of Web Content Accessibility Guidelines (WCAG) 2.0 Last Call Documents is also available.
Until WCAG 2.0 advances to W3C Recommendation, the current and referenceable document is Web Content Accessibility Guidelines 1.0 [WCAG10], published as a W3C Recommendation May 1999.
This document is the internal working draft used by the WCAG WG and is updated continuously and without notice. This document has no formal standing within W3C. Please consult the group's home page and the W3C technical reports index for information about the latest publications by this group.
This draft includes revisions that have been made since the 17 May 2007 Working Draft was published. Please refer to the latest public version of WCAG 2.0 for information about the status of WCAG 2.0 as well as information about submitting comments to the working group.
History of Changes to WCAG 2.0 Working Drafts
This section is informative.
This is a Working Draft of the Web Content Accessibility Guidelines (WCAG) version 2.0. WCAG is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a single shared standard for Web accessibility that meets the needs of individuals, organizations, and governments internationally.
WCAG 2.0 builds upon the work of WCAG 1.0 [WCAG10] with provisions that are more testable and that extend to a broader range of technologies including many that are new and evolving. WCAG 2.0 has been created to be technology independent. That is, the guidelines and success criteria in WCAG 2.0 can be applied across a wide range of existing and emerging Web technologies. Rather than specifying what technologies to use, WCAG 2.0 lays out general guidelines for using technologies along with specific testable success criteria for guiding and evaluating the use of the technologies.
WCAG 2.0 provides requirements for making Web content more accessible to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, and others. Because many people develop vision, hearing, cognitive or motion impairments as they age, following these guidelines will make your Web content more usable by many older users. [begin add]These guidelines also often make Web content more accessible to the general public as well. [2011] [end add] However, even content that completely conforms to WCAG may not be fully accessible to every person with a disability.
WCAG 2.0 covers a wide range of recommendations for making Web content more accessible. The guidelines do not include standard usability recommendations except where they have a significantly greater impact on people with disabilities than on other people.
Although some of the accessibility issues of people with cognitive, language, and learning disabilities are addressed by WCAG 2.0, either directly or through assistive technologies, the WCAG 2.0 guidelines do not address many areas of need for people with these disabilities. There is a need for more research and development in this important area.
It is important to note that Web content is just one aspect of accessibility. Just as important as accessible Web content is the availability of accessible browsers (and other user agents) that can adapt and present the content in the best form for the user. Accessible Web technologies and accessible tools for creating Web content are also important. For an overview of the different components of accessibility and how they work together see:
Essential Components of Web Accessibility - Explains how the Web Content Accessibility Guidelines work with the other WAI guidelines and with assistive technologies to provide access to the Web by people with disabilities.
User Agent Accessibility Guidelines (UAAG) Overview - Introduces guidelines on the design of accessible Browsers and other user agents.
Authoring Tool Accessibility Guidelines (ATAG) Overview - Introduces guidelines on the design of authoring and evaluation tools.
WCAG 2.0 itself is a technical standard designed primarily for Web developers and designers, authoring tool developers, evaluation tool developers, and others who need a technical standard for Web accessibility. Due to the technical and technology-independent nature of the guidelines and success criteria, and because they say what needs to be done rather than how to do it, it may sometimes be difficult to use the guidelines or success criteria for specific advice for a particular technology (e.g. HTML, XHTML, JavaScript etc).
In order to provide more concrete examples as well as specific techniques for meeting each of the success criteria, three support documents or collections have been developed by the working group to accompany the guidelines. These documents provide very specific guidance that can be used directly to meet the WCAG 2.0 guidelines.
The overall set of documents from the working group consists of:
The WCAG 2.0 Guidelines - (this document) - This document provides the guidelines, success criteria, conformance specifications as well as the definitions of terms used in the guidelines. The actual guidelines (including success criteria) are only 9 pages long.
WCAG 2.0 Quick Reference - A concise summary that includes all of the WCAG 2.0 guidelines and success criteria (from above) along with a listing of different techniques that are sufficient to meet every success criterion. It also optionally lists advisory techniques and provides links to further information on each guideline and success criterion (in Understanding WCAG 2.0). Web authors may find this the most useful document when trying to make accessible Web sites and it is a good place to start if looking for practical guidance on all of the WCAG 2.0 requirements and specific techniques to meet them.
Understanding WCAG 2.0 - A collection of short (two to four page) "Understanding" documents for each section, guideline and success criterion in WCAG 2.0. Each of these short documents focuses on one guideline or success criterion. It provides the intent of the success criterion, definitions of key words, people who benefit, how to meet the success criteria, links to sufficient techniques and additional advisory techniques and examples. This collection is equivalent to an applications manual or book on WCAG 2.0.
Editorial Note: For this release, the collection is only available as a single long document. With the next release, the individual short documents will be available as well as the full collection as one large document if desired.
Techniques and Failures for WCAG 2.0 - A collection of documents each detailing one of the techniques (or known common failures) that have been documented so far. The techniques collection is continually expanding, with new techniques being added as they are completed. Due to the design of WCAG 2.0, the techniques collection can continue to grow even after the guidelines are released. The "Quick Reference" and "Understanding" documents tie the guidelines to the new techniques as they are created. Each technique document provides an overview of a single technique, notes about user agent (including assistive technology) support, examples (sometimes including code) and a test methodology for sufficient techniques (advisory techniques do not all have tests).
Editorial Note: For this release, the Techniques collection is also only available as a single long document. With the next release, the individual technique documents will be available as well as the full collection as one large document if desired.
In addition to WCAG and its primary reference documents prepared by the WCAG Working group, there are a number of additional resource documents available on WCAG 2.0 and its relationship to Web accessibility. This set of documents will continue to grow even after the WCAG 2.0 is released. Documents available at the time of this document's release include:
Overview of Web Content Accessibility Guidelines (WCAG) 2.0 Documents - Provides an overview of WCAG 2.0 and its various informative support documents
WCAG 2 FAQ - Provides key information on the most commonly asked questions around WCAG 2.0.
WAI Resources on Introducing Web Accessibility - Provides basic information for people who are new to Web accessibility.
Other documents under development include:
Transitioning from WCAG 1.0 to 2.0 - Information to facilitate transitioning from use of WCAG 1.0 to WCAG 2.0.
Application Notes - Provides detailed application information in different areas such as "Designing Accessible Web Forms," or "Creating Basic HTML Web Pages that are Accessible."
The guidelines and success criteria are organized around the following four principles. These four principles lay the foundation necessary for anyone to access and use Web content. Anyone who wants to use the Web must have content that is:
Perceivable - Information and user interface components must be perceivable by users;
Operable - User interface components must be operable by users;
Understandable - Information and operation of user interface must be understandable by users;
Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Under each principle there is a list of guidelines that address the principle. There are a total of 12 guidelines. A convenient list of just the guidelines can be found in the table of contents.
Under each guideline there are success criteria that describe specifically what must be achieved in order to conform [begin delete]to this standard [2184] [end delete]. They are similar to the "checkpoints" in WCAG 1.0. Each success criterion is written as a statement that will be either true or false when specific Web content is tested against it.
All WCAG 2.0 success criteria are written to be testable. While some can be tested by computer programs, others require human testers for part or all of the test. The same results should be obtained with a high level of confidence when people who understand how people with different types of disabilities use the Web test the same content.
Each success criterion for a guideline has a link to the section of the Quick Reference document that provides:
sufficient techniques for meeting the success criterion,
optional advisory techniques, and
links to descriptions of the intent of the success criteria (including benefits) and examples. [2186]
[end change]WCAG 2.0 success criteria are organized into three levels of conformance.
"A" (single-A) conformance: all Level A success criteria must be satisfied in order to achieve A (single-A) conformance.
"AA" (double-A) conformance: all Level A and Level AA success criteria must be satisfied in order to achieve AA (double-A) conformance.
"AAA" (triple-A) conformance: all Level A, AA, and AAA must be satisfied in order to achieve AAA (triple-A) conformance.
The word "levels" does not mean that some success criteria are more important than others. Each success criterion in WCAG 2.0 is essential to some users, and the levels build upon each other. However, even content that conforms at AAA (triple-A) may not be fully accessible to every person with a disability or combination of disabilities, especially certain types of severe disabilities.
In general, Level A success criteria achieve accessibility by supporting assistive technology while putting the fewest possible limits on presentation. Thus people with a wide range of disabilities using a wide range of assistive technologies, from voice input and eye-tracking devices to screen readers and screen magnifiers, are able to access content in different ways. In other words, Level A success criteria support the ability of both mainstream and specialized user agents to adapt content to formats that meet their users' needs.
The success criteria in Level AA provide additional support for assistive technology. At the same time, they also support direct access to content by the many people who use conventional user agents without assistive technology. In general, Level AA success criteria place more limits on visual presentation and other aspects of content than the success criteria in Level A.
Level AAA success criteria increase both direct access and access through assistive technology. They place tighter limits on both presentation and content, which means that some types of content may not be able to satisfy this level of conformance.
It is recommended that even if content does not conform at a specific level, that it conform to the extent possible.
WCAG 2.0 includes several important new terms. In some cases, these terms are just clarifications of concepts that have been in use but have not been clearly defined in the past. In other cases, they are terms that match new concepts that have been [begin add]developed to allow for new technologies, potential accessibility issues that result from their use, and strategies that emerge to address these issues.[end add] [begin delete]developed to cope with the new technologies that are continually emerging and with the accessibility issues and strategies that are emerging to address them [2189] [end delete].
For each success criterion, there is a list of techniques deemed by the Working Group to be sufficient to meet the requirement. For each sufficient technique, there is a test to determine whether the technique has been successfully implemented. If the test(s) for a "sufficient" technique (or combination of techniques) are passed, then that success criterion has been satisfied.
Passing all tests for all sufficient techniques is not necessary. Most success criteria have multiple "sufficient techniques" listed. Any of the listed "sufficient techniques" can be used to meet the success criterion.
Note that it is not necessary to meet a success criterion using one of the sufficient techniques that have been documented by the WCAG working group. There may be other techniques which are not documented by the working group that would also meet the success criterion. The working group went through the effort to document these "sufficient techniques" in order to make it easy for authors to identify techniques that meet each success criterion and to have confidence (and evidence) that the techniques meet the success criterion. When using other externally-provided techniques to meet WCAG 2.0 requirements, it is important that they be created by individuals or organizations who are knowledgeable about the requirements of WCAG 2.0 and the needs of people with disabilities. The working group will continue to add new "sufficient techniques" as they are identified, developed, or made effective by advances in user agents including assistive technologies.
In addition to the sufficient techniques, there are a number of techniques that may enhance accessibility, but did not qualify as sufficient techniques because they are not testable, are not sufficient to meet the full requirements of the success criteria, and/or are good and effective techniques in some circumstances but not effective (and therefore sufficient) in others. These are listed as "Advisory Techniques." Authors are encouraged to use these techniques where appropriate. Although using them does not affect conformance, it can enhance accessibility for some users. Many of the advisory techniques are particularly helpful for people with cognitive, language, and learning disabilities, and use of these techniques will improve the accessibility of the content to people with these disabilities.
While not an entirely new term, it is important to note that, in this standard, the term "Web page" includes much more than static HTML pages. It also includes the increasingly dynamic Web pages that are emerging on the Web, including "pages" that can present entire virtual interactive communities. Technically a Web page, as defined in the glossary, is "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." What this means is that a Web page is whatever you find at the end of a Web address that you visit. It includes Web applications, Webcasts, multimedia objects and other types of interactive content to which the word "page" may not typically apply. It is in this evolved sense of the concept that the term is used in WCAG 2.0.
For example, the term "Web page" would include a movie-like interactive shopping environment where the user visually moves about a store dragging products off of the shelves around them and into a visual shopping cart in front of them where clicking on a product causes it to be demonstrated with a specification sheet alongside.
Several success criteria require that content (or certain aspects of content) can be "programmatically determined." This means that the content is delivered in such a way that user agents, including assistive technologies, can access the information. A critical element in having anything be "programmatically determined" is that assistive technologies are able to retrieve and use the information. This lets user agents, including assistive technologies, transform the content and present it to the user in different sensory modalities (e.g. vision, hearing) or styles of presentation. If 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. It is important neither to declare things as accessible because they might be in the future (when they aren't now) nor to declare things as inaccessible in a permanent way when they may very well become accessible in the future.
The use of the term allows the guidelines to identify what needs to be "programmatically determined" in order to meet the guidelines, and then have separate [begin add]documents (the Quick Reference, Understanding, and Technique documents) to list techniques and technologies that meet the requirements, which can be updated over time based on user agent and assistive technology support.[end add][begin delete], updateable documents (the Quick Reference, Understanding, and Technique documents) list those techniques and technologies that meet the requirements over time. [end delete] [2196]
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 [begin change]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.[end change] [2197]
"Accessibility supported" means supported by users' assistive technologies as well as the accessibility features in browsers and other user agents.
Authors who don't know which technologies or which aspects and features of a technology have support from assistive technologies should consult documented lists of technologies that are known to have accessibility support. Such lists can make it easier than it is today for an author to identify technologies or features of different technologies that are supported by assistive technologies and can be used to meet the success criteria that require assistive technology support (i.e. require that content can be programmatically determined.)
Editorial Note: The W3C WAI will be compiling existing information on its technologies. It is expected that other organizations will compile such information for their technologies. There will undoubtedly be others who create documented lists as well.
Editorial Note: The Baseline concept has been replaced by the "accessibility support" of Web technologies and "Documented lists of Web technologies that have accessibility support."
Note: The requirements for "accessibility support" of Web technologies are provided in the conformance section of these guidelines (See also Conformance.)
For more information, see Understanding accessibility support in Understanding WCAG 2.0.
This section is normative.
1.1.1 Non-text Content: All non-text content has a text alternative that presents equivalent information, except for the situations listed below. [1992] (Level A) How to Meet 1.1.1 Understanding 1.1.1
Controls, Input: If [begin add]it[end add] [begin delete]non-text content[end delete] is a control or accepts user input, then it has a name that describes its purpose. (See also Guideline 4.1.)
Media, Test, Sensory: If [begin add]it[end add] [begin delete]non-text content[end delete] is any of the following, then text alternatives at least identify the non-text content with a descriptive text label: multimedia, live audio-only or live video-only content, a test or exercise that must be presented in non-text format, or content primarily intended to create a specific sensory experience. (For multimedia, see also Guideline 1.2.)
[end change]CAPTCHA: If [begin add]it[end add] [begin delete]the purpose of non-text content[end delete] is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided[begin add], and alternative forms of CAPTCHA using output modes for different types of sensory perception[end add] [begin delete]and alternative forms in different modalities[end delete] are provided to accommodate different disabilities.
Decoration, Formatting, Invisible: If [begin add]it[end add] [begin delete]non-text content[end delete] is pure decoration, or used only for visual formatting, or if it is not presented to users, then it is implemented [begin change]in a way[end change] [begin delete]such[end delete] that it can be ignored by assistive technology.
1.1.2 Live Audio-only: All live audio-only content has a text alternative [1944] (Level AAA) How to Meet 1.1.2 Understanding 1.1.2
1.2.1 Captions (Prerecorded): Captions are provided for prerecorded multimedia, except for multimedia alternatives to text that are clearly labeled as such. (Level A) How to Meet 1.2.1 Understanding 1.2.1
1.2.2 Audio Description or Full Text Alternative: Audio description of video, or a full text alternative for multimedia including any interaction , is provided for prerecorded multimedia. (Level A) How to Meet 1.2.2 Understanding 1.2.2
Note: For 1.2.2, 1.2.4, and 1.2.7, if all of the information in the video track is already provided in the audio track, no audio description is necessary.
1.2.3 Captions (Live): Captions are provided for live multimedia. (Level AA) How to Meet 1.2.3 Understanding 1.2.3
Note: If multimedia is completely computer generated, it is not live and is subject to the requirements for prerecorded multimedia in WCAG 2.0.
1.2.4 Audio Description: Audio description of video is provided for prerecorded multimedia. (Level AA) How to Meet 1.2.4 Understanding 1.2.4
1.2.5 Sign Language: Sign language interpretation is provided for multimedia. (Level AAA) How to Meet 1.2.5 Understanding 1.2.5
1.2.6 Audio Description (Extended): Extended audio description of video is provided for prerecorded multimedia. (Level AAA) How to Meet 1.2.6 Understanding 1.2.6
1.2.7 Full Text Alternative: A full text alternative for multimedia including any interaction is provided for all prerecorded multimedia, except for multimedia alternatives to text that are clearly labeled as such. (Level AAA) How to Meet 1.2.7 Understanding 1.2.7
1.3.1 Info and Relationships: Information and relationships conveyed through presentation can be programmatically determined or are available in text, and notification of changes to these is available to user agents, including assistive technologies. (Level A) How to Meet 1.3.1 Understanding 1.3.1
1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined and sequential navigation of interactive components is consistent with that sequence. (Level A) How to Meet 1.3.2 Understanding 1.3.2
1.3.3 Sensory Characteristics: [begin add]Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation or sound.[end add] [begin delete]Instructions provided for understanding and operating content do not rely on shape, size, visual location, or orientation of components.[end delete] [2015] (Level A) How to Meet 1.3.3 Understanding 1.3.3
1.4.1 Use of Color: Any information that is conveyed by color differences is also simultaneously visually evident without the color differences. (Level A) How to Meet 1.4.1 Understanding 1.4.1
Note: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3. [2255]
[end add]1.4.2 Audio Control: If any audio plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume which can be set [begin add]to be a different level from the system volume level[end add] [begin delete]independently of the system volume[end delete]. [2131] [2185] (Level A) How to Meet 1.4.2 Understanding 1.4.2
1.4.3 Contrast (Minimum): Text and images of text have a contrast ratio of at least 5:1, except if the text is pure decoration. Larger-scale text or images of text [begin delete]can [end delete]have a contrast ratio of [begin add]at least [end add]3:1. [2000] (Level AA) How to Meet 1.4.3 Understanding 1.4.3
1.4.4 Resize text: [begin add] Text (but not images of text)[end add] [begin delete]Visually rendered text[end delete] can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality. [2164] (Level AA) How to Meet 1.4.4 Understanding 1.4.4
1.4.5 Contrast (Enhanced): Text and images of text have a contrast ratio of at least 7:1, except if the text is pure decoration. Larger-scale text or images of text [begin delete]can [end delete]have a contrast ratio of [begin add]at least [end add]5:1. [2000] (Level AAA) How to Meet 1.4.5 Understanding 1.4.5
1.4.6 Low or No Background Audio: Audio content that contains speech in the foreground does not contain background sounds, background sounds can be turned off, or background sounds are at least 20 decibels lower than the foreground speech content, with the exception of occasional sound effects. (Level AAA) How to Meet 1.4.6 Understanding 1.4.6
Note: Background sound that meets this requirement will be approximately one quarter as loud as the foreground speech content.
1.4.7 Resize and Wrap: [begin add] Text (but not images of text)[end add] [begin delete]Visually rendered text[end delete] can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality and in a way that does not require the user to scroll horizontally. [2164] (Level AAA) How to Meet 1.4.7 Understanding 1.4.7
2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A) How to Meet 2.1.1 Understanding 2.1.1
Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.
Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
2.1.2 Keyboard (No Exception): All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA) How to Meet 2.1.2 Understanding 2.1.2
2.2.1 Timing: For each time limit that is set by the content, at least one of the following is true: (Level A) How to Meet 2.2.1 Understanding 2.2.1
Turn off: the user is allowed to turn off the time limit before encountering it; or
Adjust: the user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
Extend: the user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "hit any key"), and the user is allowed to extend the time limit at least ten times; or
Real-time Exception: the time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
Essential Exception: the time limit is part of an activity where timing is essential [begin delete](for example, time-based testing) [end delete]and time limits can not be extended further without invalidating the activity. [1949]
2.2.2 Blinking: Content does not blink for more than three seconds, or a method is available to stop all blinking content in the Web page. (Level AA) How to Meet 2.2.2 Understanding 2.2.2
Note: For requirements related to flickering or flashing content, refer to Guideline 2.3.
2.2.3 Pausing: Moving, blinking, scrolling, or auto-updating information can be paused by the user unless it is part of an activity where timing or movement is essential. Moving content that is pure decoration can be stopped by the user. (Level AA) How to Meet 2.2.3 Understanding 2.2.3
2.2.4 Timing: Timing is not an essential part of the event or activity presented by the content, except for non-interactive multimedia and real-time events. (Level AAA) How to Meet 2.2.4 Understanding 2.2.4
2.2.5 Interruptions: Interruptions, such as updated content, can be postponed or suppressed by the user, except interruptions involving an emergency. (Level AAA) How to Meet 2.2.5 Understanding 2.2.5
2.2.6 Re-authenticating: When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating. (Level AAA) How to Meet 2.2.6 Understanding 2.2.6
2.3.1 Three Flashes or Below Threshold: 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. (Level A) How to Meet 2.3.1 Understanding 2.3.1
2.3.2 Three Flashes: Content does not contain anything that flashes more than three times in any one second period. (Level AAA) How to Meet 2.3.2 Understanding 2.3.2
3.1.1 Language of Page: The default human language of each Web page within the content can be programmatically determined. (Level A) How to Meet 3.1.1 Understanding 3.1.1
3.1.2 Language of Parts: The human language of each passage or phrase in the content can be programmatically determined. (Level AA) How to Meet 3.1.2 Understanding 3.1.2
Note: This requirement does not apply to individual words. It also does not apply to proper names, to technical terms or to phrases that have become part of the language of the context in which they are used.
3.1.3 Unusual Words: A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon. (Level AAA) How to Meet 3.1.3 Understanding 3.1.3
3.1.4 Abbreviations: A mechanism for finding the expanded form or meaning of abbreviations is available. (Level AAA) How to Meet 3.1.4 Understanding 3.1.4
3.1.5 Reading Level: When text requires reading ability more advanced than the lower secondary education level, supplemental content or an alternate version is available that does not require reading ability more advanced than the lower secondary education level. (Level AAA) How to Meet 3.1.5 Understanding 3.1.5
3.1.6 Pronunciation: A mechanism is available for identifying specific pronunciation of words where meaning is ambiguous without knowing the pronunciation. (Level AAA) How to Meet 3.1.6 Understanding 3.1.6
3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. (Level A) How to Meet 3.2.1 Understanding 3.2.1
3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A) How to Meet 3.2.2 Understanding 3.2.2
3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. (Level AA) How to Meet 3.2.3 Understanding 3.2.3
3.2.4 Consistent Identification: Components that have the same functionality within a set of Web pages are identified consistently. (Level AA) How to Meet 3.2.4 Understanding 3.2.4
3.2.5 Change on Request: Changes of context are initiated only by user request. (Level AAA) How to Meet 3.2.5 Understanding 3.2.5
3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and [begin add]the error is [2012] [end add] described to the user in text. (Level A) How to Meet 3.3.1 Understanding 3.3.1
3.3.2 Error Suggestion: If an input error is detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA) How to Meet 3.3.2 Understanding 3.3.2
3.3.3 Error Prevention (Legal, Financial, Data): For [begin add]Web pages[end add] [begin delete]forms[end delete] that cause legal commitments or financial transactions to occur, that modify or delete user-controllable data in data storage systems, or that submit test responses, at least one of the following is true: (Level AA) How to Meet 3.3.3 Understanding 3.3.3
Reversible: Transactions are reversible.
Checked: Submitted data is checked for input errors before going on to the next step in the process.
Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the transaction.
3.3.4 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level AA) How to Meet 3.3.4 Understanding 3.3.4
3.3.5 Help: Context-sensitive help is available. (Level AAA) How to Meet 3.3.5 Understanding 3.3.5
3.3.6 Error Prevention (All): For [begin add]Web pages[end add] [begin delete]forms[end delete] that require the user to submit information, at least one of the following is true: (Level AAA) How to Meet 3.3.6 Understanding 3.3.6
Reversible: Transactions are reversible.
Checked: Submitted data is checked for input errors before going on to the next step in the process.
Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the transaction.
4.1.1 Parsing: Content implemented using markup languages has elements with complete start and end tags, except as allowed by their specifications, and are nested according to their specifications. (Level A) How to Meet 4.1.1 Understanding 4.1.1
Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.
4.1.2 Name, Role, Value: For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically determined and programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A) How to Meet 4.1.2 Understanding 4.1.2
Note: This success criterion is primarily for Web authors who develop or script their own user interface controls. For example, standard HTML controls already meet this provision when used according to specification.
This section is normative.
Conformance means that Web content satisfies the success criteria. This conformance section describes conformance, lists the conformance requirements as well as how to make optional conformance claims, and explains the important role of accessibility support of Web technologies.
In choosing Web technologies (HTML, scripting, etc.) that will be used when creating content that will meet the WCAG 2.0 success criteria, authors must use technologies that are supported by users' assistive technologies as well as the accessibility features in browsers and other user agents. Such technologies are referred to as "accessibility supported."
The easiest way to be sure that the technologies and features being used have the necessary AT support is to use technologies from documented lists of Web technologies that are "accessibility supported." (See Documented lists of Web technologies with accessibility support in Understanding WCAG 2.0.)
Authors, companies or others may wish to create and use their own lists of accessibility-supported technologies.
To qualify as an accessibility-supported technology, the following must be true for a technology:
The Web technology must be supported by users' assistive technology (AT). This means that either the technology implements and tests accessibility APIs that are required in order for the users' assistive technology to make the technology accessible, or the technology has been tested for interoperability with users' assistive technology in the human language(s) of the content.
The Web 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 also accessibility supported and available for download or purchase in a way that does not disadvantage people with disabilities.
Note 1: Web technologies that are not accessibility supported can be used as long as conformance requirement 5 (Accessibility-Supported Technologies) and conformance requirement 6 (Non-Interference) are met.
Note 2: 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 referring to "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."
Note 3: When citing technologies that have multiple versions, the version(s) supported should be specified.
In order to conform to WCAG 2.0 all of the following conformance requirements must be met for each Web page:
1.) Level A Conformance: For level A conformance (the minimum level of conformance), the Web page satisfies all the Level A success criteria, or the page satisfies conformance requirement 4.
2.) Level AA Conformance: For level AA conformance, the Web page satisfies all the Level A and Level AA success criteria, or the page satisfies conformance requirement 4.
3.) Level AAA Conformance: For level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA success criteria, or the page satisfies conformance requirement 4.
4.) Alternate Versions: If the Web page does not meet all of the success criteria for a specified level, then a mechanism to obtain an alternate version that meets all of the success criteria can be derived from the nonconforming content or its URI, and that mechanism meets all success criteria for the specified level of conformance. 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). If multiple language versions are available, then conforming versions are required for each language offered.
Editorial Note: As currently worded, requirement #4 ensures that a mechanism is available to find a conforming version from any nonconforming version. The working group is concerned that it has not identified enough supported mechanisms to meet the needs and constraints of different technologies or the limitations authors may have in their content or server. Requirement #4 is therefore "at risk" in its current form. If there are not sufficient techniques to meet the current language, it would have to change. The two options under consideration if that happens both have disadvantages. The options are:
Fallback option #1: Requiring an accessible link from the nonconforming content, which would block use of some current and future technologies if they do not support WCAG conforming links, or
Fallback option #2: Allowing the requirement to be met by a single page with links to the conforming and non-conforming pages, or other techniques that may provide an option to find the conforming version when browsing, but that would leave the user with no way to find the conforming page after reaching a non-conforming page via search, or a link from a blog, email, article, other page etc.
Further discussion of this topic is available at Alternate Versions Conformance Requirement. The working group seeks suggestions for additional sufficient techniques that would allow us to keep the current language as well as comments, input, and thoughts on the two alternatives should we fail to identify enough.
5.) Accessibility-Supported Technologies Only: Only documented accessibility-supported Web technologies are relied upon to meet 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.
6.) 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 the users to access the rest of the page. Specifically:
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.
7.) Full pages: Conformance is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.
8.) Supplemental Information: For the purpose of determining conformance, a conforming alternative to part of a page's content is considered part of the page.
9.) Complete processes: If a Web page that is part of a process does not conform at some level, then no conformance claim is made at that level for any Web pages in that process.
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 to claim conformance for any page that is part of the sequence.
For more information, see Understanding Conformance Requirements.
Conformance claims apply to Web pages, and sets of Web pages.
Conformance claims are not required. However, if a conformance claim is made, then the conformance claim must include the following information:
The date of the claim
The guidelines title, version and URI "Web Content Accessibility Guidelines 2.0 at {URI of final document}"
The conformance level satisfied: (Level A, AA or AAA)
A description of the URIs that the claim is being made for, including whether subdomains are included in the claim.
A list of accessibility-supported technologies that includes all of the technologies relied upon .
Note: When citing technologies that have multiple versions, the version(s) supported must be specified.
In addition to the required components of a conformance claim above, consider providing additional information to assist users. Recommended additional information includes:
A list of success criteria beyond the level of conformance claimed that have been met. This information should be provided in a form that consumers can use, preferably machine-readable metadata.
A list of the specific technologies that are "used but not relied upon ."
Note: If a technology is "used but not relied upon," the content would still meet WCAG 2.0 at the stated conformance level even if that technology is turned off or not supported.
A list of user agents, including assistive technologies, that were used to test the content. [2224]
[end change]Information about any additional steps taken that go beyond the success criteria to enhance accessibility.
The list of specific technologies that are relied upon, in machine-readable metadata.
A machine-readable metadata version of the conformance claim.
Note 1: If pages can not conform (for example, conformance test pages or example pages) they would not be included in the conformance claim.
Note 2: Refer to Examples of Conformance Claims in Understanding Conformance for examples.
Sometimes, Web pages are created that will later have additional content added to them. For example, an email program, a blog, an article that allows users to add comments to the bottom, or applications supporting user contributed content. Another example would be a page composed of content aggregated from multiple contributors, such as in portals and news sites. Sometimes, the content from the other sources is automatically inserted into the page over time.
In both of these cases, it is not possible to know at the time of original posting what the content of the pages will be. Two options are available:
A conformance claim is made based on best knowledge. If a page of this type is monitored and kept conforming (non-conforming content is immediately removed or made conforming) then a conformance claim can be made since, except for error periods, the page conforms. No conformance claim should be made if it is not possible to monitor or correct non-conforming content; OR
A "statement of partial conformance" is made. A statement that the page does not conform, but could conform if certain parts were removed can be made. The form of that statement would be, "This page would conform to WCAG 2.0 at level X if the following parts from uncontrolled sources were removed."
The content that is excluded in the statement of partial conformance cannot be content that is under the author's control.
The content that is excluded in the statement of partial conformance would be described in terms that users can understand. (e.g. they can't be described as "all parts that we do not have control of" unless they are clearly marked as such.)
This section is normative.
shortened form of a word, phrase, or name
Note: This includes initialisms and acronyms where:
initialisms are shortened forms of a name or phrase made from the initial letters of words or syllables contained in that name or phrase
Note 1: Not defined in all languages.
Example 1: SNCF is a French initialism that contains the init