The presentation of this document has been augmented to identify changes from a previous version. Three kinds of changes are highlighted: [begin add] new, added text [end add], [begin change] changed text [end change], and [begin delete] deleted text [end delete].


[contents]

W3C

Understanding WCAG 2.0

A guide to understanding and implementing WCAG 2.0

W3C Working Draft 17 May 2007 -- Review Version

This version:
http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20070517/
Latest version:
http://www.w3.org/TR/UNDERSTANDING-WCAG20/
Previous version:
http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/
Editors:
Ben Caldwell, Trace R&D Center, University of Wisconsin-Madison
Michael Cooper, W3C
Loretta Guarino Reid, Google, Inc.
Gregg Vanderheiden, Trace R&D Center, University of Wisconsin-Madison
Previous Editors:
Wendy Chisholm (until July 2006 while at W3C)
John Slatin (until June 2006 while at Accessibility Institute, University of Texas at Austin)

This document is also available in these non-normative formats:


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

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, and how the success criteria in WCAG 2.0 help people with different types of disabilities. This document also provides 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.

This document indicates specific techniques to meet each success criterion. Details for how to implement each technique are available in Techniques and Failures for WCAG 2.0, but "Understanding WCAG 2.0" provides the information about the relationship of each technique to the success criteria. Techniques are categorized by the level of support they provide for the success criteria. "Sufficient techniques" are sufficient to meet a particular success criterion (either by themselves or in combination with other techniques), while other techniques are advisory and therefore optional. None of the techniques are required to meet WCAG 2.0, although some may be the only known method if a particular technology is used. "Advisory techniques" are not sufficient to meet the success criteria on their own (because they are not testable or provide incomplete support) but it is encouraged that authors follow them when possible to provide enhanced accessibility. Another support category is "Failure techniques", which describe authoring practices known to cause Web content not to conform to WCAG 2.0. Although failure techniques provide advisory information about certain authoring practices, authors must avoid those practices in order to meet the WCAG 2.0 success criteria.

This document is part of a series of documents published by the W3C Web Accessibility Initiative (WAI) to support WCAG 2.0.

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 a Public Working Draft of "Understanding WCAG 2.0." The Web Content Accessibility Guidelines Working Group considers this document to be important for understanding the success criteria in the Web Content Accessibility Guidelines 2.0 (WCAG 2.0), and encourages feedback on this draft.

This version of Understanding WCAG 2.0 includes clarifications about success criteria whose purpose and implementation were not clearly understandable in the previous Working Draft. New success criteria are supported by new sections in this document. In many cases, the techniques applicable to success criteria changed and reference to those techniques from this document updated accordingly.

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.

The WCAG Working Group seeks feedback on the following questions:

Comments on this working draft are due on or before 29 June 2007. The Working Group requests that comments be made using the provided online or downloadable comment form. If this is not possible, comments can also be sent to public-comments-wcag20@w3.org. The archives for the public comments list are publicly available. Archives of the WCAG WG mailing list discussions are also publicly available.

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.

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

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

[begin add]

This is not an introductory document. It is a detailed technical description of the guidelines and their success criteria. For an introduction to WCAG 2.0 and the complete set of documents associated with the guidelines, see Overview of Web Content Accessibility Guidelines (WCAG) 2.0 Documents. [LC-1016]

[end add]

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.

[begin add]

Understanding the Four Principles of Accessibility

The guidelines and success criteria are organized around the following four principles. These four principles lay the foundation necessary for anyone to access and use Web content. Anyone who wants to use the Web must have content that is:

  1. Perceivable - Information and user interface components must be perceivable by users

    • This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses)

  2. Operable - User interface components must be operable by users

    • This means that users must be able to operate the interface (the interface cannot require interaction that the user can not perform)

  3. Understandable - Information and operation of user interface must be understandable by users

    • This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)

  4. Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies

    • This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)

If any of these are not true, users with disabilities will not be able to use the Web.

Under each of the principles are guidelines and success criteria that help to address these principles for people with disabilities. There are many general usability guidelines that make content more usable by all people, including those with disabilities. However, in WCAG 2.0, we only include those guidelines that address problems particular to people with disabilities. This includes issues that block access or interfere with access to the Web more severely for people with disabilities.

[begin delete]

[LC-1019]

[end delete]

[end add]

Understanding Guideline 1.1: Provide text alternatives for any non-text content so that it can be changed into other forms people need such as large print, braille, speech, symbols or simpler language

Intent of Guideline 1.1

The purpose of this guideline is to ensure that all non-text content is also available in text. "Text" refers to electronic text, not an image of text. Electronic text has the unique advantage that it can be rendered visually, auditorially, 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 (not success criteria specific)

Specific techniques for meeting each success criterion for this guideline are listed in the understanding sections for each success criterion (listed below). If there are techniques, however, for addressing this guideline that do not fall under any of the success criteria, they are listed here. These techniques are not required or sufficient for meeting any success criteria, but 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.

Understanding Success Criterion 1.1.1 (Non-text Content)

[begin change]
[begin change]

1.1.1 All non-text content has a text alternative that presents equivalent information, except for the situations listed below[begin delete]Except for the situations listed below, a text alternative that presents equivalent information is provided for all non-text content[end delete]. [LC-956] [LC-1281] [LC-1524] (Level A)

[end change]
  • Controls-Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (See also Guideline 4.1.) [LC-738]

  • Media, Test, Sensory: If non-text content is multimedia [begin change],[end change] live audio-only or live video-only content[begin change],[end change] a [begin change]test or exercise that must be presented in non-text format [LC-1506] [end change] [begin change],[end change] or primarily intended to create a specific sensory experience [begin change],[end change] then text alternatives at least identify the non-text content with a descriptive text label. (For multimedia, see also Guideline 1.2.) [LC-801]

  • CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, [begin add]then [LC-738] [LC-1282] [end add] [begin change]text alternatives that identify and describe the purpose of the non-text content are provided and alternative[end change] forms [begin add]in different modalities are[end add] provided to accommodate [begin change]different [LC-800] [LC-1155] [end change] disabilities.

  • Decoration, Formatting, Invisible: If non-text content is pure decoration, or used only for visual formatting, or if it is not presented to users, [begin add]then [LC-738] [end add] it is implemented such that it can be ignored by assistive technology.

[end change]

Key Terms

non-text content
[begin add]

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language [LC-954]

[end add]
[begin delete]

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

[end delete]

Note: This includes ASCII Art (which is a pattern of characters) [begin add]and leetspeak (which is character substitution). [LC-796] [end add]

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

[begin add]

Example: An image of a chart is described in text in the paragraph after the chart. The short text-alternative for the chart indicates that a description follows. [LC-1507]

[end add]
name

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

Note 1: The name may be hidden and only exposed by assistive technology, whereas a label is presented [begin add]to all users.[end add] [begin delete]even without Assistive technology (as used in this document 732 ) [end delete] In many (but not all) cases, the label [begin add]and the name are the same.[end add] [begin delete]is a display of the name[end delete]

[begin add]

Note 2: This is unrelated to the name attribute in HTML.

[end add]
multimedia

audio or video synchronized with another [begin delete]type of media[end delete] [begin add]format for presenting information[end add] and/or with time-based interactive components [LC-1499]

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)

must be presented in non-text format

would be invalid if presented in text [LC-1506]

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

Example: [begin add]Examples include a performance of a flute solo, works of visual art etc. [LC-1189] [end add]

label

text [begin delete], image, or sound[end delete] [begin add]or other component with a text alternative [end add] that is presented to a user to identify a component within Web content

Note: [begin add]See also name. [LC-847] [end add]

CAPTCHA

initialism for "Completely Automated Public Turing test to tell Computers and Humans Apart"

Note 1: CAPTCHA tests often involve asking the user to type in text that is displayed in an obscured image or audio file.

Note 2: A Turing test is any system of tests designed to differentiate a human from a computer. It is named after famed computer scientist Alan Turing. The term was coined by researchers at Carnegie Mellon University. [CAPTCHA]

pure decoration

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

[begin add]

Note: Text is only purely decorative if the words can be rearranged or substituted without changing their purpose.

[end add]
[begin add]

Example: The cover page of a dictionary has random words in very light text in the background.

[end add]
Assistive technology ([begin change]as used in this document [LC-732] [end change])

a user agent that [begin add]both[end add]:

  1. [begin change]

    provides services to meet the requirements of users with disabilities that go beyond those offered by the mainstream user agents. Such services include alternative presentations (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)[begin add], and[end add] [LC-1178]

    [end change]
  2. usually relies on services (such as retrieving Web content and parsing markup) provided by one or more other mainstream user agents. Assistive technologies communicate data and messages with mainstream user agents by using and monitoring APIs

Note 1: [begin add]In this definition, user agents are user agents in the general sense of the term. That is, any software that retrieves and [begin change]presents[end change] Web content for users. The mainstream user agent may provide important services to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles. [LC-732] [end add]

Note 2: [begin add]Mainstream user agents may also provide services directly that meet the requirements of users with disabilities. [LC-732] [end add]

Note 3: This definition is based on User Agent Accessibility Guidelines 1.0 Glossary.

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

  • screen magnifiers, [begin change]and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc in order [LC-604] [end change] improve the visual readability of rendered text and images;

  • screen readers, which are used by people who are blind [begin change]to read textual information through synthesized speech or braille[end change];

  • [begin add]

    text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;

    [end add]
  • 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.

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 [begin change]is not covered by one of the other situations listed below[end change], 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).

[begin change]

For non-text content that is a control or accepts user input , such as images used as submit buttons or complex animations, a name is provided to describe the purpose of the non-text content so that the person at least knows what the non-text content is and why it is there.

[end change]

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. [begin change]For such content, text alternatives at least identify the non-text content with a descriptive label and where possible, some descriptive text. If the reason for including the content in the page is known and can be described it is helpful to include that information. [LC-787] [end change]

[begin add]

Sometimes there are non-text exercises that are used to prove you are human. To avoid spam robots and other software from gaining access to a site a device called a CAPTCHA is used. These usually involve visual or auditory tasks that are beyond the current capabilities of web robots. Providing a text alternative to them would however make them operable by Robots, thus defeating their purpose. In this case a text alternative would describe the purpose of the CAPTCHA, and alternate forms using different modalities would be provided to address the needs of people with different disabilities.

[end add]

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

Specific Benefits of Success Criterion 1.1.1:

  • [begin change]

    This success criterion helps people who have difficulty perceiving visual content. Assistive technology can read text alternatives aloud, present them visually, or convert them to braille.

    [end change]
  • [begin change]

    Text alternatives may help some people who have difficulty understanding the meaning of photographs, drawings, and other images (e.g. line drawings, graphic designs, paintings, three-dimensional representations), graphs, charts, animations, etc.

    [end change]
  • People who are deaf, are hard of hearing, or who are having trouble understanding audio information for any reason can read the text presentation. Research is ongoing regarding automatic translation of text into sign language. [LC-790]

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

Techniques for Addressing Success Criterion 1.1.1

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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[begin delete], the following would be sufficient[end delete]:
  1. G94: 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 short text alternative technique listed below

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)[begin delete], the following would be sufficient[end delete]:
  1. G95: Providing short text alternatives that provide a brief description of the non-text content using a short text alternative technique listed below AND one of the following techniques for long description:

[begin change]
Situation C: If non-text content is a control or accepts user input:
[end change]
  1. G82: Providing a text alternative that identifies the purpose of the non-text content using a short text alternative technique listed below

  2. [begin add]

    Using HTML form controls and links (future link)

    [end add]
  3. [begin add]

    Using (X)HTML according to spec (future link)

    [end add]
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 a short text alternative technique listed below

  2. G68: Providing a descriptive label that describes the purpose of live audio-only and live video-only content using a short text alternative technique listed below

  3. G100: Providing the accepted name or a descriptive name of the non-text content using a short text alternative technique listed below

Situation E: If non-text content is a CAPTCHA:
  1. G143: Providing a text alternative that describes the purpose of the CAPTCHA AND G144: Ensuring that the Web Page contains another CAPTCHA serving the same purpose using a different modality

Situation F: 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 assistive technology using one of the technology-specific techniques listed below

Providing short text alternatives in HTML
Providing long text alternatives in HTML

Common Failures Identified by the Working Group

The following are common mistakes that are considered failures of Success Criterion 1.1.1 by the WCAG Working Group.

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.

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 an accessibility-supported content technology) for long description listed above (future link)

General Techniques for Live Non-Text Content (Advisory)
  • [begin change]Linking to textual information that provides comparable information (e.g. for a traffic Webcam, a municipality could provide a link to the text traffic report.) (future link) [LC-788] [end change]

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

HTML Techniques (Advisory)
  • [begin change]

    H46: Using noembed with embed (HTML) [LC-786]

    [end change]
  • 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)

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 [begin add], trends and implications[end add] comparable to those available from the chart[begin delete], and provides the data in a table[end delete]. [begin add]Where possible and practical, the actual data is provided in a table. [LC-789] [end add]

  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. [begin change]Since the text of the tutorial already provides a full explanation, the text alternative has a brief description of the image and refers to the tutorial text for more information. [LC-1074] [end change]

  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.

  8. [begin add]An e-learning application[end add]

    [begin add]An e-learning application uses sound effects to indicate whether or not the answers are correct. The chime sound indicates that the answer is correct and the beep sound indicates that the answer is incorrect. A text description is also included so that people who can't hear or understand the sound understand whether the answer is correct or incorrect. [end add] [LC-1326]

  9. [begin add]

    [begin add]A linked thumbnail image[end add]

    [end add]

    A thumbnail image of the front page of a newspaper links to the home page of the "Smallville Times". The text alternative says "Smallville Times". [LC-858]

Related Resources

Resources are for information purposes only, no endorsement implied.


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 dialogue that audio description cannot fit into existing pauses in the dialogue. The option at Level A to provide a full text alternative for multimedia including any interaction instead of audio description 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 text alternative for multimedia.

This guideline also includes (at Level AAA) sign language interpretation for multimedia as well as an approach called extended audio description. 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 dialogue. [begin add]This is a case where higher-level success criteria build upon the requirements of lower-level SC with the intention of having cumulative, progressively stronger, requirements. [LC-1223] [end add]

Advisory Techniques for Guideline 1.2 (not success criteria specific)

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


Understanding Success Criterion 1.2.1 (Captions (Prerecorded))

1.2.1 Captions are provided for prerecorded multimedia, [begin add]except for multimedia alternatives to text that are clearly labeled as such. [LC-608] [end add] (Level A)

Key Terms

captions

text presented and synchronized with multimedia to provide not only the speech, but also [begin change]non-speech information conveyed through sound, including meaningful sound effects and identification of speakers [LC-846] [end change]

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 [begin delete]type of media[end delete] [begin add]format for presenting information[end add] and/or with time-based interactive components [LC-1499]

multimedia alternatives to text
[begin add]

multimedia that presents no more information than is already presented in text (directly or via text alternatives) [LC-608]

[end add]

Note: Multimedia alternatives to text are provided for those who benefit from alternate representations of text.

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 include non-speech information conveyed through sound, including meaningful sound effects.

[begin add]

It is acknowledged that at the present time there may be difficulty in creating captions for time-sensitive material and this may result in the author being faced with the choice of delaying the information until captions are available, or publishing time-sensitive content that is inaccessible to the deaf, at least for the interval until captions are available. Over time, the tools for captioning as well as building the captioning into the delivery process can shorten or eliminate such delays. [LC-1332]

[end add]
[begin add]

Captions are not needed when the multimedia is, itself, an alternate presentation of information that is also presented via text on the Web page. For example, if information on a page is accompanied by a multimedia presentation that [begin add]presents no more information than is already presented in text,[end add] but is easier for people with cognitive, language, or learning disabilities to understand, then it would not need to be captioned since the information is already presented on the page in text or in text alternatives (e.g. for images). [LC-608]

[end add]

Specific Benefits of Success Criterion 1.2.1:

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

Techniques for Addressing Success Criterion 1.2.1

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. G93: Providing open (always visible) captions

  2. G87: Providing closed captions using any readily available media format that has a video player that [begin delete]is free of charge and[end delete] supports closed captioning [LC-792]

  3. G87: Providing closed captions using any of the technology-specific techniques below

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.

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

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

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

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.

  • [begin add]

    A complex legal document contains multimedia clips for different paragraphs that show a person speaking the contents of the paragraph. Each clip is associated with its corresponding paragraph. No captions are provided for the multimedia. [LC-608]

    [end add]
  • [begin add]

    An instruction manual containing a description of a part and its necessary orientation is accompanied by a multimedia clip showing the part in its correct orientation. No captions are provided for the multimedia clip. [LC-608]

    [end add]

Understanding Success Criterion 1.2.2 (Audio Description or Full Text Alternative)

1.2.2 Audio description of video, or a [begin change]full text alternative for multimedia including any interaction[end change] , is provided for prerecorded multimedia. (Level A)

Note: [begin add]For 1.2.2, 1.2.4, and 1.2.7, if all of the information in the video track is already provided in the audio track, no audio description is necessary. [LC-1224] [end add]

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: [begin change]Audio description of video provides information about actions, characters, scene changes, on-screen text, and other visual content. [LC-845] [end change]

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

[begin add]

Note 3: Also called "video description" and "descriptive narration."

[end add]
[begin change]full text alternative for multimedia including any interaction [LC-810] [end change]
[begin change]

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

[end change]

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 [begin delete]type of media[end delete] [begin add]format for presenting information[end add] and/or with time-based interactive components [LC-1499]

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 dialogue, audio description provides 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 text alternative for multimedia including any interaction provides a running description of all that is going on in the multimedia content. The full text alternative for multimedia including any interaction reads something like a screenplay or book. Unlike audio description, the description of the video portion is 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 description and dialogue transcripts are the same as the sequence in the multimedia itself. As a result, the full text alternative for multimedia 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 text alternative for multimedia would provide hyperlinks or whatever is needed to provide the same functionality.

Note: [begin add]For 1.2.2, 1.2.3, and 1.2.7, if all of the information in the video track is already provided in the audio track, no audio description is necessary. [LC-1224] [end add]

Specific Benefits of Success Criterion 1.2.2:

  • [begin change]

    This success criterion may help some people who have difficulty watching video or other multimedia content, including people who have difficulty perceiving or understanding moving images.

    [end change]

Techniques for Addressing Success Criterion 1.2.2

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. G69: Providing a full multimedia text alternative including any interaction

  2. G78: Providing a sound track that includes audio description as the primary sound track

  3. G78: Providing a sound track that includes audio description AND associating it with the multimedia content using one of the following techniques:

  4. 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 one of the following techniques

    • Using SMIL 1.0 to merge a description track with sound track (future link)

    • Using SMIL 2.0 to merge a description track with sound track (future link)

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 description in multiple languages in SMIL 1.0 (future link)

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

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

  • A full text alternative for multimedia including any interaction 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 dialogue, the company provides a full text alternative for multimedia that all employees, including those who cannot see the demonstrations, can use to better understand what is being presented.


Understanding Success Criterion 1.2.3 (Captions (Live))

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

Note: [begin add]If multimedia is completely computer generated, it is not live and is subject to the requirements for pre-recorded multimedia in WCAG 2.0. [LC-925] [end add]

Key Terms

captions

text presented and synchronized with multimedia to provide not only the speech, but also [begin change]non-speech information conveyed through sound, including meaningful sound effects and identification of speakers [LC-846] [end change]

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 [begin delete]type of media[end delete] [begin add]format for presenting information[end add] and/or with time-based interactive components [LC-1499]

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.

Specific Benefits of Success Criterion 1.2.3:

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

Techniques for Addressing Success Criterion 1.2.3

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. G9: Creating captions for live multimedia AND G93: Providing open (always visible) captions

  2. G9: Creating captions for live multimedia AND G87: Providing closed captions using any readily available media format that has a video player that [begin delete]is free of charge and[end delete] supports closed captioning [LC-792]

  3. G9: Creating captions for live multimedia AND G87: Providing closed captions using one of the following techniques:

Note: Captions may be generated using real-time text translation service. [begin delete](stenographic or, in the future, speech-to-text with corrections)[end delete] [LC-790]

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)

Examples of Success Criterion 1.2.3

  • A Web cast

    A news organization provides a live, captioned Web cast.

Related Resources

Resources are for information purposes only, no endorsement implied.


Understanding Success Criterion 1.2.4 (Audio Description)

1.2.4 Audio description of video is provided for prerecorded multimedia. (Level AA)

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: [begin change]Audio description of video provides information about actions, characters, scene changes, on-screen text, and other visual content. [LC-845] [end change]

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

[begin add]

Note 3: Also called "video description" and "descriptive narration."

[end add]
multimedia

audio or video synchronized with another [begin delete]type of media[end delete] [begin add]format for presenting information[end add] and/or with time-based interactive components [LC-1499]

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

