[contents] [checklist]

W3C

Understanding WCAG 2.0

Editor's Draft 24 February 2006

This version:
http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20060224/
Latest version:
http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20
Previous version:
http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20060117/
Editors:
Ben Caldwell, Trace R&D Center
Wendy Chisholm, W3C
John Slatin, University of Texas at Austin
Gregg Vanderheiden, Trace R&D Center

Abstract

This document, "Understanding WCAG 2.0," is an essential guide to understanding and using "Web Content Accessibility Guidelines 2.0" [WCAG20]. It is part of a series of documents that support WCAG 2.0.

WCAG 2.0 establishes a set of "success criteria" to define conformance to the WCAG 2.0 Guidelines. A success criterion is a testable statement that will be either true or false when applied to specific Web content. "Understanding WCAG 2.0" provides detailed information about each success criterion including its intent; the key terms that are used in the success criterion; examples of Web content that meet the success criterion using various Web technologies (for instance, across HTML, CSS, XML) and common examples of Web content that do not meet the success criterion. Finally, this document also explains how the success criteria in WCAG 2.0 help people with different types of disabilities.

Status of this Document

This document is for review by the WCAG WG and is subject to change 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 section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This draft is the First Public Working Draft of "Understanding WCAG 2.0." The Web Content Accessibility Guidelines Working Group (WCAG WG) considers this document to be essential for understanding the success criteria in the Web Content Accessibility Guidelines 2.0 (WCAG 2.0), and encourages feedback on this draft. Please note that the contents of this document are informative (they provide guidance), and not normative (they do not set requirements for conforming to WCAG 2.0).

The WCAG Working Group particularly welcomes feedback on the following questions:

In addition, the WCAG Working Group has not yet had time to list all available techniques for conforming to WCAG 2.0, but intends to make the techniques as comprehensive as possible. Therefore, the WCAG Working Group welcomes contributions of additional techniques for consideration for inclusion in this document. Please submit these in the same manner as other comments as described below.

Please note that the format of this document is still in transition; the WCAG Working Group plans to create separate files for each success criterion, and to link to relevant techniques providing sample code. The WCAG Working Group is also developing a navigation structure that will make it easy to move between the various documents that support WCAG 2.0 documents.

Please send comments by 21 December 2005 to public-comments-wcag20@w3.org. The archives for this list are publicly available. Archives of the WCAG WG mailing list are also publicly available.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This document will be published as a W3C Working Group Note at the time that WCAG 2.0 becomes a W3C Recommendation.

This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals of the WCAG Working Group are discussed in the WCAG Working Group charter. The WCAG Working Group is part of the WAI Technical Activity.


Table of Contents

Appendix


Introduction

Understanding Guideline 1.1: Provide text alternatives for all non-text content.

How to Meet Success Criterion 1.1.1

1.1.1 For non-text content that is used to convey information, text alternatives convey the same information, unless the non-text content is multimedia, live audio-only or live video-only. (Level 1)

Note: For requirements for synchronized alternatives for multimedia refer to Provide synchronized alternatives for multimedia.:

Key Terms

non-text content that conveys information

non-text content content that communicates ideas, data, facts information and is not text.

text alternative

Programmatically determined text that is used in place of non-text content or text that is used in addition to non-text content and referred to from the programmatically determined text.

multimedia

audio or video synchronized with another type of media and/or with time-based interactive elements

live audio-only

A time-based live presentation that contains only audio (no video and no interaction).

live video-only

A time-based live presentation that contains only video (no audio and no interaction).

Intent of this success criterion

The intent of this success criterion is to make information conveyed by non-text content such as charts, diagrams, audio recordings, pictures, and animations available in a form that can be rendered through any modality (for example, visual, auditory or tactile). Providing text alternatives allows the information to be rendered in a variety of ways by a variety of user agents. For example, a person who cannot see a picture can have the text alternative read aloud to them using synthesized speech. A person who cannot hear an audio file can have the text alternative displayed so that he or she can read it.

Labeling multimedia presentations allows users to determine whether or not they want to play it. (Since conforming multimedia has built-in audio descriptions and captions, a full text alternative is not necessary).

Techniques for Addressing Success Criterion 1.1.1

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.1.1.

Instructions: Select the situation below that matches your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.

Situation A: If all information in non-text content can be conveyed in a short description, the following would be sufficient:

  • Providing short text alternatives using a technology-specific technique listed below.

Situation B: If all information in non-text content (except for multimedia) cannot be conveyed in a short description (e.g. a chart or diagram), the following would be sufficient:

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 1.1.1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

General Techniques (Advisory)
HTML Techniques (Advisory)
CSS Techniques (Advisory)

Benefits: How Success Criterion 1.1.1 helps people with disabilities

  • People who are blind, have low vision, or have cognitive disabilities can have text alternatives read aloud to them by assistive technology.

  • People who have trouble reading text may use tools that both read text aloud and highlight the words as they are read. In some cases, it may be difficult for someone to recognize visual information and the text alternative may help him or her understand the purpose of the non-text content.

  • People who are deaf, are hard of hearing, or who are having trouble understanding audio information for any reason can read the text presentation or (in the future) have it translated and presented as sign language by assistive technology.

  • People who are deaf-blind can read the text in braille.

  • Additionally, text alternatives support the ability to search for non-text content and to repurpose content in a variety of ways.

Examples of Success Criterion 1.1.1

In the examples below, a single piece of non-text content is used in different contexts that require different text alternatives.

  1. A data chart

    A bar chart compares how many widgets were sold in June, July, and August. The short label says, "Figure one - Sales in June, July and August." The longer description identifies the type of chart, provides a high-level summary of the data comparable to that available from the chart, and provides the data in a table.

  2. An audio recording of a speech (no video)

    The link to an audio clip says, "Chairman's speech to the assembly." A link to a text transcript is provided immediately after the link to the audio clip.

  3. An animation that illustrates how a car engine works

    An animation shows how a car engine works. There is no audio and the animation is part of a tutorial that describes how an engine works. All that is needed is a description of the image. From "How car engines work: Internal combustion"

  4. A traffic Web camera

    A Web site allows end-users to select from a variety of Web cameras positioned throughout a major city. After a camera is selected, the image updates every two minutes. A short text alternative identifies the Web camera as, "traffic Web camera." The site also provides a table of travel times for each of the routes covered by the Web cameras. The table is also updated every two minutes.

  5. A photograph of an historic event in a news story

    A photograph of two world leaders shaking hands accompanies a news story about an international summit meeting. The text alternative says, "President X of Country X shakes hands with Prime Minister Y of country Y."

  6. A photograph of a historic event in content discussing diplomatic relationships

    The same image used in a different context intended to explain nuances in diplomatic encounters. The image of the president shaking hands with the prime minister appears on a Web site discussing intricate diplomatic relationships. The first text alternative reads, "President X of country X shakes hands with Prime Minister Y of country Y on January 2, 2009." An additional text alternative describes the room where the leaders are standing, the expressions on the leaders' faces, and identifies the other people in the room. The additional description might be included on the same page as the photograph or in a separate file associated with the image through a link or other standard programmatic mechanism.

  7. An audio recording

    The Web page described in the previous example includes a link to an audio recording of the leaders' press conference. The page also links to a text transcript of the press conference. The transcript includes a verbatim record of everything the speakers say. It identifies who is speaking as well as noting other significant sounds that are part of the recording, such as applause, laughter, questions from the audience, and so on.

Related resources


How to Meet Success Criterion 1.1.2

1.1.2 For multimedia, live audio-only or live video-only content, text alternatives identify the content with a descriptive label. (See also, Provide synchronized alternatives for multimedia.: .) (Level 1)

Key Terms

multimedia

audio or video synchronized with another type of media and/or with time-based interactive elements

live audio-only

A time-based live presentation that contains only audio (no video and no interaction).

live video-only

A time-based live presentation that contains only video (no audio and no interaction).

text alternative

Programmatically determined text that is used in place of non-text content or text that is used in addition to non-text content and referred to from the programmatically determined text.

label

text that identifies a component within Web content

Intent of this success criterion

For multimedia and live single media non-text content (live audio-only or live video-only), it is important at Level 1 that users at least be able to identify what the content is, even if full text alternatives are not required at Level 1. A descriptive label is therefore specified for these categories that are exceptions from success criterion 1.1.1. Other requirements may also apply in guideline 1.2, but this success criterion is focused on ensuring that the items can at least be identified, even if they are not played or able to be played by the user.

Techniques for Addressing Success Criterion 1.1.2

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.1.2.

Technology-independent techniques

  • Providing a descriptive label that describes the purpose of live audio-only and live video-only content, using a technology-specific technique listed below.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 1.1.2

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Benefits: How Success Criterion 1.1.2 helps people with disabilities

  • People with visual impairments and/or cognitive difficulties can have the description read to them with assistive technology to help determine the purpose of the content.

  • People with hearing impairments can read the description to help determine the purpose of the content.

  • People who are deaf and blind can determine the purpose of the content in braille.

Examples of Success Criterion 1.1.2

  • A streaming audio speech.

    The link to a streaming live audio speech is labeled, "Finnie Jones' Speech to the Congregation".

  • A live video (no sound).

    The link to a live video (no sound) of a professor answering questions about a new theorem is labeled, "Professor Vanderhelm explains and answers questions on Plinthal's Theorem - Live".

  • A live radio broadcast.

    A radio station broadcasts over the internet. The station's Web site describes the genre of music played and a schedule of the shows, and the "current song" is updated each time the DJ starts a new track.

  • An on-line class.

    The link to a streaming presentation of a chemistry class goes beyond the minimum by not only describing the topic but also providing links to lecture notes and related readings.

  • An on-line photo editor.

    An embedded user interface allows uers to upload and modify photographs on-line. The interface includes the ability to crop, resize, color correct and apply various special effects to images. The text alternative identifies the purpose of the non-text content as "photo editor: upload and modify your photographs on-line." The photo editor interface is accessible.

Related resources


How to Meet Success Criterion 1.1.3

1.1.3 For non-text content that is functional, text alternatives serve the same purpose as the non-text content. If text alternatives can not serve the same purpose as the functional non-text content, text alternatives identify the purpose of the functional non-text content. (Level 1)

Key Terms

non-text content that is functional

non-text content that is capable of performing one or more actions in response to user input and is not text.

Note: This includes, but is not limited to, images used as links, image-based submit buttons, applets, and embedded programmatic objects.

text alternative

Programmatically determined text that is used in place of non-text content or text that is used in addition to non-text content and referred to from the programmatically determined text.

Intent of this success criterion

The intent of this success criterion is to ensure that the function of non-text content, such as images used as submit buttons, is available in text form if at all possible. If it is not possible to make the function available in text, then the function is identified in text.

Techniques for Addressing Success Criterion 1.1.3

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.1.3.

Instructions: Select the situation below that matches your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.

Situation A: If text alternatives can serve the same purpose as the functional non-text content, the following would be sufficient:

  • Providing a text alternative that serves the same purpose as the non-text content, using one of the technology-specific techniques below.

Situation B: If text alternatives cannot serve the same purpose as the functional non-text content, the following would be sufficient:

  • Providing a text alternative that identifies the purpose of the functional non-text content, using one of the technology-specific techniques below.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 1.1.3

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

General Techniques (Advisory)
HTML Techniques (Advisory)
CSS Techniques (Advisory)

Benefits: How Success Criterion 1.1.3 helps people with disabilities

Individuals who blind or deaf blind and using a screen reader or braille display cannot always access the functional non-text content. The text alternatives allow them to access the functionality of the content.

Examples of Success Criterion 1.1.3

In the examples below, a single piece of non-text content is used in different contexts that require different text alternatives.

  1. An image used as a button

    A magnifying glass icon is used to link to the search page of a Web site. A screen reader identifies the button as a link and speaks the text alternative, "Search."

Related resources


How to Meet Success Criterion 1.1.4

1.1.4 For non-text content that is intended to create a specific sensory experience, text alternatives at least identify the non-text content with a descriptive label. (Level 1)

Key Terms

non-text content that is intended to create a specific sensory experience

non-text content that causes a sensory experience that is not purely decorative and does not primarily convey important information or perform a function

text alternative

Programmatically determined text that is used in place of non-text content or text that is used in addition to non-text content and referred to from the programmatically determined text.

label

text that identifies a component within Web content

Intent of this success criterion

People who are not able to fully perceive content that is intended primarily to create a sensory experience can become confused about the purpose of this content if its name or short description is not provided. Although they may not be able to perceive and experience this content, giving it a name (or a short description) will help these people understand what it is that they have encountered in the content.

Techniques for Addressing Success Criterion 1.1.4

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.1.4.

Technology-independent techniques

  • Providing the descriptive name or the name the artist (or other person) gave to the non-text content, using a technology-specific technique for providing short text alternatives listed below.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 1.1.4

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

General Techniques (Advisory)
  • Providing an additional description of the non-text content using a technology-specific technique for long description listed below.

Providing long descriptions in HTML

Benefits: How Success Criterion 1.1.4 helps people with disabilities

If non-text content does not have a label, a screen reader or braille display will not know how to identify it. Without text alternatives, people who are blind or deaf blind and using a screen reader or braille display won't know what they are encountering. Even if they cannot see a painting for example, being able to hear its name (or a short description) will help them understand what it is that they have encountered in the content.

Examples of Success Criterion 1.1.4

  • A recording of a symphony.

    The Mars Philharmonic Orchestra's "Upcoming performances" page has a link to a three minute clip of the orchestra's rendition of Beethoven's 5th Symphony. The purpose is to encourage readers to buy tickets to a live performance. The link to the audio clip says, "Beethoven's 5th Symphony performed by the Mars Philharmonic Orchestra." On the same page is information about Beethoven and the 5th Symphony.

    Both pages satisfy this success criterion.

Related resources


How to Meet Success Criterion 1.1.5

1.1.5 Non-text content that is not functional, is not used to convey information, and does not create a specific sensory experience is implemented such that it can be ignored by assistive technology. (Level 1)

Key Terms

non-text content

Content that is not represented by a Unicode character or sequence of Unicode characters when rendered in a user agent according to the formal specification of the content type. This includes ASCII Art, which is a pattern of characters.

non-text content that is functional

non-text content that is capable of performing one or more actions in response to user input and is not text.

Note: This includes, but is not limited to, images used as links, image-based submit buttons, applets, and embedded programmatic objects.

non-text content that conveys information

non-text content content that communicates ideas, data, facts information and is not text.

non-text content that is intended to create a specific sensory experience

non-text content that causes a sensory experience that is not purely decorative and does not primarily convey important information or perform a function

Assistive technology

In the context of this document, an assistive technology is a user agent that:

  1. relies on services (such as retrieving Web content and parsing markup) provided by one or more other "host" user agents. Assistive technologies communicate data and messages with host user agents by using and monitoring APIs.

    provides services beyond those offered by the host user agents to meet the requirements of users with disabilities. Additional services include alternative renderings (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible).

Examples of assistive technologies that are important in the context of this document include the following:

  • screen magnifiers, which are used by people with visual disabilities to enlarge and change colors on the screen to improve the visual readability of rendered text and images.

  • screen readers, which are used by people who are blind or have reading disabilities to read textual information through synthesized speech or braille displays.

  • voice recognition software, which may be used by people who have some physical disabilities.

  • alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard.

  • alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.

Note: This term was taken from User Agent Accessibility Guidelines 1.0 Glossary.

Intent of this success criterion

Non-text content that does not have a specific purpose for users of the content (convey information, perform a function or create a specific sensory experience) should not be described because that would slow down some users who are accessing the content in text mode. However, if it has no text alternative, the user is then left wondering what the content is. The purpose of this success criterion is to make such content identifiable by assistive technologies as content that should be skipped.

Techniques for Addressing Success Criterion 1.1.5

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.1.5.

Technology-independent techniques

  • Marking the non-text content using one of the technology-specific techniques listed below.

Editorial Note: Not all mechanisms for including non-text content have a convention similar to empty alt for img elements (object and embed are two examples). Are there additional strategies/techniques for addressing this criterion that should be included here to address this?

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 1.1.5

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

CSS Techniques (Advisory)

Benefits: How Success Criterion 1.1.5 helps people with disabilities

  • Users of screen readers or braille output devices are not slowed down by data that have no purpose for them.

Examples of Success Criterion 1.1.5

  • A pair of images used to create a visual effect.

    Two images are used to create curved edges on a "tabbed" interface. The images do not provide information, functionality, or a sensory experience and are marked such that they can be ignored by an assistive technology (e.g. alt="").

Related resources

  • 'background-image' - from the CSS 2.1 Candidate Recommendation - how to use CSS to specify background images.


