[contents] [checklist]

W3C

Understanding WCAG 2.0

W3C Working Draft 27 April 2006

This version:
http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/
Latest version:
http://www.w3.org/TR/UNDERSTANDING-WCAG20/
Previous version:
http://www.w3.org/TR/2005/WD-UNDERSTANDING-WCAG20-20051123/
Editors:
Ben Caldwell, Trace Research & Development Center, University of Wisconsin-Madison
Wendy Chisholm, W3C
John Slatin, Accessibility Institute, University of Texas at Austin
Gregg Vanderheiden, Trace Research & Development Center, University of Wisconsin-Madison

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, HTML, CSS, XML) and common examples of Web content that does 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 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 second 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 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.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. This document is informative only. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.


Table of Contents

Appendix


Introduction to Understanding WCAG 2.0

Understanding WCAG 2.0 is an essential guide to understanding and using "Web Content Accessibility Guidelines 2.0" [WCAG20] Although the definition and requirements for WCAG 2.0 can all be found in the WCAG 2.0 document itself, the concepts and provisions may be new to some people. Understanding WCAG 2.0 provides an extended commentary on each guideline and each success criterion to help readers better understand the intent and how the guidelines and success criteria work together. It also provides examples of techniques or combinations of techniques that the Working Group has identified as being sufficient to meet each success criterion. Links are then provided to write-ups for each of the techniques.

Note: Where the committee has not yet been able to write up the description of the techniques the techniques are listed with "(future link)" following their title.

Understanding WCAG 2.0 is organized by guideline. There is an Understanding Guideline X.X section for each guideline. The intent and any advisory techniques that are related to the guideline but not specifically related to any of its success criteria are listed there as well.

The Understanding Guidelines X.X section is then followed by a How to Meet Success Criterion X.X.X section for each success criterion of that guideline. These How to Meet sections each contain:

Links are provided from each Guideline in WCAG 2.0 directly to each Understanding Guideline X.X in this document. Similarly, there is a link from each success criterion in WCAG 2.0 to the How to Meet Success Criterion X.X.X section in this document.

For information about individual techniques, follow the links throughout this document to the techniques of interest in the Techniques for WCAG 2.0 document.

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

Intent of Guideline 1.1

The purpose of this guideline is to ensure that all non-text content is also available in text form. "Text form" refers to electronic text, not an image of text. Electronic text has the unique advantage that it can be rendered visually, auditorily, tactilely, or by any combination. As a result, information rendered in electronic text can be presented in whatever form best meets the needs of the user. It can also be easily enlarged, spoken in a voice that is easy to understand or rendered in whatever tactile form best meets the needs of a user.

Advisory Techniques for Guideline 1.1

Specific techniques for meeting each success criterion for this guideline are listed in the How to Meet sections for each success criterion (listed below). There are some techniques, however, for addressing this guideline that do not fall under any of the success criteria. These techniques are listed here. They are not required or sufficient for meeting any success criteria but these advisory techniques can make certain types of Web content more accessible to more people.

  • All advisory techniques for this guideline relate to specific success criteria and are listed below.

How to Meet Success Criterion 1.1.1

1.1.1 For all non-text content, one of the following is true: (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

Note: This includes ASCII Art, which is a pattern of characters.

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 components

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

test or exercise that must use a particular sense

test where the content must be presented in a particular sensory format

Example: Color blindness test, hearing test, vision exercise, spelling test.

specific sensory experience

a sensory experience that is not purely decorative and does not primarily convey important information or perform a function

label

text, image, or sound that is presented to a user to identify a component within Web content

pure decoration

serving only an aesthetic purpose, providing no information, and having no functionality.

Assistive technology (in the context of this document)

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.

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

Example: 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 definition is based on User Agent Accessibility Guidelines 1.0 Glossary.

Intent of this success criterion

The intent of this success criterion is to make information conveyed by non-text content accessible through the use of a text alternative. Text alternatives are a primary way for making information accessible because they can be rendered through any sensory modality (for example, visual, auditory or tactile) to match the needs of the user. 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 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. In the future, text alternatives will also allow information to be more easily translated into sign language or into a simpler form of the same language.

Additional information

Non-text content can take a number of forms, and this success criterion specifies how each is to be handled.

For non-text content that presents information, such as charts, diagrams, audio recordings, pictures, and animations, text alternatives can make the same information available in a form that can be rendered through any modality (for example, visual, auditory or tactile). Short and long text alternatives can be used as needed to convey the information in the non-text content. Note that pre-recorded audio-only and pre-recorded video-only files are covered here. Live -audio-only and Live -video-only files are covered below (see 3rd paragraph following this one).

For non-text content that responds to user input , such as images used as submit buttons or complex animations, text alternatives are provided if at all possible. If it is not possible to make the function available in any form of text (including with the use of links, etc.), then the purpose of the non-text content is identified in text so that the person at least knows what the non-text content is and why it is there.

Non-text content that is multimedia is made accessible through guideline 1.2. However it is important that users know what it is when they encounter it on a page so they can decide what action if any they want to take with it. A text alternative that describes the multimedia and/or gives its title is therefore provided.

Live Audio-only and live video-only files - It is much more difficult to provide text alternatives that convey the same information as live audio-only and live video-only content. For these types of non-text content, text alternatives provide a descriptive label.

Sometimes a test or exercise must use a particular sense. Audio or visual information is provided that cannot be changed to text because the test or exercise must be conducted using that sense. For example, a hearing test would be invalid if a text alternative were provided. A visual skill development exercise would similarly make no sense in text form. And a spelling test with text alternatives would not be very effective. For these cases, text alternatives should be provided to describe the purpose of the non-text content; of course, the text alternatives would not provide the same information needed to pass the test.

Sometimes content is primarily intended to create a specific sensory experience that words cannot fully capture. Examples include a symphony performance, works of visual art etc. For such content, text alternatives at least identify the non-text content with a descriptive label. Providing what description is possible is also desired. If the intent of the author in creating the content - or the intent of the page author in putting the content on the page - is known and can be described, this is also very useful.

Finally, there is non-text content that really is not meant to be seen or understood by the user. Transparent images used to move text over on a page; a one pixel transparent "web-bug" that tells the author when the page is viewed; and a swirl in the corner that conveys no information but just fills up a blank space to create an aesthetic effect are all examples of this. Putting alternative text on such items just distracts people using screen readers from the content on the page. Not marking the content in any way, though, leaves users guessing what the non-text content is and what information they may have missed (even though they have not missed anything in reality). This type of non-text content, therefore, is marked or implemented in a way that assistive technologies (AT) will ignore it and not present anything to the user.

Techniques for Addressing Success Criterion 1.1.1

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.1.1 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation A: If a short description can serve the same purpose and present the same information as the non-text content, the following would be sufficient:

  1. Providing short text alternative for non-text content that serves the same purpose and presents the same information as the non-text content USING a technology-specific technique listed below (for a technology in your baseline)

Situation B: If a short description can not serve the same purpose and present the same information as the non-text content (e.g. a chart or diagram), the following would be sufficient:

  1. Providing short text alternatives that provide a brief description of the non-text content USING a technology-specific technique listed below (for a technology in your baseline) AND one of the following techniques for long description:

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

  1. Providing a text alternative that identifies the purpose of the functional non-text content USING one of the technology-specific techniques below (for a technology in your baseline)

Situation D: If non-text content is multimedia; live audio-only or live video-only content; a test or exercise that must use a particular sense; or primarily intended to create a specific sensory experience

  1. Providing a descriptive label USING one of the technology-specific techniques below (for a technology in your baseline)

  2. Providing a descriptive label that describes the purpose of live audio-only and live video-only content USING a technology-specific technique (for a technology in your baseline) for providing short text alternatives listed below

  3. Providing the accepted name or a descriptive name of the non-text content USING a technology-specific technique (for a technology in your baseline) for providing short text alternatives listed below

Situation E: If the non-text content should be ignored by assistive technology

  1. Implementing or Marking the non-text content so that it will be ignored by AT USING one of the technology-specific techniques listed below

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

(none currently documented)

General Techniques for Informative Non-Text Content(Advisory)
  • Identifying informative non-text content (future link).

  • Keeping short descriptions short (future link).

  • Describing images that include text (future link).

  • Providing a longer description of the non-text content where only a descriptive label is required using a technology-specific technique (for a technology in your baseline) for long description listed above. (future link)

General Techniques for Live Non-Text Content (Advisory)
  • Linking to live textual information, e.g., if it is a traffic web cam, linking to a site that provides textual traffic reports (future link)

  • Providing a transcript of a live audio only presentation after the fact (future link)

HTML Techniques (Advisory)
  • Writing for browsers that do not support frame (future link)

  • Providing alternative content for iframe (future link)

  • Providing text and non-text alternatives for object (future link)

  • Not using long descriptions for iframe (future link)

  • Providing redundant text links for client-side image maps (future link)

CSS Techniques (Advisory)
  • Using CSS margin and padding rules instead of spacer images (future link)

  • Using CSS background, :before or :after rules for decorative images instead of img elements (future link)

  • Displaying empty table cells (future link)

Benefits: How Success Criterion 1.1.1 helps people with disabilities

  • People who are blind, have low vision, or have cognitive limitations 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

  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 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 is 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 as well as 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


Understanding Guideline 1.2: Provide synchronized alternatives for multimedia

Intent of Guideline 1.2

The purpose of this guideline is to provide access to multimedia. Multimedia is defined in the glossary as:

multimedia: audio or video synchronized with another type of media and/or with time-based interactive components

Note that an audio file accompanied by interaction is covered here, as is a video-only file that involves interaction. These are covered because interaction must take place at a particular time. Having a text transcript that said, "for more information, click now," would not be very helpful since the reader would have no idea when the audio said, "now." As a result, synchronized captions would be needed.

Sometimes, there is so much dialogueue that audio descriptions cannot fit into existing pauses in the dialogueue. The option at Level 1 to provide a full multimedia text alternative including any interaction instead of audio descriptions for multimedia would allow access to all of the information in the multimedia. This option also allows access to the visual information in non-visual form when audio description is not provided for some other reason.

For multimedia that includes interaction, interactive elements (for example links) could be embedded in the full multimedia text alternative.

This guideline also includes (at Level 3) sign language interpretation for multimedia as well as an approach called extended audio descriptions. In extended audio description, the video is frozen periodically to allow more audio description to take place than is possible in the existing pauses in the dialogueue.

Advisory Techniques for Guideline 1.2

Specific techniques for meeting each success criterion for this guideline are listed in the How to Meet sections for each success criterion (listed below). There are some techniques, however, for addressing this guideline that do not fall under any of the success criteria. These techniques are listed here. They are not required or sufficient for meeting any success criteria but these advisory techniques can make certain types of Web content more accessible to more people.

  • All advisory techniques for this guideline relate to specific success criteria and are listed below.

How to Meet Success Criterion 1.2.1

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

Key Terms

captions

text presented and synchronized with multimedia to provide not only the speech, but also sound effects and sometimes speaker identification

Note: In some countries, the term "subtitle" is used to refer to dialogue only and "captions" is used as the term for dialogue plus sounds and speaker identification. In other countries, subtitle (or its translation) is used to refer to both.

multimedia

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

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 dialogue, but identify who is speaking and note important sounds.

Techniques for Addressing Success Criterion 1.2.1

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.2.1 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Providing open captions that are embedded directly in the video stream

  2. Providing closed captions USING any of the technology specific techniques below (for a technology in your baseline)

  3. Providing closed captions USING any readily available media format that has a video player that is free of charge and supports closed captioning

Common Failures Identified by the Working Group

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

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

(none currently documented)

Additional Technology-Independent Techniques (Advisory)
  • Providing a note saying "No sound is used in this clip" for video-only clips (future link)

Additional SMIL 1.0 Techniques (Advisory)
  • Using SMIL 1.0 to provide captions for all languages for which there are audio tracks (future link)

Additional SMIL 2.0 Techniques (Advisory)
  • Using SMIL 2.0 to provide captions for all languages for which there are audio tracks (future link)

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, or a full multimedia text alternative including any interaction, 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

Note 1: Audio descriptions of video provide information about actions, characters, scene changes, and on-screen text.

Note 2: In standard audio description, narration is added during existing pauses in dialogue. (See also Extended audio descriptions.)

full multimedia text alternative including any interaction

document including correctly sequenced descriptions of all visual settings, actions, and non-speech sounds combined with descriptive transcripts of all dialogue and a means of achieving any outcomes that are achieved using interaction during the multimedia

Note: A screenplay used to create the multimedia content would meet this definition only if it was corrected to accurately represent the final multimedia after editing.

multimedia

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

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. This success criterion describes two approaches, either of which can be used.

One approach is to provide Audio Description of the video content. The audio description augments the audio portion of the presentation with the information needed when the video portion is not available. During existing pauses in dialogueue, audio descriptions provide information about actions, characters, scene changes, and on-screen text that are important and are not described or spoken in the main sound track.

The second approach involves providing all of the information in the multimedia (both visual and auditory) in text form. A full multimedia text alternative including any interaction provides a running description of all that is going on in the multimedia content. The full multimedia text alternative reads something like a screenplay or book. Unlike audio descriptions, the descriptions of the video portion are not constrained to just the pauses in the existing dialogueue. Full descriptions are provided of all visual information, including visual context, actions and expressions of actors, and any other visual material. In addition, non-speech sounds (laughter, off-screen voices, etc.) are described, and transcripts of all dialogueue are included. The sequence of descriptions and dialogueue transcripts is the same as the sequence in the multimedia itself. As a result, the full multimedia text alternative can provide a much more complete representation of the multimedia content than audio description alone.

If there is any interaction as part of the multimedia presentation (e.g. "press now to answer the question") then the full multimedia text alternative would provide hyperlinks or whatever is needed to provide parallel functionality.

Techniques for Addressing Success Criterion 1.2.2

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.2.2 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Providing a sound track that includes audio description as the primary sound track

  2. Providing a sound track that includes audio description AND associating it with the multimedia content using a technology-specific technique (for a technology in your baseline)

  3. Providing audio description in its own sound track (future link) AND merging the description track with the original soundtrack of the multimedia content at runtime using a technology-specific technique (for a technology in your baseline)

  4. Providing a full multimedia text alternative including any interaction

Technology-Specific Techniques

SMIL 1.0 Techniques
SMIL 2.0 Techniques

Common Failures Identified by the Working Group

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

(No failures currently documented)

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

  • Providing audio descriptions in multiple languages in SMIL 1.0 (future link)

  • Providing audio descriptions in multiple languages in SMIL 2.0 (future link)

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

  • Full multimedia text alternative for a training video

    A company purchases a Training video for use by its employees and puts it on the companies intranet. The video involves explaining use of a new technology and has a person talking and showing things at the same time. Since there is no place to insert audio description of the visual demonstrations during gaps in dialogueue, the company provides a full multimedia text alternative that all employees, including those who cannot see the demonstrations, can use to better understand what is being presented.


How to Meet Success Criterion 1.2.3

1.2.3 Audio descriptions of video are provided for prerecorded multimedia. (Level 2)

Key Terms

audio description

narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone

Note 1: Audio descriptions of video provide information about actions, characters, scene changes, and on-screen text.

Note 2: In standard audio description, narration is added during existing pauses in dialogue. (See also Extended audio descriptions.)

multimedia

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

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 existing pauses in dialogueue, audio descriptions provide information about actions, characters, scene changes, and on-screen text that are important and are not described or spoken in the main sound track.

Techniques for Addressing Success Criterion 1.2.3

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.2.3 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Providing a sound track that includes audio description as the primary sound track

  2. Providing a sound track that includes audio description AND associating it with the multimedia content using a technology-specific technique (for a technology in your baseline)

  3. Providing audio description in its own sound track (future link) AND merging the description track with the original soundtrack of the multimedia content at runtime using a technology-specific technique (for a technology in your baseline)

Technology-Specific Techniques

SMIL 1.0 Techniques
SMIL 2.0 Techniques

Common Failures Identified by the Working Group

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

(No failures currently documented)

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

  • Providing audio descriptions in multiple languages in SMIL 1.0 (future link)

  • Providing audio descriptions in multiple languages in SMIL 2.0 (future link)

Benefits: How Success Criterion 1.2.3 helps people with disabilities

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

Examples of Success Criterion 1.2.3

  • 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.4

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

Key Terms

captions

text presented and synchronized with multimedia to provide not only the speech, but also sound effects and sometimes speaker identification

Note: In some countries, the term "subtitle" is used to refer to dialogue only and "captions" is used as the term for dialogue plus sounds and speaker identification. In other countries, subtitle (or its translation) is used to refer to both.

multimedia

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

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 dialogue, but also identify who is speaking and notate sound effects and other significant audio.

Techniques for Addressing Success Criterion 1.2.4

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.2.4 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Creating captions for live multimedia AND Providing open captions that are embedded directly in the video stream

  2. Creating captions for live multimedia AND Providing closed captions USING any of the technology specific techniques below (for a technology in your baseline)

  3. Creating captions for live multimedia AND Providing closed captions USING any readily available media format that has a video player that is free of charge and supports closed captioning

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

Common Failures Identified by the Working Group

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

(No failures currently documented)

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

(none currently documented)

Benefits: How Success Criterion 1.2.4 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.4

  • A Web cast

    A news organization provides a live, captioned Web cast.

Related resources

(none currently documented)

See How to Meet Success Criterion 1.2.1 .


How to Meet Success Criterion 1.2.5

1.2.5 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 independent languages that are 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 components

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.

Techniques for Addressing Success Criterion 1.2.5

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.2.5 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Common Failures Identified by the Working Group

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

(No failures currently documented)

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

(none currently documented)

Benefits: How Success Criterion 1.2.5 helps people with disabilities

  • People whose primary language is a sign language sometimes have limited reading ability. 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.5

  • 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 described in 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.6

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

Key Terms

extended audio descriptions

audio descriptions that are added to an audiovisual presentation by pausing the video so that there is time to add additional description

Note: 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 components

Intent of this success criterion

The intent of this success criterion is to provide people who are blind or visually impaired access to a multimedia presentation beyond that which can be provided by standard audio descriptions. This is done by periodically freezing the multimedia presentation and playing additional audio description. The multimedia presentation is then resumed.

Because it disrupts viewing for those who do not need the additional description, techniques that allow you to turn the feature on and off are often provided. Alternately, versions with and without the additional description can be provided.

Techniques for Addressing Success Criterion 1.2.6

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.2.6 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Creating an extended audio description for the multimedia content USING a technology-specific technique listed below (for a technology in your baseline).

Technology-Specific Techniques

SMIL 1.0 Techniques
  1. Providing audio descriptions in SMIL 1.0

SMIL 2.0 Techniques
  1. Adding extended audio descriptions in SMIL 2.0

Common Failures Identified by the Working Group

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

(No failures currently documented)

Additional Techniques (Advisory) for 1.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)