Note: [begin add]For 1.2.2, 1.2.3, and 1.2.7, if all of the information in the video track is already provided in the audio track, no audio description is necessary. [LC-1224] [end add]

Specific Benefits of Success Criterion 1.2.4:

  • 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 description of visual information.

Techniques for Addressing Success Criterion 1.2.4

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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

  2. G78: Providing a sound track that includes audio description AND associating it with the multimedia content using one of the following techniques:

  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 one of the following techniques

    • Using SMIL 1.0 to merge a description track with sound track (future link)

    • Using SMIL 2.0 to merge a description track with sound track (future link)

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.

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

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

Examples of Success Criterion 1.2.4

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


Understanding Success Criterion 1.2.5 (Sign Language)

1.2.5 Sign language interpretation is provided for multimedia. (Level AAA)

Key Terms

sign language interpretation

translation of one language, generally a spoken language, into a sign language [LC-741]

Note: [begin delete]Most[end delete] [begin add]True[end add] sign languages are independent languages that are unrelated to the spoken language(s) of the same country or region. [LC-1504]

multimedia

audio or video synchronized with another [begin delete]type of media[end delete] [begin add]format for presenting information[end add] and/or with time-based interactive components [LC-1499]

Intent of this Success Criterion

[begin change]

The intent of this success criterion is to enable people who are deaf or hard of hearing and who are fluent in a sign language to understand the content of the audio track of multimedia presentations. Written text, such as that found in captions, is often a second language. Some individuals will require sign language interpretation to gain full access to the multimedia content. [LC-591]

[end change]

Specific Benefits of Success Criterion 1.2.5:

  • People whose human 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. [LC-596]

Techniques for Addressing Success Criterion 1.2.5

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

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)

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.


Understanding Success Criterion 1.2.6 (Audio Description (Extended))

1.2.6 Extended audio description of video is provided for prerecorded multimedia. (Level AAA)

Key Terms

extended audio description

audio description that is 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 [begin delete]type of media[end delete] [begin add]format for presenting information[end add] and/or with time-based interactive components [LC-1499]

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

Specific Benefits of Success Criterion 1.2.6:

  • 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 description of the visual information. However, if there is too much dialogue the audio description is insufficient. Extended audio description can provide the additional information they needed to understand the video.

Techniques for Addressing Success Criterion 1.2.6

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. [begin add]Providing a second version of the movie with extended audio descriptions during halted video segments (future link)[end add]

  2. G8: Creating an extended audio description for the multimedia content 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 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.

  • Adding extended audio description in multiple languages in SMIL 1.0 (future link)

  • Adding extended audio description in multiple languages in SMIL 2.0 (future link)

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 description of the professor’s drawings and gestures is provided; the video is then resumed.


Understanding Success Criterion 1.2.7 (Full Text Alternative)

1.2.7 [begin delete]For prerecorded multimedia, [end delete]A [begin change]full text alternative for multimedia including any interaction[end change] is provided [begin add]for all prerecorded multimedia [LC-1156] [end add], [begin add]except for multimedia alternatives to text that are clearly labeled as such [LC-608] [end add]. (Level AAA)

Key Terms

[begin change]full text alternative for multimedia including any interaction [LC-810] [end change]
[begin change]

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

[end change]

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 alternatives to text
[begin add]

multimedia that presents no more information than is already presented in text (directly or via text alternatives) [LC-608]

[end add]

Note: Multimedia alternatives to text are provided for those who benefit from alternate representations of text.

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 description. This is done by providing a full text alternative for multimedia including any interaction.

This approach involves providing all of the information in the multimedia (both visual and auditory) in text form. A full text alternative for multimedia including any interaction provides a running description of all that is going on in the multimedia content. The full text alternative for multimedia reads something like a book. Unlike audio description, the description of the video portion is 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 text alternative for multimedia 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 text alternative for multimedia 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 text alternative for multimedia by using a refreshable braille display.

Note: [begin add]For 1.2.2, 1.2.3, and 1.2.7, if all of the information in the video track is already provided in the audio track, no audio description is necessary. [LC-1224] [end add]

Specific Benefits of Success Criterion 1.2.7:

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

Techniques for Addressing Success Criterion 1.2.7

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. G69: Providing a full multimedia text alternative including any interaction 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 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.

  • [begin change]

    H46: Using noembed with embed (HTML)

    [end change]
  • Providing a corrected script (future link)

  • Adding detail to audio description (future link)

Examples of Success Criterion 1.2.7

  • Example 1. full text alternative for multimedia 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 text alternative for multimedia 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

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Guideline 1.3: Create content that can be presented in different ways (for example spoken aloud, simpler layout, etc.) without losing information or structure488 1201

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 [begin add]structure and[end add] information cannot be [begin delete]separated from the presentation[end delete] [begin add]programmatically determined by the assistive technology[end add], then it cannot be rendered in other formats as needed by the user. [LC-1201]

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 (not success criteria specific)

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


Understanding Success Criterion 1.3.1 (Info and Relationships)

1.3.1 Information and relationships conveyed through presentation can be programmatically determined [begin add]or are available in text [LC-742] [end add], and notification of changes to these is available to user agents, including assistive technologies. (Level A)

Key Terms

relationships

[begin add]meaningful associations between distinct pieces of content [LC-1427] [end add]

presentation

[begin delete]rendering of the content and structure in a form that can be perceived by the user[end delete] [begin change]rendering of the content in a form to be perceived by users [LC-490] [LC-1501] [end change]

programmatically determined

determined by software from [begin add]author-supplied[end add] data provided in a [begin delete] user-agent-supported manner such that the[end delete] [begin add]way that different[end add] user agents, including assistive technologies, can extract and present this information to users in different modalities [LC-756] [LC-1502]

[begin add]

Example: Determined in a mark-up language from elements and attributes that are accessed directly by commonly available assistive technology.

[end add]
[begin add]

Example: Determined from technology-specific data structures in a non-mark-up language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.

[end add]
user agent

any software that retrieves and [begin change]presents[end change] Web content for users

Example: Web browsers, media players, plug-ins, and other programs — including assistive technologies — that help in retrieving[begin change], rendering, and interacting with [end change]Web content. [LC-1269]

Assistive technology ([begin change]as used in this document [LC-732] [end change])

a user agent that [begin add]both[end add]:

  1. [begin change]

    provides services to meet the requirements of users with disabilities that go beyond those offered by the mainstream user agents. Such services include alternative presentations (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)[begin add], and[end add] [LC-1178]

    [end change]
  2. usually relies on services (such as retrieving Web content and parsing markup) provided by one or more other mainstream user agents. Assistive technologies communicate data and messages with mainstream user agents by using and monitoring APIs

Note 1: [begin add]In this definition, user agents are user agents in the general sense of the term. That is, any software that retrieves and [begin change]presents[end change] Web content for users. The mainstream user agent may provide important services to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles. [LC-732] [end add]

Note 2: [begin add]Mainstream user agents may also provide services directly that meet the requirements of users with disabilities. [LC-732] [end add]

Note 3: This definition is based on User Agent Accessibility Guidelines 1.0 Glossary.

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

  • screen magnifiers, [begin change]and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc in order [LC-604] [end change] improve the visual readability of rendered text and images;

  • screen readers, which are used by people who are blind [begin change]to read textual information through synthesized speech or braille[end change];

  • [begin add]

    text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;

    [end add]
  • 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.

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; [begin add]words that have special status are indicated by changing the font family and /or bolding, italicizing, or underlining them [end add]and so on [LC-588] .

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.

[begin change]

When such relationships are perceivable to one set of users, those relationships can be made to be perceivable to all. [begin add]One method of determining whether or not information has been properly provided to all users is to access the information serially in different modalities.[end add]

[end change]
[begin add]

If links to glossary items are implemented using anchor elements (or the proper link element for the technology in use) and identified using a different font face, a screen reader user will hear that the item is a link when the glossary term is encountered even though they may not receive information about the change in font face. An on-line catalog may indicate prices using a larger font colored red. A screen reader or person who can not perceive red, still has the information about the price as long as it is preceded by the currency symbol.

[end add]
[begin add]

Some technologies do not provide a means to programmatically determine some types of information and relationships. In that case then there should be a text description of the information and relationships. For instance, "all required fields are marked with an asterisk (*)". The text description should be near the information it is describing (when the page is linearized), such as in the parent element or in the adjacent element.

[end add]

Specific Benefits of Success Criterion 1.3.1:

  • [begin change]

    This success criterion helps people with different disabilities by allowing user agents to adapt content according to the needs of individual users.

    [end change]
  • 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).

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

Techniques for Addressing Success Criterion 1.3.1

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

[begin change]

Sufficient Techniques

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: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable:
  1. [begin add]

    Separating information and structure from presentation to enable modification of presentation without altering content (future link) [LC-1201]

    [end add]
Situation B: The technology in use does NOT provide the semantic structure to make the information and relationships conveyed through presentation programmatically determinable:
  1. Making information and relationships conveyed through presentation programmatically determinable or available in text using the following techniques:

[end change]

Common Failures Identified by the Working Group

The following are common mistakes that are considered failures of Success Criterion 1.3.1 by the WCAG Working Group.

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.

Examples of Success Criterion 1.3.1

  • [begin change]A form with required fields[end change]

    [begin change]A form contains several required fields. The labels for the required fields are displayed in red. In addition, at the end of each label is an asterisk character, *. The instructions for completing the form indicate that "all required fields are displayed in red and marked with an asterisk *", followed by an example. [LC-1079] [end change]

  • 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. [LC-1079]

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


Understanding Success Criterion 1.3.2 (Meaningful Sequence)

1.3.2 [begin change]When the sequence in which content is presented affects its meaning, a correct reading sequence[end change] can be programmatically determined [begin add]and sequential navigation of interactive components is consistent with that sequence[end add]. [LC-1159] [LC-816] (Level A)

Key Terms

programmatically determined

determined by software from [begin add]author-supplied[end add] data provided in a [begin delete] user-agent-supported manner such that the[end delete] [begin add]way that different[end add] user agents, including assistive technologies, can extract and present this information to users in different modalities [LC-756] [LC-1502]

[begin add]

Example: Determined in a mark-up language from elements and attributes that are accessed directly by commonly available assistive technology.

[end add]
[begin add]

Example: Determined from technology-specific data structures in a non-mark-up language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.

[end add]

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. [begin add]Content that does not meet this success criterion may confuse or disorient users when assistive technology reads the content in the wrong order, or when alternate style sheets or other formatting changes are applied.[end add]

A sequence is meaningful if the order of content in the sequence cannot be changed without affecting its meaning. [begin delete]The order of words in sentences and sentences in paragraphs, for instance, is always meaningful. [LC-795] [end delete] [begin change]For example[end change], 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.

Specific Benefits of Success Criterion 1.3.2:

  • This success criterion may help people who rely on assistive technologies that read content aloud. The meaning evident in the sequencing of the information in the default presentation will be the same when the content is presented in spoken form.

Techniques for Addressing Success Criterion 1.3.2

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

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.

  • [begin add]

    Using left-justified text for languages that are written left to right and right-justified text for languages that are written right-to-left (future link) [LC-840]

    [end add]
  • [begin add]

    Using appropriate justification for languages that are written right-to-left (future link) [LC-840]

    [end add]
  • Providing a link to linearized rendering (future link)

  • Providing a style switcher between style sheets that affect presentation order (future link)

Examples of Success Criterion 1.3.2

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


Understanding Success Criterion 1.3.3 (Size, Shape, Location)

1.3.3 [begin delete]Information required to understand and operate content does[end delete] [begin add]Instructions provided for understanding and operating content do[end add] not rely on shape, size, visual location, or orientation of components. [LC-1160] [LC-640] (Level A)

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.

Specific Benefits of Success Criterion 1.3.3:

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

Techniques for Addressing Success Criterion 1.3.3

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Common Failures Identified by the Working Group

The following are common mistakes that are considered failures of Success Criterion 1.3.3 by the WCAG Working Group.

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.

  • [begin change]

    Using an image with a text alternative for graphical symbols instead of a Unicode font glyph with the desired graphical appearance but different meaning (future link) [LC-798]

    [end change]

Examples of Success Criterion 1.3.3

  • [begin add]Example 1: A schedule of competitive events uses color and shape to distinguish the time of each event[end add]

    [begin add]A table presents a list of times across the top row and a list of events in the first vertical column. The cell corresponding to the time of a particular event has a specific background color and diamond shaped glyph so it can be identified by color and shape.[end add] [LC-1082]

  • [begin add]Example 2: An on-line multi-page survey [end add]

    [begin add]An on-line multi-page survey uses a link implemented as a green arrow icon placed in the lower right hand corner of the content to move from one survey page to the next. The arrow is clearly labeled with "Next" and the instructions state, "To move to the next section of the survey, select the green arrow icon labeled 'Next' in the lower right below the last survey question." This example uses both positioning, color and labeling to help identify the icon.[end add] [LC-1082]


[begin delete]

Understanding Success Criterion 1.3.4 (REMOVED) (Text Variations)

[begin delete]

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. [LC-588] (Level AA)

[end delete]

Key Terms

variations in presentation of text

changes in the visual appearance or sound of the text[begin change]; or, if auditory presentation is specified in the content, changes in the sound of text such as voice.[end change] [begin delete], such as changing to a different font or a different voice[end delete] [LC-852]

programmatically determined

determined by software from [begin add]author-supplied[end add] data provided in a [begin delete] user-agent-supported manner such that the[end delete] [begin add]way that different[end add] user agents, including assistive technologies, can extract and present this information to users in different modalities [LC-756] [LC-1502]

[begin add]

Example: Determined in a mark-up language from elements and attributes that are accessed directly by commonly available assistive technology.

[end add]
[begin add]

Example: Determined from technology-specific data structures in a non-mark-up language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.

[end add]

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.

Specific Benefits of Success Criterion 1.3.4 (REMOVED):

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

[begin delete]

Techniques for Addressing Success Criterion 1.3.4 (REMOVED)

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

[begin delete]

Sufficient Techniques

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

  2. Marking emphasized or special text using one of the following techniques:

    • Using semantic markup to mark emphasized or special text

[end delete]
[begin delete]

Common Failures Identified by the Working Group

The following are common mistakes that are considered failures of Success Criterion 1.3.4 (REMOVED) by the WCAG Working Group.

  • Failure due to using CSS to create variations in presentation of text that conveys information without also using the appropriate markup or text

[end delete]

Additional Techniques (Advisory) for 1.3.4 (REMOVED)

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.

  • [begin delete]Ensure that numerals or other look alike glyphs are not used in place of letters (future link) [LC-796] [end delete]

[end delete]

Examples of Success Criterion 1.3.4 (REMOVED)

  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.


[end delete]

Understanding Guideline 1.4: Make it easier for people with disabilities to see and hear content including separating foreground from 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 (not success criteria specific)

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


Understanding Success Criterion 1.4.1 (Use of Color)

[begin change]

1.4.1 Any information that is conveyed by color [begin add]differences[end add] is also [begin add]simultaneously[end add] visually evident without [begin delete]color[end delete] [begin add]the color differences[end add]. [LC-742] (Level A)

[end change]

Key Terms

information that is conveyed by color [begin add]differences[end add]

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

[begin change]

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 differences. If the information is conveyed through color differences in an image (or other non-text format), the color may not be seen by those with color deficiencies. In this case, providing the information conveyed with color through another visual means ensures users who cannot see 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.

Specific Benefits of Success Criterion 1.4.1:

This success criterion benefits people with visual disabilities:

  • Users with partial sight often experience limited color vision.

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

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

[end change]

Techniques for Addressing Success Criterion 1.4.1

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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. G14: Ensuring that color-encoded information is also available in text

  2. G122: Including a text cue whenever color cues are used

  3. [begin add]

    Ensuring that when text color is used to convey information, the text style is visually differentiated without color (future link) [LC-559] [LC-560]

    [end add]
Situation B: If color is used within an image to convey information:
  1. G111: Using color and pattern

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

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.

  • Conveying information redundantly using color (future link)

  • Changing the background color or border of the element with focus (future link)

Examples of Success Criterion 1.4.1

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

  • Disabled Form elements.

    [begin add]Form elements which are disabled via markup or scripting, are greyed out and made inactive by the user agent. When in the disabled state these elements do not receive focus. Assistive technologies can programmatically determine the state of disabled elements and will provide this information to the user as the elements are encountered on the page. The change in color and loss of focus provides redundant, visual information about the state of the control.[end add] [LC-717]

Related Resources

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Success Criterion 1.4.2 (Audio Turnoff)

[begin change]

1.4.2 [begin change]If any audio plays automatically for more than 3 seconds, [begin add]either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume which can be set independently of the system volume.[end add] [begin delete]mechanism is available to turn it off without requiring the user to turn off all system audio.[end delete] [LC-1162] [LC-1286] [LC-1085] [LC-1237] [end change] (Level A)

[end change]

Key Terms

mechanism

process or technique for achieving a result

[begin add]

Note 1: The mechanism may be explicitly provided in the content, or may be relied on to be provided by either the platform or by user agents, including assistive technologies.

Note 2: The mechanism must meet all success criteria for the conformance level claimed. [LC-619]

[end add]

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. [begin add]Therefore, it is important that the user be able to turn off the background sound. Note: Having control of the volume includes being able to reduce its volume to zero.[end add]

Specific Benefits of Success Criterion 1.4.2:

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

  • [begin change]

    This success criterion also benefits people who have difficulty focusing on visual content (including text) when audio is playing.

    [end change]

Techniques for Addressing Success Criterion 1.4.2

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. G60: 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 page that turns off sounds that play automatically (future link)

  4. [begin add]

    Providing a user interface control to pause or stop multimedia (future link) [LC-1286]

    [end add]

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 page that turns off sounds that play automatically (future link)

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.

  • [begin add]A Flash splash page with sound that plays and then stops in less than 3 seconds. [LC-794] [end add]

  • [begin add]A Flash splash page with sound that plays automatically includes a control at the top that allows users to turn the sound off. [LC-794] [end add]


Understanding Success Criterion 1.4.3 (Contrast (Minimum))

[begin change]
[begin change]

1.4.3 Text (and images of text) have a contrast ratio of at least 5:1, except if the text is pure decoration. Larger-scale text or images of text can have a contrast ratio of 3:1. [LC-511] (Level AA)

[end change]
[end change]

Key Terms

text
[begin change]

sequence of characters [begin add]that can be programmatically determined, where the sequence is expressing something in human language [LC-954] [end add]

[end change]
[begin delete]

Note 1: [begin add]This definition does not place requirements on the specific encoding of characters. For advice about appropriate character encodings, refer to [I18N-CHAR-ENC]. [LC-849] [end add]

Note 2: Characters are those included in the Unicode/ISO/IEC 106464 repertoire.

[end delete]
contrast ratio

(L1 + 0.05) / (L2 + 0.05), where

  • L1 is the [begin change] relative luminance [LC-580] [end change] of the lighter of the [begin change]foreground [LC-1182] [end change] or background colors, and

  • L2 is the [begin change] relative luminance [LC-580] [end change] of the darker of the [begin change]foreground [LC-1182] [end change] or background colors.

Note 1: Contrast ratios can range from 1 to 21 (commonly written 1:1 to 21:1).

Note 2: For dithered colors, use the average values of the colors that are dithered (average R, average G, and average B).

Note 3: Text can be evaluated with anti-aliasing turned off.

Note 4: Background color is the specified color of content over which the text is to be rendered in normal usage. If no background color is specified, then white is assumed.

Note 5: For text displayed over gradients and background images, authors should ensure that sufficient contrast exists for each part of each character in the content.

pure decoration

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

[begin add]

Note: Text is only purely decorative if the words can be rearranged or substituted without changing their purpose.

[end add]
[begin add]

Example: The cover page of a dictionary has random words in very light text in the background.

[end add]
larger scale (text)
[begin add]

at least 18 point or 14 point bold

[end add]

Note 1: Fonts with extraordinarily thin strokes or unusual features and characteristics that reduce the familiarity of their letter forms are harder to read, especially at lower contrast levels.

Note 2: Font size is the size when the content is delivered. It does not include resizing that may be done by a user.

[begin change]

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 read by people with moderately low vision (who do not use contrast-enhancing assistive technology). For people without color deficiencies, hue and saturation have minimal or no effect on legibility as assessed by reading performance (Knoblauch et al., 1991). Color deficiencies can affect luminance contrast somewhat. However, in the recommendation, the contrast is calculated in such a way that color is not a key factor so that people who have a color vision deficit will also have adequate contrast between the text and the background. Text that is decorative and conveys no information is excluded. For example, if random words are used to create a background and the words could be rearranged or substituted without changing meaning, then it would be decorative and would not need to meet this criterion. [LC-1161]

