WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities
Site Navigation: W3C Home > WAI Home > Overview of WCAG 2.0 Documents
This mapping shows how the WCAG 1.0 checkpoints relate to the WCAG 2.0 Last Call Working Draft released May/June 2007. Note that WCAG 2.0 is still a draft and the WCAG 2.0 Guidelines and success criteria in no way supersede the checkpoints in WCAG 1.0.
The Web Content Accessibility Guidelines Working Group is working carefully to enable organizations and individuals that are currently using WCAG 1.0 (which remains a stable and referenceable document) to ensure that they will be able to make a smooth transition to WCAG 2.0 when it is released.
| In General (Priority 1) | WCAG 2.0 Success Criteria |
|---|---|
| 1.1: Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. |
1.1.1 Non-text Content: All non-text content has a text alternative that presents equivalent information, except for the situations listed below. (Level A)
For scripts, applets, and objects, alternative versions are covered by conformance requirement 4, and labels under Guideline 1.1 (See also SC 2.4.6 (Level AA) and SC 4.1.2 (Level A).). Images used as bullets are also covered in Guideline 1.3 with regard to CSS usage. For framesets, |
| 2.1: Ensure that all information conveyed with color is also available without color, for example from context or markup. |
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) |
| 4.1: Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions). |
3.1.2 Language of Parts: The human language of each passage or phrase in the content can be programmatically determined. (Level AA) 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. Note: Identification of the language for individual words is no longer required. |
| 6.1: Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. |
Conformance Requirement 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.2: Ensure that equivalents for dynamic content are updated when the dynamic content changes. | Text alternatives are addressed in Guideline 1.1, 1.2, and 4.2. If providing a text alternative for content and that content changes, then the text alternative must also be changed or else you don't conform to Guideline 1.1, 1.2, and 4.2 anymore. |
| 7.1: Until user agents allow users to control flickering, avoid causing the screen to flicker. |
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) 2.3.2 Three Flashes: Content does not contain anything that flashes more than three times in any one second period. (Level AAA) |
| 14.1: Use the clearest and simplest language appropriate for a site's content. |
Some of the Level AAA success criteria in Guideline 3.1 aid in making content understandable. There is no direct mapping. |
| And if you use images and image maps (Priority 1) | WCAG 2.0 Success Critera |
| 1.2: Provide redundant text links for each active region of a server-side image map. |
With regard to text alternatives: 1.1.1 Non-text Content: All non-text content has a text alternative that presents equivalent information, except for the situations listed below. (Level A)
With regard to keyboard access: 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) 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.4.4 Link Purpose (Context): The purpose of each link can be determined from the link text and its programmatically determined link context. (Level A) There is debate about whether pages that fail this success criterion in fact present a problem for assistive technology. The status of this item as a Level A success criterion is therefore "at risk" as a Level A success criterion depending on AT support and relative need for this provision.Conformance Requirement 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. 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:
Note: Server-side image maps are not keyboard accessible. |
| 9.1: Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape. |
With regard to text alternatives: 1.1.1 Non-text Content: All non-text content has a text alternative that presents equivalent information, except for the situations listed below. (Level A)
With regard to keyboard access: 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) 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.4.4 Link Purpose (Context): The purpose of each link can be determined from the link text and its programmatically determined link context. (Level A) There is debate about whether pages that fail this success criterion in fact present a problem for assistive technology. The status of this item as a Level A success criterion is therefore "at risk" as a Level A success criterion depending on AT support and relative need for this provision.Note: Server-side image maps are not keyboard accessible. |
| And if you use tables (Priority 1) | WCAG 2.0 Success Criteria |
| 5.1: For data tables, identify row and column headers. |
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) |
| 5.2: For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. |
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) |
| And if you use frames (Priority 1) | WCAG 2.0 Success Criteria |
| 12.1: Title each frame to facilitate frame identification and navigation. |
2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A) 2.4.4 Link Purpose (Context): The purpose of each link can be determined from the link text and its programmatically determined link context. (Level A) There is debate about whether pages that fail this success criterion in fact present a problem for assistive technology. The status of this item as a Level A success criterion is therefore "at risk" as a Level A success criterion depending on AT support and relative need for this provision.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) 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. |
| And if you use applets and scripts (Priority 1) | WCAG 2.0 Success Criteria |
| 6.3: Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. |
Conformance Requirement 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. 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:
Conformance Requirement 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. Conformance Requirement 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:
|
| And if you use multimedia (Priority 1) | WCAG 2.0 Success Criteria |
| 1.3: Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. |
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) 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.4: For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. |
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) 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) 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.4 Audio Description: Audio description of video is provided for prerecorded multimedia. (Level AA) 1.2.3 Captions (Live): Captions are provided for live multimedia. (Level AA) Note: If multimedia is completely computer generated, it is not live and is subject to the requirements for pre-recorded multimedia in WCAG 2.0. 1.2.6 Audio Description (Extended): Extended audio description of video is provided for prerecorded multimedia. (Level AAA) |
| And if all else fails (Priority 1) | WCAG 2.0 Success Criteria |
| 11.4: If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. |
Conformance Requirement 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. 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:
Conformance Requirement 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:
|
| In General (Priority 2) | WCAG 2.0 Success Criteria |
|---|---|
| 2.2: Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text]. |
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 can have a contrast ratio of 3:1. (Level AA) 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 can have a contrast ratio of 5:1. (Level AAA) |
| 3.1: When an appropriate markup language exists, use markup rather than images to convey information. |
This is dependent upon the technologies that are "relied upon" for conformance. Guidance on choosing an accessibility-supported technologies will include information about the advantages of technologies with accessibility features. This also maps to sufficient techniques on using semantic markup listed in Understanding Success Criterion 1.3.1 (Level A) and Understanding Success Criterion 1.3.4 (Level AA). |
| 3.2: Create documents that validate to published formal grammars. |
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) 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. Note: Validating to published formal grammars is a stronger requirement than unambiguous parsing required by Success Criterion 4.1.1 but validation is one of the sufficient techniques for this success criterion. Refer to Understanding Success Criterion 4.1.1 |
| 3.3: Use style sheets to control layout and presentation. |
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) Maps to several items in Understanding WCAG 2.0: CSS techniques for SC 1.3.1 (level 1), CSS techniques for SC 1.3.2 (level 1), and a client-side scripting technique for SC 1.3.3 (level 1). |
| 3.4: Use relative rather than absolute units in markup language attribute values and style sheet property values. |
1.4.4 Resize text: Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality. (Level AA) 1.4.7 Resize and Wrap: Visually rendered text 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. (Level AAA) |
| 3.5 Use header elements to convey document structure and use them according to specification. |
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) |
| 3.6: Mark up lists and list items properly. |
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) |
| 3.7: Mark up quotations. Do not use quotation markup for formatting effects such as indentation. |
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) |
| 6.5: Ensure that dynamic content is accessible or provide an alternative presentation or page. |
Conformance Requirement 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. 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:
|
| 7.2: Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off). |
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) Note: For requirements related to flickering or flashing content, refer to Guideline 2.3. |
| 7.4: Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages. |
2.2.1 Timing: For each time limit that is set by the content, at least one of the following is true: (Level A)
2.2.5 Interruptions: Interruptions, such as updated content, can be postponed or suppressed by the user, except interruptions involving an emergency. (Level AAA) 3.2.5 Change on Request: Changes of context are initiated only by user request. (Level AAA) |
| 7.5: Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects. |
3.2.5 Change on Request: Changes of context are initiated only by user request. (Level AAA) |
| 10.1: Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. |
3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. (Level A) 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) 3.2.5 Change on Request: Changes of context are initiated only by user request. (Level AAA) |
| 11.1: Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported. |
No longer required for conformance to WCAG 2.0, but relates to "accessibility supported" technologies. Note: Refer to Understanding Accessibility Support for more information . |
| 11.2: Avoid deprecated features of W3C technologies. |
No longer required for conformance to WCAG 2.0. |
| 12.3: Divide large blocks of information into more manageable groups where natural and appropriate. |
No longer required for conformance to WCAG 2.0. This partially maps to a sufficient technique for SC 2.4.1 (level 1): Providing Heading elements at the beginning of each section of content. |
| 13.1: Clearly identify the target of each link. |
2.4.4 Link Purpose (Context): The purpose of each link can be determined from the link text and its programmatically determined link context. (Level A) There is debate about whether pages that fail this success criterion in fact present a problem for assistive technology. The status of this item as a Level A success criterion is therefore "at risk" as a Level A success criterion depending on AT support and relative need for this provision.2.4.8 Link Purpose (Link Text): The purpose of each link can be identified from the link text. (Level AAA) |
| 13.2: Provide metadata to add semantic information to pages and sites. |
This is no longer required for conformance, but could be a technique for satisfying certain success criteria in Guidelines 2.4, 4.2, 3.1 and 1.3. |
| 13.3: Provide information about the general layout of a site (e.g., a site map or table of contents). |
2.4.5 Multiple Ways: More than one way is available to locate content within a set of Web pages where content is not the result of, or a step in, a process. (Level AA) This also maps to the technique Providing a Site Map. Note: This is a partial mapping. |
| 13.4: Use navigation mechanisms in a consistent manner. |
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) 3.2.4 Consistent Identification: Components that have the same functionality within a set of Web pages are identified consistently. (Level AA) |
| And if you use tables (Priority 2) | WCAG 2.0 Success Criteria |
| 5.3: Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version). |
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) |
| 5.4: If a table is used for layout, do not use any structural markup for the purpose of visual formatting. |
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) Especially: Failure of SC 1.3.1 due to using structural markup in a way that does not represent relationships in the content. |
| And if you use frames (Priority 2) | WCAG 2.0 Succes Criteria |
| 12.2: Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone. |
This is no longer required for conformance (because the longdesc attribute type on the frame element type has not been supported and is not defined in XHTML 1.1, the Working Draft of XFrames, or the Working Draft of XHTML 2.0). The |
| And if you use forms (Priority 2) | WCAG 2.0 Success Criteria |
| 10.2: Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. |
User agents now support explicit associations of labels with form controls, so the "until user agents" clause has been satisfied. This is therefore no longer a requirement under WCAG 2.0. It is an Advisory item. Other closely related SC are: 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) |
| 12.4: Associate labels explicitly with their controls. |
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) 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) 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. |
| And if you use applets and scripts (Priority 2) | WCAG 2.0 Success Criteria |
| 6.4: For scripts and applets, ensure that event handlers are input device-independent. |
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) 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) Note: Device-independent event handlers are not explicitly required. |
| 7.3: Until user agents allow users to freeze moving content, avoid movement in pages. |
The "until user agents" clause has been satisfied, so it is no longer necessary to avoid movement altogether, as long as authors do not do anything to interfere with the user's ability to pause the content. The prohibition has therefore been replaced with this success criterion 2.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) |
| 8.1: Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.] |
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) 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. Conformance Requirement 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. 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:
Conformance Requirement 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. Conformance Requirement 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:
|
| 9.2: Ensure that any element that has its own interface can be operated in a device-independent manner. |
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) 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) |
| 9.3: For scripts, specify logical event handlers rather than device-dependent event handlers. |
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) 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) |
| In General (Priority 3) | WCAG 2.0 Success Criteria |
|---|---|
| 4.2: Specify the expansion of each abbreviation or acronym in a document where it first occurs. |
3.1.4 Abbreviations: A mechanism for finding the expanded form or meaning of abbreviations is available. (Level AAA) |
| 4.3: Identify the primary natural language of a document. |
3.1.1 Language of Page: The default human language of each Web page within the content can be programmatically determined. (Level A) |
| 9.4: Create a logical tab order through links, form controls, and objects. |
2.4.3 Focus Order: If a Web page can be navigated sequentially, focusable components receive focus in an order that follows information and relationships conveyed through presentation. (Level A) |
| 9.5: Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls. |
Accesskeys are no longer required for conformance to WCAG 2.0. It is an advisory item: Providing access keys (advisory technique for SC 2.4.1 (Level 1)). |
| 10.5: Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. |
Note: This technique is no longer needed for user agents but may be useful for people with cognitive disabilities. |
| 11.3: Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.) |
This checkpoint does not map to any WCAG 2.0 success criterion, though certain aspects may map to certain success criteria or to advisory item (see Situation B under Understanding Success Criterion 4.2.1, for example). Content negotiation is discussed briefly in "Conformance to Web Content Accessibility Guidelines 2.0." |
| 13.5: Provide navigation bars to highlight and give access to the navigation mechanism. |
This checkpoint is not required by any success criterion in WCAG 2.0. It is a possible strategy to address SC 2.4.2 (Level AA). If navigation bars are used, SC 3.2.3 (Level AA) applies. 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) |
| 13.6: Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. |
2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A) Note: In WCAG 2.0, this requirement applies only to groups that are repeated on multiple delivery units. |
| 13.7: If search functions are provided, enable different types of searches for different skill levels and preferences. |
Note: This checkpoint does not directly map to any WCAG 2.0 Success Criterion and is not required. Some aspects relate to 2.4.2 (Level AA) and 3.3.4 (Level AAA) as well as advisory items in Understanding WCAG 2.0. |
| 13.8: Place distinguishing information at the beginning of headings, paragraphs, lists, etc. |
This checkpoint is not required by any Success Criterion in WCAG 2.0. Part of this maps to optional techniqueStarting section headings with unique information for SC 2.4.5 (Level AAA). |
| 13.9: Provide information about document collections (i.e., documents comprising multiple pages.) |
This checkpoint is not in WCAG 2.0 but does relate to SC 2.4.7 (Level AAA) and would appear in advisory items in Understanding WCAG 2.0. |
| 13.10: Provide a means to skip over multi-line ASCII art. |
This item is not required by any Success Criterion in WCAG 2.0. ASCII art is considered non-text content and is therefore covered by SC 1.1.1. |
| 14.2: Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page. |
This checkpoint is not required by any WCAG 2.0 Success Criterion. Providing visual illustrations of complex ideas, events, and processes and Providing a spoken version of the text are listed as is a technique that can be used to satisfy WCAG 2.0 SC 3.1.5 (Level AAA). |
| 14.3: Create a style of presentation that is consistent across pages. |
Aspects of WCAG 1.0 Checkpoint 14.3 are required by WCAG 2.0 Guideline 3.2.3 (Level AA), 3.2.4 (Level AA). There is no Success Criterion in WCAG 2.0 that is as broad as WCAG 1.0 Checkpoint 14.3, so aspects of it do not relate. |
| And if you use images and image maps (Priority 3) | WCAG 2.0 Success Criteria |
| 1.5: Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map. |
This is no longer required because user agents now render text alternatives for client-side image map areas. |
| And if you use tables (Priority 3) | WCAG 2.0 Success Criteria |
| 5.5: Provide summaries for tables. |
This is no longer required for conformance. However, in layout tables, the summary attribute must be omitted or empty. See Failure of SC 1.3.1 due to using th elements, caption elements, or non-empty summary attributes in layout tables. |
| 5.6: Provide abbreviations for header labels. |
This is no longer required for conformance, but a potentially useful technique. |
| 10.3: Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns. |
WCAG 1.0 Checkpoint 10.3 is no longer required for conformance to WCAG 2.0. 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) 2.4.3 Focus Order: If a Web page can be navigated sequentially, focusable components receive focus in an order that follows information and relationships conveyed through presentation. (Level A) |
| And if you use forms (Priority 3) | WCAG 2.0 Success Criteria |
| 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. |
This "until user agents" condition is now met and this checkpoint is no longer required. |
3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and described to the user in text. (Level A)
1.3.3 Size, Shape, Location: Instructions provided for understanding and operating content do not rely on shape, size, visual location, or orientation of components. (Level A)
1.4.2 Audio Turnoff: 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 independently of the system volume. (Level A)
2.4.2 Page Titled: Web pages have descriptive titles. (Level A)
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)
3.3.3 Error Prevention (Legal, Financial, Data): For Web pages forms 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)
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.
1.2.5 Sign Language: Sign language interpretation is provided for multimedia. (Level AAA)
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)
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)
Note: Background sound that meets this requirement will be approximately one quarter as loud as the foreground speech content.
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)
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)
2.4.6 Labels Descriptive: Headings and labels are descriptive. (Level AA)
2.4.9 Section Headings: Where content is organized into sections, the sections are indicated with headings. (Level AAA)
3.3.5 Help: Context-sensitive help is available. (Level AAA)
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)
3.1.6 Pronunciation: A mechanism is available for identifying specific pronunciation of words where meaning is ambiguous without knowing the pronunciation. (Level AAA)
3.3.6 Error Prevention (All): For Web pages forms that require the user to submit information, at least one of the following is true: (Level AAA)
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.
Skip to content