How to Meet Success Criterion 1.1.6

1.1.6 For prerecorded multimedia content, a combined document containing both captions and transcripts of audio descriptions of video is available. (Level 3)

Key Terms

captions

Synchronized transcripts of dialogue and important sounds. Captions provide access to multimedia for people who are deaf or hard of hearing.

audio description

narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone. During naturally-occurring pauses in dialog, audio descriptions of video provide information about actions, characters, scene changes and on-screen text.

Intent of this success criterion

This success criterion is designed to make audio visual material available to individuals whose vision is too poor to reliably read captions and whose hearing is too poor to reliably hear dialogue and audio descriptions. This is done by providing a single text document that consists of a combination of the captions (see SC 1.2.1) and a text transcript of the audio descriptions (see SC 1.2.2).

Techniques for Addressing Success Criterion 1.1.6

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.1.6.

Technology-independent techniques

Technology-Specific Techniques

Linking to a collated script in HTML

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 1.1.6

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

General Techniques (Advisory)

Benefits: How Success Criterion 1.1.6 helps people with disabilities

  • People who cannot see well or at all and who also cannot hear well or at all can get access to information in audio-visual presentations.

Examples of Success Criterion 1.1.6

  • A text description of a movie.

    An author takes a recording of a movie with descriptions and transcribes both the text and the audio description. She then watches the movie, picking up any additional information that is in the captions such as sounds or speaker identification and adds it to the transcription. The result is posted on the Web with a link to it immediately next to the movie's link.

Related resources


Understanding Guideline 1.2: Provide synchronized alternatives for multimedia.

How to Meet Success Criterion 1.2.1

1.2.1 Captions are provided for prerecorded multimedia. (Level 1)

Key Terms

captions

Synchronized transcripts of dialogue and important sounds. Captions provide access to multimedia for people who are deaf or hard of hearing.

multimedia

audio or video synchronized with another type of media and/or with time-based interactive elements

Intent of this success criterion

The intent of this success criterion is to enable people who are deaf or hard of hearing to watch multimedia presentations. Captions provide the part of the content available via the audio track. Captions not only include dialog, but identify who is speaking and note important sounds.

Techniques for Addressing Success Criterion 1.2.1

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.2.1.

Technology-Specific Techniques

SMIL 1.0 Techniques

SMIL 2.0 Techniques

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

  • Caption does not meet the definition of a caption (i.e. it does not include both dialog and important sounds).

Optional Techniques (Advisory) for 1.2.1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Additional SMIL 1.0 Techniques (Advisory)

  • Providing captions for all languages for which there are audio tracks.

Additional SMIL 2.0 Techniques (Advisory)

  • Providing SMIL 2.0 captions for all languages for which there are audio tracks.

Benefits: How Success Criterion 1.2.1 helps people with disabilities

People who are deaf or have a hearing loss can access the auditory information in the multimedia content through captions.

Examples of Success Criterion 1.2.1

  • A captioned tutorial

    A video clip shows how to tie a knot. The captions read,

    "(music)

    Using rope to tie knots was an important skill

    for the likes of sailors, soldiers and woodsmen.."

    From Sample Transcript Formatting by Whit Anderson.


How to Meet Success Criterion 1.2.2

1.2.2 Audio descriptions of video are provided for prerecorded multimedia. (Level 1)

Key Terms

audio description

narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone. During naturally-occurring pauses in dialog, audio descriptions of video provide information about actions, characters, scene changes and on-screen text.

multimedia

audio or video synchronized with another type of media and/or with time-based interactive elements

Intent of this success criterion

The intent of this success criterion is to provide people who are blind or visually impaired access to the visual information in a multimedia presentation. The audio description augments the audio portion of the presentation with the information needed when the video portion is not available. During naturally-occurring pauses in dialog, audio descriptions provide information about actions, characters, scene changes and on-screen text which are important and are not described or spoken in the main sound track.

Techniques for Addressing Success Criterion 1.2.2

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.2.2.

Technology-independent techniques

  • Using a technology-specific technique to create and incorporate or programmatically associate audio description for the multimedia content.

Technology-Specific Techniques

SMIL 1.0 Techniques

SMIL 2.0 Techniques

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

(None currently documented.)

Optional Techniques (Advisory) for 1.2.2

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

(None currently documented.)

Benefits: How Success Criterion 1.2.2 helps people with disabilities

  • People who are blind or have low vision as well as those with cognitive disabilities who have difficulty interpreting visually what is happening benefit from audio descriptions of visual information.

Examples of Success Criterion 1.2.2

  • A movie with audio description.

    Describer: A title, "Teaching Evolution Case Studies. Bonnie Chen." A teacher shows photographs of birds with long, thin beaks.

    Bonnie Chen: "These photos were all taken at the Everglades."

    Describer: The teacher hands each student two flat, thin wooden sticks.

    Bonnie Chen: "Today you will pretend to be a species of wading bird that has a beak like this."

    Describer: The teacher holds two of the sticks to her mouth making the shape of a beak.

    Transcript of audio based on the first few minutes of, "Teaching Evolution Case Studies, Bonnie Chen" (copyright WGBH and Clear Blue Sky Productions, Inc.)


How to Meet Success Criterion 1.2.3

1.2.3 Captions are provided for live multimedia. (Level 2)

Key Terms

captions

Synchronized transcripts of dialogue and important sounds. Captions provide access to multimedia for people who are deaf or hard of hearing.

multimedia

audio or video synchronized with another type of media and/or with time-based interactive elements

Intent of this success criterion

The intent of this success criterion is to enable people who are deaf or hard of hearing to watch real-time presentations. Captions provide the part of the content available via the audio track. Captions not only include dialog, but also identify who is speaking and notate sound effects and other significant audio.

Techniques for Addressing Success Criterion 1.2.3

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.2.3.

Technology-independent techniques

Note: Captions may be generated using real-time text translation service (stenographic or someday speech-to-text with corrections).

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 1.2.3

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Benefits: How Success Criterion 1.2.3 helps people with disabilities

  • People who are deaf or have a hearing loss can access the auditory information in the multimedia content through captions.

Examples of Success Criterion 1.2.3

  • A Web cast

    A news organization provides a live, captioned Web cast.


How to Meet Success Criterion 1.2.4

1.2.4 Sign language interpretation is provided for multimedia. (Level 3)

Key Terms

sign language interpretation

translation of spoken words and other audible information into a language that uses a simultaneous combination of handshapes, facial expressions, and orientation and movement of the hands, arms or body to convey meaning.

Note: Although some languages have a signed counterpart, most sign languages are an independent language which is unrelated to the spoken language of the same country or culture.

multimedia

audio or video synchronized with another type of media and/or with time-based interactive elements

Intent of this success criterion

The intent of this success criterion is to enable people who are deaf or hard of hearing and who are fluent in the sign language to watch multimedia presentations. Many people find it easier to follow sign language than to read the text of captions, since the captions are often a second language to them.

Note: The sign language for each country is a separate language from the spoken language.

Techniques for Addressing Success Criterion 1.2.4

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.2.4.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

(None currently documented.)

Optional Techniques (Advisory) for 1.2.4

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Sign Language Interpretation in SMIL 1.0
Sign Language Interpretation in SMIL 2.0

Benefits: How Success Criterion 1.2.4 helps people with disabilities

  • There is a segment of the population that is able to communicate in sign language, but may have weak reading skills. These individuals may not be able to read and comprehend the captions and thus require a sign language interpretation to gain access to the multimedia content.

  • Some people who communicate using sign language and are proficient readers may have impaired vision which may make it difficult to read the captions on the screen. A sign language interpretation may be easier to view.

Examples of Success Criterion 1.2.4

  • Example 1. A corporation is making an important announcement to all of its employees. The meeting will be held in the main headquarters and streamed to the Web. A sign language interpreter is provided at the meeting location. The live video includes a full view of the sign language interpreter as well as the person presenting.

  • Example 2.The same announcement as Example 1 is also Webcast to remote employees. Since there is only one display available for this, the sign language interpreter is shown in the corner of the display.

  • Example 3.A university is providing an on-line version of a particular lecture by creating a multimedia presentation of the professor delivering the lecture. The presentation includes video of the professor speaking and demonstrating a science experiment. A sign language interpretation of the lecture is created and presented on the Web with the multimedia version.


How to Meet Success Criterion 1.2.5

1.2.5 Extended audio descriptions of video are provided for prerecorded multimedia. (Level 3)

Key Terms

extended audio descriptions

audio descriptions that are added to an audio/visual presentation by pausing the video so that there is time to add addional description. This technique is only used when the sense of the video would be lost without the additional audio description.

multimedia

audio or video synchronized with another type of media and/or with time-based interactive elements

Intent of this success criterion

The intent of this success criterion is to provide people who are blind or vision impaired access to a multimedia presentation beyond that which can be provided by standard audio descriptions.

Techniques for Addressing Success Criterion 1.2.5

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.2.5.

Technology-independent techniques

  • Creating an extended audio description for the multimedia content using a technology-specific technique listed below.

Extended Audio Descriptions in SMIL 1.0

Extended Audio Descriptions in SMIL 2.0

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

(None currently documented.)

Optional Techniques (Advisory) for 1.2.5

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Additional SMIL 1.0 Techniques
Additional SMIL 2.0 Techniques

Benefits: How Success Criterion 1.2.5 helps people with disabilities

  • People who are blind, people with low vision who cannot see the screen, as well as those with cognitive disabilities who have difficulty interpreting visually, often use audio descriptions of the visual information. However, if there is too much dialog - the audio descriptions are insufficient. Extended audio descriptions can provide the additional information they need to really understand the video.

Examples of Success Criterion 1.2.5

(none documented at this time)


Understanding Guideline 1.3: Ensure that information and structure can be separated from presentation

How to Meet Success Criterion 1.3.1

1.3.1 Perceivable structures within the content can be programmatically determined. (Level 1)

Key Terms

perceivable structures

relationships in the content that are necessary to perceive the organization of the content.

programmatically determined

can be recognized by user agents, including assistive technologies, that support the technologies in the chosen baseline

Intent of this success criterion

The intent of this success criterion is to enable assistive technology to render Web content in an alternative presentation such as synthesized speech or using larger fonts or different colors while preserving the important structural relationships in the content.

Web content developers add structure to information in order to organize it in a way that makes it easier to understand. Sighted users perceive the structure through various visual cues — headings are often in a larger, bold font a separated from paragraphs by blank lines; list items are preceded by a bullet and perhaps indented; paragraphs are separated by a blank line; items that share a common characteristic are organized into tabular rows and columns; form fields may be positioned as groups that share text labels.

The purpose of this success criterion is to ensure that any structure that is perceivable to one set of users can be made to be perceivable to all.

Techniques for Addressing Success Criterion 1.3.1

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.3.1.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 1.3.1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

(None currently documented.)

Benefits: How Success Criterion 1.3.1 helps people with disabilities

  • Providing the ability to programmatically determine structure allows Web content to be presented differently to meet the needs and constraints of people with visual, hearing, and cognitive disabilities. In order for the information to be presented differently, it is necessary for the assistive technology to be able to understand the type of information. For example, if tables of information are programmatically identified as tables, a screen reader can unambiguously determine the contents of each table cell. If tables are instead created simply by positioning content in vertical columns, screen readers will only be able to read each line of text. If the "visual cells" contain more than one line of information, the user will not be able to understand it because the lines of each cell will get intermixed with the corresponding lines in the other cells. The screen reader will read the first line of each cell, then the next line of each cell, and so on.

Examples of Success Criterion 1.3.1

  • A form that uses color and an asterisk to indicated required fields

    A form contains both required and optional fields. Instructions at the top of the form explain that required fields are labeled with red text and also with an asterisk. Both the red text and the asterisk are programmatically associated with the appropriate form fields so that assistive technology users can determine the required fields.

  • A bus schedule table where the headers for each cell can be programmatically determined

    A bus schedule consists of a table with the bus stops listed vertically in the first column and the different buses listed horizontally across the first row. Each cell contains the time when the bus will be at that bus stop. The bus stop and bus cells are identified as headers for their corresponding row or column so that an assistive technology can programmatically determine which bus and which bus stop are associated with the time in each cell.

  • A form where the labels for the checkboxes can be programmatically determined

    In a form, the labels for each checkbox can be programmatically determined by an assistive technology.

  • A text document

    A simple text document is formatted with double blank lines before titles, asterisks for bullets and other standard formatting conventions so that its structure can be programmatically determined.


How to Meet Success Criterion 1.3.2

1.3.2 When information is conveyed by color, the color can be programmatically determined or the information is also conveyed through another means that does not depend on the user's ability to differentiate colors. (Level 1)

Key Terms

information is conveyed by color

perception of the color attributes is essential to understanding a piece of content

programmatically determined

can be recognized by user agents, including assistive technologies, that support the technologies in the chosen baseline

Intent of this success criterion

The intent of this success criterion is to ensure that all users can access information that is conveyed by color. If the information is conveyed through color in an image (or other non-text format), the color cannot be programmatically determined by assistive technology. In this case, providing the information conveyed with color through another means ensures that assistive technology users who cannot see the color can still perceive the information.

Color is an important asset in design of Web content, enhancing its aesthetic appeal, its usability, and its accessibility. However, some users have difficulty perceiving color. People with partial sight often experience limited color vision, and many older users do not see color well. In addition, people using text-only, limited-color or monochrome displays and browsers will be unable to access information that is presented only in color.

When color is essential to understanding content, making sure the color can be programmatically determined allows assistive technologies to inform the user about the color so they can access the information conveyed by the color. Alternately, the information conveyed by color could be made accessible by also conveying it in a non-color dependent way.

Techniques for Addressing Success Criterion 1.3.2

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.3.2.

Situation B: Color is being used within an image to convey information.

Situation C: The user agent for the technology being used supports an accessibility API

Technology-Specific Techniques

HTML Techniques
  • (None currently documented.)

CSS Techniques

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 1.3.2

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

General Techniques
CSS Techniques

Benefits: How Success Criterion 1.3.2 helps people with disabilities

  • User with visual disabilities.

    • Users with partial sight often experience limited color vision.

    • Users who are blind (using a text-only reader) and need to determine information based on color.

    • Some older users may not be able to see color well.

    • Users who have color-blindness.

    • Users with hearing and visual disabilities.

      • Users who are blind-deaf using braille (text) refreshable displays may be unable to access color-dependent information.

    • People using text-only, limited color or monochrome displays may be unable to access color-dependent information.

    • Users with a handheld device which renders information but with no color context.

    • People using text-only, limited color or monochrome browsers (user agents) may be unable to access color-dependent information.

Examples of Success Criterion 1.3.2

  • A form that uses color and an asterisk to indicated required fields

    A form contains both required and optional fields. Instructions at the top of the form explain that required fields are labeled with red text and also with an asterisk. Both the red text and the asterisk are programmatically associated with the appropriate form fields so that assistive technology users can determine the required fields.

  • An examination.

    Students view an SVG image of a chemical compound and identify the chemical elements present based on the colors used in the diagram. The text alternatives associated with each element name the color of the element and indicate the element's position in the diagram. Students who cannot perceive color have the same information about the compound as their classmates. (This technique also satisfies Guideline 1.1 Level 1.)

Related resources


How to Meet Success Criterion 1.3.3

1.3.3 Any information that is conveyed by color is visually evident when color is not available. (Level 1)

Key Terms

information is conveyed by color

perception of the color attributes is essential to understanding a piece of content

Intent of this success criterion

The intent of this success criterion is to ensure that all users can access information that is conveyed by color.

This success criterion is similar to 1.3.2. However where 1.3.2 allows color information to be made accessible directly OR via assistive technology — this success criterion (1.3.4) is focused on people with color anomalies who do not use assistive technologies. Hence this success criterion is focused on seeing that information conveyed via color is available without color and without requiring the person to use any assistive technologies.

Color is an important asset in the design of Web content, enhancing its aesthetic appeal, its usability, and its accessibility. It is not the intent of this success criterion to discourage its use. However, some users have difficulty perceiving color. People with partial sight often experience limited color vision, and many older users do not see color well. In addition, people using text-only, limited-color or monochrome displays and browsers will be unable to access information that is presented only in color

Therefore, when color is essential to understanding content, it is important to make sure that the information conveyed by color is also conveyed in a non-color dependent way.

Techniques for Addressing Success Criterion 1.3.3

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.3.3.

Instructions: Select the situation below that matches your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.

Situation B: Color is being used within an image to convey information.

Technology-Specific Techniques

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

(None currently documented.)

Optional Techniques (Advisory) for 1.3.3

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