Text that is larger and has wider character strokes is easier to read at lower contrast. The contrast requirements for larger text is therefore lower. This allows authors to use a wider range of color choices for large text, which is helpful for design of pages, particularly titles. 18 point text or 14 point bold text is judged to be large enough to require a lower contrast ratio. "18 point" and "bold" can both have different meanings in different fonts but, except for very thin or unusual fonts, they should be sufficient. Since there are so many different fonts, the general measures are used and a note regarding fancy or thin fonts is included.

[begin add]

Rationale for the Ratios Chosen

A contrast ratio of 3:1 is the minimum level recommended by [ISO-9241-3] and [ANSI-HFES-100-1988] for standard text and vision. The 5:1 ratio is used in this provision to account for the loss in contrast that results from moderately low visual acuity, congenital or acquired color deficiencies, or the loss of contrast sensitivity that typically accompanies aging.

The rationale is that loss of logarithm of visual acuity is generally linearly related to loss of logarithm of contrast sensitivity, in people with low vision such that the user with 20/40 visual acuity would need roughly 4.5:1 contrast to have the equivalent of the 3:1 minimum contrast standard for normal vision [ARDITI-FAYE]. The user with 20/47 visual acuity would require contrast of about 5:1, and the user with 20/80 visual acuity would require contrast of about 7:1.

Hues are perceived differently by users with color vision deficiencies (both congenital and acquired) resulting in different colors and relative luminance contrasts than for normally sighted users. Because of this, effective contrast and readability are different for this population. However, color deficiencies are so diverse that prescribing effective general use color pairs (for contrast) based on quantitative data is not feasible. Requiring good luminance contrast accommodates this by requiring contrast that is independent of color perception. Fortunately, most of the luminance contribution is from the mid and long wave receptors which largely overlap in their spectral responses. The result is that effective luminance contrast can generally be computed without regard to specific color deficiency, except for the use of predominantly long wavelength colors against darker colors (generally appearing black) for those who have protanopia. (We provide an advisory technique on avoiding red on black for that reason). For more information see [ARDITI-KNOBLAUCH] [ARDITI-KNOBLAUCH-1996] [ARDITI].

The contrast ratio of 5:1 was chosen for level AA because it compensated for the loss in contrast sensitivity usually experienced by users with vision loss equivalent to approximately 20/40 vision. (20/40 calculates to approximately 4.5:1 which is rounded up to 5 providing a slight additional increase in contrast.) 20/40 is commonly reported as typical visual acuity of elders at roughly age 80. [GITTINGS-FOZARD]

The contrast ratio of 7:1 was chosen for level AAA because it compensated for the loss in contrast sensitivity usually experienced by users with vision loss equivalent to approximately 20/80 vision. People with more than this degree of vision loss usually use assistive technologies to access their content (and the assistive technologies usually have contrast enhancing, as well as magnification capability built into them). The 7:1 level therefore generally provides compensation for the loss in contrast sensitivity experienced by users with low vision who do not use assistive technology and provides contrast enhancement for color deficiency as well.

Note: Calculations in [ISO-9241-3] and [ANSI-HFES-100-1988] are for body text. A relaxed contrast ratio is provided for text that is much larger.

[end add]
[begin add]

Notes on formula

Conversion from nonlinear to linear RGB values is based on IEC/4WD 61966-2-1 [IEC-4WD] and on "A Standard Default Color Space for the Internet - sRGB" [sRGB].

The formula (L1/L2) for contrast is based on [ISO-9241-3] and [ANSI-HFES-100-1988] standards.

The ANSI/HFS 100-1988 standard calls for the contribution from ambient light to be included in the calculation of L1 and L2. The .05 value used is based on Typical Viewing Flare from [IEC-4WD] and the [sRGB] paper by M. Stokes et al.

This success criterion and its definitions use the terms "contrast ratio" and "relative luminance" rather than "luminance" to reflect the fact that Web content does not emit light itself. The contrast ratio gives a measure of the relative luminance that would result when displayed. (Because it is a ratio, it is dimensionless.)

Note: [begin add]Refer to related resources for a list of tools that utilize the contrast ratio to analyze the contrast of Web content. [LC-603] [end add]

[end add]

Specific Benefits of Success Criterion 1.4.3:

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

[end change]

Techniques for Addressing Success Criterion 1.4.3

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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: text is less than 18 point if not bold and less than 14 point if bold
  1. G18: Ensuring that a contrast ratio of at least 5:1 exists between text and background behind the text

  2. H21: Not specifying background color, not specifying text color, and not using CSS that changes those defaults (HTML)

Situation B: text is as least 18 point if not bold and at least 14 point if bold
  1. G145: Ensuring that a contrast ratio of at least 3:1 exists between text and background behind the text

  2. H21: Not specifying background color, not specifying text color, and not using CSS that changes those defaults (HTML)

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.

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)

  • Creating foreground and background contrast (future link)

  • [begin add]

    Using a light pastel background rather than a white background behind black text (future link) [LC-840]

    [end add]
  • [begin add]

    Using Unicode text and style sheets instead of images of text (future link) [LC-511]

    [end add]
  • [begin add]

    Using a higher contrast values for lines in diagrams (future link)

    [end add]
  • [begin add]

    Using greater contrast level for red-black text/background combinations

    [end add]
  • [begin add]

    Using colors that are composed predominantly of mid spectral components for the light and spectral extremes (blue and red wavelengths) for the dark

    [end add]

Examples of Success Criterion 1.4.3

Related Resources

Resources are for information purposes only, no endorsement implied.


[begin add]

Understanding Success Criterion 1.4.4 (Resize text)

[begin add]

1.4.4 Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality. [LC-469] (Level AA)

[end add]

Key Terms

Assistive technology ([begin change]as used in this document [LC-732] [end change])

a user agent that [begin add]both[end add]:

  1. [begin change]

    provides services to meet the requirements of users with disabilities that go beyond those offered by the mainstream user agents. Such services include alternative presentations (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)[begin add], and[end add] [LC-1178]

    [end change]
  2. usually relies on services (such as retrieving Web content and parsing markup) provided by one or more other mainstream user agents. Assistive technologies communicate data and messages with mainstream user agents by using and monitoring APIs

Note 1: [begin add]In this definition, user agents are user agents in the general sense of the term. That is, any software that retrieves and [begin change]presents[end change] Web content for users. The mainstream user agent may provide important services to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles. [LC-732] [end add]

Note 2: [begin add]Mainstream user agents may also provide services directly that meet the requirements of users with disabilities. [LC-732] [end add]

Note 3: This definition is based on User Agent Accessibility Guidelines 1.0 Glossary.

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

  • screen magnifiers, [begin change]and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc in order [LC-604] [end change] improve the visual readability of rendered text and images;

  • screen readers, which are used by people who are blind [begin change]to read textual information through synthesized speech or braille[end change];

  • [begin add]

    text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;

    [end add]
  • 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.

Intent of this Success Criterion

The intent of this success criterion is to ensure that visually rendered text can be scaled successfully so that it can be read directly by people with mild visual disabilities, without requiring the use of assistive technology such as a screen magnifier. Users may benefit from scaling all content on the Web page, but text is most critical.

The scaling of content is primarily a user agent responsibility. User agents that satisfy UAAG 1.0 Checkpoint 4.1 allow users to configure text scale. The author's responsibility is to create web content that does not prevent the user agent from scaling the content effectively. Authors may satisfy this success criterion by verifying that content does not interfere with user agent support for resizing text, or by providing direct support for resizing text or changing the layout. An example of direct support might be via server-side script that can be used to assign different style sheets.

Content satisfies the success criterion if it can be scaled up to 200%, that is, up to twice the width and height. Authors may support scaling beyond that limit, however, as scaling becomes more extreme, adaptive layouts may introduce usability problems. For example, words may be too wide to fit into the horizontal space available to them, causing them to be truncated; layout constraints may cause text to overlap with other content when it is scaled larger; or only one word of a sentence may fit on each line, causing the sentence to be displayed as a vertical column of text that is difficult to read.

The working group feels that 200% is a reasonable accommodation that can support a wide range of designs and layouts, and complements older screen magnifiers that provide a minimum magnification of 200%. Above 200%, zoom (which resizes text, images, and layout regions and creates a larger canvas that may require both horizontal and vertical scrolling) may be more effective than text resizing. Assistive technology dedicated to zoom support would usually be used in such a situation and may provide better accessibility than attempts by the author to support the user directly.

Specific Benefits of Success Criterion 1.4.4:

  • This success criterion helps people with low vision by letting them increase text size in content so that they can read it.

Techniques for Addressing Success Criterion 1.4.4

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. Ensuring that text containers resize when the text resizes AND using measurements that are relative to other measurements in the content by using one or more of the following techniques:

  2. Providing controls on the Web page that incrementally change the size of the text (future link)

  3. Providing options within the content to switch between layouts that use a variety of font sizes (future link)

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.

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.

  • Providing large fonts by default (future link)

  • Avoiding the use of text in raster images (future link)

  • Using page-percent for container sizes (future link)

  • Avoiding scaling font sizes smaller than the user-agent default (future link)

    Note: The author won't actually know the font size, but should avoid percentage scaling that results in less than 100%

  • Avoiding justified text (future link) [LC-569]

  • Providing sufficient inter-line and inter-column spacing (future link) [LC-569]

Examples of Success Criterion 1.4.4

  • A user with vision impairments increases the text size on a web page in a browser from 1 em to 1.2 ems. While the user could not read the text at the smaller size, she can read the larger text. All the information on the page is still displayed when the larger font is used for the text.

  • A Web page contains a control for changing the scale of the page. Selecting different settings changes the layout of the page to use the best design for that scale.

  • A user uses a zoom function in his user agent to change the scale of the content. All the content scales uniformly, and the user agent provides scroll bars, if necessary.

Related Resources

Resources are for information purposes only, no endorsement implied.


[end add]

Understanding Success Criterion 1.4.5 (Contrast (Enhanced))

[begin change]

1.4.5 Text (and images of text) have a contrast ratio of at least 7:1, except if the text is pure decoration. Larger-scale text or images of text can have a contrast ratio of 5:1. [LC-511] (Level AAA)

[end change]

Key Terms

text
[begin change]

sequence of characters [begin add]that can be programmatically determined, where the sequence is expressing something in human language [LC-954] [end add]

[end change]
[begin delete]

Note 1: [begin add]This definition does not place requirements on the specific encoding of characters. For advice about appropriate character encodings, refer to [I18N-CHAR-ENC]. [LC-849] [end add]

Note 2: Characters are those included in the Unicode/ISO/IEC 106464 repertoire.

[end delete]
contrast ratio

(L1 + 0.05) / (L2 + 0.05), where

  • L1 is the [begin change] relative luminance [LC-580] [end change] of the lighter of the [begin change]foreground [LC-1182] [end change] or background colors, and

  • L2 is the [begin change] relative luminance [LC-580] [end change] of the darker of the [begin change]foreground [LC-1182] [end change] or background colors.

Note 1: Contrast ratios can range from 1 to 21 (commonly written 1:1 to 21:1).

Note 2: For dithered colors, use the average values of the colors that are dithered (average R, average G, and average B).

Note 3: Text can be evaluated with anti-aliasing turned off.

Note 4: Background color is the specified color of content over which the text is to be rendered in normal usage. If no background color is specified, then white is assumed.

Note 5: For text displayed over gradients and background images, authors should ensure that sufficient contrast exists for each part of each character in the content.

pure decoration

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

[begin add]

Note: Text is only purely decorative if the words can be rearranged or substituted without changing their purpose.

[end add]
[begin add]

Example: The cover page of a dictionary has random words in very light text in the background.

[end add]
larger scale (text)
[begin add]

at least 18 point or 14 point bold

[end add]

Note 1: Fonts with extraordinarily thin strokes or unusual features and characteristics that reduce the familiarity of their letter forms are harder to read, especially at lower contrast levels.

Note 2: Font size is the size when the content is delivered. It does not include resizing that may be done by a user.

[begin change]

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 read by people with moderately low vision (who do not use contrast-enhancing assistive technology). For people without color deficiencies, hue and saturation have minimal or no effect on legibility as assessed by reading performance (Knoblauch et al., 1991). Color deficiencies can affect luminance contrast somewhat. However, in the recommendation, the contrast is calculated in such a way that color is not a key factor so that people who have a color vision deficit will also have adequate contrast between the text and the background. Text that is decorative and conveys no information is excluded. For example, if random words are used to create a background and the words could be rearranged or substituted without changing meaning, then it would be decorative and would not need to meet this criterion. [LC-1161]

Text that is larger and has wider character strokes is easier to read at lower contrast. The contrast requirements for larger text is therefore lower. This allows authors to use a wider range of color choices for large text, which is helpful for design of pages, particularly titles. 18 point text or 14 point bold text is judged to be large enough to require a lower contrast ratio. "18 point" and "bold" can both have different meanings in different fonts but, except for very thin or unusual fonts, they should be sufficient. Since there are so many different fonts, the general measures are used and a note regarding fancy or thin fonts is included.

[begin add]

Rationale for the Ratios Chosen

A contrast ratio of 3:1 is the minimum level recommended by [ISO-9241-3] and [ANSI-HFES-100-1988] for standard text and vision. The 5:1 ratio is used in Success Criterion 1.4.3 to account for the loss in contrast that results from moderately low visual acuity, congenital or acquired color deficiencies, or the loss of contrast sensitivity that typically accompanies aging.

The rationale is that loss of logarithm of visual acuity is generally linearly related to loss of logarithm of contrast sensitivity, in people with low vision such that the user with 20/40 visual acuity would need roughly 4.5:1 contrast to have the equivalent of the 3:1 minimum contrast standard for normal vision [ARDITI-FAYE]. The user with 20/47 visual acuity would require contrast of about 5:1, and the user with 20/80 visual acuity would require contrast of about 7:1.

Hues are perceived differently by users with color vision deficiencies (both congenital and acquired) resulting in different colors and relative luminance contrasts than for normally sighted users. Because of this, effective contrast and readability are different for this population. However, color deficiencies are so diverse that prescribing effective general use color pairs (for contrast) based on quantitative data is not feasible. Requiring good luminance contrast accommodates this by requiring contrast that is independent of color perception. Fortunately, most of the luminance contribution is from the mid and long wave receptors which largely overlap in their spectral responses. The result is that effective luminance contrast can generally be computed without regard to specific color deficiency, except for the use of predominantly long wavelength colors against darker colors (generally appearing black) for those who have protanopia. (We provide an advisory technique on avoiding red on black for that reason). For more information see [ARDITI-KNOBLAUCH] [ARDITI-KNOBLAUCH-1996] [ARDITI].

The contrast ratio of 5:1 was chosen for level AA because it compensated for the loss in contrast sensitivity usually experienced by users with vision loss equivalent to approximately 20/40 vision. (20/40 calculates to approximately 4.5:1 which is rounded up to 5 providing a slight additional increase in contrast.) 20/40 is commonly reported as typical visual acuity of elders at roughly age 80. [GITTINGS-FOZARD]

The contrast ratio of 7:1 was chosen for level AAA because it compensated for the loss in contrast sensitivity usually experienced by users with vision loss equivalent to approximately 20/80 vision. People with more than this degree of vision loss usually use assistive technologies to access their content (and the assistive technologies usually have contrast enhancing, as well as magnification capability built into them). The 7:1 level therefore generally provides compensation for the loss in contrast sensitivity experienced by users with low vision who do not use assistive technology and provides contrast enhancement for color deficiency as well.

Note: Calculations in [ISO-9241-3] and [ANSI-HFES-100-1988] are for body text. A relaxed contrast ratio is provided for text that is much larger.

[end add]
[begin add]

Notes on formula

Conversion from nonlinear to linear RGB values is based on IEC/4WD 61966-2-1 [IEC-4WD] and on "A Standard Default Color Space for the Internet - sRGB" [sRGB].

The formula (L1/L2) for contrast is based on [ISO-9241-3] and [ANSI-HFES-100-1988] standards.

The ANSI/HFS 100-1988 standard calls for the contribution from ambient light to be included in the calculation of L1 and L2. The .05 value used is based on Typical Viewing Flare from [IEC-4WD] and the [sRGB] paper by M. Stokes et al.

This success criterion and its definitions use the terms "contrast ratio" and "relative luminance" rather than "luminance" to reflect the fact that Web content does not emit light itself. The contrast ratio gives a measure of the relative luminance that would result when displayed. (Because it is a ratio, it is dimensionless.)

Note: [begin add]Refer to related resources for a list of tools that utilize the contrast ratio to analyze the contrast of Web content. [LC-603] [end add]

[end add]

Specific Benefits of Success Criterion 1.4.5:

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

[end change]

Techniques for Addressing Success Criterion 1.4.5

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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: text is less than 18 point if not bold and less than 14 point if bold
  1. G17: Ensuring that a contrast ratio of at least 7:1 exists between text and background behind the text

  2. H21: Not specifying background color, not specifying text color, and not using CSS that changes those defaults (HTML)

Situation B: text is as least 18 point if not bold and at least 14 point if bold
  1. G18: Ensuring that a contrast ratio of at least 5:1 exists between text and background behind the text

  2. H21: Not specifying background color, not specifying text color, and not using CSS that changes those defaults (HTML)

Common Failures Identified by the Working Group

The following are common mistakes that are considered failures of Success Criterion 1.4.5 by the WCAG Working Group.

Additional Techniques (Advisory) for 1.4.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 a higher contrast value for text that is over a patterned background (future link)

  • [begin add]

    Using Unicode text and style sheets instead of images of text (future link) [LC-511]

    [end add]
  • [begin add]

    Using a light pastel background rather than a white background behind black text (future link) [LC-840]

    [end add]
  • [begin add]

    Using a higher contrast values for lines in diagrams (future link)

    [end add]
  • [begin add]

    Using greater contrast level for red-black text/background combinations

    [end add]
  • [begin add]

    Using colors that are composed predominantly of mid spectral components for the light and spectral extremes (blue and red wavelengths) for the dark

    [end add]

Examples of Success Criterion 1.4.5

Related Resources

Resources are for information purposes only, no endorsement implied.


Understanding Success Criterion 1.4.6 (Low or No Background Audio)

1.4.6 Audio content [begin add]that contains speech in the foreground[end add] does not contain background sounds, background sounds can be turned off, or background sounds are at least 20 decibels lower than the foreground [begin delete]audio[end delete] [begin add]speech[end add] content, with the exception of occasional sound effects. [LC-743] (Level AAA)

Note: [begin delete]A 20 decibel difference in sound level is roughly four times (4x) quieter or louder. [end delete] [begin change]Background sound that meets this requirement will be approximately one quarter as loud as the foreground speech content. [LC-743] [LC-1163] [end change]

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. [begin change]Background sound that meets this requirement will be approximately one quarter as loud as the foreground speech content. [LC-743] [end change]

[begin add]

The value of 20 dB was chosen based on Large area assistive listening systems (ALS): Review and recommendations [LAALS] and In-the-ear measurements of interference in hearing aids from digital wireless telephones [HEARING-AID-INT] [LC-1228]

[end add]

Specific Benefits of Success Criterion 1.4.6:

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

Techniques for Addressing Success Criterion 1.4.6

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Common Failures Identified by the Working Group

The following are common mistakes that are considered failures of Success Criterion 1.4.6 by the WCAG Working Group.

(No failures currently documented)

Additional Techniques (Advisory) for 1.4.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 a way for users to adjust auditory levels of foreground and background sound independently (future link)

Examples of Success Criterion 1.4.6

Related Resources

Resources are for information purposes only, no endorsement implied.


[begin add]

Understanding Success Criterion 1.4.7 (Resize and Wrap)

[begin add]

1.4.7 Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality and in a way that does not require the user to scroll horizontally. [LC-469] (Level AAA)

[end add]

Key Terms

Assistive technology ([begin change]as used in this document [LC-732] [end change])

a user agent that [begin add]both[end add]:

  1. [begin change]

    provides services to meet the requirements of users with disabilities that go beyond those offered by the mainstream user agents. Such services include alternative presentations (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)[begin add], and[end add] [LC-1178]

    [end change]
  2. usually relies on services (such as retrieving Web content and parsing markup) provided by one or more other mainstream user agents. Assistive technologies communicate data and messages with mainstream user agents by using and monitoring APIs

Note 1: [begin add]In this definition, user agents are user agents in the general sense of the term. That is, any software that retrieves and [begin change]presents[end change] Web content for users. The mainstream user agent may provide important services to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles. [LC-732] [end add]

Note 2: [begin add]Mainstream user agents may also provide services directly that meet the requirements of users with disabilities. [LC-732] [end add]