Additional SMIL 1.0 Techniques
  • Adding extended audio descriptions in multiple languages in SMIL 1.0 (future link)

Additional SMIL 2.0 Techniques
  • Adding extended audio descriptions in multiple languages in SMIL 2.0 (future link)

Benefits: How Success Criterion 1.2.6 helps people with disabilities

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

Examples of Success Criterion 1.2.6

  • Example 1. Video of a lecture. A physics professor is giving a lecture. He makes freehand sketches on the whiteboard, speaking rapidly as he draws. As soon as he has finished discussing one problem, he erases the drawing and makes another sketch while continuing to speak and gesture with his other hand. The video is paused between problems, and extended audio descriptions of the professor’s drawings and gestures are provided; the video is then resumed.


How to Meet Success Criterion 1.2.7

1.2.7 For prerecorded multimedia, a full multimedia text alternative including any interaction is provided. (Level 3)

Key Terms

full multimedia text alternative including any interaction

document including correctly sequenced descriptions of all visual settings, actions, and non-speech sounds combined with descriptive transcripts of all dialogue and a means of achieving any outcomes that are achieved using interaction during the multimedia

Note: A screenplay used to create the multimedia content would meet this definition only if it was corrected to accurately represent the final multimedia after editing.

Intent of this success criterion

The intent of this success criterion is 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 full multimedia text alternative including any interaction.

This approach involves providing all of the information in the multimedia (both visual and auditory) in text form. A full multimedia text alternative including any interaction provides a running description of all that is going on in the multimedia content. The full multimedia text alternative reads something like a book. Unlike audio descriptions, the descriptions of the video portion are not constrained to just the pauses in the existing dialogue. Full descriptions are provided of all visual information, including visual context, actions and expressions of actors, and any other visual material. In addition, non-speech sounds (laughter, off-screen voices, etc.) are described, and transcripts of all dialogue are included. The sequence of descriptions and dialogue transcripts is the same as the sequence in the multimedia itself. As a result, the full multimedia text alternative can provide a much more complete representation of the multimedia content than audio description alone.

If there is any interaction as part of the multimedia presentation (e.g. "press now to answer the question") then the full multimedia text alternative would provide hyperlinks or whatever is needed to provide parallel functionality.

Individuals whose vision is too poor to reliably read captions and whose hearing is too poor to reliably hear dialogue can access the full multimedia text alternative by using a refreshable braille display.

Techniques for Addressing Success Criterion 1.2.7

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.2.7 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Providing a full multimedia text alternative including any interaction USING one of the following techniques:

Technology-Specific Techniques

Linking to a full multimedia text alternative including any interaction in HTML

Common Failures Identified by the Working Group

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

(No failures currently documented)

Additional Techniques (Advisory) for 1.2.7

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)

General Techniques (Advisory)
  • Providing a corrected script (future link)

  • Adding detail to audio descriptions (future link)

Benefits: How Success Criterion 1.2.7 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.2.7

  • Example 1. Full multimedia text alternative for a training video

    A community center purchases a Training video for use by its clients and puts it on the center’s intranet. The video involves explaining use of a new technology and has a person talking and showing things at the same time. The community center provides a full multimedia text alternative that all clients, including those who can neither see the demonstrations nor hear the explanations in the multimedia, can use to better understand what is being presented.

Related resources

(none currently documented)


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

Intent of Guideline 1.3

The purpose of this guideline is to ensure that all information is available in a form that can be perceived by all users. If all of the information is available in a form that can be determined by software, then it can be presented to users in different ways (visually, audibly, tactilely etc.). If information is embedded in a particular presentation in such a way that the information cannot be separated from the presentation, then it cannot be rendered in other formats as needed by the user.

The success criteria under this guideline all seek to ensure that different types of information that are often encoded in presentation are also available so that they can be presented in other modalities.

Advisory Techniques for Guideline 1.3

Specific techniques for meeting each success criterion for this guideline are listed in the How to Meet sections for each success criterion (listed below). There are some techniques, however, for addressing this guideline that do not fall under any of the success criteria. These techniques are listed here. They are not required or sufficient for meeting any success criteria but these advisory techniques can make certain types of Web content more accessible to more people.


How to Meet Success Criterion 1.3.1

1.3.1 Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies. (Level 1)

Key Terms

presentation

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

programmatically determined

determined by software from data provided in a user-agent-supported manner such that the user agents can extract and present this information to users in different modalities

user agent

any software that retrieves and renders Web content for users

Example: Web browsers, media players, plug-ins, and other programs — including assistive technologies — that help in retrieving and rendering Web content.

Assistive technology (in the context of this document)

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.

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

Example: 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 definition is based on User Agent Accessibility Guidelines 1.0 Glossary.

Intent of this success criterion

The intent of this success criterion is to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes. For example, the presentation format changes when the content is read by a screen reader or when a user style sheet is substituted for the style sheet provided by the author.

Sighted users perceive structure through various visual cues — headings are often in a larger, bold font 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; a different background color may be used to indicate that several items are related to each other; and so on.

Auditory cues may be used as well. For example, a chime might indicate the beginning of a new section; a change in voice pitch or speech rate may be used to emphasize important information or to indicate quoted text; etc.

The purpose of this success criterion is to ensure that when such relationships are perceivable to one set of users, those relationships can be made to be perceivable to all.

Techniques for Addressing Success Criterion 1.3.1

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.3.1 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Making information and relationships conveyed through presentation programmatically determinable USING the technology-specific techniques below (for a technology in your baseline)

  2. Using semantic elements to mark up structure

Additional 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)

CSS Techniques
  • Using CSS styles to change or enhance the presentation of structure (future link)

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 or hearing disabilities and cognitive limitations. 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 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 assistive technology.

  • A text document

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


How to Meet Success Criterion 1.3.2

1.3.2 Any information that is conveyed by color is also visually evident without color. (Level 1)

Key Terms

information that is conveyed by color

information presented in a manner that depends entirely on the ability to perceive color

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.

Techniques for Addressing Success Criterion 1.3.2

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.3.2 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation A: If the color of particular words is used to indicate information.

  1. Ensuring that color encoded information is also available in text

  2. Including a text cue whenever color cues are used