General Techniques (Advisory)
  • Color used as redundant information is acceptable and encouraged.

Benefits: How Success Criterion 1.3.3 helps people with disabilities

  • Color is an important asset in Web design, enhancing usability and aesthetic appeal. However, some users have difficulty perceiving color. People with partial sight often experience limited color vision, and many older users do not see color well. In addition, people using text-only and monochrome displays will be unable to access information that is presented only in color.

Examples of Success Criterion 1.3.3

  1. A form that uses color and an asterisk to indicated required fields

    A form contains both required and optional fields. Instructions at the top of the form explain that required fields are labeled with red text and also with an asterisk. Both the red text and the asterisk are programmatically associated with the appropriate form fields so that assistive technology users can determine the required fields.

  2. An examination.

    Students view an SVG image of a chemical compound and identify the chemical elements present based on the colors used in the diagram. The text alternatives associated with each element name the color of the element and indicate the element's position in the diagram. Students who cannot perceive color have the same information about the compound as their classmates. (This technique also satisfies Guideline 1.1 Level 1.)


How to Meet Success Criterion 1.3.4

1.3.4 Information that is conveyed by variations in presentation of text is also conveyed in text or the variations in presentation of text can be programmatically determined. (Level 2)

Key Terms

presentation

Presentation is the rendering of the content and structure in a form that can be perceived by the user.

variations in presentations in text

Changes in the visual appearance or sound of the text, such as changing to a different font or a different voice.

programmatically determined

can be recognized by user agents, including assistive technologies, that support the technologies in the chosen baseline

Intent of this success criterion

The intent of this success criterion is to make information conveyed by varying the presentation of text available even if the information is presented in an alternative modality or if the person cannot perceive the text variations.

On a visual medium, examples of variations in the presentational of text would include:

  • emphasizing some words by bolding, italicizing or underlining them;

  • indicating content headings by increased font size and bolding font;

  • emphasizing words or indicating that they have special status (such as a key term) by changing the font family used to present them;

  • emphasizing words by raising them above centerline in a line of text.

Techniques for Addressing Success Criterion 1.3.4

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.3.4.

Technology-independent techniques

  • Using technology-specific standard techniques for marking emphasized or special text.

  • Providing the same information redundantly in the running text.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 1.3.4

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

(None currently documented.)

Benefits: How Success Criterion 1.3.4 helps people with disabilities

  • Users of screen readers or refreshable braille displays may be unable to access information conveyed by the formatting of text.

  • People with decreased visual perception, including some older users, may not see text formatting well.

Examples of Success Criterion 1.3.4

(none provided at this time)


How to Meet Success Criterion 1.3.5

1.3.5 When content is arranged in a sequence that affects its meaning, that sequence can be programmatically determined. (Level 2)

Key Terms

programmatically determined

can be recognized by user agents, including assistive technologies, that support the technologies in the chosen baseline

Intent of this success criterion

The intent of this success criterion is to enable an assistive technology to provide an alternative presentation of content while preserving the reading order needed to perceive meaning. The order of words in sentences and sentences in paragraphs, for instance, is always critical to meaning. However, if a page contains two independent articles, the relative order of the articles may not affect their meaning, as long as they are not interleaved. It must be possible to programmatically determine at least one sequence of the content that makes sense.

Techniques for Addressing Success Criterion 1.3.5

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.3.5.

Technology-Specific Techniques

CSS Techniques

Optional Techniques (Advisory) for 1.3.5

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

HTML Techniques (Advisory)
Client-Side Scripting Techniques

Benefits: How Success Criterion 1.3.5 helps people with disabilities

  • This success criterion benefits users with visual, hearing, and cognitive disabilities that rely on an alternative, linear presentation of the content. The meaning evident in the sequencing of the information in the default presentation will be the same when they access the information in the linear presentation. When this success criterion is not satisfied, users may be confused or disoriented when the information is presented in an order that makes no sense.

Examples of Success Criterion 1.3.5

  • Example 1: In a multi-column document, the linear presentation of the content flows from the top of a column to the bottom of the column, then to the top of the next column.

  • Example 2: CSS is used to position a navigation bar, the main story on a page, and a side story. The visual presentation of the sections does not match the programmatically determined order, but the meaning of the page does not depend on the order of the sections.


How to Meet Success Criterion 1.3.6

1.3.6 Information required to understand and operate content does not rely on shape, size, visual location, or orientation of components. (Level 2)

Intent of this success criterion

The intent of this success criterion is to ensure that all users can access instructions for using the content, even when users cannot perceive shapes, size or use information about spatial location or orientation. Some content relies on knowledge of the shape or position of objects that are not available from the structure of the content (for example, "round button" or "button to the right"). Some users with disabilities are not able to perceive shape or position due to the nature of the assistive technologies they use. This success criterion requires that additional information be provided to clarify anything that is dependent on this kind of information.

Providing information using shape and/or location, however, is an effective method for many users including those with cognitive disability. This provision should not discourage those types of cues as long as the information is also provided in other ways.

Techniques for Addressing Success Criterion 1.3.6

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.3.6.

Optional Techniques (Advisory) for 1.3.6

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Benefits: How Success Criterion 1.3.6 helps people with disabilities

  • People who are blind and people who have low vision may not be able to understand information if it is conveyed by shape and/or location alone. Providing additional information other than shape and/or location will allow them to understand the information conveyed by shape and/or alone.

Examples of Success Criterion 1.3.6


Understanding Guideline 1.4: Make it easy to distinguish foreground information from its background

How to Meet Success Criterion 1.4.1

1.4.1 Text or diagrams, and their background, have a luminosity contrast ratio of at least 5:1. (Level 2)

Key Terms

luminosity contrast ratio

(L1+.05) / (L2+.05) where L is luminosity and is defined as .2126*R + .7152*G + .0722B using linearized R, G, and B values. Linearized R (for example) = (R/FS)^2.2 where FS is full scale value (255 for 8 bit color channels). L1 is the higher value (of text or background) and L2 is the lower value.

Intent of this success criterion

The purpose of this success criterion is to provide enough contrast between text and its background so that it can be easily read by people with low vision. The contrast is calculated in such a way that color is not a key factor so that people who also have a color vision deficit will also see a contrast between the text and the background.

The .05 offset is included to compensate for ratio effects that occur when one value is at or near zero and for ambient light effects.

The Gamma correction (^2.2) and the RGB constants are from the sRGB definition.

This success criterion uses the term luminosity contrast ratio rather than luminance to reflect the fact that Web content does not emit light itself. Luminosity contrast ratio gives a measure of the relative luminance that would result when displayed. (Because it is a ratio, it is dimensionless.)

Techniques for Addressing Success Criterion 1.4.1

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.4.1.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

(None currently documented.)

Optional Techniques (Advisory) for 1.4.1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Benefits: How Success Criterion 1.4.1 helps people with disabilities

People with low vision often have difficulty reading text that does not contrast with its background. This can be exacerbated if the person has a color vision deficiency that lowers the contrast even further. Providing a minimum luminance contrast ratio between the text and its background can make the text more readable even if the person does not see the full range of colors. It also works for the rare individuals who see no color.

Examples of Success Criterion 1.4.1


How to Meet Success Criterion 1.4.2

1.4.2 A mechanism is available to turn off background audio that plays automatically, without requiring the user to turn off all audio. (Level 2)

Intent of this success criterion

Individuals who use screen reading software can find it hard to understand the speech output if there is other audio playing at the same time. This is exacerbated when the screen reader's speech output is software based (as most are today) and is controlled via the same volume control as the sound. The purpose of the success criterion is to provide a means to turn it off. Since the screen reader user must use the screen reader to access any controls on the screen, the means to turn it off should be easy to operate and not masked completely by loud music.

Techniques for Addressing Success Criterion 1.4.2

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.4.2.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 1.4.2

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Benefits: How Success Criterion 1.4.2 helps people with disabilities

Individuals who use screen reading technologies can hear the screen reader without other sounds playing. This is especially important for those who are hard of hearing and for those whose screen readers use the system volume (so they cannot turn sound down and screen reader up).

It also benefits those who have attention deficit disorders that prevent them from ignoring sounds and focusing on the Web content.

Examples of Success Criterion 1.4.2

  • An audio file begins playing automatically when a page is opened, however it can be stopped by the user by selecting a "silent" link at the top of the page.


How to Meet Success Criterion 1.4.3

1.4.3 Text or diagrams, and their background, have a luminosity contrast ratio of at least 10:1. (Level 3)

Key Terms

luminosity contrast ratio

(L1+.05) / (L2+.05) where L is luminosity and is defined as .2126*R + .7152*G + .0722B using linearized R, G, and B values. Linearized R (for example) = (R/FS)^2.2 where FS is full scale value (255 for 8 bit color channels). L1 is the higher value (of text or background) and L2 is the lower value.

Intent of this success criterion

The purpose of this success criterion is to provide enough contrast between text and its background so that it can be easily read by people with low vision. The contrast is calculated in such a way that color is not a key factor so that people who also have a color vision deficit will also see a contrast between the text and the background. This differs from 1.4.1, the Level 2 success criterion, in that it requires a higher level of contrast.

The .05 offset is included to compensate for ratio effects that occur when one value is at or near zero and for ambient light effects.

The Gamma correction (^2.2) and the RGB constants are from the sRGB definition.

Techniques for Addressing Success Criterion 1.4.3

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.4.3.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

(None currently documented.)

Optional Techniques (Advisory) for 1.4.3

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Benefits: How Success Criterion 1.4.3 helps people with disabilities

People with low vision often have difficulty reading text that does not contrast with its background. This can be exacerbated if the person has a color vision deficiency that lowers the contrast even further. Providing a minimum luminance contrast ratio between the text and its background can make the text more readable even if the person does not see the full range of colors. It also works for the rare individuals who see no color.

Examples of Success Criterion 1.4.3


How to Meet Success Criterion 1.4.4

1.4.4 Audio content does not contain background sounds, background sounds can be turned off, or background sounds are at least 20 decibels lower than the foreground audio content, with the exception of occasional sound effects. (Level 3)

Note: A 20 decibel difference in sound level is roughly 4 times quieter (or louder). Background sound that meets this requirement will be approximately four times (4x) quieter than the foreground audio content.

Intent of this success criterion

Individuals who are hard of hearing have difficulty separating speech from background sounds or other noise. The purpose of this success criterion is to ensure that the non-speech sounds are low enough that a user can understand the speech. A 20 decibel difference in sound level is roughly 4 times quieter (or louder). Non-speech sound that meets this requirement will be approximately four times (4x) quieter than the speech content.

Techniques for Addressing Success Criterion 1.4.4

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 1.4.4.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

(None currently documented.)

Optional Techniques (Advisory) for 1.4.4

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

(None currently documented.)

Benefits: How Success Criterion 1.4.4 helps people with disabilities

People who are hard of hearing often have great difficulty separating speech from background sound.

Examples of Success Criterion 1.4.4

The following audio tracks provide examples of speech over background sounds.

In the first example the voice (foreground) is recorded at -17.52 decibels and the music (background) is at -37.52 decibels, which makes the foreground 20 decibels louder than the background.

In the second example the voice (foreground) is at -18 decibels and the music (background) is at about -16 decibels making the foreground only 2 decibels louder than the background.

http://www.eramp.com/david/audio_contrast.htm.

Related resources


Understanding Guideline 2.1: Make all functionality operable via a keyboard interface.

How to Meet Success Criterion 2.1.1

2.1.1 All functionality of the content is operable in a non time-dependent manner through a keyboard interface, except where the task requires analog, time-dependent input. (Level 1)

Note: This does not preclude and should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation.

Key Terms

functionality

processes and outcomes acheivable through user action

keyboard interface

interface used by software to obtain keystroke input

Note: Allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.

A touch screen PDA has a keyboard interface built into its OS and a connector for connecting external Keyboards. Applications on the PDA can use the interface to obtain keyboard input from either an external keyboard or from other applications that provide simulated keyboard output - such as handwriting interpreters or speech to text applications with "keyboard emulation" functionality.

Note: Operation of the application (or parts of the application) through a keyboard operated mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard interface because operation of the program is through its pointing device interface - not through its keyboard interface.

analog, time-dependent input

where the outcome of the input is different depending on the rate of the analog movement (such as when line width varies with pen speed or pressure.) This condition is used to make exceptions where there is no known method for allowing keyboard control but not allow exceptions for those situations were keyboard commands can be used for actions normally done with a mouse such as clicking, selecting, moving, sizing.

Intent of this Success Criterion

The purpose of this success criterion is to ensure that, wherever possible, content can be operated through a keyboard or keyboard interface. When content can be operated through a keyboard or alternate keyboard, it is operable by people with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as by people who must use alternate keyboards or input devices that act as keyboard emulators. Keyboard emulators include speech input software, sip and puff software, on-screen keyboards, scanning software and a variety of assistive technologies and alternate keyboards. Individuals with low vision also may have trouble tracking a pointer and find use of software much easier (or only possible) if they can control it from the keyboard.

Some types of Web content functionality however cannot be controlled from the keyboard. A watercolor application for example where the stroke is defined by the movement and speed of movement and/or pressure is one example. The phrase "except where the task requires analog, time-dependent input" is included to separate those things that cannot reasonably be controlled from a keyboard.

Techniques for Addressing Success Criterion 2.1.1

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.1.1.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 2.1.1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Benefits: How Success Criterion 2.1.1 helps people with disabilities

  • People who are blind (who cannot user devices such as mice that require eye-hand coordination).

  • People with low vision (who may have trouble finding a tracking a pointer indicator on screen).

Examples of Success Criterion 2.1.1

  • Example 1: A drawing Program

    A drawing program allows users to create, size, position and rotate objects from the keyboard.

  • Example 2: A drag and Drop Feature

    An application that uses drag and drop also supports 'cut' and 'paste' or form controls to move objects.

  • Example 3: Association or discreet line

    A connect-the-dots program allows the user to move between dots on screen and use the spacebar to connect the current dot to the previous one.

  • Example 4: Exception - Painting Program

    A watercolor painting program passes as an exception because the brush strokes vary depending on the speed and duration of the movements.

  • Example 5: Exception - Model helicopter flight training simulator

    A model helicopter flight training simulator passes as an exception because the nature of the simulator is to teach real-time behavior of a model helicopter.


How to Meet Success Criterion 2.1.2

2.1.2 All functionality of the content is operable in a non time-dependent manner through a keyboard interface. (Level 3)

Key Terms

functionality

processes and outcomes acheivable through user action

keyboard interface

interface used by software to obtain keystroke input

Note: Allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.

A touch screen PDA has a keyboard interface built into its OS and a connector for connecting external Keyboards. Applications on the PDA can use the interface to obtain keyboard input from either an external keyboard or from other applications that provide simulated keyboard output - such as handwriting interpreters or speech to text applications with "keyboard emulation" functionality.

Note: Operation of the application (or parts of the application) through a keyboard operated mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard interface because operation of the program is through its pointing device interface - not through its keyboard interface.

Intent of this success criterion

This is the same as the success criterion 2.1.1, but no exceptions are allowed: all content is operable from the keyboard.


Understanding Guideline 2.2: Allow users to control time limits on their reading or interaction.

How to Meet Success Criterion 2.2.1

2.2.1 For each time-out that is a function of the content, at least one of the following is true: (Level 1)

  • the user is allowed to deactivate the time-out or;

  • the user is allowed to adjust the time-out over a wide range which is at least ten times the length of the default setting or;

  • the user is warned before time expires and given at least 20 seconds to extend the time-out with a simple action (for example, "hit any key") and the user is allowed to extend the timeout at least 10 times or;

  • the time-out is an important part of a real-time event (for example, an auction), and no alternative to the time-out is possible or;

  • the time-out is part of an activity where timing is essential (for example, competitive gaming or time-based testing) and time limits can not be extended further without invalidating the activity.

Editorial Note: The Working Group is considering adding techniques and/or modifying the success criterion to ensure additional accessibility features are employed for events where no alternative to a timeout is possible or where timing is essential.

Key Terms

activity where timing is essential

activity where timing is part of the design of the activity and removal of the time dependency would change the functionality of the content

Intent of this success criterion

The purpose of this success criterion is to ensure that whenever, possible users with disabilities are given adequate time to interact with Web content. People with disabilities such as blindness, dexterity impairments, and cognitive disabilities may require more time to perform functions such as filling out on-line forms. If Web functions are time-dependent, it will be difficult for some users to perform the required action before a timeout occurs. This may render the service inaccessible to them. Designing functions that are not time-dependent will help people with disabilities succeed at completing these functions. Providing options to disable timeouts, customize the length of timeouts, or request more time before a timeout occurs helps those users who require more time than expected to successfully complete forms.