Note 3: This definition is based on User Agent Accessibility Guidelines 1.0 Glossary.

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

  • screen magnifiers, [begin change]and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc in order [LC-604] [end change] improve the visual readability of rendered text and images;

  • screen readers, which are used by people who are blind [begin change]to read textual information through synthesized speech or braille[end change];

  • [begin add]

    text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;

    [end add]
  • 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.

Intent of this Success Criterion

The intent of this success criterion is to ensure that visually rendered text can be scaled successfully without requiring that the user scroll left and right to see all of the content. When the content has been authored so that this is possible, the content is said to reflow. This permits low vision users to increase the size of the text without becoming disoriented.

The scaling of content is primarily a user agent responsibility. User agents that satisfy UAAG 1.0 Checkpoint 4.1 allow users to configure text scale. The author's responsibility is to create Web content that does not prevent the user agent from scaling the content and that allows the reflow of the content within the current width of the viewport.

Content satisfies the success criterion if it can be scaled up to 200%, that is, up to twice the width and height, although authors may support scaling beyond that limit. However, as scaling becomes more extreme, adaptive layouts may introduce usability problems. For example, words may be too wide to fit into the horizontal space available to them, causing them to be truncated; layout constraints may cause text to overlap with other content when it is scaled larger; or only one word of a sentence may fit on each line, causing the sentence to be displayed as a vertical column of text that is difficult to read.

The working group feels that 200% is a reasonable accommodation that can support a wide range of designs and layouts, and complements older screen magnifiers that provide a minimum magnification of 200%. Above 200%, zoom (which resizes text, images, and layout regions and creates a larger canvas that may require both horizontal and vertical scrolling) may be more effective than text resizing. Assistive technology dedicated to zoom support would usually be used in such a situation and may provide better accessibility than attempts by the author to support the user directly.

It is important to note that horizontal scrolling may be unavoidable for some types of content. For example, content that includes large images may cause user agents to display horizontal scroll bars in where the width of the viewport has been resized to a width that is less than the width of the image.

Specific Benefits of Success Criterion 1.4.7:

  • This success criterion helps people with low vision by letting them increase text size in content so that they can read it easily. Because there is no need to scroll left and right while reading the text, users are less likely to become disoriented and lose their place.

Techniques for Addressing Success Criterion 1.4.7

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. G146: Using liquid layout AND ensuring that text containers resize when the text resizes AND using measurements that are relative to other measurements in the content by using one or more of the following techniques:

  2. Providing options within the content to switch between layouts that use a variety of font sizes (future link)

  3. Using single-column layouts (future link)

Common Failures Identified by the Working Group

The following are common mistakes that are considered failures of Success Criterion 1.4.7 by the WCAG Working Group.

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

  • Providing large fonts by default (future link)

  • Avoiding the use of text in raster images (future link)

  • Using page-percent for container sizes (future link)

  • Avoiding scaling font sizes smaller than the user-agent default (future link)

    Note: The author won't actually know the font size, but should avoid percentage scaling that results in less than 100%

  • Avoiding justified text (future link) [LC-569]

  • Providing sufficient inter-line and inter-column spacing (future link) [LC-569]

Examples of Success Criterion 1.4.7

  • A user with vision impairments increases the text size on a web page in a browser from 10 points to 14 points. While the user could not read the text at the smaller size, she can read the larger text. All the information on the page is still displayed when the larger font is used for the text. While the user may need to scroll up and down to see all of the content, it is not necessary to scroll left or right, that is, all of the content fits between the left and right edges of the viewport.

  • A Web page contains a control for changing the scale of the page. Selecting different settings changes the layout of the page to use the best design for that scale.

Related Resources

Resources are for information purposes only, no endorsement implied.


[end add]

Understanding Guideline 2.1: Make all functionality available from a keyboard

Intent of Guideline 2.1

If all functionality can be achieved using the keyboard, 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 (not success criteria specific)

Specific techniques for meeting each success criterion for this guideline are listed in the understanding sections for each success criterion (listed below). If there are techniques, however, for addressing this guideline that do not fall under any of the success criteria, they are listed here. These techniques are not required or sufficient for meeting any success criteria, but 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.

Understanding Success Criterion 2.1.1 (Keyboard)

2.1.1 All functionality of the content is operable [begin change]through a keyboard interface without requiring specific timings for individual keystrokes, except where the [begin add]underlying function[end add] requires [begin add]input that depends on the path of the user's movement and not just the endpoints.[end add] [begin delete]time-dependent analog input[end delete] [end change] [LC-921] [LC-922] [LC-1164] (Level A)

[begin add]

Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.

[end add]
[begin change]

Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

[end change]

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.

[begin change]

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 (so an alternate keyboard can be used). 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 the use of software much easier (or only possible) if they can control it from the keyboard.

[begin add]

Examples of "specific timings for individual keystrokes" include situations where a user would be required to repeat or execute multiple keystrokes within a short period of time or where a key must be held down for an extended period before the keystroke is registered. [LC-1164]

[end add]

The phrase "except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints" is included to separate those things that cannot reasonably be controlled from a keyboard.

[begin add]

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 without requiring an inordinate number of keystrokes. Free hand drawing, watercolor painting, and flying a helicopter through an obstacle course are all examples of functions that require path dependent input. Drawing straight lines, regular geometric shapes, re-sizing windows and dragging objects to a location (when the path to that location is not relevant) do not require path dependent input. [LC-921] [LC-922] [LC-1413]

[end add]
[begin add]

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

[end add]

Specific Benefits of Success Criterion 2.1.1:

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

  • [begin add]Some people with hand tremors find using a mouse very difficult and therefore usually use a keyboard [LC-1086] [end add]

[end change]

Techniques for Addressing Success Criterion 2.1.1

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. G21: Ensuring that users are not trapped in content AND ensuring keyboard control by using one of the following techniques.

    • Using HTML form controls and links (future link)

  2. G21: Ensuring that users are not trapped in content AND G90: Providing keyboard-triggered event handlers using one of the following 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)

  • [begin add]

    Avoiding use of common user-agent keyboard commands for other purposes (future link) [LC-726]

    [end add]

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


Understanding Success Criterion 2.1.2 (Keyboard (No Exception))

[begin change]

2.1.2 All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA)

[end change]

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 content where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (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 AAA.

Techniques for Addressing Success Criterion 2.1.2

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  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 AAA Success Criterion.


Understanding Guideline 2.2: Provide users with disabilities enough time to read and use content

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 (not success criteria specific)

Specific techniques for meeting each success criterion for this guideline are listed in the understanding sections for each success criterion (listed below). If there are techniques, however, for addressing this guideline that do not fall under any of the success criteria, they are listed here. These techniques are not required or sufficient for meeting any success criteria, but 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.

Understanding Success Criterion 2.2.1 (Timing)

2.2.1 For each [begin change]time limit[end change] that is [begin delete]a function of the content[end delete] [begin add]set by the content [LC-1166] [end add], at least one of the following is true: [LC-996] (Level A)

  • Turn off: the user is allowed to turn off the [begin change]time limit[end change] [begin add]before encountering it; or [LC-1238] [end add]

  • Adjust: the user is allowed to adjust the [begin change]time limit[end change] [begin add]before encountering it [LC-1238] [end add] over a wide range that is at least ten times the length of the default setting; or

  • Extend: the user is warned before time expires and given at least 20 seconds to extend the [begin change]time limit[end change] with a simple action (for example, "hit any key"), and the user is allowed to extend the [begin change]time limit[end change] at least ten times; or

  • Real-time Exception: the [begin change]time limit[end change] is a[begin delete]n important[end delete] [begin add]required [LC-1046] [end add] part of a real-time event (for example, an auction), and no alternative to the [begin change]time limit[end change] is possible; or

  • Essential Exception: the [begin change]time limit[end change] is part of an activity where timing is essential (for example, [begin delete]competitive gaming or [end delete]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 [begin change]time limit[end change] 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 time limits, customize the length of [begin change]time limits[end change], or request more time before a [begin change]time limit[end change] occurs helps those users who require more time than expected to successfully complete tasks. [begin add]Any process that happens without user initiation after a set time or on a periodic basis is a [begin change]time limit[end change]. This includes partial or full updates of content, changes to content, or the expiration of a window of opportunity for a user to react to a request for input. [LC-1089] [end add]

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

Notes regarding server time limits

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

  • Server [begin change]time limits[end change] 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 [begin change]time limit[end change]: they work instantly.

  • [begin add]This Success Criterion applies only to time limits that are set by the content itself. Time limits set externally to content, such as by the user agent or by factors intrinsic to the Internet, are not under the author's control and not subject to WCAG conformance requirements. Time limits set by Web servers should be under the author's control and are addressed by other SC. [LC-1166] [end add]

  • [begin add]

    10 times the default was chosen based on clinical experience and other guidelines. For example, if 15 seconds is allowed for a user to respond and hit a switch, 150 seconds would be sufficient to allow almost all users to hit a switch even if they had trouble. [LC-1230]

    [end add]
  • [begin add]

    20 seconds was also based on clinical experience and other guidelines. 20 seconds to hit 'any switch' is sufficient for almost all users including those with spasticity. Some would fail, but some would fail all lengths of time. A reasonable period for requesting more time is required since an arbitrarily long time can provide security risks to all users, including those with disabilities, for some applications. For example, with kiosks or terminals that are used for financial transactions, it is quite common for people to walk away without signing off. This leaves them vulnerable to those walking up behind them. Providing a long period of inactivity before asking, and then providing a long period for the person to indicate that they are present can leave terminals open for abuse. If there is no activity the system should ask if the user is there. It should then ask for an indication that a person is there ('hit any key') and then wait long enough for almost anyone to respond. For "hit any key," 20 seconds would meet this. If the person indicates that they are still present, the device should return the user to the exact condition that existed before it asked the question. [LC-1230]

    [end add]

Specific Benefits of Success Criterion 2.2.1:

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

Techniques for Addressing Success Criterion 2.2.1

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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 there are session [begin change]time limit[end change]s:
  1. G133: Providing a checkbox on the first page of a multipart form that allows users to ask for longer session time limit or no session time limit

Situation B: If a [begin change]time limit[end change] is controlled by a script on the page:
  1. Providing a way for the user to turn the [begin change]time limit[end change] off (future link)

  2. Providing the user with a means to set the [begin change]time limit[end change] to 10 times the default [begin change]time limit[end change] (future link)

  3. SCR16: Providing a script that warns the user a time limit is about to expire (SCRIPT) AND SCR1: Allowing the user to extend the default time limit (SCRIPT)

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 [begin change]time limit[end change] is present (future link)

Examples of Success Criterion 2.2.1

  • A Web site uses a client side [begin change]time limit[end change] to help protect consumers who may step away from their computer. After a period of inactivity the Web page asks if the user needs more time. If it doesn’t get a response – it times out.

  • [begin change]

    A Web page has a field that automatically updates with the latest headlines in a rotating fashion. There is an interactive control that allows the user to extend the length of time between each update to as much as 10 times the default. The control can be operated with either a mouse or a keyboard. [LC-783]

    [end change]
  • [begin change]

    In an auction, there is a time limit on the amount of time a user has to submit a bid. Since the time limit applies to all users who want to bid on a particular item, it would be unfair to extend the time limit for any one particular user. Therefore, a time limit is required for this type of activity and no extension, adjustment, or deactivation of the time limit is required by this success criteria. [LC-1046]

    [end change]
  • [begin add]

    An on-line ticket-purchasing site gives the user two minutes to confirm a purchase before the seats are returned to the general pool. Because tickets on such sites can sell out quickly, holding a ticket longer than that may invalidate the nature of the site, so this is a case in which the timing is essential and cannot be extended without invalidating the activity. However, the site does move as much of the process out of the time-critical period as possible, for instance allowing users to provide necessary information like name, payment method, etc., before entering the time-critical stage. [LC-1167]

    [end add]
  • [begin add]

    A ticket-purchasing site allows the user two minutes to confirm purchase of selected seats, but warns the user when their time is almost out and allows the user to extend this time limit some number of times with a simple action such as clicking a "Extend time limit" button. [LC-1167]

    [end add]

Related Resources

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Success Criterion 2.2.2 (Blinking)

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 page. [begin delete] or authored component[end delete] [LC-745] (Level AA)

Note: For requirements related to flickering or flashing content, refer to Guideline 2.3.

blink

turn on and off between 0.5 and 3 times per second

[begin add]

Note: The slower blink is in contrast with flashing, which refers to rapid changes in brightness which can cause seizures. See general flash and red flash thresholds. [LC-1414]

[end add]
Web page
[begin change]

a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it [LC-862]

[end change]

Note: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.

[begin change]

Example 1: When you enter http://shopping.example.com/ in your browser you enter a movie-like interactive shopping environment where you visually move about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.

[end change]

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

[begin add]

Example 3: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://mail.example.com, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.

[end add]
[begin add]

Example 4: A customizable portal site, where users can choose content to display from a set of different content modules.

[end add]

The intent of this success criterion is to avoid distracting users during their interaction with a Web page. 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 page. 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.

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

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

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

  1. G11: Creating content that blinks for less than 3 seconds

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

  3. Using a control in the Web page that stops blinking content (future link) using one of the following 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 page (future link)

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

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

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Success Criterion 2.2.3 (Pausing)

2.2.3 [begin add]Moving, blinking, scrolling, or auto-updating information can be paused by the user unless it is part of an activity where timing or movement is essential. Moving content that is pure decoration can be stopped by the user.[end add] [begin delete]Content can be paused by the user unless the timing or movement is part of an activity where timing is essential.[end delete] [LC-1169] (Level AA)

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

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.

Specific Benefits of Success Criterion 2.2.3:

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

Techniques for Addressing Success Criterion 2.2.3

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. G4: Allowing the content to be paused and restarted from where it was stopped

  2. Using script to scroll content, and providing a mechanism to pause it (future link)

  3. [begin add]

    Allowing purely decorative content to be stopped (future link) [LC-1169]

    [end add]

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)

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.

    [begin change]A stock ticker has "pause" and "restart" buttons. Pausing the ticker causes it to pause on the currently displayed stock. Restarting causes the ticker to resume from the stopped point but with a notice that the display is delayed. Since the intent of the stock ticker is usually to provide realtime information, there might also be a button that would advance the ticker to the most recently traded stock. [LC-772] [end change]

  • 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

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Success Criterion 2.2.4 (Timing)

[begin change]

2.2.4 Timing is not an essential part of the event or activity presented by the content, except for [begin add]non-interactive multimedia and[end add] real-time events. [begin delete]Except for non-interactive multimedia and real-time events, timing is not an essential part of the event or activity presented by the content[end delete] [LC-1305] (Level AAA)

[end change]

Key Terms

multimedia

audio or video synchronized with another [begin delete]type of media[end delete] [begin add]format for presenting information[end add] and/or with time-based interactive components [LC-1499]

real-time event

event that a) occurs at the same time as the viewing and b) is not completely generated by the content

Example 1: A Webcast of a live performance [begin add](occurs at the same time as the viewing and is not pre-recorded)[end add].

Example 2: An on-line auction with people bidding [begin add](occurs at the same time as the viewing).[end add]

Example 3: Live humans interacting in a fantasy world using avatars [begin add](is not completely generated by the content and occurs at the same time as the viewing).[end add] [LC-1503]

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 A success criterion in that the only exception is for real-time events.

[begin add]

Note: Video only, such as sign language, is covered in Guideline 1.1. [LC-1305]

[end add]

Specific Benefits of Success Criterion 2.2.4:

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

Techniques for Addressing Success Criterion 2.2.4

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

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)

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

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Success Criterion 2.2.5 (Interruptions)

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

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.

Specific Benefits of Success Criterion 2.2.5:

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

Techniques for Addressing Success Criterion 2.2.5

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. G75: Providing a mechanism to postpone any updating of content

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

  3. SCR14: Using scripts to make nonessential alerts optional (SCRIPT)

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)

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

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Success Criterion 2.2.6 (Re-authenticating)

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

Intent of this Success Criterion

The intent of this success criterion is to allow all users to complete authenticated transactions that have inactivity [begin change]time limit[end change]s. For security reasons, many sites implement an authentication [begin change]time limit[end change] after a certain period of inactivity. These [begin change]time limits[end change] 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.

Specific Benefits of Success Criterion 2.2.6:

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

Techniques for Addressing Success Criterion 2.2.6

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. Providing options to continue without loss of data using one of the following techniques:

[begin add]

Note: Refer to Techniques for Addressing Success Criterion 2.2.1 for techniques related to providing notifications about time limits. [LC-1097]

[end add]

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)

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 [begin change]time limit[end change] occurs while 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 time-out after 30 minutes. The program prompts the user several minutes before the time-out 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 [begin change]time limit[end change]

    A long questionnaire provided within a single Web page 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 page there are several buttons provided to save the partially completed form. In addition, with JavaScript [begin change]in the list of accessibility-supported content technologies that are relied on[end change], the user can elect to be alerted via a pop-up if the session is close to timing out.

Related Resources

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Guideline 2.3: Do not create content that is known to cause seizures

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 conforming 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 (not success criteria specific)

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


Understanding Success Criterion 2.3.1 (Three Flashes or Below Threshold)

[begin change]

2.3.1 Content does [begin add]not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. [LC-1187] [end add] [begin delete]violate the general flash threshold or the red flash threshold[end delete] (Level A)

[end change]

Key Terms

general flash and red flash thresholds

a sequence of flashes or rapidly changing image sequences where all three of the following occur:

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

  2. the flashing is below 50 Hz; and

  3. [begin add]

    the combined area of flashes occurring concurrently and contiguously occupies more than a total of .006 steradians (25% of any 10 degree visual field on the screen).

    [end add]

For the general flash threshold, a flash is defined as a pair of opposing changes in relative luminance of 10% or more and the relative luminance of the darker image is below 0.80. An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase.

For the red flash threshold, a flash is defined as any transition to or from a saturated red.

[begin change]

Note 1: For general Web content, using a 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances.

[begin delete]

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

[end delete]
[end change]
[begin delete]

[LC-1187]

[end delete]

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

[begin add]

Flashing can be caused by the display, the computer rendering the image or by the content being rendered. The author has no control of the first two. They can be addressed by the design and speed of the display and computer. The intent of this criterion is to ensure that flicker that violates the flash thresholds is not caused by the content itself. For example, the content could contain a video clip or animated image of a series of strobe flashes, or close-ups of rapid-fire explosions. [LC-1414]

[end add]

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 and contiguously means the total area that is actually flashing at the same time. It is calculated by adding up the contiguous area that is flashing simultaneously within any 10 degree angle of view.

Specific Benefits of Success Criterion 2.3.1:

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

Techniques for Addressing Success Criterion 2.3.1

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

[begin change]

Sufficient Techniques

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.

[begin add]
Situation A: Web content server over the Internet for general viewing
  1. [begin add]Using all possible 341 x 256 pixel rectangles on 1024 x 768 pixel display to represent a 10 degree field of view at normal viewing distance AND [end add] G15: Ensuring that content does not violate the general flash threshold or red flash threshold

    [begin add]

    Note: There is a tool that is available to carry out this test.

    [end add]
[end add]
[begin add]
Situation B: Web content designed for a specific large-scale display where size and viewing distance is known
  1. [begin add]Using actual viewing distance to calculate a 10 degree field of view in pixels AND [end add] G15: Ensuring that content does not violate the general flash threshold or red flash threshold

    [begin add]

    Note: There is a tool that is available to carry out this test.

    [end add]
[end add]
[end change]

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)

  • [begin add]

    Providing a mechanism to suppress any flashing content before it begins (future link) [LC-1099]

    [end add]

Examples of Success Criterion 2.3.1

  • [begin add]A Web site has video of muzzle flash of machine gun fire, but limits the size of the flashing image to a small portion of the screen below the flash threshold size. [LC-1101] [end add]

  • A movie with a scene involving very bright lightning flashes is [begin change]edited[end change] so that the lightning only flashes three times in any one second period. [LC-785] [LC-1101]


Understanding Success Criterion 2.3.2 (Three Flashes)

2.3.2 [begin change]Content does not contain anything that flashes more than three times in any one second period. [end change] [LC-494] (Level AAA)

[begin change]

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.

Success Criterion 2.3.1 requires that flashing content be less than three flashes in any 1-second period unless it is smaller than 25% 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 25% of a persons central vision.

This success criterion (2.3.2) 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.

Specific Benefits of Success Criterion 2.3.2:

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

[end change]

Techniques for Addressing Success Criterion 2.3.2

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

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)

Examples of Success Criterion 2.3.2

  • A movie with a scene involving very bright lightning flashes is [begin change]edited[end change] so that the lightning only flashes three times in any one second period. [LC-785]