Situation B: If color is used within an image to convey information.

  1. Using color and pattern (for example, colors on bar/pie charts with lines or texture fills)

  2. Ensuring that color encoded information is also available in text

Technology-Specific Techniques

Common Failures Identified by the Working Group

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

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

(none currently documented)

General Techniques
  • Conveying information redundantly using color (future link)

Client-side Scripting Techniques
  • Changing the background color or border of the element with focus (future link)

Benefits: How Success Criterion 1.3.2 helps people with disabilities

  • o This success criterion benefits people with visual disabilities:Users with partial sight often experience limited color vision.

  • Users who are blind (using a screen reader) benefit when information conveyed through color is also available in text (including text alternatives for images that use color to convey information).

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

  • Users who have color-blindness benefit when information conveyed by color is available in other visual ways.

  • Users with visual disabilities as well as limited hearing may be unable to access color-dependent information.

  • Users who are deaf-blind 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.

Examples of Success Criterion 1.3.2

  • A form that uses color and text to indicate 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 icon whose text alternative says, “Required.” . Both the red text and the icon 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

(none currently documented)


How to Meet Success Criterion 1.3.3

1.3.3 When the sequence of the content affects its meaning, that sequence can be programmatically determined. (Level 1)

Key Terms

programmatically determined

determined by software from data provided in a user-agent-supported manner such that the user agents can extract and present this information to users in different modalities

Intent of this success criterion

The intent of this success criterion is to enable a user agent to provide an alternative presentation of content while preserving the reading order needed to perceive meaning. It is important that it be possible to programmatically determine at least one sequence of the content that makes sense.

A sequence is meaningful if the order of content in the sequence cannot be changed without affecting its meaning. The order of words in sentences and sentences in paragraphs, for instance, is always meaningful. 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. In such a situation, the articles themselves may have meaningful sequence, but the container that contains the articles may not have a meaningful sequence.

The semantics of some elements define whether or not their content is a meaningful sequence. For instance, in HTML, text is always a meaningful sequence. Tables and ordered lists are meaningful sequences, but unordered lists are not.

Techniques for Addressing Success Criterion 1.3.3

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.3.3 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Ordering the content in a meaningful sequence for all the content in the Web unit

  2. Marking sequences in the content as meaningful USING technology-specific techniques (for a technology in your baseline) AND Ordering the content in a meaningful sequence for those sequences

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

(none currently documented)

HTML Techniques (Advisory)
  • Providing a link to linearized rendering (future link)

Client-Side Scripting Techniques
  • Providing a style switcher between style sheets that affect presentation order (future link)

Benefits: How Success Criterion 1.3.3 helps people with disabilities

  • This success criterion benefits users with visual, hearing, and cognitive limitations who 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.3

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

variations in presentations of text

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

programmatically determined

determined by software from data provided in a user-agent-supported manner such that the user agents can extract and present this information to users in different modalities

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.

In 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;

  • conveying information by raising characters (or words) above centerline in a line of text.

Techniques for Addressing Success Criterion 1.3.4

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.3.4 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Marking emphasized or special text USING technology-specific techniques (for a technology in your baseline)

  2. Using text to convey information that is conveyed by variations in presentation of text

Technology-Specific Techniques

HTML Techniques for Marking Text

Common Failures Identified by the Working Group

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

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

  • Ensure that numerals or other look alike glyphs are not used in place of letters (future link)

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

  1. use the correct character

    In English, the shapes of some characters, such as '0' (zero) and 'O' (o), or '1' (one) and 'l' (l), resemble one another. Languages such as Japanese and Chinese have many similar looking characters that are often mistakenly used for one another.

    In Japanese, for example, characters such as '' (Tyou-on), '' (Zenkaku dash), and '' (Zenkaku minus) all have similar appearances. Since the method of input for Japanese characters converts all of these characters from the same character '-', these characters are often misused in Japanese. The Japanese word "リード" is a correct word that means "lead" in English, while " リ―ド" is not a word at all. Sighted users do not notice this error, while users who use a screen reader cannot understand text containing such a substitution.


How to Meet Success Criterion 1.3.5

1.3.5 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 they cannot perceive shape or 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 limitations. 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.5

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.3.5 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Common Failures Identified by the Working Group

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

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

  • Using an image for "○"(circle mark) or "×"(cross mark) instead of text and providing alternative text for the image which describes the meaning of its mark (future link)

Benefits: How Success Criterion 1.3.5 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. 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.5


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

Intent of Guideline 1.4

While some guidelines are focused on making information available in a form that can be presented in alternate formats, this guideline is concerned with making the default presentation as usable as possible to people with disabilities. The primary focus is on making it easier for users to separate foreground information from the background. For visual presentations this involves making sure that information presented on top of a background contrasts sufficiently with the background. For audio presentations this involves making sure that foreground sounds are sufficiently louder than the background sounds. Individuals with visual and hearing disabilities have much greater difficulty separating foreground and background information.

Advisory Techniques for Guideline 1.4

Specific techniques for meeting each success criterion for this guideline are listed in the How to Meet sections for each success criterion (listed below). There are some techniques, however, for addressing this guideline that do not fall under any of the success criteria. These techniques are listed here. They are not required or sufficient for meeting any success criteria but these advisory techniques can make certain types of Web content more accessible to more people.


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 + 0.05) / (L2 + 0.05), where L1 is the luminosity of the lighter of the text or background colors, and L2 is the luminosity of the darker of the text or background colors.

Note 1: The luminosity of a color is defined as 0.2126 * ((R / FS) ^ 2.2) + 0.7152 * ((G / FS) ^ 2.2) + 0.0722 * ((B / FS) ^ 2.2).

  • R, G, and B are the red, green, and blue RGB values of the color.

  • FS is the maximum possible full scale RGB value for R, G, and B (255 for eight bit color channels).

  • The "^" character is the exponentiation operator.

Note 2: Luminosity values can range from 0 (black) to 1 (white), and luminosity contrast ratios can range from 1 to 21.

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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.4.1 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Ensuring that luminosity contrast of at least 5:1 exists between text and background behind the text

  2. Using a technology specific technique below (for a technology in the baseline)

Common Failures Identified by the Working Group

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

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

  • Using a higher contrast value for text that is over a patterned background (future link)

  • Creating foreground and background contrast (future link)

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

Techniques for Addressing Success Criterion 1.4.2

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.4.2 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Playing a sound that turns off automatically within three seconds

  2. Playing sounds only on user request (future link)

  3. Providing a control near the top of the Web unit that turns off sounds that play automatically (future link)

Common Failures Identified by the Working Group

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

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

  • Providing a sitewide preference to turn off audio in addition to providing a control near the top of the Web unit that turns off sounds that play automatically (future link)

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, the audio can be stopped by the user by selecting a "silent" link at the top of the page.

    An audio file begins playing automatically when a page is opened. However, the audio 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 + 0.05) / (L2 + 0.05), where L1 is the luminosity of the lighter of the text or background colors, and L2 is the luminosity of the darker of the text or background colors.

Note 1: The luminosity of a color is defined as 0.2126 * ((R / FS) ^ 2.2) + 0.7152 * ((G / FS) ^ 2.2) + 0.0722 * ((B / FS) ^ 2.2).

  • R, G, and B are the red, green, and blue RGB values of the color.

  • FS is the maximum possible full scale RGB value for R, G, and B (255 for eight bit color channels).

  • The "^" character is the exponentiation operator.

Note 2: Luminosity values can range from 0 (black) to 1 (white), and luminosity contrast ratios can range from 1 to 21.

Intent of this success criterion

The intent 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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.4.3 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Common Failures Identified by the Working Group

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

(No failures currently documented)

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

  • Using a higher contrast value for text that is over a patterned background (future link)

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 four times (4x) 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

The intent of this success criterion is to ensure that any non-speech sounds are low enough that a user who is hard of hearing can understand the speech. Individuals who are hard of hearing have difficulty separating speech from background sounds or other noise. A 20 decibel difference in sound level is roughly four 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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 1.4.4 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Common Failures Identified by the Working Group

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

(No failures currently documented)

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

  • Audio examples of 20db audio contrast between the foreground and background audio. (MP3 audio files) (future link)

  • Visual examples of 20db audio contrast between the foreground and background audio as might be seen in audio editing software packages. (JPG images) (future link)

  • Providing a way for users to adjust auditory levels of foreground and background sound independently. (future link)

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

Intent of Guideline 2.1

If all functionality can be achieved using the keyboard, then it can be accomplished by keyboard users, by speech input (which creates keyboard input), by mouse (using on screen keyboards), and by a wide variety of assistive technologies that create simulated keystrokes as their output. No other input form has this flexibility or is universally supported and operable by people with different disabilities, as long as the keyboard input is not time dependent.

Note that providing universal keyboard input does not mean that other types of input should not be supported. Optimized speech input, optimized mouse/pointer input, etc., are also good. The key is to provide keyboard input and control as well.

Some devices do not have native keyboards — for example, a PDA or cell phone. If these devices have a Web browsing capability, however, they will have some means of generating text or "keystrokes". This guideline uses the term "keyboard interface" to acknowledge that Web content should be controlled from keystrokes that may come from a keyboard, keyboard emulator, or other hardware or software that generates keyboard or text input.

Advisory Techniques for Guideline 2.1

Specific techniques for meeting each success criterion for this guideline are listed in the How to Meet sections for each success criterion (listed below). There are some techniques, however, for addressing this guideline that do not fall under any of the success criteria. These techniques are listed here. They are not required or sufficient for meeting any success criteria but these advisory techniques can make certain types of Web content more accessible to more people.

  • All advisory techniques for this guideline relate to specific success criteria and are listed below.

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 achievable through user action

keyboard interface

interface used by software to obtain keystroke input

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

Example: A touch screen PDA has a keyboard interface built into its operating system as well as a connector for external keyboards. Applications on the PDA can use the interface to obtain keyboard input either from 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 2: 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

input whose result is different depending on the rate of the analog movement (such as when line width varies with pen speed or pressure.)

Note: Most actions carried out by a pointing device can also be done from the keyboard (for example, clicking, selecting, moving, sizing). However, there is a small class of input that is done with a pointing device that cannot be done from the keyboard in any known fashion. This type of input can be best characterized by the fact that the outcome can only be achieved by moving the pointer in a smooth fashion at a certain rate. For example, in a watercolor program stroke width and opacity may depend on the rate of movement (and/or pressure) of a "brush".

Intent of this Success Criterion

The intent 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.

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. For example, a watercolor application where the stroke is defined by the movement and speed of movement and/or pressure is not something that can be controlled from a keyboard. Also, use of MouseKeys would not satisfy this success criterion because it is not a keyboard equivalent to the application; it is a mouse equivalent (i.e. it looks like a mouse to the application).

Note: This time dependence is not a time-out situation - so is not covered by 2.2.1.

Techniques for Addressing Success Criterion 2.1.1

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.1.1 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Ensuring that users are not trapped in content AND Providing keyboard-controllable event handlers USING a technology specific technique listed below (for a technology in your baseline)

Technology-Specific Techniques

Client-side Scripting Techniques

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

  • Providing keyboard access to important links and form controls (future link)

  • Using unique letter combinations to begin each item of a list (future link)

  • Choosing the most abstract event handler (future link)

  • Using the onactivate event (future link)