In some cases, however, it is not possible to change the timeout (for example, for an auction or other real-time event) and exceptions are therefore provided for those cases.

Notes Regarding Server Timeouts

  • Timed server redirects can be found below under Common Failures.

  • Server timeouts like login expiration are dealt with in success criterion 2.2.6.

  • Non-timed server redirects (e.g. 3xx response codes) are not applicable because there is no timeout: they work instantly.

Editorial Note: The sufficient techniques currently do not cover server timeouts, which some members of the WCAG Working Group think is a problem that can sometimes, but not always, be addressed. Further thoughts and comments on this are solicited.

Techniques for Addressing Success Criterion 2.2.1

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.2.1.

Situation A: Content is designed so that there are no timeouts

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 2.2.1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

  • Using a script to poll the server and notify a user if a timeout is present.

Note: Where the author has no control over the server, the timeout is not a function of the content.

Benefits: How Success Criterion 2.2.1 helps people with disabilities

  • People with physical disabilities often need more time to react, to type and to complete activities. People with low vision need more time to locate things on screen and to read. People who are blind and using screen readers may need more time to understand screen layouts, to find information and to operate controls. People who have cognitive or language problems need more time to read and to understand. People who are deaf and communicate in sign language may need more time to read information printed in text (which may be a second language for some).

  • In circumstances where a sign-language interpreter may be relating audio content to a user who is deaf, control over time limits is also important.

Examples of Success Criterion 2.2.1

Related resources


How to Meet Success Criterion 2.2.2

2.2.2 Content does not blink for more than 3 seconds, or a method is available to stop any blinking content in the delivery unit. (Level 2)

Note: Refer to Allow users to avoid content that could cause seizures due to photosensitivity.: for requirements for avoiding creating content that could cause seizures due to photosensitivity.

Editorial Note: Is there a widespread problem with individuals who are so transfixed, that they are unable to turn blinking content off (so that the second option in the above success criterion would not be possible)?

blink

turn on and off between .5 and 3 times per second

delivery unit

A set of material transferred between two cooperating web programs as the response to a single HTTP request. The transfer might, for example, be between an origin server and a user agent.

Note: This term was taken verbatim from Glossary of Terms for Device Independence.

The intent of this success criterion is to avoid distracting the user during their interaction with a delivery unit. Certain groups, particularly those with attention deficit disorders, find blinking content distracting, making it difficult for them to concentrate on other parts of the delivery unit. Three seconds was chosen because it is long enough to get a user's attention, but not so long that a user can't wait it out if they need to in order to use the page.

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.2.2.

  • (No action needed.)

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

  • Providing a mechanism to stop all content that blinks within a delivery unit.

  • Providing the user with a means to stop moving content even if it stops automatically within 3 seconds.

  • One use of content that blinks is to draw the visitor's attention to that content. Although this is an effective technique for all users with vision, it can be a problem for some users if it persists. For certain groups, including people with low literacy, reading and intellectual disabilities, and people with attention deficit disorders, content that blinks may result in it being difficult to impossible to interact with the rest of the delivery unit. Providing content that stops blinking after 3 seconds or providing a mechanism for users to stop blinking content allows people in these groups to interact with the delivery unit.

  • Example 1: A Web advertisement blinks to get viewers attention but stops after 3 seconds

  • Example 2: A form blinks an arrow near the submit button if a user finishes filling out the form but does not activate the submit button. The blinking stops after 3 seconds.

  • Example 3: An animation runs in the upper portion of the page but has a "freeze animation" button near the bottom of the animation.


How to Meet Success Criterion 2.2.3

2.2.3 Content can be paused by the user unless the timing or movement is part of an activity where timing or movement is essential. (Level 2)

Key Terms

activity where timing is essential

activity where timing is part of the design of the activity and removal of the time dependency would change the functionality of the content

Intent of this success criterion

The intent of this success criterion is to give the option to temporarily stop content from advancing or updating at a rate beyond the user's ability to read and/or understand the content as it changes.

"Moving" refers to content in which the visible content conveys a sense of motion. Common examples include motion pictures, multimedia presentations, animations, real-time games, and scrolling stock tickers.

"Time-based" refers to content that updates or disappears based on preset time interval. Common time-based content includes audio, automatically updated weather information, news, and stock price updates, and auto-advancing presentations and messages.

Techniques for Addressing Success Criterion 2.2.3

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.2.3.

Either one of the following techniques could be used.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 2.2.3

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

  • (None currently documented.)

Benefits: How Success Criterion 2.2.3 helps people with disabilities

  • People with reading disabilities, cognitive disabilities, and learning disabilities who may need more time to read or comprehend information can have additional time to read the information by pausing the content.

  • In circumstances where a sign-language interpreter may be relating audio content to a user who is deaf, control over time limits is also important.

Examples of Success Criterion 2.2.3

  • An essential animation can be paused without effecting the activity

    A Web site helps readers understand 'how things work' through animations that demonstrate processes. Animations have "pause" and "restart" buttons.

  • A stock ticker.

    A stock ticker has "pause" and "restart" buttons. Pausing the ticker causes it to pause on the current stock. Restarting causes the ticker to jump ahead to the current stock - stocks that were displayed during the pause will not be displayed. Alternatively, the stock ticker could restart where paused but it would be behind unless the user reloaded the content to jump ahead to the real-time display or unless the ticker "fast-forwarded" until it caught up with the current stock.

  • A game is designed so that users take turns rather than competing in real-time

    One party can pause the game without invalidating the competitive aspect of it.

  • An auction.

    Users cannot pause the timing because of the nature of the activity. Instead the user is allowed to prepare their bid and hold it - so that a single keystroke submits it.

Related resources


How to Meet Success Criterion 2.2.4

2.2.4 Except for real-time events, timing is not an essential part of the event or activity presented by the content. (Level 3)

Key Terms

real-time events

events that are live

Intent of this success criterion

The purpose of this success criterion is to minimize the occurrence of content that requires timed interaction. This enables people with blindness, low vision, cognitive disabilities, or motor impairments to interact with content. This differs from the Level 1 success criterion in that the only exception is for real-time events.

Techniques for Addressing Success Criterion 2.2.4

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.2.4.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

  • (None currently documented.)

Optional Techniques (Advisory) for 2.2.4

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

  • (None currently documented.)

Benefits: How Success Criterion 2.2.4 helps people with disabilities

  • People with physical disabilities often need more time to react, to type and to complete activities. People with low vision need more time to locate things on screen and to read. People who are blind and using screen readers may need more time to understand screen layouts, to find information and to operate controls. People who have cognitive or language problems need more time to read and to understand. People who are deaf and communicate in sign language may need more time to read information printed in text (which may be a second language for some).

  • In circumstances where a sign-language interpreter may be relating audio content to a user who is deaf, control over time limits is also important.

Examples of Success Criterion 2.2.4

  • A test is designed so that time to complete the test does not effect the scoring

    Example will be provided.

  • A game is designed so that users take turns rather than competing in real-time

    One party can pause the game without invalidating the competitive aspect of it.

Related resources


How to Meet Success Criterion 2.2.5

2.2.5 Interruptions, such as updated content, can be postponed or suppressed by the user, except interruptions involving an emergency. (Level 3)

Key Terms

emergency

a sudden, unexpected situation or occurrence that requires immediate action to preserve health, safety or property

Intent of this success criterion

The intent of this success criterion is to allow users to turn off updates from the author/server except in emergencies. Emergencies would include civil emergency alert messages or any other messages that would warn of data loss, loss of connection etcetera.

This allows access by people with cognitive disabilities or attention problems to be able to focus on the content. It also allows users who are blind or have low vision to keep their "viewing" focus on the content they are currently reading.

Techniques for Addressing Success Criterion 2.2.5

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.2.5.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

  • (None currently documented.)

Optional Techniques (Advisory) for 2.2.5

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

  • (None currently documented.)

Benefits: How Success Criterion 2.2.5 helps people with disabilities

  • Individuals with attention deficit disorders can focus on content without distraction.

  • Individuals with low vision or who use screen readers will not have content updated while they are viewing it (which can lead to discontinuity and misunderstanding if they start reading in one topic and finish in another).

Examples of Success Criterion 2.2.5

  • (None currently documented.)

Related resources


How to Meet Success Criterion 2.2.6

2.2.6 When an authenticated session has an inactivity timeout, the user can continue the activity without loss of data after re-authenticating. (Level 3)

Intent of this success criterion

The intent is to allow all users to complete authenticated transactions that have inactivity timeouts. For security reasons, many sites implement an authentication timeout after a certain period of inactivity. These timeouts may cause problems for persons with disabilities because it may take longer for them to complete the activity. These users must be given the ability to re-authenticate and continue with the transaction without the loss of any data already entered.

Techniques for Addressing Success Criterion 2.2.6

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.2.6.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 2.2.6

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

  • (None currently documented.)

Benefits: How Success Criterion 2.2.6 helps people with disabilities

  • This success criterion benefits people who may require additional time to complete an activity. People with cognitive disabilities may read slowly and require additionally time to read and respond to a questionnaire. Users interacting via a screen reader may need extra time to navigate and complete a complicated form. A person with motor impairments or who navigates with an alternative input device may require additional time to navigate through or complete input within a form.

  • In circumstances where a sign-language interpreter may be relating audio content to a user who is deaf, control over time limits is also important.

Examples of Success Criterion 2.2.6

  • A shopping site checkout

    A user is logged into a shopping site. While performing the checkout process, the user is distracted for a long period of time and the session times out. When the user returns to the checkout process and submits the form, the site returns a login screen to re-authenticate. After the user logs in, the check out process is restored with the same information and at the same stage. The user did not lose any data because the server had temporarily accepted and stored the submission even though the session had timed out and restored the user to the same state after re-authentication was completed.

  • Authentication in an email program

    An email program has an authentication timeout after 30 minutes. The program prompts the user several minutes before the timeout occurs and provides a link to open a new window in order to re-authenticate. The original window with the in-progress email remains intact and, after re-authentication, the user may send that data.

  • A questionnaire with a timeout

    A long questionnaire provided within a single delivery unit has information at the beginning that indicates that the session will time out after 15 minutes. The user is also informed that the questionnaire can be saved at any point and completed at a later time. Within the delivery unit there are several buttons provided to save the partially completed form. In addition, with JavaScript in the baseline, the user can elect to be alerted via a pop-up if the session is close to timing out.

Related resources


Understanding Guideline 2.3: Allow users to avoid content that could cause seizures due to photosensitivity.

How to Meet Success Criterion 2.3.1

2.3.1 Content does not violate the general flash threshold or the red flash threshold. (Level 1)

Key Terms

general flash threshold
  • A sequence of flashes or rapidly changing image sequences where both the following occur:

    1. the combined area of flashes occurring concurrently (but not necessarily contiguously) occupies more than one quarter of any 335 x 268 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 by 768 pixels and

    2. there are more than three flashes within any one-second period.

    Note: For the general flash threshold, a flash is defined as a pair of opposing changes in brightness of 10% or more of full scale white brightness, where brightness is calculated as .2126*R + .7152*G + .0722B using linearized R, G, and B values. Linearized-X = (X/FS)^2.2 where FS is full scale (usually 255 today). An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase.

red flash threshold
  • A transition to or from a saturated red where both of the following occur:

    1. the combined area of flashes occurring concurrently occupies more than one quarter of any 335 x 268 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 by 768 pixels and

    2. there are more than three flashes within any one-second period.

Intent of this success criterion

The purpose of this success criterion is to allow users to access the full content of a site without inducing seizures due to photosensitivity.

Individuals who have photosensitive seizure disorders can have a seizure triggered by content that flashes at certain frequencies for more than a few flashes. People are even more sensitive to red flashing than to other colors so a special test is provided for saturated red flashing. These guidelines are based on guidelines for broadcast industry as adapted to work for computer screens, where content is viewed from closer distance (larger angle of vision).

This success criterion replaces a much more restrictive criterion in WCAG 1.0 that did not allow any flashing (even of a single pixel) within a broad frequency range (3 to 50 hz). This success criterion is based on existing specifications in use in England and by others for television broadcast and has been adapted for computer display viewing. The 1024 x 768 screen is used as the reference screen size for the evaluation. The 335 x 268 pixel block represents a 10 degree viewport at typical viewing distance. (The 10 degree field is taken from the original specifications and represents the central vision portion of the eye – where one is most susceptible to photo stimuli).

The combined area of flashes occurring concurrently (but not necessarily contiguously) means the total area that is actually flashing at the same time. It is calculated by adding up the all of the areas of the individual flashes on the screen that are occurring at the same time.

Techniques for Addressing Success Criterion 2.3.1

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.3.1.

Technology-independent techniques

  • Seeing that content does not violate the general flash threshold or red flash threshold by testing it. (See resources for tools.)

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

(None currently documented.)

Optional Techniques (Advisory) for 2.3.1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

  • Reducing contrast for flashing content.

  • Avoiding fully saturated reds.

  • Reducing the number of flashes.

  • Not using any material that violates the pattern thresholds for photosensitivity.

  • Warning users about material that violates pattern thresholds for photosensitivity before users encounter it.

  • Providing a means to disable or turn off the material that violates pattern thresholds for photosensitivity before users encounter it.

Benefits: How Success Criterion 2.3.1 helps people with disabilities

Individuals who have seizures when viewing flashing material will be able to view all of the material on a site without have a seizure and without having to miss the full experience of the content by having to just use text alternatives. This includes those with photosensitive epilepsy as well as other photosensitive seizure disorders.

Examples of Success Criterion 2.3.1

A movie with a scene involving very bright lightning flashes is scripted so that the lightning only flashes 2 times.

Related resources

  • Trace Center Photosensitive Epilepsy Analysis Tool.


Understanding Guideline 2.4: Provide mechanisms to help users find content, orient themselves within it, and navigate through it.

How to Meet Success Criterion 2.4.1

2.4.1 Navigational mechanisms within the content can be programmatically determined. (Level 1)

navigational mechanisms

mechanisms that allow the user to locate and/or move to a different piece of content.

programmatically determined

can be recognized by user agents, including assistive technologies, that support the technologies in the chosen baseline

The purpose of this success criterion is to ensure that user agents, including assistive technologies, can recognize any navigational mechanisms that may be present in the content, beyond those perceivable structures required by 1.3.1. 1.3.1 requires perceivable structures such as headings, labels for form controls, lists, etc. to be programmatically determined.

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.4.1.

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

People who must access content sequentially, such as people with motion impairments or people with impaired vision, benefit when there are easier ways to find the content they seek. Reducing the number of keystrokes needed to reach information is important for people with motion impairments. Anyone accessing the content sequentially will save time by skipping content they are not interested in.

  • Example 1. A screen reader user can skip to the next heading in the text.

  • Example 2.A screen reader user is reading a hierarchical list such as a table of contents. It is possible to skip over the nested subheadings in the TOC because they are marked as a nested list, and it is possible to skip to the end of the current list.

  • Example 3.The user can use the Assistive Technology to "tab" to the next form field, skipping any links in the tab chain because the Assistive Technology can identify the next form field.


How to Meet Success Criterion 2.4.2

2.4.2 A mechanism is available to bypass blocks of content that are repeated on multiple perceivable units. (Level 1)

perceivable unit

The result of a user agent rendering the contents of a delivery unit. User agents may or may not render all information in a delivery unit. In some cases, a single delivery unit may be rendered as multiple perceivable units. For example, a single html file that is rendered as a set of presentation slides. Most perceivable units contain presentation and the means for interaction. However, for some devices such as printers, a perceivable unit may only contain presentation.

The intent of this success criterion is to allow people who navigate sequentially through content more direct access to the primary content of the delivery unit. Web pages and applications often have content that appears on other pages or screens. Examples of repeated blocks of content include but are not limited to navigation links, heading graphics, and advertising frames.

This is in contrast to a sighted user's ability to ignore the repeated material either by focusing on the center of the screen (where main content usually appears) or a mouse user's ability to select a link with a single mouse click rather than encountering every link or form control that comes before the item they want.

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.4.2.

HTML Techniques for creating links to skip blocks
HTML Techniques for grouping blocks of repeated material

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

HTML Techniques for keyboard access
CSS Techniques for positioning content

When this success criterion is not satisfied, it may be difficult for people with some disabilities to reach the main content of a Web page quickly and easily.

Screen reader users who visit several pages on the same site may have to hear all heading graphics and dozens of navigation links on every page before the main content is spoken.

People who use only the keyboard or a keyboard interface might have to make dozens of keystrokes before reaching a link in the main content area. This can take a long time and may cause severe physical pain for some users.