Understanding Guideline 2.4: Provide ways to help users with disabilities navigate, find content and determine where they are

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. [begin add]Unusual user interface features or behaviors may confuse people with cognitive disabilities. [LC-946] [end add]

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. [begin add]Headings are particularly important mechanisms for helping users orient themselves within content and navigate through it. Many users of assistive technologies rely on appropriate headings to skim through information and easily locate the different sections of content. Satisfying Success Criterion 1.3.1 for headings also addresses some aspects of Guideline 2.4.[end add] [LC-562]

Advisory Techniques for Guideline 2.4 (not success criteria specific)

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


Understanding Success Criterion 2.4.1 (Bypass Blocks)

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

Web page
[begin change]

a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it [LC-862]

[end change]

Note: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.

[begin change]

Example 1: When you enter http://shopping.example.com/ in your browser you enter a movie-like interactive shopping environment where you visually move about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.

[end change]

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

[begin add]

Example 3: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://mail.example.com, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.

[end add]
[begin add]

Example 4: A customizable portal site, where users can choose content to display from a set of different content modules.

[end add]

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

  • 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

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

The following are common mistakes that are considered failures of Success Criterion 2.4.1 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.

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

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Success Criterion 2.4.2 (Page Titled)

[begin change]

2.4.2 Web pages have [begin add]descriptive[end add] titles. [LC-625] [LC-841] [LC-1052] [LC-1289] (Level A)

[end change]
Web page
[begin change]

a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it [LC-862]

[end change]

Note: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.

[begin change]

Example 1: When you enter http://shopping.example.com/ in your browser you enter a movie-like interactive shopping environment where you visually move about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.

[end change]

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

[begin add]

Example 3: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://mail.example.com, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.

[end add]
[begin add]

Example 4: A customizable portal site, where users can choose content to display from a set of different content modules.

[end add]

The intent of this success criterion is to help users find content and orient themselves within it by ensuring that each Web page has a [begin add]descriptive[end add] 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. [LC-625]

  • [begin add]This criterion benefits all users in allowing users to quickly and easily identify whether the information contained in the Web page is relevant to their needs. [end add]

  • [begin add]People with visual disabilities will benefit from being able to differentiate content when multiple Web pages are open. [end add]

  • [begin add]People with cognitive disabilities, limited short-term memory and reading disabilities also benefit from the ability to identify content by its title. [end add]

  • [begin add]This criterion also benefits people with severe mobility impairments whose mode of operation relies on audio when navigating between Web pages. [end add]

[begin delete]

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. [begin delete]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.[end delete] [LC-1105]

[end delete]

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

  1. G88: Providing descriptive titles for Web pages [begin add] AND associating a title with a Web page [end add]using one of the following techniques: [LC-625]

The following are common mistakes that are considered failures of Success Criterion 2.4.2 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.

  • 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 "References for Web Content Accessibility Guidelines 2.0."

  • [begin delete] An audio file. [end delete]

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

  • [begin delete] A video clip. [end delete]

    [begin delete]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.[end delete]

  • [begin delete] An image. [end delete]

    [begin delete]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.)[end delete] [LC-625]

  • [begin add] A Web application. [end add]

    [begin add]A banking application lets a user inspect his bank accounts, view past statements, and perform transactions. The Web application dynamically generates titles for each Web page, e.g., "Bank XYZ, accounts for John Smith" "Bank XYZ, December 2005 statement for Account 1234-5678". [end add] [LC-625]

Resources are for information purposes only, no endorsement implied.


Understanding Success Criterion 2.4.3 (Focus Order)

[begin change]
[begin change]

2.4.3 If a Web page [begin delete]or authored component[end delete] can be navigated sequentially, [begin add]focusable components receive focus in an order that follows information and relationships conveyed through presentation.[end add] [begin delete]components receive focus in an order that follows relationships and sequences in the content.[end delete] [LC-745] [LC-628] (Level A)

[end change]
[end change]
Web page
[begin change]

a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it [LC-862]

[end change]

Note: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.

[begin change]

Example 1: When you enter http://shopping.example.com/ in your browser you enter a movie-like interactive shopping environment where you visually move about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.

[end change]

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

[begin add]

Example 3: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://mail.example.com, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.

[end add]
[begin add]

Example 4: A customizable portal site, where users can choose content to display from a set of different content modules.

[end add]
navigated sequentially

navigated in the order defined for advancing focus from one element to the next with the keyboard [LC-974]

presentation

[begin delete]rendering of the content and structure in a form that can be perceived by the user[end delete] [begin change]rendering of the content in a form to be perceived by users [LC-490] [LC-1501] [end change]

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. [begin add]There may be different orders that reflect logical relationships in the content. For example, move through components in a table one row at a time or one column at a time both reflect the logical relationships in the content. Either order would satisfy this success criterion. [end add] [LC-930]

[begin change]

An additional example of navigation is using arrow key navigation to traverse a tree component. The user can use the up and down arrow keys to move from tree node to tree node. Pressing the left arrow key may expand a node, then using the down arrow key, will move into the newly expanded nodes. This navigation sequence follows the expected sequence for a tree control - as additional items get expanded or collapsed, they are added or removed from the navigation sequence. [LC-930]

[end change]
[begin add]

The way that sequential navigation order is determined in Web content is defined by the technology of the content. For example, simple HTML defines sequential navigation via the notion of tabbing order. Dynamic HTML may modify the navigation sequence using scripting along with the addition of a tabindex attribute to allow focus to additional elements. In this case, the navigation should follow relationships and sequences in the content. If no scripting or tabindex attributes are used, the navigation order is the order that components appear in the content stream. (See HTML 4.01 Specification, section 17.11, "Giving focus to an element"). [LC-974]

[end add]
  • 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.

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

  1. G59: 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 one of the following 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.

(none currently documented)

  • [begin change]Example that fails to meet the success criterion: [end change]: An on-line subscription form.

    [begin change]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 section of the form for collecting marketing data includes fields such as name, street address, city, state or province, and postal code. Another section of the form includes several checkboxes so that users can indicate newsletters they want to receive. However, the tab order for the form skips between fields in different sections of the form.[end change]

    [begin add]An individual using a screen magnifier fills in the form. Because of the level of magnification, only a small portion of the page is visible. She tabs through the fields, entering her name, then her street address. However, the next field in tab order is not the field for the city, but the checkbox beside the name of a newsletter. The user assumes that she has provided all of the necessary address information and presses Enter to submit the form. She is surprised when she receives an error message telling her that one or more required fields is incomplete. [LC-1111] [end add]

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Success Criterion 2.4.4 (Link Purpose (Context))

2.4.4 [begin delete]Each link is programmatically associated with text from which its purpose can be determined.[end delete] [begin add]The purpose of each link can be determined from the link text and its programmatically determined link context. [end add] [LC-497] [LC-872] (Level A)

Editorial Note: There is debate about whether pages that fail this success criterion in fact present a problem for assistive technology. The status of this item as a Level A success criterion is therefore "at risk" as a Level A success criterion depending on AT support and relative need for this provision.

programmatically determined link context

additional information that can be programmatically determined from relationships with a link[begin change], combined with the link text, and presented to users in different modalities[end change]

[begin delete]
  1. Additional information that can be programmatically determined from relationships with a link; and

  2. can be extracted, combined with the link text, and presented to users in different modalities.

[end delete]
[begin change]

Example 1: In HTML, information that is programmatically determinable from a link in English includes text that is in the same sentence, paragraph, list, or table cell as the link or in a table header cell that is associated with the table cell that contains the link.

Example 2: A screen reader provides commands to read the current sentence when focus is on a link in that sentence.

[end change]
[LC-497]
[begin change]

The intent of this success criterion is to help users understand the purpose of each link so they can decide whether they want to follow the link. This is generally achieved by reading the link itself. Assistive technology has the ability to provide users with a list of links that are on the Web page. Link text that is as meaningful as possible will aid users who want to choose from this list of links. Meaningful link text also helps those who wish to tab from link to link. Meaningful links help users choose which links to follow without requiring complicated strategies to understand the page.

[end change]
[begin add]

In some situations, authors may want to provide part of the description of the link in the nearby text. In this case the user should be able to identify the purpose of the link without moving focus from the link. In other words, they can arrive on a link and find out more about it without losing their place. This can be achieved by putting the description of the link in the same sentence, paragraph, list item, or table cell as the link because these are directly associated with the link itself. These descriptions will be most useful to the user if the description of the link precedes the link. (For instance, if you must use ambiguous link text, it is better to put it at the end of the sentence that describes its destination, rather than putting the ambiguous phrase at the beginning of the sentence.) This is because if the description follows the link, there can be confusion and difficulty for screen reader users who are reading through the page in order (top to bottom).

[end add]
[begin add]

Links with the same destination should have the same descriptions (per Success Criterion 3.2.4), but links with different purposes and destinations should have different descriptions. [LC-497]

[end add]
[begin add]

Note: There may be situations where the purpose of the link is is supposed to be unknown or obscured. For instance, a game may have links identified only as door #1, door #2, and door #3. This link text would be sufficient because the purpose of the links is to create suspense for all users.

[end add]
  • 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 returning to the current content.

  • People with cognitive limitations will not become disoriented by multiple means of navigation to and from content they are not interested in.

  • [begin change]People with visual disabilities will be able to determine the purpose of a link by exploring the link's context. [end change] [LC-497]

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

The following are common mistakes that are considered failures of Success Criterion 2.4.4 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.

  • A link contains text that gives a description of the information at that URL

    [begin change]A page contains the sentence "There was much bloodshed during the Medieval period of history." Where "Medieval period of history" is a link.[end change]

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

    [begin change]A page contains the sentence "Learn more about the Government of Ireland's Commission on Electronic Voting at Go Vote!" where "Go Vote!" is a link.[end change]

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

    [begin change]An icon of a voting machine and the text "Government of Ireland's Commission of Electronic Voting" are combined to make a single link. The alt text for the icon is null, since the purpose of the link is already described by the text of the link next to the icon.[end change]

  • A list of book titles

    [begin change]A list of books is available in three 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."[end change]

  • News article summaries

    [begin change]A Web page contains a collection of news articles. The main page lists the first few sentences of each article, followed by a "Read more" link. A screen reader command to read the current paragraph provides the context to interpret the purpose of the link.[end change] [LC-497]

Resources are for information purposes only, no endorsement implied.


Understanding Success Criterion 2.4.5 (Multiple Ways)

2.4.5 More than one way is available to locate content within a set of Web pages where content is not the result of, or a step in, a process. [begin delete] or task [LC-496] [end delete] (Level AA)

set of Web pages

collection of Web pages that have a specific relationship to each other and that are created as a body of work by an author, group or organization [LC-711] [LC-916]

Note: Different language versions would be considered different bodies of work.

Example: A set of Web pages that make up a report, a test, an exercise, a catalog, or an application.

process

series of user actions where each action is required in order to complete an activity

[begin change]

Example 1: Successful use of a series of Web pages on a shopping site requires users to view alternative products, prices and offers, select products, submit an order, provide shipping information and provide payment information.

[end change]

Example 2: An account registration page requires successful completion of a Turing test before the registration form can be accessed.

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.

  • 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 by 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 that provides an overview of the site rather than reading and traversing through several Web pages. Some users may prefer to explore the site in a sequential manner, moving from Web page to Web page in order to best understand the concepts and layout.

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

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

  1. Using two or more of the following 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.

  • 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 that lists several categories of foods. A user may type "soup" in to the search engine or may select "soup" from the list box to go to a page with a list of recipes made from the company's soup products

  • Links between Web pages.

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

  • 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 results based on user input. There is no other way to locate the search results except to perform the search process itself.

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Success Criterion 2.4.6 (Labels Descriptive)

[begin change]

2.4.6 [begin delete]Titles, [end delete]Headings and labels are descriptive. [LC-625] [LC-839] (Level AA)

[end change]
label

text [begin delete], image, or sound[end delete] [begin add]or other component with a text alternative [end add] that is presented to a user to identify a component within Web content

Note: [begin add]See also name. [LC-847] [end add]

The intent of this success criterion is to help users understand what information is contained in Web pages and how that information is organized. When [begin delete]titles and [end delete]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. [LC-625]

  • Descriptive [begin change]headings[end change] 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 [begin change]labels[end change] 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. [LC-625]

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

  1. G130: Providing descriptive headings

  2. G131: Providing descriptive labels

Note: [begin delete]Titles, h[end delete]Headings and labels must be programmatically determined, per success criterion 1.3.1.

The following are common mistakes that are considered failures of Success Criterion 2.4.6 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)

  • 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, Identify 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, [other sections unique to this article], Conclusion, Author Biography, Glossary, and Bibliography. The title of each Web page clearly identifies the article it contains, creating a useful balance between the uniqueness of the articles and the consistency of the section headings.

Resources are for information purposes only, no endorsement implied.


Understanding Success Criterion 2.4.7 (Location)

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

[LC-711]
set of Web pages

collection of Web pages that have a specific relationship to each other and that are created as a body of work by an author, group or organization [LC-711] [LC-916]

Note: Different language versions would be considered different bodies of work.

Example: A set of Web pages that make up a report, a test, an exercise, a catalog, or an application.

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

  • 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 set of Web pages and needs to navigate that Web site to understand the content of that page or to find more related information.

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

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)

  • Links to help user determine their 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 portal home page.

Resources are for information purposes only, no endorsement implied.


Understanding Success Criterion 2.4.8 (Link Purpose (Link Text))

2.4.8 The purpose of each link can be [begin delete] programmatically determined [end delete] [begin add]identified[end add] from the link text. [LC-497] (Level AAA)

programmatically determined

determined by software from [begin add]author-supplied[end add] data provided in a [begin delete] user-agent-supported manner such that the[end delete] [begin add]way that different[end add] user agents, including assistive technologies, can extract and present this information to users in different modalities [LC-756] [LC-1502]

[begin add]

Example: Determined in a mark-up language from elements and attributes that are accessed directly by commonly available assistive technology.

[end add]
[begin add]

Example: Determined from technology-specific data structures in a non-mark-up language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.

[end add]

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. [begin change]Links with the same destination should have the same descriptions (per Success Criterion 3.2.4), but links with different purposes and destinations should have different descriptions. Because the purpose of a link can be identified from its link text, links can be understood when they are out of context, such as when the user agent provides a list of all the links on a page. [end change] [LC-497]

  • This success criterion helps people with motion impairment by letting them skip Web pages 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.

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

  1. G91: Providing link text that describes the purpose of a link using one of the following techniques:

  2. Providing a supplemental description of the purpose of a link using one of the following techniques:

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.

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

Resources are for information purposes only, no endorsement implied.


[begin add]

Understanding Success Criterion 2.4.9 (Section Headings)

[begin add]

2.4.9 Where content is organized into sections, the sections are indicated with headings. (Level AAA)

[end add]

The intent of this success criterion is to provide headings for sections of a Web page, when the page is organized into sections. For instance, long documents are often divided into a variety of chapters, chapters have subtopics and subtopics are divided into various sections, sections into paragraphs, etc. When such sections exist, they need to have headings that introduce them. This clearly indicates the organization of the content, facilitates navigation within the content, and provides mental "handles" that aid in comprehension of the content. Other page elements may complement headings to improve presentation (e.g., horizontal rules and boxes), but visual presentation is not sufficient to identify document sections.

  • People who are blind will know when they have moved from one section of a Web page to another and will know the purpose of each section.

  • People with some learning disabilities will be able to use the headings to understand the overall organization of the page content more easily.

  • People who navigate content by keyboard will be able to jump the focus from heading to heading, enabling them to find quickly content of interest.

  • In pages where content in part of the page updates, headings can be used to quickly access updated content.

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

The following are common mistakes that are considered failures of Success Criterion 2.4.9 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 the 'live' property to mark live regions (future link) (ARIA)

  • A menu contains different sections for different courses. Each section has a heading: Appetizers, Salad, Soup, Entree, Dessert.

  • A Web application contains a settings page that is divided into groups of related settings. Each section contains a heading describing the class of settings.


[end add]

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 it 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 a 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 (for example, certain Japanese Kanji, example), pronunciation information must be available as well

Advisory Techniques for Guideline 3.1 (not success criteria specific)

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

[begin delete]

[LC-840]

[end delete]

Understanding Success Criterion 3.1.1 (Language of Page)

3.1.1 The [begin change]default[end change] human language [begin delete]or languages[end delete] of [begin change]each[end change] Web page [begin add]within the content[end add] can be programmatically determined. [LC-1371] [LC-1376] [LC-501] (Level A)

Key Terms

human language

[begin add]language that is spoken, written or signed (visually or tactilely) by humans to communicate with one another[end add] [begin delete]languages used by humans to communicate, including spoken, written, and signed languages[end delete] [LC-1184] [LC-1500]

Note: See also sign language.

Web page
[begin change]

a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it [LC-862]

[end change]

Note: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.

[begin change]

Example 1: When you enter http://shopping.example.com/ in your browser you enter a movie-like interactive shopping environment where you visually move about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.

[end change]

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

[begin add]

Example 3: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://mail.example.com, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.

[end add]
[begin add]

Example 4: A customizable portal site, where users can choose content to display from a set of different content modules.

[end add]
programmatically determined

determined by software from [begin add]author-supplied[end add] data provided in a [begin delete] user-agent-supported manner such that the[end delete] [begin add]way that different[end add] user agents, including assistive technologies, can extract and present this information to users in different modalities [LC-756] [LC-1502]

[begin add]

Example: Determined in a mark-up language from elements and attributes that are accessed directly by commonly available assistive technology.

[end add]
[begin add]

Example: Determined from technology-specific data structures in a non-mark-up language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.

[end add]

Intent of this Success Criterion

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

[begin delete]

"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 between language, 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. [LC-1383]

[end delete]
[begin add]

The default human language of the Web page is the default text-processing language as discussed in Internationalization Best Practices: Specifying Language in XHTML & HTML Content. When a Web page uses several languages, the default text-processing language is the language which is used most. (If several languages are used equally, the first language used should be chosen as the default human language.) [LC-1376]

[end add]

Note: [begin add]For multilingual sites targeting Conformance Level A, the Working Group strongly encourages developers to follow SC 3.1.2 as well even though that is a Level AA success criterion.[end add] [LC-1376]

Specific Benefits of Success Criterion 3.1.1:

This success criterion helps:

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

  • [begin change]

    people who find it difficult to read written material with fluency and accuracy, such as recognizing characters and alphabets or decoding words;

    [end change]
  • [begin add]

    people with certain cognitive, language and learning disabilities who use text-to-speech software [LC-1124]

    [end add]
  • people who rely on captions for multimedia.

Techniques for Addressing Success Criterion 3.1.1

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. Identifying [begin change]default[end change] human language(s) using one of the following techniques:

[begin delete]

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

  1. [begin delete] Identifying [begin change]default[end change] human language(s) using a technology-specific technique listed below AND Identifying the primary text direction using the following techniques: [end delete]

[LC-1383]
[end delete]

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.

(No failures currently documented)

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 [begin change]default[end change] language in the HTTP header (future link)

  • [begin delete]

    using dc:lang in the meta element to specify language or multiple languages (future link) [LC-1375]

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

  • [begin delete] Specifying the direction of text (future link)[end delete] [LC-1383]

Examples of Success Criterion 3.1.1

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

    A Web page produced in Germany includes content in both German and English, but most of the content is in German. The [begin change]default[end change] human language is identified as German (de).

  • [begin delete] Example 2. A Web page whose [begin change]default[end change] human language is written right-to-left [end delete]

    [begin delete]All of the content in a Web page is written in Hebrew. The [begin change]default[end change] human language is identified as Hebrew (he) [begin delete]and the direction is identified as right-to-left [LC-1383] [end delete].[end delete]

Related Resources

Resources are for information purposes only, no endorsement implied.


Understanding Success Criterion 3.1.2 (Language of Parts)

3.1.2 The human language of each passage or phrase in the [begin delete] Web page [end delete] [begin add]content[end add] can be programmatically determined. [LC-502] (Level AA)

[begin change]

Note: This requirement does not apply to individual words. It also does not apply to proper names, to technical terms or to phrases that have become part of the language of the context in which they are used. [LC-882] [LC-913]

[end change]

Key Terms

human language

[begin add]language that is spoken, written or signed (visually or tactilely) by humans to communicate with one another[end add] [begin delete]languages used by humans to communicate, including spoken, written, and signed languages[end delete] [LC-1184] [LC-1500]

Note: See also sign language.

Web page
[begin change]

a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it [LC-862]

[end change]

Note: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.

[begin change]

Example 1: When you enter http://shopping.example.com/ in your browser you enter a movie-like interactive shopping environment where you visually move about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.

[end change]

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

[begin add]

Example 3: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://mail.example.com, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.

[end add]
[begin add]

Example 4: A customizable portal site, where users can choose content to display from a set of different content modules.

[end add]
programmatically determined