Benefits: How Success Criterion 2.1.1 helps people with disabilities

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

  • People with low vision (who may have trouble finding or 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: Moving between and connecting discrete points

    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.

  • Example 6: A PDA with an optional keyboard

    A PDA device that is usually operated via a stylus has an optional keyboard that can be attached. The keyboard allows full web browsing in standard fashion. The Web content is operable because it was designed to work with keyboard only access.


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 achievable through user action

keyboard interface

interface used by software to obtain keystroke input

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

Example: A touch screen PDA has a keyboard interface built into its operating system as well as a connector for external keyboards. Applications on the PDA can use the interface to obtain keyboard input either from 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 2: 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

The intent of this success criterion is to ensure that all content is operable from the keyboard.This is the same as success criterion 2.1.1, except that no exceptions are allowed. This does not mean that analog, time-dependent input (excluded from the requirements of 2.1.1) must be made keyboard accessible. Rather, it means that content that uses analog, time-dependent input cannot conform to this success criterion and therefore cannot meet Guideline 2.1 at Level 3.

Techniques for Addressing Success Criterion 2.1.2

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.1.2 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. No additional techniques exist for this success criterion. Follow techniques for success criterion 2.1.1. If that is not possible because there is a requirement for analog, time-dependent input, then it is not possible to meet this level 3 success criterion.


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

Intent of Guideline 2.2

Many users who have disabilities need more time to complete tasks than the majority of users: they may take longer to physically respond, they may take longer to read things, they may have low vision and take longer to find things or to read them, or they may be accessing content through an assistive technology that requires more time. This guideline focuses on ensuring that users are able to complete the tasks required by the content with their own individual response times. The primary approaches deal with eliminating time constraints or providing users enough additional time to allow them to complete their tasks. Exceptions are provided for those cases where this is not possible.

Advisory Techniques for Guideline 2.2

Specific techniques for meeting each success criterion for this guideline are listed in the How to Meet sections for each success criterion (listed below). There are some techniques, however, for addressing this guideline that do not fall under any of the success criteria. These techniques are listed here. They are not required or sufficient for meeting any success criteria but these advisory techniques can make certain types of Web content more accessible to more people.

  • All advisory techniques for this guideline relate to specific success criteria and are listed below.

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 that 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 ten 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.

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 ensure that users with disabilities are given adequate time to interact with Web content whenever possible. People with disabilities such as blindness, dexterity impairments, and cognitive limitations 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 tasks.

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.

Techniques for Addressing Success Criterion 2.2.1

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.2.1 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation A: If a time-out is controlled by a script on the page

  1. Providing a script that warns the user a time-out is about to expire AND Allowing the user to extend the default time-out

  2. Providing a way for the user to turn the time-out off (future link)

  3. Providing the user with a means to set the time-out to 10 times the default time-out (future link)

Common Failures Identified by the Working Group

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

Additional 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 time-out is present (future link)

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 limitations 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

  • A Website uses a client side timeout to help protect consumers who may step away from their computer. After a period of inactivity the Web unit asks if the user needs more time. If it doesn’t get a response – it times out.

  • A Web page has a field that automatically updates with the latest headlines in a rotating fashion. There is a slider that allows the user to slow the update rate by as much as 10.

Related resources

(none currently documented)


How to Meet Success Criterion 2.2.2

2.2.2 Content does not blink for more than three seconds, or a method is available to stop all blinking content in the Web unit or authored component. (Level 2)

Note: For requirements related to flickering or flashing content, refer to Allow users to avoid content that could cause seizures due to photosensitivity: .

blink

turn on and off between 0.5 and 3 times per second

Web unit

a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Note: This definition is based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.

Example 1: An interactive movie-like shopping environment where the user navigates about and activates products to have them demonstrated, and moves them to a cart to buy them.

Example 2: A Web page including all embedded images and media.

authored component

an authored unit intended to be used as a part of another authored unit

The intent of this success criterion is to avoid distracting users during their interaction with a Web 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 Web unit. Three seconds was chosen because it is long enough to get a user's attention, but not so long that a user can not wait it out if necessary in order to use the page and the blinking blocks their ability to focus on the page.

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.2.2 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Creating content that blinks for less than 3 seconds OR

  2. Using a control in the Web unit that stops blinking content (future link) USING a technology-specific technique below (for a technology in your baseline) OR

  3. Using a technology to include blinking content that can be turned off via the user agent (future link)

  • Setting animated gif images to stop blinking after n cycles (within 3 seconds) (future link)

Script Techniques

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 Web unit (future link)

  • Providing the user with a means to stop moving content even if it stops automatically within 3 seconds (future link)

  • Providing content that stops blinking after three seconds or providing a mechanism for users to stop blinking content allows people with certain disabilities to interact with the Web unit.

  • 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 make it difficult or even impossible to interact with the rest of the Web 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.

(none currently documented)


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

paused

stopped by user request and not restarted until requested by user

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 provide an 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 a preset time interval. Common time-based content includes audio, automatically updated weather information, news, stock price updates, and auto-advancing presentations and messages.

Techniques for Addressing Success Criterion 2.2.3

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.2.3 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Technology-Specific Techniques

Script Techniques
  • Using script to scroll content, and provide a mechanism to pause it (future link)

Common Failures Identified by the Working Group

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

Additional 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 limitations, 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 users 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 updated during the pause will not be displayed.

  • 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 of an auction because of the nature of the activity. Instead, the user is allowed to prepare a bid and hold it - so that a single keystroke submits it.

Related resources

(none currently documented)


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 event

event that a) occurs at the same time as the viewing, b) is not completely generated by the content, and c) is not pre-recorded

Example 1: A Webcast of a live performance.

Example 2: An on-line auction with people bidding.

Example 3: Live humans interacting in a fantasy world using avatars.

Intent of this success criterion

The intent of this success criterion is to minimize the occurrence of content that requires timed interaction. This enables people with blindness, low vision, cognitive limitations, 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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.2.4 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Common Failures Identified by the Working Group

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

(No failures currently documented)

Additional 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 limitations 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

    Rather than calibrating an on-line test using a time limit, the test is calibrated based on scores when users have no time limits.

  • 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

(none currently documented)


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 warn of danger to health, safety, or property, including data loss, loss of connection, etcetera.

This allows access by people with cognitive limitations or attention disorders 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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.2.5 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Providing a mechanism to postpone any updating of content OR

  2. Allowing users to request updates instead of automatically updating content (future link)

Technology-Specific Techniques

Client-side Scripting Techniques

Common Failures Identified by the Working Group

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

Additional 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

  • Example 1. Setting user preferences

    The preferences page of a Web portal includes an option to postpone all updates and alerts until the end of the current session, except for alerts concerning emergencies.

Related resources

(none currently documented)


How to Meet Success Criterion 2.2.6

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

Intent of this success criterion

The intent of this success criterion 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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.2.6 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Providing options to continue without loss of data using a technology-specific technique listed below (for a technology in your baseline)

Technology-Specific Techniques

Server-Side Techniques

Common Failures Identified by the Working Group

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

Additional 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 limitations may read slowly and require additional 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 with extremely limited use of the hands is logged into a shopping site. It takes so long to enter credit card information into the application that a time-out occurs wile the user is performing the checkout process. 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 Web 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 Web 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

(none currently documented)


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

Intent of Guideline 2.3

Some people with seizure disorders can have a seizure triggered by flashing visual content. Most people are unaware that they have this disorder until it strikes. In 1997, a cartoon on television in Japan sent over 700 children to the hospital, including about 500 who had seizures [EPFND]. Warnings do not work well because they are often missed, especially by children who may in fact not be able to read them.

The objective of this guideline is to ensure that content that is marked as conformant to WCAG 2.0 avoids the types of flash that are most likely to cause seizure when viewed even for a second or two.

Advisory Techniques for Guideline 2.3

Specific techniques for meeting each success criterion for this guideline are listed in the How to Meet sections for each success criterion (listed below). There are some techniques, however, for addressing this guideline that do not fall under any of the success criteria. These techniques are listed here. They are not required or sufficient for meeting any success criteria but these advisory techniques can make certain types of Web content more accessible to more people.


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 all three of the following occur:

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

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

    3. the flashing is below 50 Hz.

Note 1: 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 0.2126 * ((R / FS) ^ 2.2) + 0.7152 * ((G / FS) ^ 2.2) + 0.0722 * ((B / FS) ^ 2.2). R, G, and B are the red, green, and blue RGB values of the color; FS is the maximum possible full scale RGB value for R, G, and B (255 for eight bit color channels); and the "^" character is the exponentiation operator. An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase. This applies only when the brightness of the darker image is below .80 of full scale white brightness.

Note 2: Based on Wisconsin Computer Equivalence Algorithm for Flash Pattern Analysis (FPA)

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

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

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

    3. The flashing is below 50 Hz.

Intent of this success criterion