People who use screen magnifiers can do not have to search through the same headings or other blocks of information to find the other side where the content begins each time then enter a new page.

  • A news organization's home page contains a main story in the middle of the page, surrounded by lots of blocks and sidebars for advertising, searching, and other services. It contains a link at the top of the page that jumps to the main story. Without using this link, a keyboard user needs to tab through approximately 40 links to reach the main story; the screen reader user has to listen to 200 words; and the screen magnifier user must search around for the location of the main body.


How to Meet Success Criterion 2.4.3

2.4.3 More than one way is available to locate content within a set of delivery units where content is not the result of, or a step in, a process or task. (Level 2)

delivery unit

A set of material transferred between two cooperating web programs as the response to a single HTTP request. The transfer might, for example, be between an origin server and a user agent.

Note: This term was taken verbatim from Glossary of Terms for Device Independence.

The purpose of this success criterion is to make it possible for users to locate content in a manner that best meets their needs. Users may find one technique easier or more comprehensible to use than another.

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.4.3.

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Providing an opportunity to navigate sites in more than one manner can help people find information faster. A person with visual impairments may find it easier to navigate to the correct part of the site using a search, rather than scrolling through a large navigation bar using a screen magnifier or screen reader. A person with cognitive disabilities may prefer a table of contents or site map which provides an overview of the site rather than reading and traversing through several delivery units. Some users may prefer to explore the site in a sequential manner, moving from delivery unit to delivery unit in order to best understand the concepts and layout.

  • A search mechanism .

    A large food processing company provides a site containing recipes created using its products. The site provides a search mechanism to search for recipes using a particular ingredient. In addition, it provides a list box which lists several categories of foods. A user may type "soup" in to the search engine or may select "soup" from the list box to be taken to a page with a list of recipes made from the company's soup products

  • Links between delivery units

    A local hair salon has created a Web site to promote its services. The site contains only five delivery units. There are links on each delivery unit to sequentially move forward or backward through the delivery units. In addition, each delivery unit contains a list of links to reach each of the other delivery units.

  • where content is a result of a process or task - funds transfer confirmation:

    An on-line banking site allows fund transfer between accounts via the Web. There is no other way to locate the confirmation of fund transfer until the account owner completes the transfer.

  • where content is a result of a process or task - search engine results:

    A search engine provides the search result based on user input. There is no other way to locate the search results except to perform the search process itself.

  • Graphic Organizers page at the National Center for Accessible Curriculum provides a useful overview of different kinds of graphic organizers and their uses, plus a summary of relevant research on the effectiveness of graphical organizers for students with learning disabilities.


How to Meet Success Criterion 2.4.4

2.4.4 Delivery units have titles. (Level 2)

delivery unit

A set of material transferred between two cooperating web programs as the response to a single HTTP request. The transfer might, for example, be between an origin server and a user agent.

Note: This term was taken verbatim from Glossary of Terms for Device Independence.

Titles help users find content and orient themselves within content. Titles identify the current location without requiring users to read or interpret page content. When titles appear in site maps or lists of search results, users can more quickly identify the content they need.

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.4.4.

Examples of HTML delivery units that should have titles include Web pages, and frames within a page.

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

HTML Techniques for Frame Titles

These techniques benefit all users. They are especially helpful for users with disabilities that make reading slow and for people with limited short-term memory. People who have difficulty using their hands or who experience pain when doing so will benefit from techniques that reduce the number of keystrokes required to reach the content they need.

  • Example 1: A Web page is titled: "Smallville High School Home Page".

  • Example 2: Each frame in an application has a title: "Navigation Bar", "Upcoming Events", "Latest Sports Results"


How to Meet Success Criterion 2.4.5

2.4.5 Each programmatic reference to another delivery unit or to another location in the same delivery unit, is associated with text describing the destination. (Level 2)

programmatic reference

functional component, such as a link or control, that causes a change of context when activated

delivery unit

A set of material transferred between two cooperating web programs as the response to a single HTTP request. The transfer might, for example, be between an origin server and a user agent.

Note: This term was taken verbatim from Glossary of Terms for Device Independence.

Editorial Note: The WCAG Working Group is not sure how close the "association" between the text and the destination should be. On one hand, if you have a page with a list of book titles with links saying WORD, PDF, HTML, and TEXT following each title, it seems logical that having the title next to the row of links would be better than repeating the title in each of the links. It would be better for people who look at the page and better for someone reading down the page with a screen reader looking for a book title and then selecting the type. On the other hand, allowing "text next to a link" to suffice for 'associated' would allow one to say "for more information" next to a link labeled "click here". This can lead to a page of 'click here' links and that is not seen as desirable.

  1. Is there a rule or wording for the success criterion that allows one but not the other?

  2. How big is the problem?

  3. Would requiring that all links contain full information about their destination (without reading any surrounding text) be overly restrictive or not?

  4. Should links be required to make sense when read out of context? (Or is this requiring that pieces of content need to make sense when removed from the rest of the content?)

  5. Note: Jumping between links or listing the links on a page is a common navigation technique.

Comments invited.

The intent of this success criterion is to help users know where a link goes, so they can decide whether they want to navigate there. A good description on a link improves orientation by helping users interpret the destination page.

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.4.5.

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

This success criterion helps people with motion impairment by letting them skip delivery units that they are not interested in, avoiding the keystrokes needed to visit the referenced content and then return to the current content.

People with cognitive impairment will not become disoriented by extra navigation to and from content they are not interested in.

People with visual disabilities will benefit from not losing their place in the content when they return to the original page. The screen reader's list of links is more useful for finding information because the targets of the link are described.

  • A link is preceded by a text description of the information at that URL.

    "Learn more about the Government of Ireland's Commission on Electronic Voting" appears before the link "Go Vote!"

  • metadata that is programmatically associated with a link provides additional information about the target.

    A the text of a link is "Commission on Electronic Voting." Additionally, the description, "Home page of the Government of Ireland's Commission on Electronic Voting" is associated with the link.

  • Both an icon and text are included in the same link

    An icon of a voting machine and the text "Government of Ireland's Commission of Electronic Voting" are combined to make a single link.

  • A list of book titles

    A list of books is available in 3 formats: HTML, PDF, and mp3 (a recording of a person reading the book). To avoid hearing the title of each book three times (once for each format), the first link for each book is the title of the book, the second link says "PDF" and the third says, "mp3."


How to Meet Success Criterion 2.4.6

2.4.6 Titles, headings and labels are descriptive. (Level 3)

label

text that identifies a component within Web content

The intent of this success criterion is to help users understand what information is contained in delivery units and how that information is organized. When titles and headings are clear and descriptive, users can find the information they seek more easily, and they can understand the relationships between different parts of the content more easily.

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.4.6.

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Descriptive titles are especially helpful for users who have disabilities that make reading slow and for people with limited short-term memory. These people benefit when section titles make it possible to predict what each section contains.

People who have difficulty using their hands or who experience pain when doing so will benefit from techniques that reduce the number of keystrokes required to reach the content they need.

This success criterion helps people who use screen readers by ensuring that titles and headings are meaningful when read out of context - for example, in a Table of Contents, or when jumping from heading to heading within a page.

This success criterion may also help users with low vision who can see only a few words at a time.

  • A news site.

    The home page of a news site lists the headlines for the top stories of the hour. Under each heading are the first 35 words of the story and a link to the full article. Each headline gives a clear idea of the article's subject.

  • A guide on how to write well

    A guide on writing contains the following section titles: How To Write Well, Cut Out Useless Words, Identifying Unnecessary Words, etc. The section headings are clear and concise, and the structure of the information is reflected in the structure of the headings.

  • Example 3: Consistent headings in different articles

    A collection of Web pages contain articles in a common style. The articles use the same headings for some sections, but the title of the Web page makes it easy to tell the topic of the section.

    For example, the Web site may contain papers from a conference. Submissions to the conference are required to have the following organization: Summary, Introduction, ... sections unique to this article ..., Conclusion, Author Biography, Glossary, and Bibliography.


How to Meet Success Criterion 2.4.7

2.4.7 When a delivery unit is navigated sequentially, elements receive focus in an order that follows relationships and sequences in the content. (Level 3)

delivery unit

A set of material transferred between two cooperating web programs as the response to a single HTTP request. The transfer might, for example, be between an origin server and a user agent.

Note: This term was taken verbatim from Glossary of Terms for Device Independence.

The intent of this success criterion is to ensure that when users navigate sequentially through content, they encounter information in an order that reflects the logical relationships in the content. This reduces confusion by letting users form a consistent mental model of the content.