determined by software from [begin add]author-supplied[end add] data provided in a [begin delete] user-agent-supported manner such that the[end delete] [begin add]way that different[end add] user agents, including assistive technologies, can extract and present this information to users in different modalities [LC-756] [LC-1502]

[begin add]

Example: Determined in a mark-up language from elements and attributes that are accessed directly by commonly available assistive technology.

[end add]
[begin add]

Example: Determined from technology-specific data structures in a non-mark-up language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.

[end add]

Intent of this Success Criterion

[begin change]

The intent of this success criterion is to ensure that user agents can correctly present content written in multiple languages. This applies to graphical browsers as well as screen readers, braille displays, and other voice browsers.

[end change]
[begin change]

Both assistive technologies and conventional user agents can render text more accurately if the language of each passage of text is identified. Screen readers can use the pronunciation rules of the language of the text. Visual browsers can display characters and scripts in appropriate ways. This is especially important when switching between languages that read from left to right and languages that read from right to left, or when text is rendered in a language that uses a different alphabet. Users with disabilities who know all the languages used in the Web page will be better able to understand the content when each passage is rendered appropriately.

[end change]
[begin change]

When no other language has been specified for a phrase or passage of text, its human language is the default human language of the Web page (see Success Criterion 3.1.1). So the human language of all content in single language documents can be programmatically determined.

[end change]
[begin change]

Individual words or phrases in one language can become part of another language. 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. Hence a passage of English text may contain the word "rendezvous" without specifying that its human language is French and still satisfy this success criterion. [begin change]Frequently, when the human language of text appears to be changing for a single word, that word has become part of the language of the surrounding text. Because this is so common in some languages, single words are not included in this success criterion. [LC-913] [end change] [LC-1296]

[end change]

Specific Benefits of Success Criterion 3.1.2:

This success criterion helps:

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

  • [begin change]

    people who find it difficult to read written material with fluency and accuracy, such as recognizing characters and alphabets, decoding words, and understanding words and phrases;

    [end change]
  • [begin add]

    people with certain cognitive, language and learning disabilities who use text-to-speech software; [LC-1124]

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

Techniques for Addressing Success Criterion 3.1.2

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. Identifying changes in human languages using one of the following techniques:

[begin delete]
[begin delete]Identifying text direction of passages and phrases in HTML [LC-1383] [end delete]
[begin delete]
  • [begin delete] Using a Unicode right-to-left mark (RLM) or left-to-right mark (LRM) to mix text direction inline [end delete]

  • [begin delete] Using the dir attribute on an inline element to resolve problems with nested directional runs [end delete]

[end delete]
[end delete]

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.

(No failures currently documented)

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 [begin change]default[end change] human language of the Web page visually distinct (future link)

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

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

Examples of Success Criterion 3.1.2

  1. A German phrase in an English sentence.

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

Resources are for information purposes only, no endorsement implied.


Understanding Success Criterion 3.1.3 (Unusual Words)

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

Key Terms

mechanism

process or technique for achieving a result

[begin add]

Note 1: The mechanism may be explicitly provided in the content, or may be relied on to be provided by either the platform or by user agents, including assistive technologies.

Note 2: The mechanism must meet all success criteria for the conformance level claimed. [LC-619]

[end add]
used in an unusual or restricted way

words used in such a way that users must know exactly [begin delete]what[end delete] [begin add]which[end add] definition to apply in order to understand the content correctly

[LC-851]

Example: [begin delete]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.[end delete] [begin add]The term "gig" means something [begin add]different[end add] if it occurs in a discussion of music concerts [begin change]than it does in[end change] article about computer hard drive space, but the appropriate definition can be determined from context.[end add] By contrast, the word "text" is used in a very specific way in WCAG 2.0, so a definition is supplied in the glossary. [LC-1508]

idiom

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 "さじを投げる [begin delete](どうするこ ともできなくなり、あきらめること[end delete]" literally translates into "he [begin change]throws[end change] a spoon," but it means that there is nothing he [begin change]can[end change] do and finally he [begin change]gives[end change] up. [LC-1240] [LC-1382]

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 nonliteral word usage and specialized words or usage. Certain disabilities make it difficult to understand figurative language or specialized usage. [begin add]Providing such mechanisms is vital for these audiences. Specialized information intended for non-specialist readers is encouraged to satisfy this success criterion, even when claiming only Single-A or Double-A conformance. [LC-945] [end add]

Specific Benefits of Success Criterion 3.1.3:

[begin add]

This success criterion may help people with cognitive, language and learning disabilities who:

[end add]
  • [begin add]

    have difficulty decoding words

    [end add]
  • [begin add]

    have difficulty understanding words and phrases

    [end add]
  • [begin add]

    have difficulty using context to aid understanding

    [end add]
[begin add]

It would also help people with visual disabilities who:

[end add]
  • [begin add]

    lose context when zoomed-in with a screen magnifier

    [end add]
[begin delete]
  • [begin delete]

    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.

    [end delete]
[end delete]

Techniques for Addressing Success Criterion 3.1.3

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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 Web page:
  1. G101: 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 a Web page using one of the following techniques:

  2. G101: Providing the definition of a word or phrase used in an unusual or restricted way for each occurrence of the word or phrase in a Web page using one of the following techniques:

Situation B: If the word or phrase means different things within the same Web page:
  1. G101: Providing the definition of a word or phrase used in an unusual or restricted way for each occurrence of the word or phrase in a Web page 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.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)

  • [begin add]

    Avoiding unusual foreign words (future link) [LC-840]

    [end add]

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

  • 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

Resources are for information purposes only, no endorsement implied.

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


Understanding Success Criterion 3.1.4 (Abbreviations)

3.1.4 A mechanism for finding the expanded form [begin add]or meaning[end add] of abbreviations is available. [LC-883] (Level AAA)

Key Terms

mechanism

process or technique for achieving a result

[begin add]

Note 1: The mechanism may be explicitly provided in the content, or may be relied on to be provided by either the platform or by user agents, including assistive technologies.

Note 2: The mechanism must meet all success criteria for the conformance level claimed. [LC-619]

[end add]
abbreviation

shortened form of a word, phrase, or name

Note: This includes initialisms and acronyms where:

  1. initialisms are shortened forms of a name or phrase made from the initial letters of words or syllables contained in that name or phrase

    Note 1: Not defined in all languages.

    Example 1: SNCF is a French initialism that contains the initial letters of the Société Nationale des Chemins de Fer, the French national railroad.

    Example 2: ESP is an initialism for extrasensory perception.

  2. acronyms [begin change]are abbreviated forms made from the initial letters or parts of other words (in a name or phrase) which may be pronounced as a word[end change] [LC-1175] [LC-1413]

    Example: NOAA is an acronym made from the initial letters of the National Oceanic and Atmospheric Administration in the United States.

Intent of this Success Criterion

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

Specific Benefits of Success Criterion 3.1.4:

[begin change]

This success criterion may help people who:

[end change]
  • [begin delete]

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

    [end delete]
  • [begin delete]

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

    [end delete]
  • [begin delete]

    People with memory loss

    [end delete]
  • [begin add]

    have difficulty decoding words;

    [end add]
  • [begin add]

    rely on screen magnifiers (magnification may reduce contextual cues);

    [end add]
  • [begin add]

    have limited memory;

    [end add]
  • [begin add]

    have difficulty using context to aid understanding.

    [end add]

[begin delete]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. [end delete]Abbreviations may confuse [begin change]some[end change] 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."

[begin add]

It would also help people with visual disabilities who:

[end add]
  • [begin add]

    Lose context when zoomed-in with a screen magnifier

    [end add]

Techniques for Addressing Success Criterion 3.1.4

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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: [begin change]If the abbreviation has only one meaning within the Web page:[end change]
  1. G102: Providing the expansion or explanation of an abbreviation for the first occurrence of the abbreviation in a Web page using one of the following techniques:

  2. G102: Providing the expansion or explanation of an abbreviation for all occurrences of the abbreviation in a Web page using one of the following techniques:

Situation B: [begin change]If the abbreviation means different things within the same Web page:[end change]
  1. G102: Providing the expansion or explanation of an abbreviation for all occurrences of abbreviations in a Web page 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 a Web page (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)

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.

  • [begin add]Expanded forms of Abbreviations.[end add]

    [begin add]The expanded form of each abbreviation is available in a programmatically determinable manner. User agents that speak the text can use the expanded form to announce the abbreviation. Other user agents might make the expanded form available as a tooltip or as contextual help for the abbreviation. [end add] [LC-915]

Related Resources

Resources are for information purposes only, no endorsement implied.


Understanding Success Criterion 3.1.5 (Reading Level)

3.1.5 When text requires reading ability more advanced than the lower secondary education level, supplemental content [begin add]or an alternate version [end add] is available that does not require reading ability more advanced than the lower secondary education level. [LC-1505] (Level AAA)

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 that [begin delete]users may use in addition to or instead of the default content, that[end delete]illustrates or clarifies the [begin change]primary[end change] content [LC-1505]

Example 1: [begin delete]Examples of supplemental content may include text, images and audio.[end delete] [begin add]An audio version of a Web page. [end add]

Example 2: [begin add]An illustration of a complex process.[end add]

Example 3: [begin add]A paragraph describing the major outcomes and recommendations made in a research study. [end add]

alternate version

version that provides all of the same information and functionality [begin add]in the same human language [end add] and is as up to date as [begin delete]any[end delete] [begin add]the[end add] non-conforming content [LC-940] [LC-1490]

Intent of this Success Criterion

[begin add]Content should be written as clearly and simply as possible. [LC-569] [LC-887] [end add] The intent of this success criterion is:

  • to ensure that additional content is available to aid the 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. [begin add]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. [LC-542] [end add] 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 page. If the Web page includes text written for different purposes or different styles are used, the selected passages include samples of the types of content in the Web page and the different styles in which the content is written. (In many cases, the Web page 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.

[begin add]

When a web page contains multiple languages, a readability result should be calculated for each language that constitutes at least 5% of the content and that is used in full sentences or paragraphs (not just individual words or phrases). The overall readability of the page should be judged on the language that yields the worst readability results. [LC-1535]

[end add]

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 school7-9 years of school10-12 years of schoolMore than 12 years of school

Adapted from International Standard Classification of Education [UNESCO]

Specific Benefits of Success Criterion 3.1.5:

[begin add]

This success criterion may help people who:

[end add]
[begin change]
  • Have difficulty comprehending and interpreting written language (e.g. articles, instructions, or newspapers in text or braille), for the purpose of obtaining general knowledge or specific information

[end change]
[begin delete]

[LC-542]

[end delete]

Techniques for Addressing Success Criterion 3.1.5

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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

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

  3. G79: 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. [begin change]For some people who are deaf, a sign language version of the page may be easier to understand than a written language version since sign language may be their first language. [LC-597] [end change] 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.

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

  • [begin add]

    Using the clearest and simplest language appropriate for the content (future link) [LC-1255]

    [end add]
  • 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 viewable by humans (future link)

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 a reading ability at the lower secondary education level.

    The paragraphs below (114 words total) require a 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

Resources are for information purposes only, no endorsement implied.


Understanding Success Criterion 3.1.6 (Pronunciation)

3.1.6 A mechanism is available for identifying specific pronunciation of words where meaning [begin delete]cannot be determined without pronunciation[end delete] [begin add]is ambiguous without knowing the pronunciation[end add]. [LC-1192] (Level AAA)

Key Terms

mechanism

process or technique for achieving a result

[begin add]

Note 1: The mechanism may be explicitly provided in the content, or may be relied on to be provided by either the platform or by user agents, including assistive technologies.

Note 2: The mechanism must meet all success criteria for the conformance level claimed. [LC-619]

[end add]

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.

[begin add]For example, in the English language heteronyms are words that are spelled the same but have different pronunciations and meanings, such as the words desert (abandon) and desert (arid region). [LC-543] [end add]Additionally, in some languages certain characters can be pronounced in different ways. In Japanese, for example, there are characters like Han characters(Kanji) that 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.

Specific Benefits of Success Criterion 3.1.6:

[begin add]

This success criterion may help people who: [LC-542]

[end add]
  • [begin change]

    have difficulty decoding words

    [end change]
  • [begin change]

    have difficulty using context to aid understanding

    [end change]
  • [begin change]

    use technologies that read the words aloud

    [end change]

Techniques for Addressing Success Criterion 3.1.6

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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

  2. Linking to pronunciations (future link)

  3. G62: 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

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)

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

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Guideline 3.2: Make Web pages appear and operate in predictable ways

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 page to Web page and by making the behavior of functional and interactive components predictable. It is difficult for some users to form an overview of the Web page: 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 pages 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 (not success criteria specific)

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


Understanding Success Criterion 3.2.1 (On Focus)

3.2.1 When any component receives focus, it does not [begin delete]cause[end delete] [begin add]initiate[end add] a change of context. [LC-981] (Level A)

Key Terms

changes of context

change of:

  1. user agent;

  2. viewport;

  3. focus;

  4. content that changes the meaning of the Web page.

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;

Specific Benefits of Success Criterion 3.2.1:

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

Techniques for Addressing Success Criterion 3.2.1

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

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)

Examples of Success Criterion 3.2.1

  • Example 1: A 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.

  • [begin add]Example of a Failure: A help dialog[end add]

    [begin add]When a field receives focus, a help dialog describing the field opens. As a keyboard user tabs through the Web page, the dialog opens every time the user attempts to tab past the field. [end add] [LC-1130]


Understanding Success Criterion 3.2.2 (On Input)

3.2.2 Changing the setting of any [begin change] user interface component [end change] does not automatically cause a change of context [begin delete](beyond moving to the next user interface component in tab order),[end delete] unless the [begin change]user has been advised of the behavior before using the component.[end change] [LC-969] [LC-503] [LC-755] [LC-1299] [LC-968] (Level A)

Key Terms

user interface component

a part of the content that is perceived by users as a single control for a distinct function

Note: Multiple user interface components may be implemented as a single programmatic element. Components here is not tied to programming techniques but rather to what the user perceives as separate controls.

Example: An applet has a "control" that can be used to move through content by line or page or random access. Since each of these would need to have a name and be setable independently, they would each be a "user interface component."

changes of context

change of:

  1. user agent;

  2. viewport;

  3. focus;

  4. content that changes the meaning of the Web page.

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.

Specific Benefits of Success Criterion 3.2.2:

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

Techniques for Addressing Success Criterion 3.2.2

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. G80: Providing a submit button to initiate a change of context using a technology-specific technique listed below

  2. G13: Describing what will happen before a change to a form control is made

    • H32: Providing submit buttons (HTML)

    • [begin change]Using a button with a select element to perform an action [LC-1131] [end change] (future link)

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

    • Hiding and showing content based on 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)

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

  • [begin add]A form contains fields representing US phone numbers. All of the numbers have a three digit area code followed by a three digit prefix and finally a four digit number, and each part of the phone number is entered into a separate field. When the user completes the entry of one field and enter the first digit of the next field, the focus automatically moves to the next field of the phone number. This behavior of phone fields is described for the user at the beginning of the form. [end add] [LC-755] [LC-1299]


Understanding Success Criterion 3.2.3 (Consistent Navigation)

3.2.3 Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages [begin delete]or other primary resources [LC-505] [LC-914] [end delete] occur in the same relative order each time they are repeated, unless a change is initiated by the user. (Level AA)

Key Terms

Web page
[begin change]

a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it [LC-862]

[end change]

Note: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.

[begin change]

Example 1: When you enter http://shopping.example.com/ in your browser you enter a movie-like interactive shopping environment where you visually move about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.

[end change]

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

[begin add]

Example 3: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://mail.example.com, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.

[end add]
[begin add]

Example 4: A customizable portal site, where users can choose content to display from a set of different content modules.

[end add]
set of Web pages

collection of Web pages that have a specific relationship to each other and that are created as a body of work by an author, group or organization [LC-711] [LC-916]

Note: Different language versions would be considered different bodies of work.

Example: A set of Web pages that make up a report, a test, an exercise, a catalog, or an application.

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 [begin change]within [LC-983] [end change] a set of Web pages 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 pages to be able to predict the location of the content they are looking for and find it more quickly when they encounter it again.

[begin add]

Users may initiate a change in the order by using adaptive user agents or by setting preferences so that the information is presented in a way that is most useful to them. [LC-612] [LC-612]

[end add]

Specific Benefits of Success Criterion 3.2.3:

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

Techniques for Addressing Success Criterion 3.2.3

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

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.

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

  • Using dynamic navigation (future link) [LC-1132]

  • Creating layout, positioning, layering, and alignment (future link)

Examples of Success Criterion 3.2.3

  • A consistently located control

    A search field is the last item on every Web page 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

Resources are for information purposes only, no endorsement implied.


Understanding Success Criterion 3.2.4 (Consistent Identification)

3.2.4 Components that have the same functionality within a set of Web pages are identified consistently. (Level AA)

Key Terms

same functionality

[begin delete]identical[end delete] [begin add]same[end add] result when used [LC-982]

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 page
[begin change]

a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it [LC-862]

[end change]

Note: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.

[begin change]

Example 1: When you enter http://shopping.example.com/ in your browser you enter a movie-like interactive shopping environment where you visually move about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.

[end change]

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

[begin add]

Example 3: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://mail.example.com, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.

[end add]
[begin add]

Example 4: A customizable portal site, where users can choose content to display from a set of different content modules.

[end add]

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 pages. 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 pages. If identical functions have different labels on different Web pages, 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.

Specific Benefits of Success Criterion 3.2.4:

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

Techniques for Addressing Success Criterion 3.2.4

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  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 page that links to the next Web page. 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 page. 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 page. 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 pages 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.

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)

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: Consistent references to other pages

    A Web site publishes articles on-line. Each article spans multiple Web pages and each page contains a link to the first page, the next page and the previous page of the article. If the references to the next page read "page 1", "page 2", "page 2" etcetera, the labels are not the same but they are consistent. Therefore, these references are not failures of this success criterion.

  • Example 4: Icons with similar functions

    An e-commerce application uses a printer icon that allows the user to print receipts and invoices. In one part of the application, the printer icon is labeled "Print receipt" and is used to print receipts, while in another part it is labeled "Print invoice" and is used to print invoices. The labeling is consistent ("Print x"), but the labels are different to reflect the different functions of the icons. Therefore, this example does not fail the success criterion.

  • Example 5: Save icon

    A common "save" icon is used through out the site where page save function is provided on multiple Web pages.

  • Example 6: Example of a Failure

    A submit "search" button on one Web page and a "find" button on another Web page 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.


Understanding Success Criterion 3.2.5 (Change on Request)

3.2.5 Changes of context are initiated only by user request. (Level AAA)

Key Terms

changes of context

change of:

  1. user agent;

  2. viewport;

  3. focus;

  4. content that changes the meaning of the Web page.

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.

Specific Benefits of Success Criterion 3.2.5:

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

Techniques for Addressing Success Criterion 3.2.5

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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 Web page allows automatic updates:
  1. G76: Providing a mechanism to request an update of the content instead of updating automatically

Situation B: If automatic redirects are possible:
  1. SVR1: Implementing automatic redirects on the server side instead of on the client side (SERVER)

  2. G110: Using an instant client-side redirect using one of the following techniques:

Situation C: If the Web page uses pop-up windows:
  1. Including pop-up windows using one of the following techniques:

Situation D: If using an onchange event on a select element:
  1. SCR19: Using an onchange event on a select element without causing a change of context (SCRIPT)

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.

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

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.

Related Resources

Resources are for information purposes only, no endorsement implied.


Understanding Guideline 3.3: Help users avoid and correct mistakes that do occur

Intent of Guideline 3.3

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 3.3 (not success criteria specific)

Specific techniques for meeting each success criterion for this guideline are listed in the understanding sections for each success criterion (listed below). If there are techniques, however, for addressing this guideline that do not fall under any of the success criteria, they are listed here. These techniques are not required or sufficient for meeting any success criteria, but 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.

Understanding Success Criterion 3.3.1 (Error Identification)

3.3.1 If an input error is [begin add]automatically[end add] detected, [begin change]the item that is [begin delete]determined to be [end delete]in error [end change] is identified and described to the user in text. [LC-978] (Level A)

Key Terms

input error

information provided by the user that is not accepted

Note: This includes:

  1. Information that is required by the Web page 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. [begin add]The error message should be as specific as possible. [LC-979] [end add] 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.

[begin add]

The identification and description of an error can be combined with programmatic information that user agents or assistive technologies can use to identify an error and provide error information to the user. For example, certain technologies can specify that the user's input must not fall outside a specific range, or that a form field is required. Currently, few technologies support this kind of programmatic information, but the success criterion does not require, nor prevent it. [LC-629]

[end add]