The intent 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 the broadcasting industry as adapted for computer screens, where content is viewed from a closer distance (using a 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 resolution for the evaluation. The 341 x 256 pixel block represents a 10 degree viewport at a typical viewing distance. (The 10 degree field is taken from the original specifications and represents the central vision portion of the eye, where people are 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 all of the areas of the individual flashes within any 341 x 256 pixel viewport that are occurring at the same time.

Techniques for Addressing Success Criterion 2.3.1

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.3.1 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Common Failures Identified by the Working Group

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

(No failures currently documented)

Additional 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 any flashing content (future link)

  • Avoiding fully saturated reds for any flashing content (future link)

  • Reducing the number of flashes even if they do not violate thresholds (future link)

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 having a seizure and without having to miss the full experience of the content by being limited to text alternatives. This includes people 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 two times.


How to Meet Success Criterion 2.3.2

2.3.2 Web units do not contain any components that flash more than three times in any 1-second period. (Level 3)

Key Terms

Web unit

a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Note: This definition is based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.

Example 1: An interactive movie-like shopping environment where the user navigates about and activates products to have them demonstrated, and moves them to a cart to buy them.

Example 2: A Web page including all embedded images and media.

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.

Success criterion 2.3.1 requires that flashing content be less than three flashes in any 1-second period unless it is smaller than 40% of a 341 x 256 pixel area (on a 1024 x 768 screen). This would keep the stimuli to less than 40% of a person's central vision for a typical screen. However, some users access Web content through screen enlargers. For these people, the area described in section 2.3.1 would (when magnified) be more than 40% of a persons central vision.

This success criterion eliminates all flashing components that flash more than three times in any 1-second period. In this fashion, magnification at any level would not yield content that would fail the general flash or red flash thresholds.

Techniques for Addressing Success Criterion 2.3.2

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.3.2 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Common Failures Identified by the Working Group

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

(No failures currently documented)

Additional Techniques (Advisory) for 2.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.

  • Reducing contrast for any flashing content (future link)

  • Avoiding fully saturated reds for any flashing content (future link)

  • Reducing the number of flashes even if they don't violate thresholds (future link)

Benefits: How Success Criterion 2.3.2 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 having a seizure and without having to miss the full experience of the content by being limited to text alternatives. This includes people with photosensitive epilepsy as well as other photosensitive seizure disorders.

Examples of Success Criterion 2.3.2

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


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

Intent of Guideline 2.4

The intent of this guideline is to help users find the content they need and allow them to keep track of their location. These tasks are often more difficult for people with disabilities. For finding, navigation, and orientation, it is important that the user can find out what the current location is. For navigation, information about the possible destinations needs to be available. Screen readers convert content to synthetic speech which, because it is audio, must be presented in linear order. Some success criteria in this guideline explain what provisions need to be taken to ensure that screen reader users can successfully navigate the content. Others allow users to more easily recognize navigation bars and page headers and to bypass this repeated content.

This guideline works closely with guideline 1.3, which ensures that any structure in the content can be perceived, a key to navigation as well.

Advisory Techniques for Guideline 2.4

Specific techniques for meeting each success criterion for this guideline are listed in the How to Meet sections for each success criterion (listed below). There are some techniques, however, for addressing this guideline that do not fall under any of the success criteria. These techniques are listed here. They are not required or sufficient for meeting any success criteria but these advisory techniques can make certain types of Web content more accessible to more people.


How to Meet Success Criterion 2.4.1

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

Web unit

a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Note: This definition is based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.

Example 1: An interactive movie-like shopping environment where the user navigates about and activates products to have them demonstrated, and moves them to a cart to buy them.

Example 2: A Web page including all embedded images and media.

The intent of this success criterion is to allow people who navigate sequentially through content more direct access to the primary content of the Web 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.

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.4.1 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Grouping blocks of repeated material in a way that can be skipped USING one of the technology-specific techniques below (for a technology in your baseline)

  2. Creating links to skip blocks of repeated material USING one of the following techniques:

HTML Techniques for creating links to skip blocks
  • Creating HTML links to skip blocks of content (future link)

HTML Techniques for grouping blocks of repeated material

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

(No failures currently documented)

Additional Techniques (Advisory) for 2.4.1
  • Providing keyboard access to important links and form controls (future link)

  • Providing skip links to enhance page navigation (future link)

HTML Techniques for keyboard access
  • Providing access keys (future link)

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 can avoid having 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 can reach content with fewer keystrokes. Otherwise, they 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 do not have to search through the same headings or other blocks of information to find where the content begins each time they enter a new page.

  • People with cognitive limitations as well as people who use screen readers may benefit when links are grouped into lists

  • A news organization's home page contains a main story in the middle of the page, surrounded by many blocks and sidebars for advertising, searching, and other services. There is 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.

(none currently documented)


How to Meet Success Criterion 2.4.2

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

Web unit

a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Note: This definition is based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.

Example 1: An interactive movie-like shopping environment where the user navigates about and activates products to have them demonstrated, and moves them to a cart to buy them.

Example 2: A Web page including all embedded images and media.

The intent 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.

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.4.2 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Choose two or more of the following:

  1. Providing links to navigate to related Web units

  2. Providing a Table of Contents

  3. Providing a Site Map

  4. Providing a search engine to help users find content (future link)

  5. Providing a list of links to all other Web units

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

(No failures currently documented)

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. Users 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 Web units. Some users may prefer to explore the site in a sequential manner, moving from Web unit to Web unit in order to best understand the concepts and layout.

  • Individuals with cognitive limitations may find it easier to use search features than to attempt to use a hierarchical navigation scheme that be difficult to understand.

  • 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 Web units

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

(none currently documented)


How to Meet Success Criterion 2.4.3

2.4.3 Web units have titles. (Level 2)

Web unit

a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Note: This definition is based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.

Example 1: An interactive movie-like shopping environment where the user navigates about and activates products to have them demonstrated, and moves them to a cart to buy them.

Example 2: A Web page including all embedded images and media.

The intent of this success criterion is to help users find content and orient themselves within it by ensuring that each Web unit has a title. 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.

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.4.3 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Associating a title with a Web page USING a technology-specific technique below (for a technology in your baseline)

HTML Techniques

The following are common mistakes that are considered failures of success criterion 2.4.3 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
  • Providing a meaningful name for identifying frames (future link).

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.

  • A document.

    The title of Web Content Accessibility Guidelines 2.0 is "Web Content Accessibility Guidelines 2.0."

    • The introduction has the title "Introduction to Web Content Accessibility Guidelines 2.0"

    • The main body has the title "WCAG 2.0 Guidelines"

    • Appendix A has the title "Glossary to Web Content Accessibility Guidelines 2.0"

    • Appendix B has the title "Checklist for Web Content Accessibility Guidelines 2.0"

    • Appendix C has the title "Acknowledgements for Web Content Accessibility Guidelines 2.0"

    • Appendix D has the title "Mapping of WCAG 1.0 checkpoints to WCAG 2.0"

    • Appendix E has the title "References for Web Content Accessibility Guidelines 2.0"

  • An audio file

    A podcast is associated with the title "Today's Tech Tips" by setting the id3 property of the .mp3 file.

  • A video clip

    A video clip is associated with a title using the meta element in SMIL 1.0 or SMIL 2.0, plus the title attribute of the main par element in the SMIL file.

  • An image

    A .JPEG image is associated with a title using EXIF metadata stored in the image file. (Note: Current user agents do not read this metadata.)


How to Meet Success Criterion 2.4.4

2.4.4 Each link is programmatically associated with text from which its purpose can be determined. (Level 2)

The intent of this success criterion is to help users understand the purpose of each link in the content, so they can decide whether they want to follow the link. Links with the same purpose and destination are associated with the same description (per success criterion 3.2.4), but links with different purposes and destinations are associated with different descriptions. A good description on a link improves orientation by helping users understand the link's purpose and whether they want to follow it.

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.4.4 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Providing link text that describes the purpose of a link

  2. Providing a supplemental description of the purpose of a link USING a technology-specific technique below (for a technology in your baseline)

  3. Identifying the purpose of a link using link text combined with link context USING a technology-specific technique below (for a technology in your baseline)

HTML Techniques for providing link text
HTML Techniques for supplementing link text
HTML Techniques for supplementing link text with the link context
CSS Techniques for supplementing link text

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

(No failures currently documented)

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 links 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 limitations 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 when 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!"

  • 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.5

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

label

text, image, or sound that is presented to a user to identify a component within Web content

The intent of this success criterion is to help users understand what information is contained in Web 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. Descriptive labels help users identify specific components within the content.

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.4.5 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Providing descriptive titles for Web units

  2. Providing descriptive headings

  3. Providing descriptive labels

Note: Titles, headings, and labels must be programmatically determined, per success criterion 1.3.1.

HTML Techniques

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

(No failures currently documented)

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 unique section headings in a Web Page (future link)

  • Starting section headings with unique information (future link)

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 Web site contains 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. The title of each Web unit clearly identifies the article it contains, creating a useful balance between the uniqueness of the articles and the consistency of the section headings.


How to Meet Success Criterion 2.4.6

2.4.6 When a Web unit or authored component is navigated sequentially, components receive focus in an order that follows relationships and sequences in the content. (Level 3)

Web unit

a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Note: This definition is based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.

Example 1: An interactive movie-like shopping environment where the user navigates about and activates products to have them demonstrated, and moves them to a cart to buy them.

Example 2: A Web page including all embedded images and media.

authored component

an authored unit intended to be used as a part of another authored unit

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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.4.6 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Placing the interactive elements in an order that follows sequences and relationships within the content

  2. Giving focus to elements in an order that follows sequences and relationships within the content USING a technology-specific technique below (for a technology in your baseline)

HTML Techniques

The following are common mistakes that are considered failures of success criterion 2.4.6 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.

(none currently documented)

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.

(none currently documented)


How to Meet Success Criterion 2.4.7

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

Web unit

a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Note: This definition is based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.

Example 1: An interactive movie-like shopping environment where the user navigates about and activates products to have them demonstrated, and moves them to a cart to buy them.

Example 2: A Web page including all embedded images and media.

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.

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.4.7 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Providing a breadcrumb trail

  2. Providing a Site Map

  3. Identifying a Web unit's relationship to a larger collection of Web units USING a technology-specific technique (for a technology in your baseline)

  4. Indicating current location within navigation bars

HTML techniques for document collection relationships

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

(No failures currently documented)

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 link to the home page or main page (future link)

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 hierarchy of categories. Each page also contains a link to the Directory Home.


How to Meet Success Criterion 2.4.8

2.4.8 The purpose of each link can be programmatically determined from the link. (Level 3)

programmatically determined

determined by software from data provided in a user-agent-supported manner such that the user agents can extract and present this information to users in different modalities

The intent of this success criterion is to help users understand the purpose of each link in the content, so they can decide whether they want to follow it. Links with the same purpose have the same description (per success criterion 3.2.4), but links with different purposes have different descriptions. Because the purpose of a link can be programmatically determined, it can be made available by the user agent when the link is out of context, such as when the user agent provides a list of all the links on a page.

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.4.8 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Providing link text that describes the purpose of a link.

  2. Providing a supplemental description of the purpose of a link USING a technology-specific technique below (for a technology in your baseline).

HTML Techniques for providing link text
HTML Techniques for supplementing link text
CSS Techniques for supplementing link text

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

(No failures currently documented)

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 web 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 limitations 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 target of the links are described.

  • 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). The title of the book is followed by links to the different formats. The rendered text for each link is just the format type, but the text associated with each link includes the title as well as the format, for instance, "Gulliver's Travels, MP3."


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

Intent of Guideline 2.5

Everyone makes mistakes. However, people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for them to detect that they have made an error. Typical error indication methods may not be obvious to them because of a limited field of view, limited color perception, or use of assistive technology. This guideline seeks to reduce the number of serious or irreversible errors that are made, increase the likelihood that all errors will be detected, and help users understand what they should do to correct an error.

Advisory Techniques for Guideline 2.5

Specific techniques for meeting each success criterion for this guideline are listed in the How to Meet sections for each success criterion (listed below). There are some techniques, however, for addressing this guideline that do not fall under any of the success criteria. These techniques are listed here. They are not required or sufficient for meeting any success criteria but these advisory techniques can make certain types of Web content more accessible to more people.

  • All advisory techniques for this guideline relate to specific success criteria and are listed below.

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

information provided by the user that is not accepted

Note: This includes:

  1. Information that is required by the Web 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, re-displaying 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 is not functional.

Techniques for Addressing Success Criterion 2.5.1

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.5.1 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

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

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

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

  1. Providing a text message when user input falls outside the required format or values

Technology-Specific Techniques

Script Techniques

Common Failures Identified by the Working Group

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

(No failures currently documented)

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

  • Validating form submissions on the server (future link)

  • Re-displaying a form with a summary of errors (future link)

  • Providing error notification as the user enters information (future link)

  • Assisting the user in making corrections by providing links to each error (future link)

  • Highlighting or visually emphasizing errors where they occur (future link)

  • Supplementing text with non-text content when reporting errors (future link)

Benefits: How Success Criterion 2.5.1 helps people with disabilities

Providing information about input errors in text allows users who are blind or colorblind 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.

  • Providing multiple cues

    The user fails to fill in two fields on the form. In addition to describing the error and providing a unique character to make it easy to search for the fields, the fields are highlighted in yellow to make it easy to visually search for them as well.

Related resources

(none currently documented)


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

information provided by the user that is not accepted

Note: This includes:

  1. Information that is required by the Web 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 limitations 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 even though they are aware that it has occurred.

Techniques for Addressing Success Criterion 2.5.2

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.5.2 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation A: If a mandatory field contains no information:

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

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

  1. Providing a text message when user input falls outside the required format or values

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

  1. Providing a text message when the user provides information that is not in list of allowed values

Common Failures Identified by the Working Group

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

(No failures currently documented)

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

  • Making error messages easy to understand and distinguishable from other text in the Web unit (future link)

  • Validating form submissions on the server (future link)

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

  • Repeating and emphasizing suggestions for correcting each input error in the context of its form field (future link)

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

  • Providing additional contextual help for the form field requiring change (future link)

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 (future link)

  • 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 (future link)

  • Displaying errors and suggestions in the context of the original form (for example, re-displaying a form where input errors and suggestions for correction are highlighted and displayed in the context of the original form) (future link)

HTML Techniques
  • Providing "correct examples" for data and data formats as initial text in mandatory form fields (future link)

  • Providing links to suggested correction text "close to" form fields, or providing the suggested correction text itself directly on the Web unit "next to" form fields (future link)

Client-Side Scripting Techniques
  • Providing client-side validation and alert

  • Providing client-side validation and adding error text via the DOM (future link)

  • Calling a function from the submit action of a form to perform client side validation (future link)

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.

    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

(none currently documented)


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

information provided by the user that is not accepted

Note: This includes:

  1. Information that is required by the Web 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 when performing an action that cannot be reversed. 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 cannot 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 involve transactions that take place immediately and cannot be altered afterwards, and can be very costly. Likewise, it may be an unrecoverable error if users unintentionally modify or delete data stored in a database that they later need to access, such as their travel profile in a travel services Web site. Test data is included in this provision because, in order for tests to be valid, users are not allowed to modify their answers once submitted; so users need to be able to ensure that their submission is correct.

Users with disabilities may be more likely to make mistakes. People with reading 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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.5.3 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

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

  1. Providing a period of time after submission of the form when the order can be updated or cancelled by the user (future link) OR

  2. Providing the ability for the user to review and correct answers before submitting

Situation B: If an action causes information to be deleted:

  1. Providing the ability to recover deleted information OR

  2. Providing a message to the user asking him or her to confirm that he or she really does want to delete the information (future link) OR

  3. Requiring a user to select a checkbox before a control that would cause a deletion to occur can be submitted (future link)

Situation C: If the Web unit includes a testing application:

  1. Providing the ability for the user to review and correct answers before submitting OR

  2. Asking for confirmation before final submission (future link)

Common Failures Identified by the Working Group

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

(No failures currently documented)

Additional 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 (future link)

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 so that the user can inspect the order for correctness. The user can either confirm the order or make changes.

Related resources

(none currently documented)


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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 2.5.4 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation A: If a form requires text input:

  1. Providing a help link on every Web unit OR

  2. Providing help bubbles (future link) OR

  3. Providing help by an assistant in the Web unit (future link) OR

  4. Providing spell checking and suggestions for text input if applicable to the language (future link)

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

  1. Providing expected data format and example

Common Failures Identified by the Working Group

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

(No failures currently documented)

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

  • Checking byte of character and auto-converting to expected byte for text input if applicable (future link)

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

(none currently documented)


Understanding Guideline 3.1: Make text content readable and understandable.

Intent of Guideline 3.1

The intent of this guideline is to allow text content to be read by users and by assistive technology, and to ensure that information necessary for understanding is available.

People with disabilities experience text in many different ways. For some the experience is visual; for some it is auditory; for some it is tactile; for still others it is both visual and auditory. Some users experience great difficulty in recognizing written words, yet understand extremely complex and sophisticated documents when the text is read aloud, or when key processes and ideas are illustrated visually or interpreted as Sign language. For some users, it is difficult to infer the meaning of a word or phrase from context, especially when the word or phrase is used in an unusual way or has been given specialized meaning; for these users, the ability to read and understand may depend on the availability of specific definitions or the expanded forms of acronyms or abbreviations. User agents, including speech-enabled as well as graphical applications, may be unable to present text correctly unless the language and direction of the text are identified; while these may be minor problems for most users, they can be enormous barriers for users with disabilities. In cases where meaning cannot be determined without pronunciation information (certain Japanese kanji, for example), pronunciation information must be available as well

Advisory Techniques for Guideline 3.1

Specific techniques for meeting each success criterion for this guideline are listed in the How to Meet sections for each success criterion (listed below). There are some techniques, however, for addressing this guideline that do not fall under any of the success criteria. These techniques are listed here. They are not required or sufficient for meeting any success criteria but these advisory techniques can make certain types of Web content more accessible to more people.

  • All advisory techniques for this guideline relate to specific success criteria and are listed below.

How to Meet Success Criterion 3.1.1

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

Key Terms

natural languages

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

Note: See also sign language interpretation.

Web unit

a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Note: This definition is based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.

Example 1: An interactive movie-like shopping environment where the user navigates about and activates products to have them demonstrated, and moves them to a cart to buy them.

Example 2: A Web page including all embedded images and media.

programmatically determined

determined by software from data provided in a user-agent-supported manner such that the user agents can extract and present this information to users in different modalities

Intent of this Success Criterion

The intent of this success criterion is to ensure that content developers provide information in the Web 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 Web 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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 3.1.1 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

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

  1. Identifying primary natural language(s) USING a technology-specific technique listed below (for a technology in your baseline)

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

  1. Identifying primary natural language(s) USING a technology-specific technique listed below AND Identifying the primary text direction USING a technology-specific technique listed below (for a technology in your baseline)

Technology-Specific Techniques

Identifying primary natural language(s) in HTML
Identifying text direction in HTML

Common Failures Identified by the Working Group

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

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

  • Specifying the primary language in the HTTP header (future link)

Additional HTML Techniques (Advisory)
  • using dc:lang in the meta element to specify language or multiple languages (future link)

  • using http or the Content-Language meta tag for metadata (future link)

Additional CSS Techniques (Advisory)
  • Specifying the direction of text (future link)

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 reading disabilities and cognitive limitations that make it difficult to recognize (decode) individual words and sentences;

  • people who rely on captions for multimedia.

Examples of Success Criterion 3.1.1

  • Example 1. A Web unit with content in two languages

    A Web unit produced in Germany includes content in both German and English, but most of the content is in German. The primary natural language is identified as German (de).

  • Example 2. A Web unit whose primary natural language is written right-to-left

    All of the content in a Web unit is written in Hebrew. The primary language is identified as Hebrew (he) and the direction is identified as right-to-left.

Related resources

(none currently documented)


How to Meet Success Criterion 3.1.2

3.1.2 The natural language of each passage or phrase in the Web unit 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

Web unit

a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Note: This definition is based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.

Example 1: An interactive movie-like shopping environment where the user navigates about and activates products to have them demonstrated, and moves them to a cart to buy them.

Example 2: A Web page including all embedded images and media.

programmatically determined

determined by software from data provided in a user-agent-supported manner such that the user agents can extract and present this information to users in different modalities

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 Web 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 Web 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 Web 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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 3.1.2 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

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

  1. Identifying changes in natural languages USING a technology-specific technique listed below (for a technology in your baseline)

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

  1. Identifying changes in natural languages USING a technology-specific technique listed below AND Identifying text direction of passages and phrases USING a technology-specific technique listed below (for a technology in your baseline)

Common Failures Identified by the Working Group

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

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

  • Making text that is not in the primary natural language of the Web unit visually distinct (future link)

  • Giving the names of any languages used in foreign passages or phrases (future link)

Additional HTML Techniques (Advisory)
  • Marking individual words, especially when they are links to versions in other languages (Deutsch, Français, Nederlands, Castellano, ...) (future link)

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 or phrases used in an unusual or restricted way, including idioms and jargon. (Level 3)

Key Terms

mechanism

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

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.

idioms

phrase whose meaning cannot be deduced from the meaning of the individual words and the specific words cannot be changed without losing the meaning

Example 1: In English, "kicking the bucket" means "dying". But the phrase cannot be changed to "kicking the buckets" or "kicking the tub" or "booting the bucket" or "knocking over the bucket" without losing its meaning.

Example 2: In English, "spilling the beans" means "revealing a secret." However, "knocking over the beans" or "spilling the vegetables" does not mean the same thing."

Example 3: In Japanese, the phrase "さじを投げる(どうするこ ともできなくなり、あきらめること" literally translates into "he threw a spoon". But it means that there was nothing he could do and finally he gave up.

Example 4: In Dutch, "Hij ging met de kippen op stok" literally translates into "He went to roost with the chickens". But it means that he went to bed early.

jargon

words used in a particular way by people in a particular field

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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 3.1.3 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation A: If the word or phrase has a unique meaning within the authored component:

  1. Providing the definition of a word or phrase used in an unusual or restricted way for the first occurrence of the word or phrase in an authored component USING one of the following techniques:

  2. Providing the definition of a word or phrase used in an unusual or restricted way for each occurrence of the word or phrase in an authored component USING one of the following techniques:

    • Linking to definitions

    • Providing a Glossary

    • Providing a function to search an on-line dictionary (future link)

    • Using a dictionary cascade (future link)

    • USING a technology-specific technique below (for a technology in your baseline)

Situation B: If the word or phrase means different things within the same authored component:

  1. Providing the definition of a word or phrase used in an unusual or restricted way for each occurrence of the word or phrase in an authored component using one of the following techniques:

Technology-Specific Techniques

HTML Techniques for Providing Inline Definitions
HTML Techniques for Providing a Glossary

Common Failures Identified by the Working Group

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

(No failures currently documented)

Additional Techniques (Advisory) for 3.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.

  • Using the title attribute to provide explanations of words or phrases (future link)

  • Using markup and visual formatting to help users recognize words that have special meaning (future link)

  • Providing a voice-enabled dictionary search, so that users who have difficulty typing or spelling can speak the word whose definition they need (future link)

  • Providing a sign language dictionary to help users who are deaf find the necessary definitions (future link)

  • Providing a mechanism for finding definitions for all words in text content (future link)

  • Providing a mechanism to determine the meaning of each word or phrase in text content (future link)

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 limitationss. 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 Web 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

Note: Includes 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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 3.1.4 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation A: If the abbreviation has a unique meaning within the authored component:

  1. Providing the expansion or explanation of an abbreviation for the first occurrence of the abbreviation in an authored component USING one of the following techniques:

  2. Providing the expansion or explanation of an abbreviation for all occurrences of the abbreviation in an authored component using one of the following techniques:

    • Linking to definitions

    • Providing a Glossary

    • Providing a function to search an on-line dictionary (future link)

    • Using a dictionary cascade (future link)

    • Using a technology-specific technique below (for a technology in your baseline)

Situation B: If the abbreviation means different things within the same authored component:

  1. Providing the expansion or explanation of an abbreviation for all occurrences of abbreviations in an authored component using one of the following techniques:

Common Failures Identified by the Working Group

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

(No failures currently documented)

Additional Techniques (Advisory) for 3.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.

  • Using the title attribute to provide explanations of words or phrases (future link)

  • Using unique abbreviations in an authored component (future link)

  • Using visual formatting to help users recognize abbreviations (future link)

  • Providing access to a talking dictionary, to support users who might have difficulty decoding written definitions (future link)

  • Providing a voice-enabled dictionary search, so that users who have difficulty typing or spelling can speak the word whose definition they need (future link)

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, supplemental content is available that does not require reading ability more advanced than the lower secondary education level. (Level 3)

Key Terms

Lower secondary education level

the two or three year period of education that begins after completion of six years of school and ends nine years after the beginning of primary education.

Note: This definition is based on [UNESCO].

supplemental content

additional content, which users may use in addition to or instead of the default content, that illustrates or clarifies the default content

Example: Examples of supplemental content may include text, images 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], 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.