Some Web content must support sequential navigation. For example, a person using a keyboard or keyboard interface to complete an on-line form typically uses the tab key to move from one input element to the next item on the form. Each time the user presses the tab key, the another element receives focus (that is, the user's next action will affect the item that has focus). In some cases it may be necessary to specify the sequence in which items will receive focus, because the default sequence is not logical.

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.4.7.

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

These techniques benefit users who navigate documents sequentially and expect the tab order to match the sequential reading order. People with visual impairments or people with disabilities that make reading difficult can become disoriented when tabbing takes focus someplace unexpected.

  • Example of the results of failure to meet the success criterion: An on-line subscription form.

    A company's Web site includes a form that collects marketing data and allows users to subscribe to several newsletters published by the company. The form includes typical fields such as name, street address, city, state or province, and postal code. It also includes several checkboxes so that users can indicate which newsletters they want to receive. An individual using a screen magnifier enters her name and street address and presses the tab key, expecting that she will next enter the name of her city. But instead the focus moves to a checkbox beside the name of a newsletter. Only part of the newsletter's title is visible because of the screen magnification, and the user does not realize what has happened. She keys in her address and submits the form. She is surprised when she receives an error message telling her that one or more required fields is incomplete.


How to Meet Success Criterion 2.4.8

2.4.8 Information about the user's location within a set of delivery units is available. (Level 3)

delivery unit

A set of material transferred between two cooperating web programs as the response to a single HTTP request. The transfer might, for example, be between an origin server and a user agent.

Note: This term was taken verbatim from Glossary of Terms for Device Independence.

The intent of this success criterion is to provide the user a way to orient herself within a Web site or Web application and find related information.

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.4.8.

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

This success criterion is helpful for people with a short attention span who may become confused when following a long series of navigation steps to a Web page. It is also helpful when a user follows a link directly to a page deep within a Web site and needs to navigate that Web site to understand the content of that page or to find more related information.

  • Links to help user determine location in a site

    A research group is part of an educational department at a university. The group's home page links to the department home page and the university's home page.

  • A breadcrumb trail

    A portal Web site organizes topics into categories. As the user navigates through categories and subcategories, a breadcrumb trail shows the current location in the categories hierarchy. Each page also contains a link to the Directory Home.


Understanding Guideline 2.5: Help users avoid mistakes and make it easy to correct mistakes that do occur.

How to Meet Success Criterion 2.5.1

2.5.1 If an input error is detected, the error is identified and described to the user in text. (Level 1)

Key Terms

input error

Any information provided by the user that is not accepted. This includes:

  1. information that is required by the delivery unit but omitted by the user.

  2. information that is provided by the user but that falls outside the required data format or values.

Intent of this success criterion

The intent of this success criterion is to ensure that users are aware that an error has occurred and can determine what is wrong. In the case of an unsuccessful form submission, redisplaying the form and indicating the fields in error is insufficient for some users to perceive that an error has occurred. Screen reader users, for example, will not know there was an error until they encounter one of the indicators. They may abandon the form altogether before encountering the error indicator, thinking that the page simply isn't functional.

Techniques for Addressing Success Criterion 2.5.1

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.5.1.

Instructions: Select the situation(s) below that match your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.

Situation A: A form contains fields for which information from the user is mandatory:

  • Providing a text message when any of the mandatory information has not been provided. The text message either identifies the mandatory fields or describes the method used to identify the mandatory fields.

Situation B: Information provided by the user is required to be in a specific data format or of certain values:

  • Providing a text message when the user provides any information that falls outside the required data format or values. The text message does one of the following:

    • identifies the field(s) in error and describes the acceptable data format or value range(s).

    • describes the method used to identify the field(s) in error and the method used to describe the acceptable data format or value range.

  • Validating data format for data provided in a form field.

  • Validating data provided in a form field.

  • Indicating mandatory fields on a form.

Script Techniques

  • Providing client-side validation and alert.

  • Providing client-side validation and adding error text via the DOM.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 2.5.1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

  • Providing error notification as the user enters information.

  • Assisting the user in making corrections by providing links to each error.

  • Highlighting or visually emphasizing errors where they occur.

Benefits: How Success Criterion 2.5.1 helps people with disabilities

Providing information about input errors in text allows users who are blind, colorblind, or have learning disabilities to perceive the fact that an error occurred.

Examples of Success Criterion 2.5.1

  • Identifying errors in a form submission.

    An airline Web site offers a special promotion on discounted flights. The user is asked to complete a simple form that asks for personal information such as name, address, phone number, seating preference and e-mail address. If any of the fields of the form are either not completed or completed incorrectly, a text message is displayed notifying the user that some of the information provided has not been accepted. The message also specifies that the form will be redisplayed with incorrect fields identified by two asterisks. The user is then presented with the same form, with all previously and correctly entered information still available. The user is asked to make corrections to any form fields marked with two asterisks.

    Note: This success criterion does not mean that color or text styles cannot be used to indicate errors. It simply requires that errors also be identified using text. In this example, two asterisks are used in addition to color.

Related resources


How to Meet Success Criterion 2.5.2

2.5.2 If an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user. (Level 2)

Key Terms

input error

Any information provided by the user that is not accepted. This includes:

  1. information that is required by the delivery unit but omitted by the user.

  2. information that is provided by the user but that falls outside the required data format or values.

Intent of this success criterion

The intent of this success criterion is to ensure that users receive appropriate suggestions for correction of an input error if it is possible.

Success Criterion 2.5.1 provides for notification of errors. However, persons with cognitive disabilities may find it difficult to understand how to correct the errors. People with visual disabilities may not be able to figure out exactly how to correct the error. In the case of an unsuccessful form submission, users may abandon the form because although they may be aware that an error has occurred, they may be unsure of how to correct the error.

Techniques for Addressing Success Criterion 2.5.2

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.5.2.

Instructions: Select the situation(s) below that match the input error for a field. Beneath it are the option(s) that are known and documented to be sufficient for suggestions for that error.

Situation A: A mandatory field contains no information:

  • Providing a text message that identifies the field as mandatory.

Situation B: Information for a field is required to be in a specific data format:

  • Providing a text message containing examples of the data format, or

  • Providing a text message that describes the data format, or

  • Providing a text message that shows values in the data format that are "similar" to the user's entry

Situation C: Information provided by the user is required to be one of a limited set of values:

  • Providing a text message containing the list of acceptable values and highlighting values (if any) that are "similar" to the user's entry, or

  • Providing a dialog that allows the user to choose from a list of acceptable values, or

  • Providing a text message that describes the set of acceptable values, or

  • Providing a text message that describes the set of acceptable values and suggests values from the list that are "similar" to the user's entry.

Techniques for providing suggestions to the user

  • Providing a text message that contains information about the number of input errors, suggestions for corrections for each item, and instructions on how to proceed

  • Providing a text message that contains suggestions for correction as the first item (or one of the first items) of content, or emphasizing this information in the content.

  • Displaying errors and suggestions in the context of the original form (for example, redisplaying a form where input errors and suggestions for correction are highlighted and displayed in the context of the original form).

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 2.5.2

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

  • When mandatory information has not been provided, including descriptions or examples of correct information in addition to identifying the field as mandatory.

  • Repeating and emphasizing suggestions for correcting each input error in the context of its form field.

  • Providing a way for the user to skip from each item in a list of suggestions to its corresponding form field.

  • Providing additional contextual help for the form field requiring change.

HTML Techniques
  • Providing "correct examples" for data and data formats as initial text in mandatory form fields.

  • Providing links to suggested correction text "close to" form fields, or providing the suggested correction text itself directly on the delivery unit "next to" form fields.

Client-Side Scripting Techniques
  • Using client-side validation and alert to provide contextual help and suggestions for correction for the form fields requiring change.

  • Providing feedback for user actions in the form of suggestions for correction via the DOM.

Benefits: How Success Criterion 2.5.2 helps people with disabilities

Providing information about how to correct input errors allows users who have learning disabilities to fill in a form successfully. Users who are blind or have impaired vision understand more easily the nature of the input error and how to correct it. People with motion impairment can reduce the number of times they need to change an input value.

Examples of Success Criterion 2.5.2

  • Additional Help for Correcting An Input Error

    An example of output from an HTML form that was not successfully submitted (and an image that it uses). It describes an input error that occurred among other "correct" input and offers additional help for the form field that caused the input error.

  • Suggestions from a Limited Set of Values

    An input field requires that a month name be entered. If the user enters "12", suggestions for correction may include

    • a list of the acceptable values, e.g. "Choose one of: January, February, March, April, May, June, July, August, September, October, November, December"

    • a description of the set of values, e.g. Please provide the name of the month

    • the conversion of the input data, interpreted as a different month format: do you mean "December"?

Related resources


How to Meet Success Criterion 2.5.3

2.5.3 For forms that cause legal or financial transactions to occur, that modify or delete data in data storage systems, or that submit test responses, at least one of the following is true: (Level 2)

  1. Actions are reversible.

  2. Actions are checked for input errors before going on to the next step in the process.

  3. The user is able to review and confirm or correct information before submitting it.

Key Terms

input error

Any information provided by the user that is not accepted. This includes:

  1. information that is required by the delivery unit but omitted by the user.

  2. information that is provided by the user but that falls outside the required data format or values.

Intent of this success criterion

The intent of this success criterion is to help users with disabilities avoid serious consequences as the result of a mistake. For example, purchasing non-refundable airline tickets or submitting an order to purchase stock in a brokerage account are financial transactions with serious consequences. If a user has made a mistake on the date of air travel, he or she could end up with a ticket for the wrong day which can't be exchanged. If the user made a mistake on the number of stock shares to be purchased, he or she could end up purchasing more stock than intended. Both of these types of mistakes can be very costly.

Users with disabilities may be more likely to make mistakes. People with learning disabilities may transpose numbers and letters, and those with motor disabilities may hit keys by mistake. Providing the ability to reverse actions allows users to correct a mistake that could result in serious consequences. Providing the ability to review and correct information gives the user an opportunity to detect a mistake before taking an action that has serious consequences.

Techniques for Addressing Success Criterion 2.5.3

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.5.3.

Instructions: Select the situation(s) below that match your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.

Situation A: An application which causes a legal transaction, such as making a purchase or submitting an income tax return, to occur:

  • Providing a period of time after submission of the form when the order can be updated or cancelled by the user, or

  • Providing the ability to review and correct all aspects of the transaction before submission.

Situation B: An action which causes information to be deleted:

  • Providing the ability to recover the deleted information, or

  • Providing a message to the user asking him or her to confirm that he or she really does want to delete the information.

Situation C: A testing application:

  • Providing the ability for the user to review and correct answers before submitting, or

  • Asking for confirmation before final submission

Client-Side Scripting Techniques

  • Alert or pop-up window asking "Are you sure?" and with controls for "OK" and "Cancel".

Server-Side Scripting Techniques

  • Server-side technique that allows users to log back in, see their past transactions and cancel them.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 2.5.3

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

  • Informing the user what irreversible action is about to happen.

Benefits: How Success Criterion 2.5.3 helps people with disabilities

Providing safeguards to avoid serious consequences resulting from mistakes helps users with all disabilities who may be more likely to make mistakes.

Examples of Success Criterion 2.5.3

  • Order confirmation

    A Web retailer offers on-line shopping for customers. When an order is submitted, the order information, including items ordered, quantity of each ordered item, shipping address, and payment method, are displayed allowing the user to inspect the order for correctness. The user can either confirm the order or make changes.

Related resources


How to Meet Success Criterion 2.5.4

2.5.4 Context-sensitive help is available for text input. (Level 3)

Key Terms

context-sensitive help

Help text that provides information related to the function currently being performed.

Intent of this success criterion

The intent of this success criterion is to help users avoid making mistakes. Some users with disabilities may be more likely to make mistakes than users without disabilities. Using context-sensitive help, users find out how to perform an operation without losing track of what they are doing.

Techniques for Addressing Success Criterion 2.5.4

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.5.4.

Instructions: Select the situation(s) below that match your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.

Situation A: If a form requires text input:

  • Providing a help link on every delivery unit, or

  • Providing help bubbles, or

  • Providing help by an assistant in the delivery unit, or

  • Providing a help link on every delivery unit, or

  • Providing spell checking and suggestions for text input if applicable to the language.

Situation B: If a form requires text input in expected data format:

  • Providing expected data format and example

Additional Technology-Independent Techniques

  • Checking byte of character and auto-converting to expected byte for text input if applicable.

    • For example, characters in Japanese require either a single or a double byte. If the user inputs a double byte instead of a single byte for a single-byte character, a server-side program can detect the incorrect byte and convert it to the expected format.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 2.5.4

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Benefits: How Success Criterion 2.5.4 helps people with disabilities

Assistance for text input helps individuals with writing disabilities and people with reading and intellectual disabilities who often have difficulty writing text in forms or other places that need text input.

Additionally, these kinds of assistance help people who are aging and have the same difficulty in text input and/or mouse operation.

Examples of Success Criterion 2.5.4

  • Online job application

    Some of the questions may be hard for new job seekers to understand. A help link next to each question provides instructions and explanations for each question.

Related resources


Understanding Guideline 3.1: Make text content readable and understandable.

How to Meet Success Criterion 3.1.1

3.1.1 The primary natural language or languages of the delivery unit can be programmatically determined. (Level 1)

Key Terms

natural languages

languages are those used by humans to communicate, including spoken, written, and signed languages.

programmatically determined

can be recognized by user agents, including assistive technologies, that support the technologies in the chosen baseline

Intent of this Success Criterion

The intent of this success criterion is to ensure that content developers provide information in the delivery unit that user agents need to present text and other linguistic content correctly. Both assistive technologies and conventional user agents can render text more accurately when the language of the delivery unit is identified. Screen readers can load the correct pronunciation rules. Visual browsers can display characters and scripts correctly. Media players can show captions correctly. As a result, users with disabilities will be better able to understand the content.

"Language declarations in HTML and XHTML have nothing to do with character encoding or the direction of text. (…) [T]here is not always a one-to-one mapping between language and script, and therefore directionality. For example, Azerbaijani can be written using both right-to-left and left-to-right scripts." (From Relationships with character encoding and directionality.) Therefore, there are separate mechanisms for declaring the language and directionality of text. The default text direction is left-to-right, which means that direction only needs to be specified if it is right-to-left.

Techniques for Addressing Success Criterion 3.1.1

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 3.1.1.

Instructions: Select the situation below that matches your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.

Situation A: If the text direction of the delivery unit is left to right, the following would be sufficient:

  • Identifying primary natural language(s) using a technology-specific technique listed below.

Situation B: If the text direction of the delivery unit is right to left, the following would be sufficient:

  • Identifying primary natural language(s) using a technology-specific technique listed below including identifying text direction using a technology-specific technique listed below.

Technology-Specific Techniques

Identifying primary natural language in HTML
  • Identifying primary natural language.

    • using the lang attribute on the html element (HTML 4.01);

    • using the lang attribute AND the xml:lang attribute on the html element (XHTML served as text/html);

    • using the xml:lang attribute on the html element (XHTML served as application/xhtml+xml)

Identifying text direction in HTML

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 3.1.1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Additional Technology-Independent Techniques (Advisory)

(none currently documented)

Additional HTML Techniques (Advisory)
Additional CSS Techniques (Advisory)
  • Specifying the direction of text (or is this sufficient? depends on baseline?)

Benefits: How Success Criterion 3.1.1 helps people with disabilities

This success criterion helps:

  • people who Use screen readers or other technologies that convert text into synthetic speech;

  • people with learning disabilities and cognitive limitations that make it difficult to recognize (decode) individual words and sentences;

  • people who rely on captions for multimedia.


How to Meet Success Criterion 3.1.2

3.1.2 The natural language of each passage or phrase in the content can be programmatically determined. (Level 2)

Note: This requirement does not apply to individual words or phrases that have become part of the primary language of the content.

Key Terms

programmatically determined

can be recognized by user agents, including assistive technologies, that support the technologies in the chosen baseline

Intent of this success criterion

The intent of this success criterion is to ensure that user agents can correctly present content written in a language that is different from the primary language of the delivery unit. This applies to graphical browsers as well as screen readers, braille displays, and other voice browsers.

Both assistive technologies and conventional user agents can render text more accurately if changes of language within the delivery unit are identified. Screen readers can switch to the pronunciation rules for the language of the foreign text, then switch back to the pronunciation rules of the primary language at the end of the foreign phrase or passage. Visual browsers can display characters and scripts in appropriate ways. This is especially important when one language reads from left to right and the other reads from right to left, or when the foreign phrase or passage uses a different alphabet than the primary language. Users with disabilities who know the language of the foreign passage or phrase as well as the language of the delivery unit as a whole will be better able to understand the content.

This requirement does not apply to individual words or to phrases that have become part of the primary language of the content. For example, "rendezvous" is a French word that has been adopted in English, appears in English dictionaries, and is properly pronounced by English screen readers.

Techniques for Addressing Success Criterion 3.1.2

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 3.1.2.

Instructions: Select the situation below that matches your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.

Situation A: If the foreign passage or phrase has the same text direction as the primary content, the following would be sufficient:

Situation B: If the foreign passage or phrase has a different text direction from the primary content, the following would be sufficient:

Optional Techniques (Advisory) for 3.1.2

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Additional Technology-Independent Techniques (Advisory)
Additional HTML Techniques (Advisory)

Benefits: How Success Criterion 3.1.2 helps people with disabilities

This success criterion helps:

  • people who Use screen readers or other technologies that convert text into synthetic speech;

  • people with learning disabilities and cognitive limitations that make it difficult to recognize (decode) individual words and sentences;

  • people who rely on captions to recognize language changes in the soundtrack of multimedia content.

Examples of Success Criterion 3.1.2

  1. a German phrase in an English sentence.

    In the following sentence, "He maintained that the DDR (German Democratic Republic) was just a 'Treppenwitz der Weltgeschichte'.", the German phrase 'Treppenwitz der Weltgeschichte' is marked as German. Depending on the markup language, English may either be marked as the language for the entire document except where specified, or marked at the paragraph level. When a screen reader encounters the German phrase, it changes pronunciation rules from English to German to pronounce the word correctly.

Related resources


How to Meet Success Criterion 3.1.3

3.1.3 A mechanism is available for identifying specific definitions of words used in an unusual or restricted way, including idioms and jargon. (Level 3)

Key Terms

mechanism

a process or technique for achieving a result

used in an unusual restricted way

words used in such a way that users must know exactly what definition to apply in order to understand the content correctly. For example, the word "representational" means something quite different if it occurs in a discussion of visual art as opposed to a treatise on government, but the appropriate definition can be determined from context. By contrast, the word "text" is used in a very specific way in WCAG 2.0, so a definition is supplied in the glossary.

idiomatic expressions

words or phrases specific to a region or language that do not mean what the dictionary definitions of the individual words say. For example, the English phrase "he blew his stack" means that someone became very angry.

jargon

words used in a particular way by people in a particular field. For example, the word StickyKeys is jargon from the field of assistive technology/accessibility.

Intent of this success criterion

Certain disabilities make it difficult to understand non-literal word usage and specialized words or usage. Certain disabilities make it difficult to understand figurative language or specialized usage.

Techniques for Addressing Success Criterion 3.1.3

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 3.1.3.

Technology-independent techniques

Provide the definition of words using at least one of the techniques from the following list or one of the technology-specific techniques.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

  • None identified at this time.

Benefits: How Success Criterion 3.1.3 helps people with disabilities

  • This success criterion helps people with disabilities that affect their ability to use context to aid understanding. This includes people with certain learning disabilities and cognitive impairments. In addition, people with low vision often lose context when screen magnifiers zoom in on a small area of the screen. This success criterion also helps people who have difficulty recognizing words (decoding) or remembering the meaning of words by limiting the number of dictionary entries they must read in order to find the definition that fits the context.

Examples of Success Criterion 3.1.3

  • Text that includes a definition for a word used in an unusual way.

    Organize the list or "cascade" of dictionaries and other resources so that the definition search will find the intended definitions instead of displaying definitions from other sources in the "cascade." (The "cascade" lists the dictionaries and other reference materials in the order most likely to bring up the right definition. This controls the order to follow when searching for definitions.)

  • Including definitions in the glossary.

    WCAG 2.0 uses the word "text" in a specific way. Thus, when the word "text" is used within WCAG 2.0 it is linked to the definition of "text" provided in a glossary within the same delivery unit.

  • The specific definition of a word is provided at the bottom of the page.

    The internal link from the word to the corresponding definition is also provided within the page.

Related resources

Note: The inclusion of a product or vendor name in the list below does not constitute an endorsement by the Web Content Accessibility Guidelines Working Group or the Web Accessibility Initiative of the World Wide Web Consortium. This list is provided simply for convenience, and to give users an idea of what resources may be available


How to Meet Success Criterion 3.1.4

3.1.4 A mechanism for finding the expanded form of abbreviations is available. (Level 3)

Key Terms

abbreviation

Shortened form of a word, phrase or name, i.e. a general category that includes abbreviations, initialisms and acronyms.

Intent of this success criterion

The intent of this success criterion is to ensure that users can access the expanded form of abbreviations.

Techniques for Addressing Success Criterion 3.1.4

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 3.1.4.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

  • (None currently documented.)

Benefits: How Success Criterion 3.1.4 helps people with disabilities

This success criterion helps people whose disabilities make reading difficult or impossible. These include:

  • People with learning disabilities or cognitive limitations that impair the ability to read.

  • People with low vision. Screen magnification may reduce contextual cues.

  • People with memory loss

This success criterion also helps people with disabilities that affect their ability to recognize words as well as their ability to use context to aid understanding. Acronyms and abbreviations may confuse these readers in different ways:

  • Some abbreviations do not look like normal words and cannot be pronounced according to the usual rules of the language. For example, the English word "room" is abbreviated as "rm," which does not correspond to any English word or phoneme. The user has to know that "rm" is an abbreviation for the word "room" in order to say it correctly.

  • Sometimes the same abbreviation means different things in different contexts. For example, in the English sentence "Dr. Johnson lives on Boswell Dr.," the first "Dr." is an abbreviation for "Doctor" and the second instance is an abbreviation for the word "Drive" (a word that means "street"). Users must be able to understand the context in order to know what the abbreviations mean.

  • Some acronyms spell common words, but are used in different ways. For example, "JAWS" is an acronym for a screen reader whose full name is "Job Access with Speech." It is also a common English word referring to the part of the mouth that holds the teeth. The acronym is used differently than the common word.

  • Some acronyms sound like common words but are spelled differently. For example, the acronym for Synchronized Multimedia Integration Language, S M I L, is pronounced like the English word "smile."

Examples of Success Criterion 3.1.4

  • A dictionary search form.

    A Web site includes a search form provided by an on-line acronym service. Users enter an acronym and the form returns a list of possible expansions from the sources that it searched.

  • A medical Web site.

    A medical Web site provides information for both doctors and patients. The site includes a set of cascading dictionaries: a very specialized medical dictionary is first, followed by a second medical dictionary for the general public. The cascade also includes a list of acronyms and abbreviations that are unique to the site, and finally there is a standard dictionary as well. The standard dictionary at the end of the list provides definitions for most words in the text. The specialized medical dictionary yields definitions of unusual medical terms. Definitions for words that appear in more than one dictionary are listed in the order of the cascade. The meaning of acronyms and abbreviations is provided by the list of acronyms and abbreviations.

  • An abbreviation whose expansion is provided the first time the abbreviation appears in the content.

    The name, "World Wide Web Consortium," appears as the first heading on the organization’s home page. The abbreviation, "W3C," is enclosed in parentheses in the same heading.

Related resources


How to Meet Success Criterion 3.1.5

3.1.5 When text requires reading ability more advanced than the lower secondary education level, one or more of the following types of supplemental content is available: (Level 3)

  1. A text summary that requires reading ability less advanced than the lower secondary education level.

  2. Graphical illustrations of concepts or processes that must be understood in order to use the content.

  3. A spoken version of the text content.

Key Terms

supplemental content

Additional content that illustrates or clarifies default text content, which users may use instead of or in addition to the default text content. For example, there may be supplements in text, graphics, and audio.

Intent of this success criterion

The intent of this success criterion is:

  • To ensure that additional content is available to aid understanding of difficult or complex text;

  • to establish a testable measure indicating when such additional content is required.

This success criterion helps people with reading disabilities while also allowing authors to publish difficult or complex Web content. Text difficulty is described in terms of the level of education required to read the text . Education levels are defined according to the International Standard Classification of Education (UNESCO 1975, 1997), which was created to allow international comparison among systems of education.

Difficult or complex text may be appropriate for most members of the intended audience (that is, most of the people for whom the content has been created). But there are people with disabilities, including reading disabilities, even among highly educated users with specialized knowledge of the subject matter. It may be possible to accommodate these users by making the text more readable. If the text cannot be made more readable, then supplemental content is needed.

Supplemental content is required when text demands reading ability more advanced than the lower secondary education level — that is, more than nine years of school. Such text presents severe obstacles to people with reading disabilities, and is considered difficult even for people without disabilities who have completed upper secondary education.

Techniques for Addressing Success Criterion 3.1.5

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 3.1.5.

Instructions: Select the situation below that matches your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.

Determine if your text content matches Situation A or Situation B, by

  • Measuring the readability of text content

Situation A: If the text requires reading ability at the lower secondary education level or lower, the following would be sufficient:

  • Not including supplemental content

Situation B: If the text requires reading ability more advanced than the lower secondary education level, then one of the following would be sufficient:

Technology-Specific Techniques

(None currently documented.)

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

(None currently documented.)

Optional Techniques (Advisory) for 3.1.5

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Additional technology-independent techniques
Additional technology-specific techniques

Benefits: How Success Criterion 3.1.5 helps people with disabilities

This success criterion benefits people with reading disabilities who can understand complex ideas and processes presented in highly readable text or by other means, such as graphics illustrating relationships and processes or through the spoken word.

Reading and intellectual disabilities affect the ability to recognize individual words. Decoding must be automatic in order for people to read fluently. The act of decoding text word by word consumes much of the mental energy that most people are able to use for understanding what they read.

Examples of Success Criterion 3.1.5

  1. A scientific journal including readable summaries of complex research articles

    A scientific journal includes articles written in highly technical language aimed at specialists in the field. The journal's Table of Contents page includes a plain-language summary of each article. The summaries are intended for a general audience with eight years of school. The metadata for the journal uses the Dublin Core specification to identify the education level of the articles' intended audience as "advanced"; and the education level of the intended audience for the summaries as "lower secondary education."

  2. Medical information for members of the public.

    A medical school operates a Web site that explains recent medical and scientific discoveries. The articles on the site are written for people without medical training. Each article uses the Dublin Core metadata specification to identify the education level of the intended audience as "lower secondary education" and includes the Flesch Reading Ease score for the article. A link on each page displays the education level and other metadata. No supplemental content is required because people who read at the lower secondary education level can read the articles.

  3. An e-learning application.

    An on-line course about Spanish cultural history includes a unit on Moorish architecture. The unit includes text written for students with different reading abilities. Photographs and drawings of buildings illustrate architectural concepts and styles. Graphic organizers are used to illustrate complex relationships, and an audio version using synthetic speech is available. The metadata for each version describes the academic level of the content and includes a readability score based on formulas developed for Spanish-language text. The learning application uses this metadata and metadata about the students to provide versions of instructional content that match the needs of individual students.

Related resources

  • A Plain Language Audit Tool provides a checklist for determining whether documents can be edited for clarity and "plain language." The checklist includes a readability assessment. Available from the Northwest Territories (Canada) Literacy Council at http://www.nwt.literacy.ca/plainlng/auditool/cover.htm.

  • The Plain Language Network Web site provides many useful resources to help writers produce documents that communicate clearly in a variety of cultural and rhetorical contexts. Refer to: http://www.plainlanguagenetwork.org/.

  • The US government's plain language Web site provides general information about plain language as well as information about use of plain language in US government documents, including legal requirements

  • The Plain English Campaign Web site provides useful information and guidance for authors writing in English.

  • Hall, T.,and Strangman, N. CAST: Graphic organizers. Retrieved 5 April 2005. This article illustrates several different kinds of graphic organizers, explains how each type may be useful, and summarizes research findings that graphic organizers support learning, especially among students with learning disabilities.


Understanding Guideline 3.2: Make the placement and functionality of content predictable.

How to Meet Success Criterion 3.2.1

3.2.1 When any component receives focus, it does not cause a change of context. (Level 1)

Key Terms

changes of context

change of :

  1. user agent;

  2. viewport;

  3. focus;

  4. content that changes the meaning of the delivery unit.

Note: A change of content is not always a change of context. Small changes in content, such as an expanding outline or dynamic menu, do not change the context.

Intent of this success criterion

The intent of this success criterion is to ensure that functionality is predictable as visitors navigate their way through a document. Any component that is able to trigger an event when it receives focus must not change the context. Examples of changing context when a component receives focus include, but are not limited to:

  • forms submitted automatically when a component receives focus;

  • new windows launched when a component receives focus;

  • focus is changed to another component when that component receives focus;

Techniques for Addressing Success Criterion 3.2.1

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 3.2.1.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 3.2.1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

(None currently documented.)

Benefits: How Success Criterion 3.2.1 helps people with disabilities

  • People who navigate with a keyboard, including people with visual impairments that may use assistive technologies and people with mobility problems whose motor control makes using a pointing device difficult, may activate a change of context without having an opportunity to make appropriate choices.

  • People with cognitive difficulties may be unaware that an implicit action has caused a change of context.

Examples of Success Criterion 3.2.1


How to Meet Success Criterion 3.2.2

3.2.2 Changing the setting of any form control or field does not automatically cause a change of context (beyond moving to the next field in tab order) unless the delivery unit contains instructions before the control that describe the behavior. (Level 1)

Key Terms

changes of context

change of :

  1. user agent;

  2. viewport;

  3. focus;

  4. content that changes the meaning of the delivery unit.

Note: A change of content is not always a change of context. Small changes in content, such as an expanding outline or dynamic menu, do not change the context.

Intent of this success criterion

The intent of this success criterion is to ensure that entering data or selecting from a control have predictable effects. Changes in context, such as changing the input fields based on the value of a radio button can confuse users that do not easily perceive the change or are easily distracted by changes. Changes of context should occur only when it is clear that such a change will happen when a field is selected or a button is pressed.

See Benefits.

Techniques for Addressing Success Criterion 3.2.2

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 3.2.2.

Technology-independent techniques

  • Using a submit button to initiate a change of context.

Technology-Specific Techniques

HTML Techniques
  • Not using select elements that cause change in context.

    Using a submit button instead of triggering with the onchange event for Select menus that open a new page with more than one option (because they cannot be used with the keyboard otherwise).

    If some design principle demands the use of onChange, a title attribute can clarify the issue. For example, this will help the user understand that an action will be taken upon selection:

    title="Use alt down arrow to open a list of languages."

  • Not using input elements that cause change in context.

    Not having a click on a radio button or checkbox trigger an event that submits a page or pops up a window unless this action is clearly indicated to be the expected action.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 3.2.2

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

  • Describing what will happen when an item is selected.

Benefits: How Success Criterion 3.2.2 helps people with disabilities

  • Providing consistent and predictable responses to user actions is important feedback for users. This lets them know that your site is working properly and encourages them to continue interacting with the content. When users receive an unexpected response, they might conclude that something is wrong or broken. Some people might become so confused they will not be able to use your site.

  • Individuals who are unable to detect changes of context or may not realize that the context has changed are less likely to become disoriented while navigating a site. This applies to people in the following ways:

    • Individuals who are blind or have low vision may have difficulty knowing when a visual context change, such as a new window popping up, has occurred. In this case, warning users of context changes in advance minimizes confusion when the user discovers that the back button no longer behaves as expected.

  • Some individuals with low vision, with reading and intellectual disabilities, and who have difficulty interpreting visual cues may benefit from additional cues in order to detect changes of context.

Examples of Success Criterion 3.2.2

All of the following techniques violate success criterion 3.2.2.

  • The following examples that violate success criterion 3.2.2 are followed by suggested remedies:

    • A form control that automatically takes an action such as submitting a page. Use a separate submit button.

    • A form control that significantly changes the content when selected. A separate button should be use to change the content. Small changes to content such as changing explanations based of the value of the selection or revealing more detail are allowed.

  • A form is presented to the user with multiple fields to be filled in. A submit button is used to accept the values and initiate a change of context.


How to Meet Success Criterion 3.2.3

3.2.3 Navigational mechanisms that are repeated on multiple delivery units within a set of delivery units occur in the same relative order each time they are repeated unless a change is initiated by the user. (Level 2)

Key Terms

delivery unit

A set of material transferred between two cooperating web programs as the response to a single HTTP request. The transfer might, for example, be between an origin server and a user agent.

Note: This term was taken verbatim from Glossary of Terms for Device Independence.

same relative order

Each item maintains its position relative to the other items. Items are considered to be in the same relative order even if other items are inserted or removed from the original order. For example, expanding navigation menus may insert an additional level of detail or a secondary navigation section may be inserted into the reading order.

Intent of this success criterion

The intent of this success criterion is to encourage the use of consistent presentation and layout for users who interact with repeated content in a set of delivery units and need to locate specific information or functionality more than once. Individuals with low vision who use screen magnification to display a small portion of the screen at a time often use visual cues and page boundaries to quickly locate repeated content. Presenting repeated content in the same order is also important for visual users who use spatial memory or visual cues within the design to locate repeated content.

It is important to note that the use of the term "same order" in this criterion is not meant to imply that subnavigation menus cannot be used or that blocks of secondary navigation or page structure cannot be used. Instead, this criterion is intended to assist users who interact with repeated content across delivery units to be able to predict the location of the content they are looking for and find it more quickly when they encounter it again.

Techniques for Addressing Success Criterion 3.2.3

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 3.2.3.

Technology-Specific Techniques

(None currently documented.)

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

(None currently documented.)

Optional Techniques (Advisory) for 3.2.3

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Additional Technology-Independent Techniques (Advisory)
  • Using templates to ensure consistency across multiple delivery units.

  • Using dynamic navigation.

Additional Technology-Specific Techniques (Advisory)

CSS Techniques

Benefits: How Success Criterion 3.2.3 helps people with disabilities

  • Ensuring that changes of context can be programmatically determined allows user agents to provide warnings to users that they are about to occur or support settings that allow users to disable them.

  • Users expect user agents to change the context (that is, load a new page) whenever they select a link or a submit button. They can be surprised and confused, however, if the context changes when they are simply navigating through the Web page or changing the setting of a form field. The surprise and confusion is more severe for users who are blind or have low vision and can't see that a new page is loading but simply hear their screen reader suddenly start reading an entirely new page. The surprise and confusion can also be more severe for users with learning disabilities. Avoiding these types of unexpected changes in context reduces such surprise and confusion.

  • Ensuring that repeated components occur in the same order on each page of a site helps users become comfortable that they will able to predict where they can find things on each page. This helps users with learning disabilities and also those who are blind.

Examples of Success Criterion 3.2.3

  • A consistently located control

    A user may recall that a search field is always located at the bottom right corner of a page in a site. After browsing a number of pages within the site and not finding what they were looking for, the user can quickly locate the search function.

  • An expanding navigation menu

    A navigation menu includes a list of seven items with links to the main sections of a site. When a user selects one of these items, a list of subnavigation items is inserted into the top-level navigation menu.

  • Consistently positioned skip navigation controls

    A "skip navigation" link is included as the first link on every page in a Web site. The link allows users to quickly bypass heading information and navigational content and begin interacting with the main content of a page.

  • Skip to navigation link

    A skip to navigation link is provided to navigational content at the end of a page. The link is consistently located at the top of each page so that keyboard users can easily locate it when needed.

Related resources


How to Meet Success Criterion 3.2.4

3.2.4 Components that have the same functionality within a set of delivery units are identified consistently. (Level 2)

Key Terms

same functionality

Items are considered to have the same functionality if the outcome of their use is identical. For instance, a submit "search" button on one delivery unit and a "find" button on another delivery unit may both have a field to enter a term and list topics in the web site related to the term submitted. In this case they would have same functionality but would not be labeled consistently.

delivery unit

A set of material transferred between two cooperating web programs as the response to a single HTTP request. The transfer might, for example, be between an origin server and a user agent.

Note: This term was taken verbatim from Glossary of Terms for Device Independence.

Intent of this success criterion

The intent of this criterion is to ensure consistent identification of functional components that appear repeatedly within a set of delivery units. A strategy that people who use screen readers use when operating a Web site is to rely heavily on their familiarity with functions that may appear on different delivery units. If identical functions have different labels on different delivery units, the site will be considerably more difficult to use. It may also be confusing and increase the cognitive load for people with cognitive difficulties. Therefore, consistent labeling will help.

This consistency extends to the text alternatives. If icons or other non-text items have the same functionality, then their text alternatives should as well.

See Benefits.

Techniques for Addressing Success Criterion 3.2.4

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 3.2.4.

Technology-independent techniques

  • Using consistent label, names, and text alternatives for content that has the same functionality.

Note 1: Text alternatives that are "consistent" are not always "identical." For instance, you may have an graphical arrow at the bottom of a delivery unit that links to the next delivery unit. The text alternative may say "Go to page 4." Naturally, it would not be appropriate to repeat this exact text alternative on the next delivery unit. It would be more appropriate to say "Go to page 5". Although these text alternatives would not be identical, they would be consistent, and therefore would satisfy this success criterion.

Note 2: A single non-text-content-item may be used to serve different functions. In such cases, different text alternatives are necessary and should be used. Examples can be commonly found with the use of icons such as a check marks, cross marks, and traffic signs. Their functions can be different depending on the context of the delivery unit. A check mark icon may function as "approved", "completed", or "included", to name a few, depending on the situation. Using "check mark" as text alternative across all delivery units does not help users understand the function of the icon. Different text alternatives can be used when the same non-text content serves multiple functions.

Technology-Specific Techniques

HTML Techniques

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 3.2.4

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Additional Technology-Independent Techniques (Advisory)
  • Ensuring that the text alternative conveys the function of the component and what will happen when the user activates it.

  • Using the same non-text content for a given function whenever possible.

Additional Technology-Specific Techniques (Advisory)

Benefits: How Success Criterion 3.2.4 helps people with disabilities

  • People who figure out functionality on one page on a site can find the desired functions on other pages if they are present.

  • People with difficulty reading text or detecting text alternatives can interact with the Web without depending on text alternatives.

  • People who depend on text alternatives can have a more predictable experience. They can also search for the button if it has a consistent label on different pages.

Examples of Success Criterion 3.2.4

  • Example 1: Document Icon

    A document icon, which is used to indicate document download throughout out a site. Since there may be multiple documents to download, text alternatives are useful to differentiate the documents. In this case, the document icon serves the same function of loading documents. Using different text alternatives identifying document names for different documents is a consistent use of text alternative.

  • Example 2: Check Mark

    A check mark icon functions as "approved", on one page but as "included",on another. Since they serve different functions, they have different text alternatives.

  • Example 3: Example of a Failure

    A common "save" icon is used through out the site where page save function is provided on multiple delivery units.

  • Example 4: Example of a Failure

    A submit "search" button on one delivery unit and a "find" button on another delivery unit may both have a field to enter a term and list topics in the Web site related to the term submitted. In this case they would have same functionality but would not be labeled consistently.


How to Meet Success Criterion 3.2.5

3.2.5 Changes of context are initiated only by user request. (Level 3)

Key Terms

changes of context

change of :

  1. user agent;

  2. viewport;

  3. focus;

  4. content that changes the meaning of the delivery unit.

Note: A change of content is not always a change of context. Small changes in content, such as an expanding outline or dynamic menu, do not change the context.

Intent of this success criterion

The intent of this success criterion is to encourage design of Web content that gives users full control of changes of context. This success criterion aims to eliminate potential confusion that may be caused by unexpected changes of context such as automatic launching of new windows, automatic submission of forms after selecting an item from a list, etcetera. Such unexpected changes of context may cause difficulties for people with motor impairments, people with low vision, people who are blind, and people with certain cognitive disabilities.

Further below is a description of who benefits from this success criterion.

Techniques for Addressing Success Criterion 3.2.5

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 3.2.5.

Instructions: Select the situation below that matches your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.

For automatic updates:

For automatic redirects:

For pop-up windows:

Technology-Specific Techniques

Server-Side Techniques

Provide automatic redirects by

  • using an instant server-side redirect.

Optional Techniques (Advisory) for 3.2.5

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

HTML Techniques (Advisory)

If you cannot use server-side redirects, implement automatic redirects by

Open new windows by

Client-Side Scripting Techniques (Advisory)

(None currently documented.)

Benefits: How Success Criterion 3.2.5 helps people with disabilities

  • Individuals who are unable to detect changes of context or may not realize that the context has changed are less likely to become disoriented while navigating a site. This applies to people in the following ways:

    • individuals who are blind or have low vision may have difficulty knowing when a visual context change, such as a new window popping up, has occurred. In this case, warning users of context changes in advance minimizes confusion when the user discovers that the back button no longer behaves as expected.

  • Some individuals with low vision, with reading and intellectual disabilities, and who have difficulty interpreting visual cues may benefit from additional cues in order to detect changes of context.

  • People with certain cognitive disabilities do not get confused if automatic redirects are performed by the Web server instead of the browser.

Examples of Success Criterion 3.2.5

  • an "update now" button

    Instead of automatically updating the content, the author provides an "Update now" button that requests a refresh of the content.

  • An automatic redirection

    A user is automatically redirected from an old page to a new page in such a way that he or she never realizes the redirect has occurred.


Understanding Guideline 4.1: Ensure compatibility with current and future user agents (including assistive technologies)

How to Meet Success Criterion 4.1.1

4.1.1 Delivery units can be parsed unambiguously and the relationships in the resulting data structure are also unambiguous. (Level 1)

Key Terms

delivery unit

A set of material transferred between two cooperating web programs as the response to a single HTTP request. The transfer might, for example, be between an origin server and a user agent.

Note: This term was taken verbatim from Glossary of Terms for Device Independence.

parsed unambiguously

Parsing transforms markup or other code into a data structure, usually a tree, which is suitable for later processing and which captures the implied hierarchy of the input. Parsing unambiguously means that there is only one data structure that can result

Intent of this success criterion

The purpose is to ensure that user agents (including assistive technology) can accurately interpret parsable content. If it is not unambiguously parsable then different user agents may present it differently or be completely unable to parse it. The fact that it can be parsed (using repair techniques during parsing) by major mainstream user agents does not mean that it can be parsed (or parsed accurately) by special browsers (including assistive technologies) that a user with a disability might need to employ.

Techniques for Addressing Success Criterion 4.1.1

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 4.1.1.

Technology-independent techniques

Technology-Specific Techniques

Parsing HTML unambiguously
Parsing XML-based content unambiguously
Parsing other technologies unambiguously

Editorial Note: We are exploring the role of this guideline for non-XML format files. Comments and suggestions are invited.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 4.1.1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

(none currently documented)

Benefits: How Success Criterion 4.1.1 helps people with disabilities

  • Ensuring that delivery units parse unambiguously helps ensure that assistive technologies can parse the content accurately and without crashing.

Examples of Success Criterion 4.1.1

Related resources


How to Meet Success Criterion 4.1.2

4.1.2 The role, state, and value can be programmatically determined for every user interface component in the Web content that accepts input from the user or changes dynamically in response to user input or external events. (Level 1)

Key Terms

programmatically determined

can be recognized by user agents, including assistive technologies, that support the technologies in the chosen baseline

Intent of this success criterion

The intent of this success criterion is to provide information in a form that assistive technology can extract accessibility information about interactive user interface components in order to present them to users in an understandable way. For example, a screen reader may tell a user that the current control is a checkbox and that it is not checked. Checkbox is the "role" and "not checked" is the state. Users are then able to understand that the option represented by the checkbox is selected. A speech recognition program might build an interaction vocabulary using this information.

Techniques for Addressing Success Criterion 4.1.2

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 4.1.2.

{no technology-independent techniques currently documented}

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

(none currently documented)

Optional Techniques (Advisory) for 4.1.2

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

(none currently documented)

Benefits: How Success Criterion 4.1.2 helps people with disabilities

Providing role, state, and value information on all user interface components enables compatibility with assistive technology, such as screen readers, screen magnifiers, and speech recognition software, used by users with disabilities.

Examples of Success Criterion 4.1.2


How to Meet Success Criterion 4.1.3

4.1.3 The label of each user interface control in the Web content that accepts input from the user can be programmatically determined and is explicitly associated with the control. (Level 1)

Key Terms

label

text that identifies a component within Web content

programmatically determined

can be recognized by user agents, including assistive technologies, that support the technologies in the chosen baseline

Intent of this success criterion

Following this success criterion ensures that assistive technologies can provide the correct label for all user interface controls.

Techniques for Addressing Success Criterion 4.1.3

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 4.1.3.

Technology-independent techniques

  • Labeling UI controls using a technology specific technique listed below

Technology-Specific Techniques

Editorial Note: Looking for script techniques, and role of APIs. Comments invited.

HTML

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 4.1.3

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

(none currently documented)

Benefits: How Success Criterion 4.1.3 helps people with disabilities

  • Users of some assistive technologies complete forms by navigating from control to control without encountering content, including labels, in between. The layout of pages can also make it difficult to determine which label is associated with which control based purely on contextual information. Explicit association of the control to the label allows user agents to present the correct label for a control on demand.

  • Users who have difficulty in mouse operation can select a checkbox/radio button by clicking on the label text.

Examples of Success Criterion 4.1.3

(none currently documented)

Related resources

(none currently documented)


How to Meet Success Criterion 4.1.4

4.1.4 The content and properties of user interface elements in the Web content that can be changed via the user interface can also be directly changed programmatically. (Level 1)

Note: Some examples of standardized properties that typically can be changed by the user interface include its value, whether it is currently selected, and whether it currently has the focus.

Editorial Note: The working group is still considering whether this criterion should be included and, if so, at what level.

Intent of this success criterion

This ensures that users can use their assistive technologies to change the value and state of all content that can be changed via the user interface.

NOTE: Success criterion 3 ensures that values can be read and this success criterion ensures that they can be controlled.

Techniques for Addressing Success Criterion 4.1.4

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 4.1.4.

Technology-independent techniques

NOTE: In most markup languages, this functionality is provided through the user agent. In programming languages, it needs to be provided through support of accessibility features in APIs.

Technology-Specific Techniques

(none currently documented)

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

(none currently documented)

Optional Techniques (Advisory) for 4.1.4

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

(none currently documented)

Benefits: How Success Criterion 4.1.4 helps people with disabilities

Some users rely on their assistive technology for their interface. This criterion allows them to do so.

Examples of Success Criterion 4.1.4

(none currently documented)

Related resources

(none currently documented)


How to Meet Success Criterion 4.1.5

4.1.5 Changes to content, structure, selection, focus, attributes, values, state, and relationships of the user interface elements in the Web content can be programmatically determined. (Level 1)

Key Terms

programmatically determined

can be recognized by user agents, including assistive technologies, that support the technologies in the chosen baseline

Intent of this success criterion

The intent of this SC is to ensure that assistive technologies can inform users when changes have occurred within the content. To do this assistive technologies must be notified of changes that may affect the content the user perceives or how they interact with it. Failure to meet this SC can cause assistive technologies to continue to present the original content, resulting in an inaccurate perception. This can also impede proper interaction as the assistive technology may present an incorrect indication of the present state and values of user interface controls, causing the user to input incorrect or invalid data.

Techniques for Addressing Success Criterion 4.1.5

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 4.1.5.

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 4.1.5

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

(none currently documented)

Benefits: How Success Criterion 4.1.5 helps people with disabilities

Users of assistive technology can access dynamic content successfully. Assistive technology and assistive technology users can keep their model of the content in sync with the user agent.

Examples of Success Criterion 4.1.5

(none currently documented)


Understanding Guideline 4.2: Ensure that content is accessible or provide an accessible alternative

How to Meet Success Criterion 4.2.1

4.2.1 If content does not meet all Level 1 success criteria, then an alternate version is available from the same URI that does meet all Level 1 success criteria. (Level 1)

Key Terms

content

Information in the delivery unit that is used by the user agent to generate perceivable units. This includes the code and markup that define the structure, presentation, and interaction, as well as text, images, and sounds that convey information to the end-user.

alternate version

a version that provides all of the same information and functionality and is as up to date as any non-conformant content

Intent of this success criterion

The intent of this success criterion is to ensure that an accessible version of all content is available. Authors may use inaccessible technologies or formats on their Web sites. But they must also provide all of the information and functionality in an accessible form that is easily obtained. Note that this is a fallback option and is not preferable to making the content itself accessible.

Techniques for Addressing Success Criterion 4.2.1

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 4.2.1.

Technology-Specific Techniques

(none currently documented)

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

Optional Techniques (Advisory) for 4.2.1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Additional Technology-Independent Techniques (Advisory)
Additional HTML Techniques (Advisory)
Additional CSS Techniques (Advisory)

Benefits: How Success Criterion 4.2.1 helps people with disabilities

The benefits of determining and documenting technology requirements are that individuals can identify (either through site documentation or automatically through metadata) whether or not they are likely to be able to use a site. In conjunction with a search engine or a proxy server, this could be used to automatically filter out sites a user cannot access or to automatically filter to the top sites that would be most usable. Documenting technology requirements will cause authors to evaluate assumptions about user agents and will minimize the number of sites that are inadvertently inaccessible because they are unaware of backward compatibility issues. The benefits of ensuring user interface accessibility and providing accessible alternatives are that individuals who must use alternative browsing technologies and devices will be able to access the content. Individuals who cannot afford or otherwise do not have access to newer technologies also benefit from backward compatibility in that they will not need to purchase upgrades or equipment as often.

Examples of Success Criterion 4.2.1

  • An on-line store that lists required technologies.

    By documenting minimum user agent requirements, the store makes it possible for people using particular technologies to determine whether they are going to have trouble using the store or its checkout mechanism before they begin shopping. This prevents users from finding that, after they have selected their products and initiated a checkout process, they are unable to complete their transaction. They can, therefore, choose alternatives where they can be assured greater success.

  • An intranet site that transforms gracefully.

    A large company was concerned about the ability to address individuals at many diverse office locations that have different technology bases. To address the problem, they created two versions of their content and documented the requirements for each, making it easy for individual locations to determine which version would work best for their technologies.

  • An informational site ensuring backward compatibility.

    An information site covers a wide variety of subjects and wants to enable their visitors to quickly find the topics they're looking for. To do this, they have implemented an interactive menu system that is only supported in the most recent version of two popular user agents. To ensure that their visitors who do not use these specific user agents are still able to effectively use the site, a navigation mechanism that does not depend on the interactive menu system they are using is presented to user agents that do not support the newer technology.

Related resources

(none currently documented)


How to Meet Success Criterion 4.2.2

4.2.2 Content meets the following criteria even if the content uses a technology that is not in the chosen baseline: (Level 1)

  1. If content can be entered using the keyboard, then the content can be exited using the keyboard.

Key Terms

content

Information in the delivery unit that is used by the user agent to generate perceivable units. This includes the code and markup that define the structure, presentation, and interaction, as well as text, images, and sounds that convey information to the end-user.

baseline

Set of technologies assumed to be supported by, and enabled in, user agents in order for Web content to conform to these guidelines.

Note: Some examples of entities that may set baselines that an author may have to follow include the author, a company, a customer and government entities.

Intent of this success criterion

The intent of this SC is to ensure that content does not include components that actively interfere with the accessibility of the remaining content. These include:

  • components that would trap keyboard users within inaccessible content.

The baseline is the set of technologies that must be supported for the Web site's content and functionality to be available to the user. All content implemented in technologies in the baseline must conform to WCAG for the claim of conformance for the site to be valid. Content may be implemented in technologies that are not in the baseline, however, if accessible alternatives are provided using technologies that are in the baseline, or if the content is accessible from a user agent that supports only the technologies in the baseline. It is vital that there be no characteristics of any of the content that actively interfere with its accessibility. This is because user agents that support the technology could be present and create accessibility problems even though the technology is not part of the baseline.

The requirement that content that can be entered via the keyboard can be exited via the keyboard refers to "keyboard trapping", a common situation in which the keyboard focus can become stuck in inaccessible plugins, leaving a keyboard-only user with no way to return to the accessible content.

Techniques for Addressing Success Criterion 4.2.2

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 4.2.2.

Instructions: Select the situation below that matches your content. Beneath it, are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.

Technology-Specific Techniques

(none currently documented)

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

  • Trapping keyboard focus

    When content in a different technology receives keyboard focus, it often sets its own context for keyboard navigation and overrides the global context of the user agent. In particular, when focus reaches the end of the tab cycle it may wrap to the top of the tab order for its content type, not return to the parent document and continue in its tab cycle.

Optional Techniques (Advisory) for 4.2.2

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Benefits: How Success Criterion 4.2.2 helps people with disabilities

This success criterion ensures that accessible content in the baseline is not unintentionally rendered inaccessible by simultaneously displayed content in technologies outside of the baseline. It describes "active inaccessibility" cases that must be avoided even for technologies outside of the baseline and the scope of the WCAG conformance claim.

Examples of Success Criterion 4.2.2

  1. Non-baseline content contains a link to information about how to move focus back to the baseline content via the keyboard.

  2. The Help information available from the non-baseline content documents how to move focus back to the baseline content via the keyboard, and the Help information can be accessed via the keyboard.

  3. (Advisory) The Help information available for the delivery unit documents how to move focus from the non-baseline content to the baseline content via the keyboard, and the Help information can be accessed via the keyboard.

Related resources

(none currently documented)


How to Meet Success Criterion 4.2.3

4.2.3 Content implemented using technologies outside of the chosen baseline satisfies all Level 1 and 2 WCAG requirements supported by the technologies. (Level 3)

Key Terms

baseline

Set of technologies assumed to be supported by, and enabled in, user agents in order for Web content to conform to these guidelines.

Note: Some examples of entities that may set baselines that an author may have to follow include the author, a company, a customer and government entities.

Intent of this success criterion

At Level 1 and 2, WCAG conformance is only required for technologies inside the baseline. Technologies outside the baseline need not conform, although accessible alternatives using technologies inside the baseline must be provided. This success criterion takes accessibility requirements at Level 3 further and states that any accessibility features supported by technologies outside the baseline must be used, even though accessible alternatives are also provided.

This requires that any accessibility features supported by technologies outside the chosen baseline be used, even though accessible alternatives are also provided. Some technologies do not provide features capable of meeting all WCAG requirements, and therefore content in those technologies cannot meet WCAG requirements alone. For that reason, this success criterion does not require that content in technologies outside the baseline meet all WCAG requirements.

Techniques for Addressing Success Criterion 4.2.3

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 4.2.3.

Technology-independent techniques

Technology-Specific Techniques

(none currently documented)

Common Failures Identified by the Working Group

The following are common failures that are considered failures of this success criterion by the WCAG Working Group.

(none currently documented)

Optional Techniques (Advisory) for 4.2.3

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Benefits: How Success Criterion 4.2.3 helps people with disabilities

Although by definition content in technologies outside the baseline need not be accessible in order to conform to WCAG, because accessible alternatives are provided, accessibility features should nevertheless be provided. This permits users with disabilities who have user agents that do support the technology to use that content, rather than be forced to rely on the accessible alternative. It also future-proofs the site: should the baseline be extended to include a technology that is currently outside the baseline, the content already meets WCAG requirements. This is good practice and always desirable, but is only required for WCAG conformance at Level 3 by this success criterion.

Examples of Success Criterion 4.2.3

  • A Web site is developed for a baseline that contains HTML and Script, but does not support Flash. An interactive Flash movie provides video clips and responses to user input. The information provided is also available in HTML with Script support, but the experience is not as rich. The Flash movie provides text alternatives, keyboard support, appropriate tab order, etc. to help make it directly accessible so users who wish can access the richer content directly instead of the accessible alternative.

  • At a Web site developed for a baseline that contains HTML but not PDF, a PDF version of a print book is provided with an HTML alternative. Although all the content is available in the HTML version, it cannot be printed in a manner that is true to the design of the original book, and it is much harder to keep track of pagination for references. The PDF version is structured with a logical reading order, text alternatives for images, etc. so it can be viewed directly by users who prefer to access that version and use the features of the PDF reader.

  • Prerecorded video is provided on the site. Although the video format supports text tracks for captioning and alternate audio tracks for described video, user agent support for these features is known to be imperfect. Therefore it is decided to leave the video format out of the baseline, and provide a text transcript and text descriptions as an accessible alternative. Nevertheless, captions and audio descriptions are also provided in the video so users who wish can access them while the video is playing.

  • An HTML page provides "menu bar"-style navigation with the aid of ECMAScript to display and hide menu options. Because the site is designed to be used by users who have browsers that do not support script, the baseline only includes HTML and does not mandate the use of script. Accordingly, the navigation menus are designed so that if scripts are not supported, links take users to alternate navigation pages so they can navigate the site if the menu options are not shown. The script is designed to be accessible for user agents that do support script, including providing keyboard operability, not preventing keyboard and mouse commands from working, and displaying/hiding content instead of generating/removing content to ensure that users can access the menus as they appear.


Appendix A References (Non-Normative)

WCAG20
" Web Content Accessibility Guidelines 2.0 ", B. Caldwell, W. Chisholm, J. Slatin, and G. Vanderheiden, eds.