Specific Benefits of Success Criterion 3.3.1:

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

  • [begin add]This success criterion may help people with cognitive, language, and learning disabilities who have difficulty understanding the meaning represented by icons and other visual cues. [LC-1115] [end add]

Techniques for Addressing Success Criterion 3.3.1

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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. G83: Providing text descriptions to identify required fields that were not completed

Situation B: If information provided by the user is required to be in a specific data format or of certain values.
  1. G85: Providing a text description when user input falls outside the required format or values

  2. SCR18: Providing client-side validation and alert (SCRIPT)

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

Common Failures Identified by the Working Group

The following are common mistakes that are considered failures of Success Criterion 3.3.1 by the WCAG Working Group.

(No failures currently documented)

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

  • G139: Creating a mechanism that allows users to jump to errors

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

Examples of Success Criterion 3.3.1

  • Identifying errors in a form submission

    [begin change]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, an alert is displayed notifying the user which field or fields were missing or incorrect. [LC-1116] [end change]

    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 easier to visually search for them as well.

Related Resources

Resources are for information purposes only, no endorsement implied.


Understanding Success Criterion 3.3.2 (Error Suggestion)

3.3.2 If an input error is detected and suggestions for correction are known[begin add], then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.[end add] [begin delete]and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user[end delete] (Level AA)

Key Terms

input error

information provided by the user that is not accepted

Note: This includes:

  1. Information that is required by the Web page 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 3.3.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.

[begin add]

The content author may provide the description of the error, or the user agent may provide the description of the error based on technology-specific, programmatically determined information. [LC-630]

[end add]

Specific Benefits of Success Criterion 3.3.2:

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

Techniques for Addressing Success Criterion 3.3.2

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Note: [begin add]In some cases, more than one of these situations may apply. For example, when a mandatory field also requires the data to be in a specific format. [LC-1117] [end add]

Sufficient Techniques

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. G83: Providing text descriptions to identify required fields that were not completed

Situation B: If information for a field is required to be in a specific data format:
  1. G85: Providing a text description when user input falls outside the required format or values

  2. [begin add]

    Providing links to suggested correction text "close to" form fields, or providing the suggested correction text itself directly on the Web page "next to" form fields (future link) [LC-1119]

    [end add]
  3. [begin add]

    Providing client-side validation and adding error text via the DOM (future link) [LC-1119]

    [end add]
Situation C: Information provided by the user is required to be one of a limited set of values:
  1. G84: Providing a text description when the user provides information that is not in the list of allowed values

  2. [begin add]

    Providing links to suggested correction text "close to" form fields, or providing the suggested correction text itself directly on the Web page "next to" form fields (future link) [LC-1119]

    [end add]
  3. [begin add]

    Providing client-side validation and adding error text via the DOM (future link) [LC-1119]

    [end add]

Common Failures Identified by the Working Group

The following are common mistakes that are considered failures of Success Criterion 3.3.2 by the WCAG Working Group.

(No failures currently documented)

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

  • G139: Creating a mechanism that allows users to jump to errors

  • Making error messages easy to understand and distinguishable from other text in the Web page (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 (Advisory)
  • Providing a text description that contains information about the number of input errors, suggestions for corrections to each item, and instructions on how to proceed (future link)

  • Providing a text description 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 (Advisory)
  • 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 page "next to" form fields (future link)

Client-Side Scripting Techniques (Advisory)
ARIA Techniques (Advisory)

Examples of Success Criterion 3.3.2

  • Additional Help for Correcting An Input Error

    [begin change]

    The result of a form that was not successfully submitted describes an input error in place in the page along with the correct input and offers additional help for the form field that caused the input error. [LC-1118]

    [end change]
  • 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, e.g., "Do you mean 'December'?"

Related Resources

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Success Criterion 3.3.3 (Error Prevention (Legal, Financial, Data))

3.3.3 For forms that cause legal [begin add]commitments[end add] or financial transactions to occur, that modify or delete [begin add]user-controllable[end add] data in data storage systems, or that submit test responses, at least one of the following is true: [LC-1471] [LC-708] (Level AA)

  1. Reversible: [begin add]Transactions[end add] [begin delete]Actions[end delete] are reversible. [LC-1196]

  2. Checked: [begin add]Submitted data is checked for[end add] [begin delete]Actions are checked for[end delete] input errors before going on to the next step in the process. [LC-1196]

  3. Confirmed: [begin add]A mechanism is available for reviewing, confirming, and correcting information before finalizing the transaction.[end add] [begin delete]The user is able to review and confirm or correct information before submitting it.[end delete] [LC-1170] [LC-1196]

Key Terms

[begin add]legal commitments [LC-1471] [end add]

transactions where the person incurs a legally binding obligation or benefit

Example: A marriage license, a stock trade (financial and legal), a will, a loan, adoption, signing up for the army, a contract of any type, etc.

user-controllable

data that is intended to be accessed by users

Note: This does not refer such things as internet logs and search engine monitoring data.

Example: Name and address fields for a user's account.

input error

information provided by the user that is not accepted

Note: This includes:

  1. Information that is required by the Web page but omitted by the user

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

process

series of user actions where each action is required in order to complete an activity

[begin change]

Example 1: Successful use of a series of Web pages on a shopping site requires users to view alternative products, prices and offers, select products, submit an order, provide shipping information and provide payment information.

[end change]

Example 2: An account registration page requires successful completion of a Turing test before the registration form can be accessed.

mechanism

process or technique for achieving a result

[begin add]

Note 1: The mechanism may be explicitly provided in the content, or may be relied on to be provided by either the platform or by user agents, including assistive technologies.

Note 2: The mechanism must meet all success criteria for the conformance level claimed. [LC-619]

[end add]

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

[begin add]

User-controllable data is data that is intended to be accessed by users. (e.g., name and address for the user’s account.) It does not refer such things as internet logs and search engine monitoring data.

[end add]

Specific Benefits of Success Criterion 3.3.3:

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

Techniques for Addressing Success Criterion 3.3.3

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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 canceled by the user (future link)

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

Situation B: If an action causes information to be deleted:
  1. G99: Providing the ability to recover deleted information

  2. [begin change]

    Providing a dialog to the user which requires confirmation before information is deleted (future link) [LC-1122]

    [end change]
  3. [begin change]

    Requiring a user to select a confirmation checkbox before submitting an action that causes information to be deleted (future link) [LC-1123]

    [end change]
Situation C: If the Web page includes a testing application:
  1. G98: Providing the ability for the user to review and correct answers before submitting

  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 3.3.3 by the WCAG Working Group.

(No failures currently documented)

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

  • Informing the user what irreversible action is about to happen (future link)

  • SCR18: Providing client-side validation and alert (SCRIPT)

  • [begin add]Placing focus in the field containing the error (future link) [LC-727] [end add]

  • [begin add]Avoiding use of the same words or letter combinations to begin each item of a drop-down list (future link) [LC-727] [end add]

Examples of Success Criterion 3.3.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

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Success Criterion 3.3.4 (Labels or Instructions)

[begin add]

3.3.4 Labels or instructions are provided when content requires user input. (Level AA)

[end add]

Key Terms

label

text [begin delete], image, or sound[end delete] [begin add]or other component with a text alternative [end add] that is presented to a user to identify a component within Web content

Note: [begin add]See also name. [LC-847] [end add]

Intent of this Success Criterion

The intent of this success criterion is to help users avoid making mistakes when their input is required. To help avoid mistakes it is good user interface design to provide simple instructions and cues for entering information. Some users with disabilities may be more likely to make mistakes than users without disabilities or recovery from mistakes may be more difficult, making mistake avoidance an important strategy for users with disabilities. People with disabilities rely on well documented forms and procedures to interact with a page. Blind users need to know exactly what information should be entered into form fields and what the available choices are. Simple instructions visually connected to form controls can assist users with cognitive disabilities or those accessing a page using a screen magnifier.

The intent of this success criterion is not to clutter the page with unnecessary information but to provide important cues and instructions that will benefit people with disabilities. Too much information or instruction can be just as much of a hindrance as too little. The goal is to make certain that enough information is provided for the user to accomplish the task without undue confusion or navigation.

Specific Benefits of Success Criterion 3.3.4:

  • Label elements associated with input elements insure that information about the input field is spoken by screen readers when the field receives focus.

  • Field labels located in close proximity to the associated field assist users of screen magnifiers because the field and label are more likely to visible within the magnified area of the page.

  • Providing examples of expected data formats help users with cognitive, language and learning disabilities to enter information correctly.

  • Clearly identifying required fields prevents a keyboard only user from submitting an incomplete form and having to navigate the redisplayed form to find the uncompleted field and provide the missing information.

[begin add]

Techniques for Addressing Success Criterion 3.3.4

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. G131: Providing descriptive labels AND one of the following:

Common Failures Identified by the Working Group

The following are common mistakes that are considered failures of Success Criterion 3.3.4 by the WCAG Working Group.

(No failures currently documented)

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

[end add]

Examples of Success Criterion 3.3.4

  • A field which requires the user to enter the two character abbreviation for a US state has a link next to it which will popup an alphabetized list of state names and the correct abbreviation.

  • A field for entering a date contains initial text which indicates the correct format for the date.

  • A field for entering a given name is clearly labeled with "Given Name" and the field for family name is labeled "Family Name" to avoid confusion over which name is requested.

  • [begin add]

    A U.S. phone number separates the area code, exchange, and number into three fields. Parentheses surround the area code field, and a dash separates the exchange and number fields. While the punctuation provides visual clues to those familiar with the U.S. telephone number format, the punctuation is not sufficient to label the fields. The single "Phone number" label also cannot label all three fields. To address this, the three fields are grouped in a fieldset with the legend "Phone number". Visual labels for the fields (beyond the punctuation) cannot be provided in the design, so invisible labels are provided with the "title" attribute to each of the three fields. The value of this attribute for the three fields are, respectively, "Area Code", "Exchange", and "Number".

    [end add]

Related Resources

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Success Criterion 3.3.5 (Help)

3.3.5 Context-sensitive help is available[begin delete] for text input [LC-1197] [end delete]. (Level AAA)

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.

[begin add]

Context-sensitive help only needs to be provided when the label is not sufficient to describe all functionality. In most cases, context-sensitive help should not be placed in the form itself, but should instead be available to users when they request it (e.g. by linking to a separate help file). [LC-757]

[end add]
[begin add]

The content author may provide the help text, or the user agent may provide the help text based on technology-specific, programmatically determined information. [LC-632]

[end add]

Specific Benefits of Success Criterion 3.3.5:

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

Techniques for Addressing Success Criterion 3.3.5

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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. G71: Providing a help link on every Web page

  2. [begin change]Using scripts to provide context-sensitive bubble help[end change] (future link) [LC-730]

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

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

  5. [begin add]Using the title attribute to provide context-sensitive help [LC-730] [end add]

  6. [begin add]

    Providing instructions at the top of a form (future link) [LC-1252]

    [end add]
Situation B: If a form requires text input in an expected data format:
  1. G89: Providing expected data format and example

  2. [begin add]

    Providing instructions at the top of a form (future link) [LC-1252]

    [end add]

Common Failures Identified by the Working Group

The following are common mistakes that are considered failures of Success Criterion 3.3.5 by the WCAG Working Group.

(No failures currently documented)

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

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

Examples of Success Criterion 3.3.5

  • on-line 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

Resources are for information purposes only, no endorsement implied.

(none currently documented)


[begin add]

Understanding Success Criterion 3.3.6 (Error Prevention (All))

[begin add]

3.3.6 For forms that require the user to submit information, at least one of the following is true: [LC-1171] (Level AAA)

  1. Reversible: Transactions are reversible.

  2. Checked: Submitted data is checked for input errors before going on to the next step in the process.

  3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the transaction.

[end add]

Key Terms

input error

information provided by the user that is not accepted

Note: This includes:

  1. Information that is required by the Web page but omitted by the user

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

process

series of user actions where each action is required in order to complete an activity

[begin change]

Example 1: Successful use of a series of Web pages on a shopping site requires users to view alternative products, prices and offers, select products, submit an order, provide shipping information and provide payment information.

[end change]

Example 2: An account registration page requires successful completion of a Turing test before the registration form can be accessed.

mechanism

process or technique for achieving a result

[begin add]

Note 1: The mechanism may be explicitly provided in the content, or may be relied on to be provided by either the platform or by user agents, including assistive technologies.

Note 2: The mechanism must meet all success criteria for the conformance level claimed. [LC-619]

[end add]

Intent of this Success Criterion

The intent of this success criterion is to help users with disabilities avoid consequences that may result from making a mistake when submitting form data. This criterion builds on Success Criterion 3.3.3 in that it applies to all forms that require users to submit information.

Users with disabilities may be more likely to make mistakes and may have more difficulty detecting or recovering from 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.

Specific Benefits of Success Criterion 3.3.6:

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

Techniques for Addressing Success Criterion 3.3.6

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. Following the sufficient techniques for Success Criterion 3.3.3 for all forms that require the user to submit information.


[end add]

Understanding Guideline 4.1: Maximize 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 (not success criteria specific)

Specific techniques for meeting each success criterion for this guideline are listed in the understanding sections for each success criterion (listed below). If there are techniques, however, for addressing this guideline that do not fall under any of the success criteria, they are listed here. These techniques are not required or sufficient for meeting any success criteria, but 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.

Understanding Success Criterion 4.1.1 (Parsing)

4.1.1 [begin delete] Web page [begin delete]or authored components [end delete]can be parsed unambiguously , and the relationships in the resulting data structure are also unambiguous.[end delete] [begin add]Content implemented using markup languages has elements with complete start and end tags, except as allowed by their specifications, and are nested according to their specifications.[end add] [LC-1179] [LC-910] (Level A)

[begin add]

Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.

[end add]

Key Terms

Web page
[begin change]

a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it [LC-862]

[end change]

Note: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.

[begin change]

Example 1: When you enter http://shopping.example.com/ in your browser you enter a movie-like interactive shopping environment where you visually move about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.

[end change]

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

[begin add]

Example 3: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://mail.example.com, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.

[end add]
[begin add]

Example 4: A customizable portal site, where users can choose content to display from a set of different content modules.

[end add]
parsed unambiguously
[begin delete]

parsed into only one data structure

[end delete]
[begin delete]

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.

[end delete]

Intent of this Success Criterion

The intent of this success criterion is to ensure that user agents, including assistive technologies, can accurately interpret [begin add]and parse content. If the content cannot be parsed into a data structure, then different user agents may present it differently or be completely unable to parse it. Some user agents use "repair techniques" to render poorly coded content. [end add] [begin delete]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.[end delete]

[begin add]

Since repair techniques vary among user agents, authors can not assume that content will be accurately parsed into a data structure or that it will be rendered correctly by specialized user agents, including assistive technologies, unless the content us created according to the rules defined in the formal grammar for that technology. [begin add]In markup languages, errors in element and attribute syntax and failure to provide properly nested start/end tags lead to errors that prevent user agents from parsing the content reliably.[end add] [begin delete][end delete]Therefore, the success criterion requires that the content can be parsed using only the rules of the formal grammar [LC-910]

[end add]

Specific Benefits of Success Criterion 4.1.1:

  • Ensuring that Web pages [begin add]have complete start and end tags and are nested according to specification[end add] [begin delete]parse unambiguously[end delete] helps ensure that assistive technologies can parse the content accurately and without crashing.

Techniques for Addressing Success Criterion 4.1.1

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. G134: Validating Web pages

  2. Fully conforming to specifications (future link)

  3. Ensuring that Web pages can be parsed [begin delete]unambiguously[end delete] by 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 4.1.1 by the WCAG Working Group.

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)

Examples of Success Criterion 4.1.1

Related Resources

Resources are for information purposes only, no endorsement implied.

(none currently documented)


Understanding Success Criterion 4.1.2 (Name, Role, Value)

4.1.2 For all user interface components, the name and role can be programmatically determined; [begin add]states, properties, and[end add] values that can be set by the user can be programmatically determined and programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. [LC-935] (Level A)

Note: This success criterion is primarily for Web authors who develop or script their own user interface controls. For example, standard HTML controls already meet this provision when used according to specification.

Key Terms

user interface component

a part of the content that is perceived by users as a single control for a distinct function

Note: Multiple user interface components may be implemented as a single programmatic element. Components here is not tied to programming techniques but rather to what the user perceives as separate controls.

Example: An applet has a "control" that can be used to move through content by line or page or random access. Since each of these would need to have a name and be setable independently, they would each be a "user interface component."

name

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

Note 1: The name may be hidden and only exposed by assistive technology, whereas a label is presented [begin add]to all users.[end add] [begin delete]even without Assistive technology (as used in this document 732 ) [end delete] In many (but not all) cases, the label [begin add]and the name are the same.[end add] [begin delete]is a display of the name[end delete]

[begin add]

Note 2: This is unrelated to the name attribute in HTML.

[end add]
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 [begin add]author-supplied[end add] data provided in a [begin delete] user-agent-supported manner such that the[end delete] [begin add]way that different[end add] user agents, including assistive technologies, can extract and present this information to users in different modalities [LC-756] [LC-1502]

[begin add]

Example: Determined in a mark-up language from elements and attributes that are accessed directly by commonly available assistive technology.

[end add]
[begin add]

Example: Determined from technology-specific data structures in a non-mark-up language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.

[end add]
programmatically set

set by software using methods that are [begin add]supported by user agents, including assistive technologies [end add] [begin delete] user-agent-supported [end delete]

user agent

any software that retrieves and [begin change]presents[end change] Web content for users

Example: Web browsers, media players, plug-ins, and other programs — including assistive technologies — that help in retrieving[begin change], rendering, and interacting with [end change]Web content. [LC-1269]

Assistive technology ([begin change]as used in this document [LC-732] [end change])

a user agent that [begin add]both[end add]:

  1. [begin change]

    provides services to meet the requirements of users with disabilities that go beyond those offered by the mainstream user agents. Such services include alternative presentations (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)[begin add], and[end add] [LC-1178]

    [end change]
  2. usually relies on services (such as retrieving Web content and parsing markup) provided by one or more other mainstream user agents. Assistive technologies communicate data and messages with mainstream user agents by using and monitoring APIs

Note 1: [begin add]In this definition, user agents are user agents in the general sense of the term. That is, any software that retrieves and [begin change]presents[end change] Web content for users. The mainstream user agent may provide important services to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles. [LC-732] [end add]

Note 2: [begin add]Mainstream user agents may also provide services directly that meet the requirements of users with disabilities. [LC-732] [end add]

Note 3: This definition is based on User Agent Accessibility Guidelines 1.0 Glossary.

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

  • screen magnifiers, [begin change]and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc in order [LC-604] [end change] improve the visual readability of rendered text and images;

  • screen readers, which are used by people who are blind [begin change]to read textual information through synthesized speech or braille[end change];

  • [begin add]

    text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;

    [end add]
  • 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.

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.

Specific Benefits of Success Criterion 4.1.2:

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

Techniques for Addressing Success Criterion 4.1.2

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

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

Situation B: 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 one of the following techniques:

Situation C: If using a standard user interface component in a programming technology:
  1. G135: 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

Situation D: If creating your own user interface component in a programming language:
  1. G10: Creating components using a technology that supports the accessibility API features of the platforms on which the user agents will be run to expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes

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.

  • [begin add]

    Providing labels for all form controls that do not have implicit labels (future link) [LC-654]

    [end add]

Examples of Success Criterion 4.1.2


[begin add]

Understanding Conformance

What does conformance mean?

Conformance to a standard means that you meet or satisfy the 'requirements' of the standard. In WCAG 2.0 the 'requirements' are the success criteria. To conform to WCAG 2.0, you would need to satisfy the success criteria. Most standards only have one level of conformance. In order to accommodate different situations that may require or allow greater levels of accessibility than others, WCAG 2.0 has 3 levels of conformance, and therefore three levels of success criteria.

Understanding Levels of Conformance