Reading disabilities such as dyslexia make it difficult to recognize written or printed words and associate them with the correct sounds. This is called "decoding" the text. Text that uses short, common words and short sentences is easier to decode and usually requires less advanced reading ability than text that uses long sentences and long or unfamiliar words.

The education level required to read text content (also called "readability") is measured by analyzing selected passages of text from the Web unit. If the Web unit includes text written for different purposes or different styles are used, the selected passages include samples of the types of content in the Web unit and the different styles in which the content is written. (In many cases, the Web unit contains only one kind of text content — e.g., technical documentation, a legal notice, marketing material, etc. — and all the content uses the same style.)

Educators can also measure the education level required to read text content. For example, qualified teachers can evaluate text according to local education standards to determine if it requires reading ability beyond what is expected for students in the last year of lower secondary education.

The readability of content may also be determined by applying a readability formula to the selected passage. Many (though not all) readability formulas base their calculations on passages of 100 words. Such formulas have been developed for many languages. The number of words in the passage is counted, and the length of the words is determined by counting either the number of syllables or the number of characters. Most readability formulas also count the number and length of sentences. The average length of words and sentences in the content is then used to calculate a readability score. (Some languages, such as Japanese, may include multiple scripts within the same passage. Readability formulas for these languages may use the number and length of such "runs" in their calculations.) The result may be presented as a number (for example, on a scale from 0-100) or as a grade level. These results can then be interpreted using the education levels described in the International Standard Classification of Education.

Levels of education
Primary education Lower secondary education Upper secondary education Advanced education
First 6 years of school 7-9 years of school 10-12 years of school More than 12 years of school

Adapted from International Standard Classification of Education [UNESCO]

Techniques for Addressing Success Criterion 3.1.5

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 3.1.5 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Providing a text summary that requires reading ability less advanced than the upper secondary education level

  2. Providing visual illustrations of complex ideas, events, and processes

  3. Providing a spoken version of the text

  4. Making the text easier to read (future link)

  5. Providing sign language versions of information, ideas, and processes that must be understood in order to use the content (future link)

Note: Different sites may address this success criterion in different ways. An audio version of the content may be helpful to some users. But if a site is intended for individuals who are deaf, providing an audio file would not be useful. For sites designed for people who are deaf a sign language version of the page may be most useful for users who cannot understand the text well. Some sites may decide to do both or other combinations. No technique will help all users who have difficulty. So different techniques are provided as sufficient techniques here for authors trying to make their sites more accessible. Any numbered technique or combination above can be used by a particular site and it is considered sufficient by the working group.

Common Failures Identified by the Working Group

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

(No failures currently documented)

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

(none currently documented)

Additional technology-independent techniques
  • Providing text for navigational and landing pages that requires reading ability that is less advanced than the lower secondary education level (future link)

  • Providing text for interior pages that requires reading ability at the lower secondary education level (future link)

  • Including content summaries in metadata (future link)

Additional technology-specific techniques
  • Using the Dublin Core accessibility element to associate text content with text, graphical, or spoken supplements (future link)

  • Using RDF to associate supplements with primary content (future link)

  • Providing a clear representational image on the site's home page (future link)

  • Making metadata human-viewable (future link)

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

  4. Science information that requires reading ability at the lower secondary education level.

    The paragraphs below (114 words total) require reading ability of grade 6.9 in the United States, according to the Flesch-Kinkaid formula. In the US, grade 6.9 is at the lower secondary education level.

    In a dazzling and dramatic portrait painted by the Sun, the long thin shadows of Saturn's rings sweep across the planet's northern latitudes. Within the shadows, bright bands represent areas where the ring material is less dense, while dark strips and wave patterns reveal areas of denser material.

    The shadow darkens sharply near upper right, corresponding to the boundary of the thin C ring with the denser B ring. A wide-field, natural color view of these shadows can be seen here.

    The globe of Saturn's moon Mimas (398 kilometers, or 247 miles across) has wandered into view near the bottom of the frame. A few of the large craters on this small moon are visible.

    (Source: NASA - Sun-striped Saturn)

Related resources


How to Meet Success Criterion 3.1.6

3.1.6 A mechanism is available for identifying specific pronunciation of words where meaning cannot be determined without pronunciation. (Level 3)

Key Terms

mechanism

process or technique for achieving a result

Intent of this success criterion

The intent of this success criterion is to help people who are blind, people who have low vision, and people with reading disabilities to understand content in cases where meaning depends on pronunciation. Often words or characters have different meanings, each with its own pronunciation. The meaning of such words or characters can usually be determined from the context of the sentence. However, for more complex or ambiguous sentences, or for some languages, the meaning of the word cannot be easily determined or determined at all without knowing the pronunciation. When the sentence is read aloud and the screen reader reads the word using the wrong pronunciation, it can be even more difficult to understand than when read visually. When words are ambiguous or indeterminate unless the pronunciation is known, then providing some means of determining the pronunciation is needed.

Additionally, in some languages certain characters can be pronounced in different ways. In Japanese, for example, there are characters like Han characters(Kanji) which have multiple pronunciations. Screen readers may speak the characters incorrectly without the information on pronunciation. When read incorrectly, the content will not make sense to users.

Techniques for Addressing Success Criterion 3.1.6

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 3.1.6 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Providing the pronunciation immediately following the word (future link)

  2. Linking to pronunciations (future link)

  3. Providing a Glossary that includes pronunciation information for words that have a unique pronunciation in the content and have meaning that depends on pronunciation

  4. Providing pronunciation information USING a technology-specific technique below

Technology-Specific Techniques

HTML Techniques

Common Failures Identified by the Working Group

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

(No failures currently documented)

Additional Techniques (Advisory) for 3.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.

  • Providing pronunciations in a sound file, so that users can listen to the pronunciations of the word (future link)

  • Providing a mechanism for finding pronunciations for all foreign words in text content (future link)

  • Providing a mechanism to determine the pronunciations of each word or phrase in text content (future link)

Benefits: How Success Criterion 3.1.6 helps people with disabilities

  • Providing pronunciation information helps users who are blind understand content when text requires a specific pronunciation that screen readers cannot determine from context alone.

  • People with reading disabilities benefit when pronunciation information helps them decode content

Examples of Success Criterion 3.1.6

  • Giving the reading of a person's name

    Web content in Japanese provides kana (Japanese phonetic syllabary characters) written next to Han characters (Kanji) show the pronunciation of a person's name. The kana is provided to users in parentheses right after the word. Giving the reading of the words written in Han characters (Kanji) allows both sighted users and screen readers to read/pronounce the words correctly. Note that screen readers will speak the word twice: the Han characters (Kanji) that can be pronounced in a wrong way are read first and then kana is spoken in order to provide the correct reading.

  • Showing the reading of the words by ruby element

    Web content using XHTML 1.1 provides kana (phonetic syllabary characters) written above the characters to show the reading (pronunciation) of the words by using the ruby element.

  • Providing sound files of the pronunciation.

    A document includes some words whose meaning cannot be determined without knowing the correct pronunciation. Each word is linked to a sound file that gives the correct pronunciation. Users can select these links to find out how to pronounce the words.

  • Including pronunciation information in the glossary.

    A Web page includes a glossary section. Some items in the glossary include pronunciation information as well as definitions. Words in the content whose meaning cannot be determined without knowing their pronunciation are linked to the appropriate entries in the glossary.

  • Text that includes pronunciation information for characters shared by several languages but pronounced differently in each language

    A Japanese university Web site includes several short phrases quoted from scholarly texts in Chinese and Korean. The quotations are written using the same script as the Japanese text. Pronunciation information is provided to show the correct reading of the Chinese and Korean characters.

Note: For Japanese, the ruby element is used for showing the "reading" rather than "pronunciation".

Related resources

(none currently documented)


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

Intent of Guideline 3.2

The intent of this success criterion is to help users with disabilities by presenting content in a predictable order from Web unit to Web unit and by making the behavior of functional and interactive components predictable. It is difficult for some users to form an overview of the Web unit: screen readers present content as a one-dimensional stream of synthetic speech that makes it difficult to understand spatial relationships. Users with cognitive limitations may become confused if components appear in different places on different pages.

To give just a few examples, people who use screen magnifiers see only part of the screen at any point in time; a consistent layout makes it easier for them to find navigation bars and other components. Placing repeated components in the same relative order within a set of Web units allows users with reading disabilities to focus on an area of the screen rather than spending additional time decoding the text of each link. Users with limited use of their hands can more easily determine how to complete their tasks using the fewest keystrokes; and so on.

Advisory Techniques for Guideline 3.2

Specific techniques for meeting each success criterion for this guideline are listed in the How to Meet sections for each success criterion (listed below). There are some techniques, however, for addressing this guideline that do not fall under any of the success criteria. These techniques are listed here. They are not required or sufficient for meeting any success criteria but these advisory techniques can make certain types of Web content more accessible to more people.

  • All advisory techniques for this guideline relate to specific success criteria and are listed below.

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 Web 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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 3.2.1 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Common Failures Identified by the Working Group

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

Additional 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

  • This success criterion helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a change of context will occur unexpectedly.

Examples of Success Criterion 3.2.1

  • Example 1. An dropdown menu

    A dropdown menu on a page allows users to choose between jump destinations. If the person uses the keyboard to move down to a choice and activates it (with a spacebar or enter key) it will jump to a new page. However, if the person moves down to a choice and either hits the escape or the tab key to move out of the pulldown menu – it does not jump to a new screen as the focus shifts out of the dropdown menu.


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 authored 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 Web 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 has predictable effects. Changes in context, such as changing the input fields based on the value of a radio button, can confuse users who do not easily perceive the change or are easily distracted by changes. Changes of context are appropriate only when it is clear that such a change will happen when a field is selected or a button is pressed.

Techniques for Addressing Success Criterion 3.2.2

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 3.2.2 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Technology-Specific Techniques

HTML Techniques
Client-side Scripting Techniques
  • Using a "Go" button with a select element to perform an action (future link)

  • Hiding and showing content based upon a select element change (future link)

  • Hiding and showing content based upon a radio element change (future link)

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

(none currently documented)

Benefits: How Success Criterion 3.2.2 helps people with disabilities

  • This success criterion helps users with disabilities by making interactive content more predictable. Unexpected changes of context can be so disorienting for users with visual disabilities or cognitive limitations that they are unable to use the content.

  • Individuals who are unable to detect changes of context are less likely to become disoriented while navigating a site. For example:

    • Individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as a new window popping up. 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 others 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

  • A form is provided for creating calendar entries in a web based calendaring and scheduling application. Along with the standard fields for subject, time and location, there is a set of radio buttons to select the type of calendar entry to create. The calendar entry type can be meeting, appointment or reminder. If the user selects the radio for meeting, additional fields are displayed on the page for entering the meeting participants. Different fields appear if the reminder button is chosen. Because only parts of the entry change and the overall structure remains the same the basic context remains for the user. Instructions at the beginning of the Web unit explain the behavior of each radio button and the fields that appear when the button is selected.

  • A tab panel user interface is implemented within a Web unit. The tab panel consists of 5 tabs, each with a different title and content: US News, World News, Weather, Entertainment, and Humor. As the user navigates from tab to tab using the arrow keys, the contents of the Web unit are updated to reflect the selected tab. For example, when the user navigates to the Humor tab, A short account of a humorous incident is made visible in the tab panel, replacing the previous contents of the panel. This is the expected behavior of a tab panel user interface. The tab key can be used to navigate within the elements of the tab panel and then to other elements on the page below the current panel.


How to Meet Success Criterion 3.2.3

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

Key Terms

Web unit

a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Note: This definition is based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.

Example 1: An interactive movie-like shopping environment where the user navigates about and activates products to have them demonstrated, and moves them to a cart to buy them.

Example 2: A Web page including all embedded images and media.

same relative order

same position relative to other items

Note: 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 Web 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 phrase "same order" in this section 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 success criterion is intended to assist users who interact with repeated content across Web 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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 3.2.3 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Technology-Specific Techniques

Common Failures Identified by the Working Group

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

(No failures currently documented)

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

  • Using templates to ensure consistency across multiple Web units (future link)

  • Using dynamic navigation (future link)

Additional Technology-Specific Techniques (Advisory)
CSS Techniques
  • Creating layout, positioning, layering, and alignment (future link)

Benefits: How Success Criterion 3.2.3 helps people with disabilities

  • 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 cognitive limitations, users with low vision, users with intellectual disabilities, and also those who are blind.

Examples of Success Criterion 3.2.3

  • A consistently located control

    A search field is the last item on every Web unit in a site. users 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 Web units are identified consistently. (Level 2)

Key Terms

same functionality

identical result when used

Example: A submit "search" button on one Web page and a "find" button on another Web page 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 the same functionality but would not be labeled consistently.

Web unit

a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Note: This definition is based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.

Example 1: An interactive movie-like shopping environment where the user navigates about and activates products to have them demonstrated, and moves them to a cart to buy them.

Example 2: A Web page including all embedded images and media.

Intent of this success criterion

The intent of this success criterion is to ensure consistent identification of functional components that appear repeatedly within a set of Web 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 Web units. If identical functions have different labels on different Web units, the site will be considerably more difficult to use. It may also be confusing and increase the cognitive load for people with cognitive limitations. 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 be consistent as well.

Techniques for Addressing Success Criterion 3.2.4

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 3.2.4 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Using consistent labels, 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 Web unit that links to the next Web 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 Web 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 check marks, cross marks, and traffic signs. Their functions can be different depending on the context of the Web 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 Web 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 mistakes that are considered failures of success criterion 3.2.4 by the WCAG Working Group.

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

  • Ensuring that the text alternative conveys the function of the component and what will happen when the user activates it (future link)

  • Using the same non-text content for a given function whenever possible (future link)

Benefits: How Success Criterion 3.2.4 helps people with disabilities

  • People who learn functionality on one page on a site can find the desired functions on other pages if they are present.

  • When non-text content is used in a consistent way to identify components with the same functionality, 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 component if it has a consistent label on different pages.

Examples of Success Criterion 3.2.4

  • Example 1: Document Icon

    A document icon is used to indicate document download throughout a site. The text alternative for the icon always begins with the word “Download,” followed by a shortened form of the document title. Using different text alternatives to identify document names for different documents is a consistent use of text alternatives.

  • 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 Web units.

  • Example 4: Example of a Failure

    A submit "search" button on one Web unit and a "find" button on another Web unit both have a field to enter a term and list topics in the Web site related to the term submitted. In this case, the buttons have the same functionality but are not 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 Web 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 limitations.

Techniques for Addressing Success Criterion 3.2.5

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 3.2.5 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation B: If automatic redirects are possible:

  1. Implementing automatic redirects on the server side instead of on the client side

  2. Using an instant client-side redirect USING a technology-specific technique listed below

Situation C: If the Web unit uses pop-up windows:

  1. Including pop-up windows using a technology-specific technique listed below

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

(none currently documented)

HTML Techniques (Advisory)

Open new windows by:

  • Using the target attribute instead of scripts (future link), indicating that the link may open in a new window, or

  • Providing normal hyperlinks without the target attribute (future link), because many user agents allow users to open links in another window or tab.

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. For examle:

    • individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as a new window popping up. 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 limitations 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: Support compatibility with current and future user agents (including assistive technologies)

Intent of Guideline 4.1

The purpose of this guideline is to support compatibility with current and future user agents, especially assistive technologies (AT). This is done both by 1) ensuring that authors do not do things that would break AT (e.g. poorly formed markup) or circumvent AT (e.g. by using unconventional markup or code) and 2) exposing information in the content in standard ways that assistive technologies can recognize and interact with. Since technologies change quickly, and AT developers have much trouble keeping up, it is important that content follow conventions and be compatible with APIs so that AT can more easily work with new technologies as they evolve.

Advisory Techniques for Guideline 4.1

Specific techniques for meeting each success criterion for this guideline are listed in the How to Meet sections for each success criterion (listed below). There are some techniques, however, for addressing this guideline that do not fall under any of the success criteria. These techniques are listed here. They are not required or sufficient for meeting any success criteria but these advisory techniques can make certain types of Web content more accessible to more people.

  • All advisory techniques for this guideline relate to specific success criteria and are listed below.

How to Meet Success Criterion 4.1.1

4.1.1 Web units or authored components can be parsed unambiguously, and the relationships in the resulting data structure are also unambiguous. (Level 1)

Key Terms

Web unit

a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Note: This definition is based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.

Example 1: An interactive movie-like shopping environment where the user navigates about and activates products to have them demonstrated, and moves them to a cart to buy them.

Example 2: A Web page including all embedded images and media.

authored component

an authored unit intended to be used as a part of another authored unit

parsed unambiguously

parsed into only one data structure

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

Intent of this success criterion

The intent of this success criterion is to ensure that user agents (including assistive technology) can accurately interpret parsable content. If the content cannot be parsed into a single data structure, then different user agents may present it differently or be completely unable to parse it. Some mainstream browsers use “repair techniques” to render poorly coded content. This does not mean that the content can be accurately parsed into a single data structure or that it will be rendered correctly by the specialized user agents and assistive technologies used by people with disabilities.