The success criteria were assigned to one of the three levels of conformance by the working group after taking into consideration a wide range of interacting issues. Some of the common factors evaluated when setting the level included: whether the success criterion is essential (in other words, if the success criterion isn't met, then even assistive technology can't make content accessible); whether it is possible to satisfy the success criterion for all Web sites and types of content that use that technology or feature; whether the success criterion requires skills that could reasonably be achieved by the content creators (that is, the knowledge and skill to do this could be acquired with between 1 hour and a week's training).

All success criteria must be important access issues for people with disabilities that address problems beyond the usability problems that might be faced by all users. In other words, the issue must cause a proportionately greater problem for people with disabilities than it causes people without disabilities in order to be considered an accessibility issue (and covered under these accessibility guidelines).

All success criteria must also be testable. This is important since otherwise it would not be possible to determine whether one met or failed to meet the success criteria. The success criteria can be either machine or human testable (or a combination of both) as long as it is possible to determine whether a success criterion has been satisfied with a high level of confidence.

Understanding Accessibility Support

Many of the success criteria deal with providing accessibility through assistive technologies or special accessibility features in mainstream user agents (such as 'show captions'). That is, the success criteria require that something be done in the Web content that would make it possible for assistive technologies to successfully present information from the content to the user. For example, a picture that you were supposed to click on to go to a topic would not be accessible to a person who was blind. But providing alternate text for the picture in a way that assistive technologies understand allows the assistive technology to present the text to a user who is blind. The key here is that the text must be presented in a way that assistive technologies can understand and use.

When new technologies are introduced, two things must happen in order for people using assistive technologies to be able to access them. First, the technologies must be designed in a way that assistive technologies could access all the information they need to present the content to the user. Secondly, the assistive technologies may need to be redesigned or modified to be able to actually work with these new technologies.

Basically, a Web content technology is "accessibility supported" when the assistive technologies that users have actually will work with the technologies AND when the accessibility features of mainstream technologies will work with the technology. Specifically, to qualify as an accessibility-supported technology, the following must be true for a technology:

  1. The Web technology must be supported by users' assistive technology (AT). This means that [begin change]either the technology implements and tests accessibility APIs that are required in order for the users' assistive technology to make the technology accessible, or the technology has been tested for interoperability with users' assistive technology in the human language(s) of the content.[end change] [begin delete]at least one of the following is true:[end delete]

    [begin delete]
    1. The technology implements accessibility APIs that are supported by users' assistive technology; OR

    2. The technology has been tested for interoperability with users' assistive technology in the human language(s) of the content.

    [end delete]
  2. The [begin change]Web technology must have accessibility-supported[end change] [begin delete]host [end delete]user agents that are available to users.

    This means that at least one of the following is true:

    1. The technology is supported natively in widely-distributed [begin delete]host [end delete]user agents that are also accessibility supported (such as HTML and CSS); OR

    2. The technology is supported in a widely-distributed plug-in that is also accessibility supported; OR

    3. The content is available in a closed environment, such as a university or corporate network, where the [begin delete]host [end delete]user agent required by the technology and used by the organization is also accessibility supported; OR

    4. The [begin delete]host [end delete]user agent(s) that support the technology are also accessibility supported and available for download or purchase in a way that does not disadvantage people with disabilities.

[begin add]

Note 1: Web technologies that are not accessibility supported can be used as long as conformance requirement 5 (Accessibility-Supported Technologies) and conformance requirement 6 (Non-Interference) are met.

Note 2: When a Web Technology is "accessibility supported," it does not imply that the entire technology must be supported. Most technologies lack support for at least one feature. When referring to "accessibility support" for a technology, the support for specific aspects, features, and extensions should be cited if the technology as a whole is not accessibility supported. A profile of a technology may be used to give a name to the set of aspects, features, or extensions of a technology that are "accessibility supported."

[begin add]

Note 3: When citing technologies that have multiple versions, the version(s) supported should be specified. [LC-483]

[end add]
[end add]

The working group has not specified how much or how many assistive technologies must support a Web technology in order for it to be classified as 'accessibility supported'. This is a complex topic and one that varies both by environment and by language. There are different levels of AT support in different languages and even countries since some environments or countries may provide free assistive technologies.

Clearly, a new technology can not be supported by all past assistive technologies, so requiring that a technology be supported by all assistive technologies is not possible. Yet support by just one technology (for a disability) might be enough if the content were viewed only within a company and all employees (with that disability) were provided with that technology.

The working group, therefore, limited itself to defining what constituted support and defers the judgment of how much, how many, or which AT must support a technology to the community and to entities closer to each situation that set requirements for an organization, purchase, community, etc.

[begin add]

Understanding Documented lists of Web technologies with Accessibility Support

Because individual authors would not be able to do all of the research necessary to determine which technologies, and which features of the technologies, are actually supported by which versions of assistive technologies and user agents, authors will usually rely on public documented lists of Web technologies including which assistive technologies support their various features. By public, we only mean that the list and its documentation are public. Anyone can create a publicly documented list of "Web Technologies and their Accessibility Support." People may even create recommended documented lists of technologies and give them a name (e.g. the XYZ Accessibility Coalition's 2007 Supported Technologies List) that authors can use. As long as they are publicly documented, authors or customers etc. can easily select lists that meet their needs. Customers or others can pick lists that fit their environment or the public Web at any point in time and specify those be used in creating their content.

There is no requirement in WCAG that a documented list be used or that technologies from such a list be used. They are only described as a method to make an otherwise critical, but somewhat complicated aspect of conformance easier for authors who are not themselves experts on assistive technology support (or who just don't have the time to keep up with advances in mainstream and assistitive technology support for each other).

Authors, companies or others may wish to create and use their own lists of accessibility-supported technologies.

[end add]
[begin add]

Understanding Conformance Requirements

There are nine requirements that must be met in order for content to be classified as 'conforming' to WCAG 2.0. This section provides brief notes on those requirements. This section will be expanded over time to address questions that may arise or to provide new examples of ways to meet the different conformance requirements.

Understanding Requirements 1,2, & 3

[begin change]

1.) Level A Conformance: For level A conformance (the minimum level of conformance), the Web page satisfies all the Level A success criteria, or the page satisfies conformance requirement 4.

[end change]
[begin change]

2.) Level AA Conformance: For level AA conformance, the Web page satisfies all the Level A and Level AA success criteria, or the page satisfies conformance requirement 4.

[end change]
[begin change]

3.) Level AAA Conformance: For level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA success criteria, or the page satisfies conformance requirement 4.

[end change]

The first three requirements deal with the levels of conformance. They explain that no conformance is possible without at least satisfying all of the Level A success criteria either with a Web page or with an alternate Web page (see #4 below).

Understanding Requirement 4

4.) Alternate Versions: If [begin change]the[end change] Web page [begin delete]within the scope of a claim [end delete]does not meet all of the [begin delete]required WCAG 2.0 [end delete]success criteria [begin change]for a specified[end change] level[begin delete] claimed[end delete], then a mechanism to obtain an alternate version that meets [begin add]all of [end add]the success criteria can be derived from the nonconforming content or its URI, and that mechanism meets all success criteria for the [begin change]specified level of conformance[end change]. The alternate version does not need to be matched page for page with the original (e.g. the alternative to a page may consist of multiple pages). [LC-465] If multiple language versions are available, then conforming versions are required for each language offered. [LC-939]

Editorial Note: As currently worded, requirement #4 ensures that a mechanism is available to find a conforming version from any nonconforming version. The working group is concerned that it has not identified enough supported mechanisms to meet the needs and constraints of different technologies or the limitations authors may have in their content or server. Requirement #4 is therefore "at risk" in its current form. If there are not sufficient techniques to meet the current language, it would have to change. The two options under consideration if that happens both have disadvantages. The options are:

  • Fallback option #1: Requiring an accessible link from the nonconforming content, which would block use of some current and future technologies if they do not support WCAG conforming links, or

  • Fallback option #2: Allowing the requirement to be met by a single page with links to the conforming and non-conforming pages, or other techniques that may provide an option to find the conforming version when browsing, but that would leave the user with no way to find the conforming page after reaching a non-conforming page via search, or a link from a blog, email, article, other page etc.

Further discussion of this topic is available at Alternate Versions Conformance Requirement. The working group seeks suggestions for additional sufficient techniques that would allow us to keep the current language as well as comments, input, and thoughts on the two alternatives should we fail to identify enough.

The intent of this conformance requirement is to ensure that a conforming version of all content is available. Authors may use non-conforming technologies or formats on their Web sites. But they must also provide all of the information and functionality in a way that conforms. If a Web page does not meet the success criteria, it can be included in a set of 'conforming' pages if there is another page in the same set that does conform and if there is a way to find the conforming page once you have landed on the non-conforming page. This provision allows new technologies to be introduced that may not initially be accessibility supported. It also allows technologies that may be more accessible and usable to some people (including people with some disabilities) that might not be accessible to all disabilities, as long as there is a page that conforms can be reached if you land on the non-conforming page. For content served in different languages, it is important to provide a conforming version for each language. [LC-940]

[begin add]

Note that providing an alternate version is a fallback option for conformance to WCAG and the preferred method of conformance is to make all content directly accessible. [LC-517]

[end add]

A number of different methods for finding the conforming page are provided since one technique may not always be possible. For example, if the author has control of the server there are some powerful techniques that will allow users to always have the choice up front. In many cases however the author may not have control of the services on their Web server. In these cases other techniques are provided. We expect that additional techniques will also be developed over time and they will be added here as they arise. For example a developer of a new technology that some assistive technologies cannot see might build in a feature that would allow those technologies to automatically present a link to users that could take them to an alternate version.

Sufficient Techniques for Meeting Conformance Requirement 4

Each numbered item below represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this conformance requirement.

  1. Using environment variables to ensure that the only way to access non-conforming content is from conforming content (future link)

  2. [begin delete]

    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)

    [end delete]
Common Failures Identified by the Working Group
Additional Techniques (Advisory) for Conformance Requirement 4
  • Using content negotiation (future link)

  • Providing user settings as a way to store preferences (future link)

  • Providing style switchers (future link)

  • Using noframes (future link)

  • Using noscript (future link)

  • Using a fallback mechanism for applets (if applet not a [begin change]relied on accessibility-supported content technology[end change], need alternative mechanism for functionality) (future link)

  • [begin add]

    Excluding non-conforming content from search results (future link)

    [end add]
  • [begin add]

    Using only technologies which are accessibility supported at the conformance level claimed (future link)

    [end add]
  • [begin add]

    Providing reciprocal links between conforming and non-conforming versions (future link) [LC-465]

    [end add]
Examples of Conformance Requirement 4
  • An intranet site with multiple versions.

    A large company was concerned that the use of emerging Web technologies on an intranet site might limit their ability to address the needs of diverse office locations that have different technology bases and individual employees who use a wide variety of user agents and assistive technologies. To address these concerns, the company created an alternate version of the content that met all Level A success criteria using a more limited [begin change]set of accessibility-supported content technologies[end change]. 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.

Understanding Requirement 5

5.) Accessibility-Supported Technologies Only: Only documented accessibility-supported Web technologies are relied upon to meet success criteria. Any information or functionality that is implemented in technologies that are not accessibility supported must also be available via technologies that are accessibility supported.

[begin delete]

Note: Conformance can not be achieved if part of a Web page is excluded. For example, conformance can not apply to a set of pages, but exclude a part of the page or a particular type of content (for example, images or scripts) since doing so would allow exclusion of individual success criteria.

[end delete]

This conformance requirement is explained above under Understanding Accessibility Support.

Understanding Requirement 6

[begin change]

6.) Non-Interference: If Web technologies that are not accessibility supported are used on a page, or accessibility-supported technologies are used in a non-conforming way, then they do not block the ability of the users to access the rest of the page. Specifically: [LC-750]

  1. No Keyboard Trap: If focus can be moved to technologies that are not accessibility supported using a keyboard interface, then focus can be moved away from that content using only a keyboard interface, and the method for doing so is described before the content is encountered and in a way that meets all Level A success criteria.

  2. Three Flashes or Below Threshold: [begin change]To minimize the risk of seizures due to photosensitivity, content does not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds (see Success Criterion 2.3.1). [LC-716] [end change]

  3. [begin add]

    Non support: The content continues to meet the conformance requirements when the (non accessibility-supported) technology is turned on, turned off, or is not supported by a user agent.

    [end add]
[end change]

This basically says that technologies that are not accessibility supported can be used, as long as all the information is also available using technologies that are accessibility supported and as long as the non-accessibility-supported material does not interfere. The three provisions make sure that it doesn't trap the user in the non-accessibility-supported material, doesn't cause a seizure risk, and won't block access if the user turns off the non-accessibility-supported material (e.g. turns support off in their browser) or if their user agent doesn't support it at all.

Technologies that are not accessibility supported can be used, or technologies that are accessibility supported can be used in a non conforming manner, as long as all the information is also available using technologies that are accessibility supported, in a manner that does conform, and as long as the non-accessibility-supported material does not interfere.

"Keyboard trapping" refers to a situation in which the keyboard focus can become stuck in non-conforming content, 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. For more on meeting this "no-keyboard trapping" condition see:

The following two advisory techniques are also provided:

  • When the Web page uses non accessibility-supported content technologies that can capture keyboard focus, documenting the keyboard interface to exit the non accessibility-supported content content from within the accessibility-supported content (future link)

  • [begin add]

    Providing a mechanism to skip non accessibility-supported content (future link) [LC-561]

    [end add]

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 an accessibility-supported content technology.

Understanding Requirement 7

[begin change]

7.) Full pages: Conformance is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.

[end change]

This provision simply requires that the whole page conform. Statements about "part of a page conforming" cannot be made.

Note: Because of conformance requirement 6, a whole page may conform even parts of it use non accessibility-supported content technologies.

Understanding Requirement 8

[begin add]

8.) Supplemental Information: For the purpose of determining conformance, a conforming alternative to part of a page's content is considered part of the page.

[end add]

Sometimes, supplemental information may be available for information on a page. The longdesc attribute in HTML is an example. With longdesc, a long description of a graphic might be on a separate page that the user can jump to from the page with the graphic. This makes it clear that such content is considered part of the Web page, so that requirement #7 is satisfied for the combined set of Web pages considered as a single Web page.

Understanding Requirement 9

[begin change]

9.) Complete processes: If a Web page that is part of a process does not conform at some level, then no conformance claim is made at that level for any Web pages in that process.

Example: An online store has a series of pages that are used to select and purchase products. All pages in the series from start to finish (checkout) must conform in order to claim conformance for any page that is part of the sequence.

[begin add]

For more information, see Understanding Conformance Requirements.

[end add]
[end change]

This provision prevents a Web page that is part of a larger process from being considered conforming if the process overall is not. This would prevent a shopping site from being classified as conforming if the checkout or other features of the site that are part of the shopping and buying process do not conform.

[end add]

Understanding Conformance Claims

It is not required to make any conformance claim in order to conform. If one does make a claim however the rules must be followed.

Sometimes, one may want to make a claim for just the content that was added after a certain date. Or, one may want to claim WCAG 1.0 conformance for content up to a date and WCAG 2.0 for content that was created or modified after that date. There are no prohibitions in WCAG 2.0 to any of these practices as long as it is clear which pages are claiming conformance to which version of WCAG. [LC-1210]

The most useful way of attaching conformance claims to content is to do so in standard machine readable form. In this fashion, search tools or special user agents can make use of this information to provide more accessible content or adjust to the content. There are a number of metadata based options under development for making claims. We will provide more information about these as they become available.

Examples of Conformance Claims

Example 1: On 23 March 2008, [begin add]all content available on the server at [LC-1152] [end add] http://www.wondercall.example.com conforms to [begin change]Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/ [LC-1151] [end change]. Single-A conformance.

  • The technology that this content "relies upon" is: HTML 4.01.

  • The technologies that this content "uses but does not rely upon" are: CSS2, and gif.

  • This content was tested using the following user agents and assistive technologies: Firefox 1.5 on Windows 2000 SP4 with Jaws 7.0, Firefox 1.5 on Windows XP SP 2 with Jaws 7.0, IE 6.0 on Windows 2000 SP4 with Jaws 4.51, IE 6.0 on Windows 2000 SP4 with Jaws 7.0, and Firefox 1.5 on Windows XP SP2 with Jaws 7.0, Safari 2.0 with OS X 10.4.

Example 2: On 5 May 2008, [begin add]the page [LC-1152] [end add]"G7: An Introduction" http://telcor.example.com/nav/G7/intro.html conforms to [begin change]Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/ [LC-1151] [end change]. Double-A conformance.

  • The following additional success criteria have also been met: 1.1.2, 1.2.5, and 1.4.3.

  • The documented set of accessibility-supported content technologies used for this claim is AsCTset#1-2006 at http://UDLabs.org/AsCTset#1-2006.html.

  • The technologies that this content "relies upon" is: XHTML 1.0 (Strict), and Real Video.

  • The technologies that this content "uses but does not rely upon" are: JavaScript 1.2, CSS2.

Example 3: On 21 June 2008, [begin add]all content beginning with the URI [LC-1152] [end add] http://example.com/nav and http://example.com/docs conform to [begin change]Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/[end change]. Triple-A conformance.

  • The documented set of accessibility-supported content technologies used for this claim is SMITH- AsCTset#2-2008 at http://smithreports.example.com/AsCTsets/AS2-2008.

  • The technologies that this content "relies upon" are: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, JPEG, PNG.

  • The user agents (including AT) that this content has been tested with can be found at http://example.com/docs/WCAG20/test/technologies.html.

Example 4: [begin add](using boolean logic) On 6 July 2008, http://example.com/ AND NOT (http://example.com/archive/ OR http://example.com/publications/archive/) conforms to [begin change]Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/[end change]. Double-A (AA) conformance. [LC-572] [end add]

  • The documented set of accessibility-supported content technologies used for this claim is ISA- AsCTset#1-2008 at http://ISA.example.gov/AsCTsets/AS2-2008.

Example 5: [begin add](using a regular expression) On 12 August 2008, http://www.example.com/(marketing|sales|contact)/.* conforms to [begin change]Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/[end change]. Double-A (AA) conformance. [LC-572] [end add]

  • The technologies that this content "relies upon" is: XHTML 1.0 Transitional.

  • The technologies that this content "uses but does not rely upon" are CSS 1.0 and JavaScript 1.2.


[end add]

Appendix A References

ANSI-HFES-100-1988
ANSI/HFS 100-1988, American National Standard for Human Factors Engineering of Visual Display Terminal Workstations, Section 6, pp. 17-20.
ARDITI
Arditi, A. (2002). Effective color contrast: designing for people with partial sight and color deficiencies. New York, Arlene R. Gordon Research Institute, Lighthouse International. Also available at http://www.lighthouse.org/color_contrast.htm.
ARDITI-FAYE
Arditi, A. and Faye, E. (2004). Monocular and binocular letter contrast sensitivity and letter acuity in a diverse ophthalmologic practice. Supplement to Optometry and Vision Science, 81 (12S), 287.
ARDITI-KNOBLAUCH
Arditi, A. and Knoblauch, K. (1994). Choosing effective display colors for the partially-sighted. Society for Information Display International Symposium Digest of Technical Papers, 25, 32-35.
ARDITI-KNOBLAUCH-1996
Arditi, A. and Knoblauch, K. (1996). Effective color contrast and low vision. In B. Rosenthal and R. Cole (Eds.) Functional Assessment of Low Vision. St. Louis, Mosby, 129-135.
CAPTCHA
The CAPTCHA Project, Carnegie Mellon University. The project is online at http://www.captcha.net.
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.
GITTINGS-FOZARD
Gittings, NS and Fozard, JL (1986). Age related changes in visual acuity. Experimental Gerontology, 21(4-5), 423-433.
HEARING-AID-INT
Levitt, H., Kozma-Spytek, L., & Harkins, J. (2005). In-the-ear measurements of interference in hearing aids from digital wireless telephones. Seminars in Hearing, 26(2), 87.
IEC-4WD
IEC/4WD 61966-2-1: Colour Measurement and Management in Multimedia Systems and Equipment - Part 2.1: Default Colour Space - sRGB. May 5, 1998.
ISO-9241-3
ISO 9241-3, Ergonomic requirements for office work with visual display terminals (VDTs) - Part 3: Visual display requirements. Amendment 1.
I18N-CHAR-ENC
"Tutorial: Character sets & encodings in XHTML, HTML and CSS," R. Ishida, ed., This tutorial is available at http://www.w3.org/International/tutorials/tutorial-char-enc/.
KNOBLAUCH
Knoblauch, K., Arditi, A. and Szlyk, J. (1991). Effects of chromatic and luminance contrast on reading. Journal of the Optical Society of America A, 8, 428-439.
LAALS
Bakke, M. H., Levitt, H., Ross, M., & Erickson, F. (1999). Large area assistive listening systems (ALS): Review and recommendations (Final Report. NARIC Accession Number: O16430). Jackson Heights, NY: Lexington School for the Deaf/Center for the Deaf Rehabilitation Research Engineering Center on Hearing Enhancement.
sRGB
"A Standard Default Color Space for the Internet - sRGB," M. Stokes, M. Anderson, S. Chandrasekar, R. Motta, eds., Version 1.10, November 5, 1996. A copy of this paper is available at http://www.w3.org/Graphics/Color/sRGB.html.
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.
WCAG20
"Web Content Accessibility Guidelines 2.0," B. Caldwell, M Cooper, L Guarino Reid, and G. Vanderheiden, eds., W3C Working Draft 17 May 2007. This W3C Working Draft is available at http://www.w3.org/TR/2007/WD-WCAG20-20070517/. The latest version of WCAG 2.0 is available at http://www.w3.org/TR/WCAG20/