Techniques for Addressing Success Criterion 4.1.1

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 4.1.1 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

  1. Ensuring that Web units can be parsed unambiguously by using one of the technology-specific techniques below (future link) OR

  2. Validating Web units OR

  3. Fully Conforming to specifications (future link)

Additional 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 Web 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

(none currently documented)


How to Meet Success Criterion 4.1.2

4.1.2 For all user interface components, the name and role can be programmatically determined, values that can be set by the user can be programmatically set, and notification of changes to these items is available to user agents, including assistive technologies. (Level 1)

Key Terms

name

text by which software can identify a component within Web content to the user

Note: The name may be hidden and only exposed by assistive technology, whereas a label is presented even without assistive technology. In many (but not all) cases, the label is a display of the name.

role

text or a number by which software can identify the function of a component within Web content

Example: A number that indicates whether an image functions as a hyperlink, command button, or check box.

programmatically determined

determined by software from data provided in a user-agent-supported manner such that the user agents can extract and present this information to users in different modalities

programmatically set

set by software using methods that are user-agent-supported

user agent

any software that retrieves and renders Web content for users

Example: Web browsers, media players, plug-ins, and other programs — including assistive technologies — that help in retrieving and rendering Web content.

Assistive technology (in the context of this document)

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.

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

Example: 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 definition is based on User Agent Accessibility Guidelines 1.0 Glossary.

Intent of this success criterion

The intent of this success criterion is to ensure that Assistive Technologies (AT) can gather information about, activate(or set) and keep up to date on the status of user interface controls in the content.

When standard controls from accessible technologies are used, this process is straightforward. If the user interface elements are used according to specification the conditions of this provision will be met. (see examples of success criterion 4.1.2 below)

If custom controls are created, however, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies.

Techniques for Addressing Success Criterion 4.1.2

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 4.1.2 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation A: If using a standard user interface component in a markup language (e.g. HTML):

  1. Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes USING technology-specific techniques below (for a technology in your baseline)

Situation B: If using a standard user interface component in a programming technology

  1. Using the accessibility API features of a technology to expose names and roles, to allow user-settable properties to be directly set, and to provide notification of changes USING technology-specific techniques below (for a technology in your baseline).

Situation D: If using script or code to re-purpose a standard user interface component in a markup language

  1. Exposing the names and roles, allowing user-settable properties to be directly set, and providing notification of changes USING technology-specific techniques (for a technology in your baseline)

Technology-Specific Techniques

HTML Techniques
XHTML 2 Techniques
  • Using (X)HTML according to spec (future link)

  • Using XHTML role, state, and value attributes if repurposing static elements as interactive user interface components (future link)

Script

Common Failures Identified by the Working Group

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

Additional 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 people with disabilities.

Examples of Success Criterion 4.1.2


Understanding Guideline 4.2: Ensure that content is accessible or provide an accessible alternative

Intent of Guideline 4.2

This guideline focuses on ensuring that an accessible version of all Web content is available and that inaccessible versions will not harm users who do encounter them.

Some Web content may not be able to meet WCAG 2.0 at the level of conformance being claimed, or the content may use technologies that are not in the baseline. In these cases, the guideline requires that another version of the content that does conform be available from the same location. Even when a conforming version is provided, this guideline encourages (at level 3) that all versions of the content be made as accessible as possible. This increases the number of users who can benefit from the content. For example, if a multimedia presentation uses a technology that is not in the baseline, then it cannot conform. However, if it is made as accessible as possible, there is an increased likelihood that individuals whose user agents and AT can access the content will be able to use the multimedia presentation rather than an alternative.

Advisory Techniques for Guideline 4.2

Specific techniques for meeting each success criterion for this guideline are listed in the How to Meet sections for each success criterion (listed below). There are some techniques, however, for addressing this guideline that do not fall under any of the success criteria. These techniques are listed here. They are not required or sufficient for meeting any success criteria but these advisory techniques can make certain types of Web content more accessible to more people.

  • All advisory techniques for this guideline relate to specific success criteria and are listed below.

How to Meet Success Criterion 4.2.1

4.2.1 At least one version of the content meets all level 1 success criteria, but alternate version(s) that do not meet all level 1 success criteria may be available from the same URI. (Level 1)

Key Terms

content

information to be communicated to the user by means of a user agent

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

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

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 4.2.1 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation A: If you are using a technology in which it is possible to create an accessible link to an alternate version:

  1. Providing a link at the beginning of the nonconforming content that points to an alternate version that does meet WCAG 2.0 Level 1 success criteria

Situation B: If you are using a technology in which it is not possible to create an accessible link to an alternate version:

  1. Ensuring that the only way to get to an inaccessible version is from a link from the accessible version OR

  2. Providing the nonconforming content to users whose preferences indicate they can handle it while providing the accessible version as the default if no content negotiation is done (future link)

    Note: This option may not be immediately possible with today's technologies and user agents due to lack of support for content negotiation.

  3. Providing links to alternatives along with explanations of the purpose of those links (future link)

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

  • Using content negotiation (future link)

  • Providing user settings as a way to store preferences (future link)

  • Providing style switchers (future link)

Additional HTML Techniques (Advisory)
  • Using noframes (future link)

  • Using noscript (future link)

  • Using a fallback mechanism for applets (if applet not in baseline, need alternative mechanism for functionality) (future link)

Additional CSS Techniques (Advisory)
  • Increasing the size of text content (future link)

Benefits: How Success Criterion 4.2.1 helps people with disabilities

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.

Examples of Success Criterion 4.2.1

  • An intranet site with multiple versions.

    A large company was concerned that the use of emerging Web technologies on an intranet site might limit their ability to address the needs of diverse office locations that have different technology bases and individual employees who use a wide variety of user agents and assistive technologies. To address these concerns, the company created an alternative version of the content that met all Level 1 success criteria using a more limited baseline. The requirements for each version were carefully documented, and both versions were available from the same URI, making it easy for each location to choose the version best suited to their needs.

  • An informational site ensuring backward compatibility.

    An information site covers a wide variety of subjects and wants to enable visitors to quickly find the topics they are looking for. To do this, the site has implemented an interactive menu system that is only supported in the most recent version of two popular user agents. To ensure that visitors who do not use these specific user agents are still able to effectively use the site, a navigation mechanism that does not depend on the interactive menu system is presented to user agents that do not support the newer technology.

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.

  2. Content conforms to success criterion 2.3.1 (general and red flash).

Key Terms

content

information to be communicated to the user by means of a user agent

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

Note: For more information on baselines and their use, refer to Technology Assumptions and the "baseline."

Intent of this success criterion

The intent of this success criterion is to ensure that content which uses technologies outside the baseline does not include components that actively interfere with the accessibility of the remaining content. Such components include:

  • components that would trap keyboard users within inaccessible content.

  • flashing components that could cause seizures due to photosensitivity

"Keyboard trapping" refers to 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. The requirement that content that can be entered via the keyboard can be exited via the keyboard is to prevent this 'lock up' effect.

The requirement to satisfy Success Criterion 2.3.1 is intended to ensure that users with photosensitivity (including users who may not be aware of their vulnerability) do not encounter flashing content that could cause a seuzure.

Content may be implemented in technologies that are not in the baseline 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 used could be present and create accessibility problems even though the technology is not part of the baseline.

Techniques for Addressing Success Criterion 4.2.2

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 4.2.2 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation A: If a Web unit uses non-baseline technology that can take keyboard focus

Situation B: If the Web unit includes flashing content:

  1. Following all techniques in How to Meet Success Criterion 2.3.1

Common Failures Identified by the Working Group

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

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

  • When the Web unit uses non-baseline technology that can capture keyboard focus, documenting the keyboard interface to exit the non-baseline content within the baseline content (future link)

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 Web 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 At least one version of the content meets all level 2 success criteria, but alternate version(s) that do not meet all level 2 success criteria may be available from the same URI. (Level 2)

Key Terms

content

information to be communicated to the user by means of a user agent

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

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 at the level of conformance claimed. 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.3

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 4.2.3 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.

Situation A: If you are using a technology in which it is possible to create an accessible link to an alternate version

  1. Providing a link at the beginning of the nonconforming content that points to an alternate version that does meet WCAG 2.0 Level 2 success criteria

Situation B: If you are using a technology in which it is not possible to create an accessible link to an alternate version

  1. Ensuring that the only way to get to an inaccessible version is from a link from the accessible version OR

  2. Providing the nonconforming content to users whose preferences indicate they can handle it while providing the accessible version as the default if no content negotiation is done (future link)

    Note: This option may not be immediately possible with today's technologies and user agents due to lack of support for content negotiation.

  3. Providing links to alternatives along with explanations of the purpose of those links (future link)

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

  • Using content negotiation (future link)

  • Providing user settings as a way to store preferences (future link)

  • Providing style switchers (future link)

Additional HTML Techniques (Advisory)
  • Using noframes (future link)

  • Using noscript (future link)

  • Using a fallback mechanism for applets (if applet is not in baseline, need alternative mechanism for functionality) (future link)

Additional CSS Techniques (Advisory)
  • Increasing the size of text content (future link)

Benefits: How Success Criterion 4.2.3 helps people with disabilities

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

Examples of Success Criterion 4.2.3

  • An intranet site with multiple versions.

    A large company was concerned that the use of emerging Web technologies on an intranet site might limit their ability to address the needs of diverse office locations that have different technology bases and individual employees who use a wide variety of user agents and assistive technologies. To address these concerns, the company created an alternative version of the content that met all Level 1 success criteria using a more limited baseline. The requirements for each version were carefully documented, and both versions were available from the same URI, making it easy for each location to choose the version best suited to their needs.

  • An informational site ensuring backward compatibility.

    An information site covers a wide variety of subjects and wants to enable visitors to quickly find the topics they are looking for. To do this, the site has implemented an interactive menu system that is only supported in the most recent version of two popular user agents. To ensure that visitors who do not use these specific user agents are still able to effectively use the site, a navigation mechanism that does not depend on the interactive menu system is presented to user agents that do not support the newer technology.

Related resources

(none currently documented)


How to Meet Success Criterion 4.2.4

4.2.4 Content implemented using technologies outside of the chosen baseline satisfies all Level 1 and Level 2 requirements supported by the technologies. (Level 3)

Key Terms

baseline

set of technologies assumed to be supported by, and enabled in, user agents

Note: For more information on baselines and their use, refer to Technology Assumptions and the "baseline."

Intent of this success criterion

The intent of this success criterion is to ensure that all content is as accessible as possible, even when it is implemented using technologies that are not listed in the baseline.

At Levels 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.

Some technologies do not provide features capable of meeting all WCAG requirements, and therefore content implemented in those technologies cannot meet WCAG requirements alone. For that reason, this success criterion does not require that content implemented in technologies outside the baseline meet all WCAG requirements.

Techniques for Addressing Success Criterion 4.2.4

Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion 4.2.4 as long as the technologies used are in the baseline you are using. All techniques listed would be helpful to some users. However, they only satisfy the success criterion if all of the technologies used are in your baseline. (Use of technologies not in the baseline is allowed, but an alternate conformant version would be required per success criterion 4.2.1.)

Common Failures Identified by the Working Group

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

(No failures currently documented)

Additional Techniques (Advisory) for 4.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.

  • Follow general techniques for all WCAG success criteria at level 3 (future link) AND

  • Follow all technology-specific techniques at level 3 that the technologies outside the baseline can support (future link)

Benefits: How Success Criterion 4.2.4 helps people with disabilities

  • Ensuring that content implemented in technologies outside the baseline satisfies as many Level 1 and Level 2 success criteria as possible, while also providing accessible alternatives, means that more users with disabilities will have direct access to the content.

Examples of Success Criterion 4.2.4

  • Example 1

    A Web site is developed for a baseline that contains HTML and Script, but does not include 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, captions, etc. to help make it directly accessible so users who wish can access the richer content directly instead of the accessible alternative.

  • Example 2

    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.

  • Example 3

    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 full multimediea text alternative including any interaction 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.

  • Example 4

    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., W3C Last Call Working Draft 27 April 2006. This W3C Working Draft is available at http://www.w3.org/TR/2006/WD-WCAG20-20060427/. The latest version of WCAG 2.0 is available at http://www.w3.org/TR/WCAG20/
UNESCO
International Standard Classification of Education, 1997. A copy of the standard is available at http://www.unesco.org/education/information/nfsunesco/doc/isced_1997.htm.
EPFND
Experts Issue Recommendations to Protect Public from Seizures Induced by TV / Videogames. A copy of the standard is available at http://www.epilepsyfoundation.org/aboutus/pressroom/pr20050919.cfm.