[contents]
This document is also available in these non-normative formats:
Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
This document is the internal working draft used by the WCAG WG and is updated continuously and without notice. This document has no formal standing within W3C. Please consult the group's home page and the W3C technical reports index for information about the latest publications by this group.
This draft includes revisions that have been made since the 17 May 2007 Working Draft was published. Please refer to the latest public version of WCAG 2.0 for information about the status of WCAG 2.0 as well as information about submitting comments to the working group.
History of Changes to WCAG 2.0 Working Drafts
Understanding WCAG 2.0 is an essential guide to understanding and using "Web Content Accessibility Guidelines 2.0" [WCAG20] Although the normative 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 a non-normative 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.
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.
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 Understanding Success Criterion X.X.X section for each success criterion of that guideline. These How to Meet sections each contain:
The success criterion as it appears in WCAG 2.0
Intent of the success criterion
Benefits (how the success criterion helps people with disabilities)
Examples
Related Resources
Techniques or combinations of techniques that are sufficient to meet the guidelines
Common failures of this success criterion
Additional advisory techniques that go beyond what is required to meet the success criterion but can be used to make some or all types of content more accessible. Use of advisory techniques does not impact the level of conformance claimed.
Key terms for this success criterion (taken from the WCAG 2.0 Glossary)
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.
For links to information on different disabilities and assistive technologies see Disabilities on Wikipedia.
The guidelines and success criteria are organized around the following four principles, which lay the foundation necessary for anyone to access and use Web content. Anyone who wants to use the Web must have content that is:
Perceivable - Information and user interface components must be presentable to users in ways they can perceive
This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses)
Operable - User interface components and navigation must be operable
This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)
Understandable - Information and the operation of user interface must be understandable
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)
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.
Under each principle there is a list of guidelines that address the principle. There are a total of 12 guidelines. A convenient list of just the guidelines can be found in the WCAG 2.0 table of contents. One of the key objective of the guidelines is to ensure that content is directly accessible to as many people as possible, and capable of being re-presented in different forms to match different peoples' sensory, physical and cognitive abilities.
Under each guideline, there are success criteria that describe specifically what must be achieved in order to conform to this standard. They are similar to the "checkpoints" in WCAG 1.0. Each success criterion is written as a statement that will be either true or false when specific Web content is tested against it. The success criteria are written to be technology neutral.
All WCAG 2.0 success criteria are written as testable criteria for objectively determining if content satisfies the success criteria. While some of the testing can be automated using software evaluation programs, others require human testers for part or all of the test.
Although content may satisfy the success criteria, the content may not always be usable by people with a wide variety of disabilities. Professional reviews utilizing recognized qualitative heuristics are important in achieving accessibility for some audiences. In addition , usability testing is recommended. Usability testing aims to determine how well people can use the content for its intended purpose.
The content should be tested by those who understand how people with different types of disabilities use the Web. It is recommended that users with disabilities be included in test groups when performing human testing.
Each success criterion for a guideline has a link to the section of the Quick Reference document that provides:
sufficient techniques for meeting the success criterion,
optional advisory techniques, and
links to descriptions of the intent of the success criteria, including benefits, and examples
Rather than having technology specific techniques in WCAG 2.0, the guidelines and success criteria themselves have been written in a technology neutral fashion. In order to provide guidance and examples for meeting the guidelines using specific technologies (for example HTML) the working group has identified sufficient techniques for each success criterion that are sufficient to meet that success criterion. The list of sufficient techniques is maintained in the "Understanding WCAG 2.0" (and mirrored in the WCAG 2.0 Quick Reference). In this way it is possible to update the list as new techniques are discovered, and as Web Technologies and Assistive Technologies progress.
Note that all techniques are informative. The "sufficient techniques" are considered sufficient by the WCAG Working Group to meet the success criteria. However, it is not necessary to use these particular techniques. If techniques are used other than those listed by the Working Group, then some other method for establishing the technique's ability to meet the success criteria would be needed
Most success criteria have multiple sufficient techniques listed. Any of the listed sufficient techniques can be used to meet the success criterion. There may be other techniques which are not documented by the working group that could also meet the success criterion. As new sufficient techniques are identified they will be added to the listing.
In addition to the sufficient techniques, there are a number of advisory techniques that can enhance accessibility, but did not qualify as sufficient techniques because are not sufficient to meet the full requirements of the success criteria, they are not testable, and/or are good and effective techniques in some circumstances but not effective or helpful in others. These are listed as advisory techniques and are right below the sufficient techniques. Authors are encouraged to use these techniques wherever appropriate to increase accessibility of their Web pages.
Editorial Note: Where the committee has not yet been able to write up the description of a technique, the techniques are listed with "(future link)" following their title.
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
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 is presentation neutral. That is, it can be rendered visually, auditorily, tactilely, or by any combination. As a result, information rendered in electronic text can be presented in whatever form best meets the needs of the user. It can also be easily enlarged, spoken in a voice that is easy to understand, or rendered in whatever tactile form best meets the needs of a user.
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.
Providing sign language videos for audio-only files (future link)
1.1.1 Non-text Content: All non-text content has a text alternative that presents equivalent information, except for the situations listed below. (Level A)
Controls, Input: If it is a control or accepts user input, then it has a name that describes its purpose. (See also Guideline 4.1.)
Media, Test, Sensory: If it is (1) synchronized media, (2) live audio-only or live video-only content, (3) a test or exercise that must be presented in non-text format, (4) primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content , or (5) a media alternative to text that is clearly labeled as such . (For synchronized media, see also Guideline 1.2.)
Note: Prerecorded audio-only and video-only files would be covered under Success Criterion 1.1.1, which requires text alternatives that present equivalent information.
CAPTCHA: If it is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
Decoration, Formatting, Invisible: If it is pure decoration, or used only for visual formatting, or if it is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.
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.
CAPTCHAs are a controversial topic in the accessibility community. As is described in the paper Inaccessibility of CAPTCHA, CAPTCHAs intrinsically push the edges of human abilities in an attempt to defeat automated processes. Every type of CAPTCHA will be unsolvable by users with certain particular disabilities. However, they are widely used, and the Web Content Accessibility Guidelines Working Group believes that if CAPTCHAs were forbidden outright, Web sites would choose not to conform to WCAG rather than abandon CAPTCHA. This would create barriers for a great many more users with disabilities. For this reason the Working Group has chosen to structure the requirement about CAPTCHA in a way that meets the needs of most people with disabilities, yet is also considered adoptable by sites. Requiring two different forms of CAPTCHA on a given site ensures that most people with disabilities will find a form they can use.
Because some users with disabilities will still not be able to access sites that meet the minimum requirements, the Working Group provides recommendations for additional steps. Organizations motivated to conform to WCAG should be aware of the importance of this topic and should go as far beyond the minimum requirements of the guidelines as possible. Additional recommended steps include:
Providing more than two modalities of CAPTCHAs
Providing access to a human customer service representative who can bypass CAPTCHA
Not requiring CAPTCHAs for authorized users
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 is not covered by one of the other situations listed below, 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 prerecorded audio-only and prerecorded video-only files are covered here. Live-audio-only and Live-video-only files are covered below (see 3rd paragraph following this one).
For non-text content that 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.
Non-text content that is synchronized media 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 synchronized media and/or gives its title is therefore provided.
Live Audio-only and live video-only files - It is much more difficult to provide text alternatives that convey the same information as live audio-only and live video-only content. For these types of non-text content, text alternatives provide a descriptive label.
Sometimes a test or exercise must use a particular sense. Audio or visual information is provided that cannot be changed to text because the test or exercise must be conducted using that sense. For example, a hearing test would be invalid if a text alternative were provided. A visual skill development exercise would similarly make no sense in text form. And a spelling test with text alternatives would not be very effective. For these cases, text alternatives should be provided to describe the purpose of the non-text content; of course, the text alternatives would not provide the same information needed to pass the test.
Sometimes content is primarily intended to create a specific sensory experience that words cannot fully capture. Examples include a symphony performance, works of visual art etc. For such content, text alternatives at least identify the non-text content with a descriptive label 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.
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.
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.
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.
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.
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.
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.
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, trends and implications comparable to those available from the chart. Where possible and practical, the actual data is provided in a table.
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.
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. 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.
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.
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."
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.
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.
An e-learning application
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.
A linked thumbnail image
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".
Different alternatives for an image of the world: An image of the world that is used on a travel site as a link to the International Travel section has the text alternative "International Travel". The same image is used as a link on a university Web site with the text alternative "International Campuses".
Resources are for information purposes only, no endorsement implied.
Excerpts from the NBA Tape Recording Manual, Third Edition. Information on describing complex images to people who are blind.
Inaccessibility of CAPTCHA. Examines a number of potential solutions that allow systems to test for human users while preserving access by users with disabilities.
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.
Instructions: Select the situation below that matches your content. Each situation includes numbered techniques (or combinations of techniques) that the Working Group deems to be sufficient for that situation.
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
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:
G92: Providing long description for non-text content that serves the same purpose and presents the same information using a long text alternative technique listed below
G82: Providing a text alternative that identifies the purpose of the non-text content using a short text alternative technique listed below
Using HTML form controls and links (future link)
H44: Using label elements to associate text labels with form controls (HTML)
H65: Using the title attribute to identify form controls when the label element cannot be used (HTML)
Using (X)HTML according to spec (future link)
Providing a descriptive label using a short text alternative technique listed below
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
G100: Providing the accepted name or a descriptive name of the non-text content using a short text alternative technique listed below
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
H36: Using alt attributes on images used as submit buttons (HTML)
H2: Combining adjacent image and text links for the same resource (HTML)
H24: Providing text alternatives for the area elements of image maps (HTML)
Providing text alternatives for strings where look-alike glyphs are used in place of letters (e.g. leetspeak) (future link)
Providing text alternatives for ASCII art (future link)
H45: Using longdesc (HTML)
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.
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)
Providing different sizes for non-text content when it cannot have an equivalent accessible alternative (future link)
Using server-side scripts to resize images of text (future link)
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)
Providing a transcript of a live audio only presentation after the fact (future link)
Providing more than two modalities of CAPTCHAs (future link)
Providing access to a human customer service representative who can bypass CAPTCHA (future link)
Not requiring CAPTCHAs for authorized users (future link)
Writing for browsers that do not support frame
Providing alternative content for iframe
H27: Providing text and non-text alternatives for object (HTML)
Not using long descriptions for iframe
Providing redundant text links for client-side image maps (future link)
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)
Using the ARIA presentation role to indicate elements are purely presentational (future link)
Using metadata to associate text transcriptions with a video (future link)
Using metadata to associate text transcriptions with audio-only content (future link)
EXAMPLE: Providing, in metadata, URL(s) that points to an audio description and a text transcript of a video.
EXAMPLE: Providing, in metadata, URL(s) that point to several text transcripts (English, French, Dutch) of an audio file.
The following are common mistakes that are considered failures of Success Criterion 1.1.1 by the WCAG Working Group.
hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents
Note 1: functionality provided by assistive technology includes 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).
Note 2: Assistive technologies often communicate data and messages with mainstream user agents by using and monitoring APIs.
Note 3: The distinction between mainstream user agents and assistive technologies is not absolute. Many mainstream user agents provide some features to assist individuals with disabilities. The basic difference is that mainstream user agents target broad and diverse audiences that usually include people with and without disabilities. Assistive technologies target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important functionality to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles.
Example: Examples of assistive technologies that are important in the context of this document include the following:
screen magnifiers, 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 to improve the visual readability of rendered text and images;
screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;
text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
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 (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices.);
alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.
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]
a time-based live presentation that contains only audio (no video and no interaction)
a time-based live presentation that contains only video (no audio and no interaction)
media that presents no more information than is already presented in text (directly or via text alternatives)
Note: A media alternative to text is provided for those who benefit from alternate representations of text. Media alternatives to text may be audio-only, video-only (including sign-language video), or audio-video.
would be invalid if presented in text
Example: Color blindness test, hearing test, vision exercise, spelling test.
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 to all users. In many (but not all) cases, the label and the name are the same.
Note 2: This is unrelated to the name attribute in HTML.
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
Note: This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which is character substitution), and images representing text .
serving only an aesthetic purpose, providing no information, and having no functionality
Note: Text is only purely decorative if the words can be rearranged or substituted without changing their purpose.
Example: The cover page of a dictionary has random words in very light text in the background.
a sensory experience that is not purely decorative and does not primarily convey important information or perform a function
Example: Examples include a performance of a flute solo, works of visual art etc.
audio or video synchronized with another format for presenting information and/or with time-based interactive components
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
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.
1.1.2 Live Audio-only: All live audio-only content has a text alternative (Level AAA)
The intent of this success criterion is to make information conveyed by live audio, such as video conferencing, live speeches and radio webcasts, accessible through the use of a text alternative. A live text caption service will enable live audio to be accessible to people who are Deaf or hard of hearing, or who cannot otherwise hear the audio. Such services use a trained human operator who listens in to what is being said and uses a special keyboard to enter the text with only a small delay. They are able to capture a live event with a high degree of fidelity, and also to insert notes on any non spoken audio which is essential to understanding the event. A transcript is sometimes a possibility if the live audio is following a set script; but a live caption service is preferred because it plays out at the same pace as the audio itself, and can adapt to any deviations from the script that might occur.
Using untrained operators, or providing a transcript which differs markedly from what actually happens would not be considered meeting this success criterion.
A public relations firm uses Web based caption services to cover live events; the output from the service is incorporated in a sub frame of the Web page which includes the streaming audio control.
A live radio play of a fringe theatre group is being broadcast to the Web. As the actors stick largely to a set script, and the budget for the program is small, the producers provide a link (with the playwright’s permission) to the script of the play.
A streaming audio server uses a media format which can also accommodate text and graphics, such as Flash or Silverlight. A stenographer is used to create live captions at an event, and these are mixed on the fly to produce live captions in the media stream which can be viewed by the media player.
A CEO is to give a press release by telephone to the media in response to a breaking news story, the audio is being recorded and streamed over the internet, but due to time constraints a Web captioning service cannot be set up in time. As the press release is a set statement which the CEO will be reading out, the company simultaneously provides the transcript of the release.
Resources are for information purposes only, no endorsement implied.
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.
Providing a viewport to a live text service which is being created by a trained stenographer who transcribes the spoken audio with minimal errors (future link)
Providing a link to a text transcript of a prepared statement or script if the script is followed (future link)
G150: Providing text alternatives for live audio-only content
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.
The following are common mistakes that are considered failures of Success Criterion 1.1.2 by the WCAG Working Group.
(No failures currently documented)
Guideline 1.2: Provide synchronized alternatives for synchronized media
The purpose of this guideline is to provide access to synchronized media. Synchronized media is defined in the glossary as:
audio or video synchronized with another format for presenting information 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 synchronized media including any interaction instead of audio description for synchronized media would allow access to all of the information in the synchronized media. This option also allows access to the visual information in non-visual form when audio description is not provided for some other reason.
For synchronized media that includes interaction, interactive elements (for example links) could be embedded in the full text alternative for synchronized media.
This guideline also includes (at Level AAA) sign language interpretation for synchronized media 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. 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.
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.
1.2.1 Captions (Prerecorded): Captions are provided for prerecorded synchronized media, except if the synchronized media is an alternative to text and is clearly labeled as such . (Level A)
The intent of this success criterion is to enable people who are deaf or hard of hearing to watch synchronized media 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.
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.
Captions are not needed when the synchronized media 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 synchronized media presentation that presents no more information than is already presented in text, 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).
People who are deaf or have a hearing loss can access the auditory information in the synchronized media content through captions.
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.
A complex legal document contains synchronized media 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 synchronized media.
An instruction manual containing a description of a part and its necessary orientation is accompanied by a synchronized media clip showing the part in its correct orientation. No captions are provided for the synchronized media clip.
Resources are for information purposes only, no endorsement implied.
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.
G87: Providing closed captions using any readily available media format that has a video player that supports closed captioning
G87: Providing closed captions using any of the technology-specific techniques below
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)
The following are common mistakes that are considered failures of Success Criterion 1.2.1 by the WCAG Working Group.
text presented and synchronized with synchronized media to provide not only the speech, but also non-speech information conveyed through sound, including meaningful sound effects and identification of speakers
Note 1: 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.
Note 2: Audio descriptions can be, but do not need to be, captioned since they are descriptions of information that is already presented visually.
media that presents no more information than is already presented in text (directly or via text alternatives)
Note: A media alternative to text is provided for those who benefit from alternate representations of text. Media alternatives to text may be audio-only, video-only (including sign-language video), or audio-video.
audio or video synchronized with another format for presenting information and/or with time-based interactive components
1.2.2 Audio Description or Full Text Alternative: Audio description of video, or a full text alternative for synchronized media including any interaction , is provided for prerecorded synchronized media. (Level A)
Note: For 1.2.2, 1.2.4, and 1.2.7, if all of the information in the video track is already provided in the audio track, no audio description is necessary.
The intent of this success criterion is to provide people who are blind or visually impaired access to the visual information in a synchronized media 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 synchronized media (both visual and auditory) in text form. A full text alternative for synchronized media including any interaction provides a running description of all that is going on in the synchronized media content. The full text alternative for synchronized media 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 synchronized media itself. As a result, the full text alternative for synchronized media can provide a much more complete representation of the synchronized media content than audio description alone.
If there is any interaction as part of the synchronized media presentation (e.g. "press now to answer the question") then the full text alternative for synchronized media would provide hyperlinks or whatever is needed to provide the same functionality.
Note 1: 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.
Note 2: 1.2.2, 1.2.3, and 1.2.7 overlap somewhat with each other. This is to give the author some choice at the minimum conformance level, and to provide additional requirements at higher levels. At Level A in SC 1.2.2, authors do have the choice of providing either an audio description or a full text alternative. If they wish to conform at Level AA, under SC 1.2.4 authors must provide an audio description - a requirement already met if they chose that alternative for 1.2.2, otherwise an additional requirement. At Level AAA under SC 1.2.7 they must provide an extended text description. This is an additional requirement if both 1.2.2 and 1.2.4 were met by providing an audio description only. If 1.2.2 was met, however, by providing a text description, and the 1.2.4 requirement for an audio description was met, then 1.2.7 does not add new requirements.
This success criterion may help some people who have difficulty watching video or other synchronized media content, including people who have difficulty perceiving or understanding moving images.
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 synchronized media 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 synchronized media that all employees, including those who cannot see the demonstrations, can use to better understand what is being presented.
Resources are for information purposes only, no endorsement implied.
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.
G69: Providing a full synchronized media text alternative including any interaction
G78: Providing a sound track that includes audio description as the primary sound track
G78: Providing a sound track that includes audio description AND associating it with the synchronized media content using one of the following techniques:
Providing audio description in its own sound track (future link) AND merging the description track with the original soundtrack of the synchronized media 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)
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)
The following are common mistakes that are considered failures of Success Criterion 1.2.2 by the WCAG Working Group.
(No failures currently documented)
narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone
Note 1: Audio description of video provides information about actions, characters, scene changes, on-screen text, and other visual content.
Note 2: In standard audio description, narration is added during existing pauses in dialogue. (See also extended audio description.)
Note 3: Also called "video description" and "descriptive narration."
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 synchronized media
Note: A screenplay used to create the synchronized media content would meet this definition only if it was corrected to accurately represent the final synchronized media after editing.
audio or video synchronized with another format for presenting information and/or with time-based interactive components
1.2.3 Captions (Live): Captions are provided for live synchronized media. (Level AA)
Note: If synchronized media is completely computer generated, it is not live and is subject to the requirements for prerecorded synchronized media in WCAG 2.0.
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.
People who are deaf or have a hearing loss can access the auditory information in the synchronized media content through captions.
A Web cast
A news organization provides a live, captioned Web cast.
Resources are for information purposes only, no endorsement implied.
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.
G9: Creating captions for live synchronized media AND G93: Providing open (always visible) captions
G9: Creating captions for live synchronized media AND G87: Providing closed captions using any readily available media format that has a video player that supports closed captioning
G9: Creating captions for live synchronized media AND G87: Providing closed captions using one of the following techniques:
Note: Captions may be generated using real-time text translation service.
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)
The following are common mistakes that are considered failures of Success Criterion 1.2.3 by the WCAG Working Group.
(No failures currently documented)
text presented and synchronized with synchronized media to provide not only the speech, but also non-speech information conveyed through sound, including meaningful sound effects and identification of speakers
Note 1: 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.
Note 2: Audio descriptions can be, but do not need to be, captioned since they are descriptions of information that is already presented visually.
audio or video synchronized with another format for presenting information and/or with time-based interactive components
1.2.4 Audio Description: Audio description of video is provided for prerecorded synchronized media. (Level AA)
The intent of this success criterion is to provide people who are blind or visually impaired access to the visual information in a synchronized media 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 1: 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.
Note 2: 1.2.2, 1.2.4, and 1.2.7 overlap somewhat with each other. This is to give the author some choice at the minimum conformance level, and to provide additional requirements at higher levels. At Level A in SC 1.2.2, authors do have the choice of providing either an audio description or a full text alternative. If they wish to conform at Level AA, under SC 1.2.4 authors must provide an audio description - a requirement already met if they chose that alternative for 1.2.2, otherwise an additional requirement. At Level AAA under SC 1.2.7 they must provide an extended text description. This is an additional requirement if both 1.2.2 and 1.2.4 were met by providing an audio description only. If 1.2.2 was met, however, by providing a text description, and the 1.2.4 requirement for an audio description was met, then 1.2.7 does not add new requirements.
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.
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.)
Resources are for information purposes only, no endorsement implied.
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.
G78: Providing a sound track that includes audio description as the primary sound track
G78: Providing a sound track that includes audio description AND associating it with the synchronized media content using one of the following techniques:
Providing audio description in its own sound track (future link) AND merging the description track with the original soundtrack of the synchronized media 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)
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)
Providing audio description for live synchronized media (future link)
The following are common mistakes that are considered failures of Success Criterion 1.2.4 by the WCAG Working Group.
(No failures currently documented)
narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone
Note 1: Audio description of video provides information about actions, characters, scene changes, on-screen text, and other visual content.
Note 2: In standard audio description, narration is added during existing pauses in dialogue. (See also extended audio description.)
Note 3: Also called "video description" and "descriptive narration."
audio or video synchronized with another format for presenting information and/or with time-based interactive components
1.2.5 Sign Language: Sign language interpretation is provided for prerecorded synchronized media. (Level AAA)
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 synchronized media presentations. Written text, such as that found in captions, is often a second language. Because sign language provides the ability to provide intonation, emotion and other audio information that is reflected in sign language interpretation, but not in captions, sign language interpretation provides richer and more equivalent access to synchronized media. People who communicate extensively in sign language are also faster in sign language and synchronized media is a time-based presentation.
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 synchronized media content.
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 synchronized media 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 synchronized media version.
Resources are for information purposes only, no endorsement implied.
National Institute on Deafness and other Communication Disorders: Information on American Sign Language
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.
G54: Including a sign language interpreter in the video stream
Providing a new page that has the video with the sign language interpretation of the audio track (future link)
G81: Providing a synchronized video of the sign language interpreter that can be displayed in a different viewport or overlaid on the image by the player 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.
The following are common mistakes that are considered failures of Success Criterion 1.2.5 by the WCAG Working Group.
(No failures currently documented)
translation of one language, generally a spoken language, into a sign language
Note: True sign languages are independent languages that are unrelated to the spoken language(s) of the same country or region.
audio or video synchronized with another format for presenting information and/or with time-based interactive components
1.2.6 Audio Description (Extended): Extended audio description of video is provided for prerecorded synchronized media. (Level AAA)
The intent of this success criterion is to provide people who are blind or visually impaired access to a synchronized media presentation beyond that which can be provided by standard audio description. This is done by periodically freezing the synchronized media presentation and playing additional audio description. The synchronized media 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.
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.
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.
Resources are for information purposes only, no endorsement implied.
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.
Providing a second version of the movie with extended audio descriptions during halted video segments (future link)
G8: Creating an extended audio description for the synchronized media content 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.
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)
The following are common mistakes that are considered failures of Success Criterion 1.2.6 by the WCAG Working Group.
(No failures currently documented)
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.
audio or video synchronized with another format for presenting information and/or with time-based interactive components
1.2.7 Full Text Alternative: A full text alternative for synchronized media including any interaction is provided for all prerecorded synchronized media, except if the synchronized media is an alternative to text and is clearly labeled as such . (Level AAA)
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 synchronized media including any interaction.
This approach involves providing all of the information in the synchronized media (both visual and auditory) in text form. A full text alternative for synchronized media including any interaction provides a running description of all that is going on in the synchronized media content. The full text alternative for synchronized media 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 synchronized media itself. As a result, the full text alternative for synchronized media can provide a much more complete representation of the synchronized media content than audio description alone.
If there is any interaction as part of the synchronized media presentation (e.g. "press now to answer the question") then the full text alternative for synchronized media 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 synchronized media by using a refreshable braille display.
Note 1: 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.
Note 2: 1.2.2, 1.2.4, and 1.2.7 overlap somewhat with each other. This is to give the author some choice at the minimum conformance level, and to provide additional requirements at higher levels. At Level A in SC 1.2.2, authors do have the choice of providing either an audio description or a full text alternative. If they wish to conform at Level AA, under SC 1.2.4 authors must provide an audio description - a requirement already met if they chose that alternative for 1.2.2, otherwise an additional requirement. At Level AAA under SC 1.2.7 they must provide an extended text description. This is an additional requirement if both 1.2.2 and 1.2.4 were met by providing an audio description only. If 1.2.2 was met, however, by providing a text description, and the 1.2.4 requirement for an audio description was met, then 1.2.7 does not add new requirements.
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.
Example 1. full text alternative for synchronized media 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 synchronized media that all clients, including those who can neither see the demonstrations nor hear the explanations in the synchronized media, can use to better understand what is being presented.
Resources are for information purposes only, no endorsement implied.
(none currently documented)
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.
G69: Providing a full synchronized media text alternative including any interaction using one of the following techniques
Linking to the full text alternative for synchronized media including any interaction 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 corrected script (future link)
Adding detail to audio description (future link)
The following are common mistakes that are considered failures of Success Criterion 1.2.7 by the WCAG Working Group.
(No failures currently documented)
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 synchronized media
Note: A screenplay used to create the synchronized media content would meet this definition only if it was corrected to accurately represent the final synchronized media after editing.
media that presents no more information than is already presented in text (directly or via text alternatives)
Note: A media alternative to text is provided for those who benefit from alternate representations of text. Media alternatives to text may be audio-only, video-only (including sign-language video), or audio-video.
Guideline 1.3: Create content that can be presented in different ways (for example simpler layout2094 ) without losing information or structure
The purpose of this guideline is to ensure that all information is available in a form that can be perceived by all users, for example, spoken aloud, or presented in a simpler visual layout . 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 structure and information cannot be programmatically determined by the assistive technology, then it cannot be rendered in other formats as needed by the user.
The success criteria under this guideline all seek to ensure that different types of information that are often encoded in presentation are also available so that they can be presented in other modalities.
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.
Making links visually distinct (future link)
1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
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; words that have special status are indicated by changing the font family and /or bolding, italicizing, or underlining them and so on.
Auditory cues may be used as well. For example, a chime might indicate the beginning of a new section; a change in voice pitch or speech rate may be used to emphasize important information or to indicate quoted text; etc.
When such relationships are perceivable to one set of users, those relationships can be made to be perceivable to all. One method of determining whether or not information has been properly provided to all users is to access the information serially in different modalities.
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 cannot perceive red, still has the information about the price as long as it is preceded by the currency symbol.
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.
There may also be cases where it may be a judgment call about what information should appear in text and what would need to be directly associated, and it may be most appropriate to duplicate some information (for instance, in an HTML table, providing the summary both in the paragraph before the table and in the summary attribute of the table itself). However, wherever possible it is necessary for the information to be programmatically determined rather than providing a text description before encountering the table.
Note: It is not required that color values be programmatically determined. The information conveyed by color cannot be adequately presented simply by exposing the value. Therefore, success criterion 1.4.1 addresses the specific case of color, rather than success criterion 1.3.1.
This success criterion helps people with different disabilities by allowing user agents to adapt content according to the needs of individual users.
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.
A form with required fields
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.
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.
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.
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.
Instructions: Select the situation below that matches your content. Each situation includes numbered techniques (or combinations of techniques) that the Working Group deems to be sufficient for that situation.
G115: Using semantic elements to mark up structure AND H49: Using semantic markup to mark emphasized or special text (HTML)
G117: Using text to convey information that is conveyed by variations in presentation of text
Separating information and structure from presentation to enable modification of presentation without altering content (future link)
Making information and relationships conveyed through presentation programmatically determinable using the following techniques:
H51: Using table markup to present tabular information (HTML)
H39: Using caption elements to associate data table captions with data tables (HTML)
H73: Using the summary attribute of the table element to give an overview of data tables (HTML)
H63: Using the scope attribute to associate header cells and data cells in data tables (HTML)
H43: Using id and headers attributes to associate data cells with header cells in data tables (HTML)
H44: Using label elements to associate text labels with form controls (HTML)
H65: Using the title attribute to identify form controls when the label element cannot be used (HTML)
H71: Providing a description for groups of form controls using fieldset and legend elements (HTML)
Using OPTGROUP to group OPTION elements inside a SELECT (future link)
Grouping form controls with FIELDSET and LEGEND (future link)
SCR21: Using functions of the Document Object Model (DOM) to add content to a page (Scripting)
G117: Using text to convey information that is conveyed by variations in presentation of text
Making information and relationships conveyed through presentation programmatically determinable or available in text using the following techniques:
T1: Using standard text formatting conventions for paragraphs (TXT)
T2: Using standard text formatting conventions for lists (TXT)
T3: Using standard text formatting conventions for headings (TXT)
Presenting tabular information in plain text (future link)
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 CSS styles to change or enhance the presentation of structure (future link)
Using CSS rather than tables for page layout (future link)
Positioning labels to maximize predictability of relationships
Providing labels for all form controls that do not have implicit labels (future link)
The following are common mistakes that are considered failures of Success Criterion 1.3.1 by the WCAG Working Group.
hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents
Note 1: functionality provided by assistive technology includes 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).
Note 2: Assistive technologies often communicate data and messages with mainstream user agents by using and monitoring APIs.
Note 3: The distinction between mainstream user agents and assistive technologies is not absolute. Many mainstream user agents provide some features to assist individuals with disabilities. The basic difference is that mainstream user agents target broad and diverse audiences that usually include people with and without disabilities. Assistive technologies target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important functionality to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles.
Example: Examples of assistive technologies that are important in the context of this document include the following:
screen magnifiers, 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 to improve the visual readability of rendered text and images;
screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;
text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
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 (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices.);
alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.
rendering of the content in a form to be perceived by users
determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities
Example: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.
Example: Determined from technology-specific data structures in a non-markup language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.
meaningful associations between distinct pieces of content
any software that retrieves and presents Web content for users
Example: Web browsers, media players, plug-ins, and other programs — including assistive technologies — that help in retrieving, rendering, and interacting with Web content.
1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined . (Level A)
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. 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.
A sequence is meaningful if the order of content in the sequence cannot be changed without affecting its meaning. For example, 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.
The order of content in a sequence is not always meaningful. For example, the relative order of the main section of a Web page and a navigation section does not affect their meaning. They could occur in either order in the programmatically determined reading sequence. As another example, a magazine article contains several callout sidebars. The order of the article and the sidebars does not affect their meaning. In these cases there are number of different reading orders for a Web page that can satisfy the success criterion.
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.
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.
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.
G57: Ordering the content in a meaningful sequence for all the content in the Web page
Marking sequences in the content as meaningful using one of the following techniques AND G57: Ordering the content in a meaningful sequence for those sequences
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 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)
Using appropriate justification for languages that are written right-to-left (future link)
Providing a link to linearized rendering (future link)
Providing a style switcher between style sheets that affect presentation order (future link)
The following are common mistakes that are considered failures of Success Criterion 1.3.2 by the WCAG Working Group.
determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities
Example: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.
Example: Determined from technology-specific data structures in a non-markup language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.
1.3.3 Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation or sound. (Level A)
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.
In some languages, it is commonly understood that "above" refers to the content previous to that point in the content and "below" refers to the content after that point. In such languages, if the content being referenced is in the appropriate place in the reading order and the references are unambiguous, statements such as "choose one of the links below" or "all of the above" would conform to this success criterion.
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.
Example 1: A schedule of competitive events uses color and shape to distinguish the time of each event
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.
Example 2: An on-line multi-page survey
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.
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.
Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.
Using an image with a text alternative for graphical symbols instead of a Unicode font glyph with the desired graphical appearance but different meaning (future link)
The following are common mistakes that are considered failures of Success Criterion 1.3.3 by the WCAG Working Group.
Guideline 1.4: Make it easier for users2204 to see and hear content including separating foreground from background
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.
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.
Using readable fonts (future link)
Making sure any text in images of text is at least 14 points and has good contrast (future link)
Providing a highly visible highlighting mechanism for links or controls when they receive keyboard focus (future link)
1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)
Note 1: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3.
Note 2: Programmatic access to color and other visual presentation coding is covered in Guideline 1.3.
The intent of this success criterion is to ensure that all users can access information that is conveyed by color differences, that is, by the use of color where each color has a meaning assigned to it. If the information is conveyed through color differences in an image (or other non-text format), the color may not be seen by users 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.
Examples of information conveyed by color differences: “required fields are red”, “error is shown in red”, and “Mary’s sales are in red, Tom's are in blue”.
Note: This should not in any way discourage the use of color on a page, or even color coding if it is redundant with other visual indication.
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.
People using text-only, limited color, or monochrome displays may be unable to access color-dependent information.
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.
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.
Resources are for information purposes only, no endorsement implied.
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.
Instructions: Select the situation below that matches your content. Each situation includes numbered techniques (or combinations of techniques) that the Working Group deems to be sufficient for that situation.
G14: Ensuring that information conveyed by color differences is also available in text
Ensuring that when text color differences are used to convey information, the text style is visually differentiated without color differences (future link)
Conveying all information in text that is conveyed by color differences (future link)
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)
C16: Changing the background color or border of the element with focus (CSS)
The following are common mistakes that are considered failures of Success Criterion 1.4.1 by the WCAG Working Group.
1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume which can be set to be a different level from the system volume level . (Level A)
Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
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. 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.
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).
This success criterion also benefits people who have difficulty focusing on visual content (including text) when audio is playing.
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.
A Flash splash page with sound that plays and then stops in less than 3 seconds.
A Flash splash page with sound that plays automatically includes a control at the top that allows users to turn the sound off.
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.
G60: Playing a sound that turns off automatically within three seconds
Playing sounds only on user request (future link)
Providing a control near the top of the Web page that turns off sounds that play automatically (future link)
Providing a user interface control to pause or stop synchronized media (future link)
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)
The following are common mistakes that are considered failures of Success Criterion 1.4.2 by the WCAG Working Group.
process or technique for achieving a result
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.
1.4.3 Contrast (Minimum): Text and images of text have a contrast ratio of at least 5:1, except for the following: (Level AA)
Large Print: Large-scale text and large-scale images of text have a contrast ratio of at least 3:1;
Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are incidental text in an image, or that are not visible to anyone, have no minimum contrast requirement.
Note: Success Criteria 1.4.3 and 1.4.6 can be met via a contrast control available on or from the page.
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. Therefore, 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.
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.
The previously-mentioned contrast requirements for text also apply to images of text (text that has been rendered into pixels and then stored in an image format) as stated in success criterion 1.4.3.
This requirement applies to situations in which images of text were intended to be understood as text. Incidental text, such as in photographs that happen to include a street sign, are not included. Nor is text that for some reason is designed to be invisible to all viewers. Stylized text, such as in corporate logos, should be treated in terms of its function on the page, which may or may not warrant including the content in the text alternative.
Note 1: Some people with cognitive disabilities require color combinations or hues that have low contrast, and therefore we allow and encourage authors to provide mechanisms to adjust the foreground and background colors of the content. Some of the combinations that could be chosen may have contrast levels that will be lower than those found in the Success Criteria. This is not a violation of this Success Criteria provided there is a mechanism that will return to the default values set out in the Success Criteria.
Note 2: Images of text do not scale as well as text because they tend to pixelate. It is also harder to change foreground and background contrast and color combinations for images of text, which is necessary for some users. Therefore, we suggest using text wherever possible, and when not, consider supplying an image of higher resolution.
Although this success criterion only applies to text, similar issues occur for data presented in charts or graphs. Good color contrast should also be provided for data presented in these forms.
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.
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: Refer to related resources for a list of tools that utilize the contrast ratio to analyze the contrast of Web content.
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.
Resources are for information purposes only, no endorsement implied.
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.
Instructions: Select the situation below that matches your content. Each situation includes numbered techniques (or combinations of techniques) that the Working Group deems to be sufficient for that situation.
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)
Using a light pastel background rather than a white background behind black text (future link)
Using Unicode text and style sheets instead of images of text (future link)
Using a higher contrast values for lines in diagrams (future link)
Using greater contrast level for red-black text/background combinations
Using colors that are composed predominantly of mid spectral components for the light and spectral extremes (blue and red wavelengths) for the dark
Using a light pastel background rather than a white background behind black text to create sufficient but not extreme contrast (future link)
Making icons using simple line drawings that meet the contrast provisions for text (future link)
Providing sufficient color contrast in graphs and charts (future link)
The following are common mistakes that are considered failures of Success Criterion 1.4.3 by the WCAG Working Group.
(L1 + 0.05) / (L2 + 0.05), where
L1 is the relative luminance of the lighter of the foreground or background colors, and
L2 is the relative luminance of the darker of the foreground 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: Background color is the specified color of content over which the text is to be rendered in normal usage. It is a failure if no background color is specified when a foreground color is specified, because the user's default background color is unknown and cannot be evaluated for sufficient contrast. For the same reason, it is a failure if no foreground color is specified when a background color is specified.
text that is inconsequential to the meaning of the image
Example: In a photo of two men talking on a street corner, there is a sign on a store in the background.
with at least 18 point or 14 point bold or font size that would yield equivalent stroke width for Chinese, Japanese and Korean (CJK) fonts
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.
Note 3: The actual size of the character that a user sees in dependent both on the author-defined size and the users display or user-agent settings. This success criterion is based on common pixel sizes available today. Users who have low vision would be responsible for choosing appropriate settings.
sequence of characters that can be programmatically determined, where the sequence is expressing something in human language
1.4.4 Resize text: Text (but not images of text) can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)
The intent of this success criterion is to ensure that visually rendered text, including text-based controls (text characters that have been displayed so that they can be seen [vs. text characters that are still in data form such as ASCII]) 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, including text-based controls , 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.
The author cannot rely on the user agent to satisfy this success criterion for HTML content if users do not have access to a user agent with zoom support. For example, if they work in a environment that requires them to use IE 6 or Firefox.
If the author is using a technology whose user agents do not provide zoom support, the author is responsible to provide this type of functionality directly or to provide content that works with the type of functionality provided by the user agent. If the user agent doesn't provide zoom functionality but does let the the user change the text size, the author is responsible for ensuring that the content remains usable when the text is resized.
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.
Note: Images of text do not scale as well as text because they tend to pixelate, and therefore we suggest using text wherever possible. It is also harder to change foreground and background contrast and color combinations for images of text, which are necessary for some users.
This success criterion helps people with low vision by letting them increase text size in content so that they can read it.
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.
Resources are for information purposes only, no endorsement implied.
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.
G142: Using a technology that has commonly-available user agents that support zoom
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:
Specifying the size of objects in terms of the font size (future link)
Techniques for relative measurements
Techniques for text container resizing
Calculating size and position in a way that scales with text size (future link) (Scripting)
Providing controls on the Web page that incrementally change the size of the text (future link)
Providing options within the content to switch between layouts that use a variety of font sizes (future link)
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)
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)
Providing sufficient inter-line and inter-column spacing (future link)
Providing different sizes for non-text content when it cannot have an equivalent accessible alternative (future link)
Avoiding the use of text in raster images (future link)
Using server-side scripts to resize images of text (future link)
Ensuring that text in raster images is at least 18pt (future link)
Scaling text down to 50% (future link)
The following are common mistakes that are considered failures of Success Criterion 1.4.4 by the WCAG Working Group.
hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents
Note 1: functionality provided by assistive technology includes 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).
Note 2: Assistive technologies often communicate data and messages with mainstream user agents by using and monitoring APIs.
Note 3: The distinction between mainstream user agents and assistive technologies is not absolute. Many mainstream user agents provide some features to assist individuals with disabilities. The basic difference is that mainstream user agents target broad and diverse audiences that usually include people with and without disabilities. Assistive technologies target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important functionality to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles.
Example: Examples of assistive technologies that are important in the context of this document include the following:
screen magnifiers, 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 to improve the visual readability of rendered text and images;
screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;
text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
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 (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices.);
alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.
sequence of characters that can be programmatically determined, where the sequence is expressing something in human language
1.4.5 Images of Text (Limited): When the accessibility supported technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following: (Level AA)
Customizable: The image of text can be visuallycustomized to the user's requirements;
Essential: A particular presentation of text is essential to the information being conveyed.
Note: Logotypes (text that is part of a logo or brand name) are considered essential.
The intent of this success criterion is to encourage authors who are using technologies that are capable of achieving a specific visual presentation to enable people who require a particular visual presentation of text to be able to adjust the text presentation as required. This includes people who require the text in a particular font size, foreground and background color, font family, line spacing or alignment.
If an author can use text to achieve the same visual effect, he or she should present the information as text rather than using an image. If for any reason, the author cannot format the text to get the same effect, the effect won't be reliably presented on the commonly available user agents, or using a technology to meet this criterion would interfere with meeting other criterion such as 1.4.4, then an image of text can be used. This includes instances where a particular presentation of text is essential to the information being conveyed, such as type samples, logotypes, brand names, etc. Images of text can also be used where it is possible for users to customize the image of text to match their requirements.
Techniques for satisfying this success criterion are the same as those for Success Criterion 1.4.9, except that they only need to apply if the visual presentation can be achieved with the technologies that the author is using. For success criterion 1.4.9, the sufficient techniques would be applied only when the user can customize the output.
People with low vision (who may have trouble reading the text with the authored font family, size and/or color).
People with visual tracking problems (who may have trouble reading the text with the authored line spacing and/or alignment).
Styled Headings
Rather than using bitmap images to present headings in a specific font and size, an author uses CSS to achieve the same result.
Dynamically Generated Images
A Web page uses server-side scripting to present text as an an image. The page includes controls that allow the user to adjust the font size and foreground and background colors of the generated image.
A quote
A web page contains a quote. The quote itself is presented as italicized text, indented from the left margin. The name of the person to whom the quote is attributed is below the quote with 1.5x the line space and further indented from the left margin. CSS is used to position the text; set the spacing between lines; as well as display the text's font family, size, color and decoration.
Navigation items
A web page contains a menu of navigation links that have both an icon and text to describe their target. CSS is used to display the text's font family, size and foreground and background colors; as well as the spacing between the navigation links.
A logo containing text
A web site contains the organisation's logo in the top left corner of each web page. The logo contains logotype (text as part, or all, of the logo). The visual presentation of the text is essential to the identity of the logo and is included as a gif image which does not allow the text characteristics to be changed. The image has a text alternative.
Representation of a font family
A web page contains information about a particular font family. Substituting the font family with another font would defeat the purpose of the representation. The representation is included as a jpeg image which does not allow the text characteristics to be changed. The image has a text alternative.
A representation of a letter
A web page contains a representation of an original letter. The depiction of the letter in its original format is essential to information being conveyed about the time period in which it was written. The letter is included as a gif image which does not allow the text characteristics to be changed. The image has a text alternative.
Symbolic text characters
A form allows users to enter blocks of text. The form provides a number of buttons, including functions to style the text and check spelling. Some of the buttons use text characters that do not form a sequence that expresses something in human language. For example "B" to increase font weight, "I" to italicize the text and "ABC" to check the spelling. The symbolic text characters are included as gif images which do not allow the text characteristics to be changed. The buttons have text alternatives.
Resources are for information purposes only, no endorsement implied.
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.
Using CSS to control visual presentation of text (future link)
Providing controls on the Web page that change the visual presentation of text (future link)
G140: Separating information and structure from presentation so that Web pages can be presented different ways without losing information OR Separating information and structure from presentation to enable modification of presentation without altering content (future link)
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.
C8: Using CSS letter-spacing to control spacing within a word (CSS)
Avoid applying text styling to text characters within a word (future link)
Changing line height (future link)
Specifying the font family (future link)
Changing letter-spacing (future link)
Aligning text (future link)
Changing the case of text (future link)
Indenting paragraphs (future link)
Layering text over images (future link)
Italicizing text (future link)
Increasing font weight of text (future link)
Styling the first line of a block of text (future link)
Styling the first letter of a block of text (future link)
Adding a drop-shadow to text (future link)
The following are common mistakes that are considered failures of Success Criterion 1.4.5 by the WCAG Working Group.
(No failures currently documented)
1.4.6 Contrast (Enhanced): Text and images of text have a contrast ratio of at least 7:1, except for the following: (Level AAA)
Large Print: Large-scale text and large-scale images of text have a contrast ratio of at least 5:1;
Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are incidental text in an image, or that are not visible to anyone, have no minimum contrast requirement.
Note: Success Criteria 1.4.3 and 1.4.6 can be met via a contrast control available on or from the page.
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. Therefore, 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.
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.
Note: When fonts have anti-aliasing applied to make them look smoother, they can lose darkness or lightness. Thus, the actual contrast can be reduced. Thicker stem widths will reduce this effect (thin fonts could have the full stem lightened rather than just the ends). Using larger fonts and testing for legibility in user agents with font smoothing turned on is recommended.
The previously-mentioned contrast requirements for text also apply to images of text (text that has been rendered into pixels and then stored in an image format) as stated in success criterion 1.4.5
This requirement applies to situations in which images of text were intended to be understood as text. Incidental text, such as in photographs that happen to include a street sign, are not included. Nor is text that for some reason is designed to be invisible to all users. Stylized text, such as in corporate logos, should be treated in terms of its function on the page, which may or may not warrant including the content in the text alternative.
Although this success criterion only applies to text, similar issues occur for data presented in charts or graphs. Good color contrast should also be provided for data presented in these forms.
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.
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: Refer to related resources for a list of tools that utilize the contrast ratio to analyze the contrast of Web content.
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.
Resources are for information purposes only, no endorsement implied.
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.
Instructions: Select the situation below that matches your content. Each situation includes numbered techniques (or combinations of techniques) that the Working Group deems to be sufficient for that situation.
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)
Using Unicode text and style sheets instead of images of text (future link)
Using a light pastel background rather than a white background behind black text (future link)
Using a higher contrast values for lines in diagrams (future link)
Using greater contrast level for red-black text/background combinations
Using colors that are composed predominantly of mid spectral components for the light and spectral extremes (blue and red wavelengths) for the dark
Using a light pastel background rather than a white background behind black text to create sufficient but not extreme contrast (future link)
Making icons using simple line drawings that meet the contrast provisions for text (future link)
Providing sufficient color contrast in graphs and charts (future link)
The following are common mistakes that are considered failures of Success Criterion 1.4.6 by the WCAG Working Group.
(L1 + 0.05) / (L2 + 0.05), where
L1 is the relative luminance of the lighter of the foreground or background colors, and
L2 is the relative luminance of the darker of the foreground 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: Background color is the specified color of content over which the text is to be rendered in normal usage. It is a failure if no background color is specified when a foreground color is specified, because the user's default background color is unknown and cannot be evaluated for sufficient contrast. For the same reason, it is a failure if no foreground color is specified when a background color is specified.
text that is inconsequential to the meaning of the image
Example: In a photo of two men talking on a street corner, there is a sign on a store in the background.
with at least 18 point or 14 point bold or font size that would yield equivalent stroke width for Chinese, Japanese and Korean (CJK) fonts
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.
Note 3: The actual size of the character that a user sees in dependent both on the author-defined size and the users display or user-agent settings. This success criterion is based on common pixel sizes available today. Users who have low vision would be responsible for choosing appropriate settings.
sequence of characters that can be programmatically determined, where the sequence is expressing something in human language
1.4.7 Low or No Background Audio: Audio content that is not an audio CAPTCHA and that contains speech in the foreground does not contain background sounds, background sounds can be turned off, or background sounds are at least 20 decibels lower than the foreground speech content, with the exception of occasional sound effects. (Level AAA)
Note: Background sound that meets this requirement will be approximately one quarter as loud as the foreground speech content.
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. Background sound that meets this requirement will be approximately one quarter as loud as the foreground speech content.
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]
People who are hard of hearing often have great difficulty separating speech from background sound.
Resources are for information purposes only, no endorsement implied.
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.
Not including audio content (future link)
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)
The following are common mistakes that are considered failures of Success Criterion 1.4.7 by the WCAG Working Group.
(No failures currently documented)
1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA)
foreground and background colors can be selected by the user
width is no more than 80 characters
text is not aligned on both the left and the right
line spacing is at least space-and-a-half within paragraphs, and paragraph spacing is larger than line spacing
text is resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text
The intent of this success criterion is to ensure that visually rendered text is presented in such a manner that it can be perceived without its layout interfering with its readability. People with some cognitive, language and learning disabilities and some low vision users cannot perceive the text and/or lose their reading place if the text is presented in a manner that is difficult for them to read.
People with some visual or cognitive disabilities need to be able to select the color of text and the color of the background. They sometimes choose combinations that seem unintuitive to someone without that disability. Sometimes these combinations have very low contrast. Sometimes only very specific color combinations work for them. Control of color or other aspects of text presentation makes a huge difference to their comprehension. For this reason we encourage authors to have as many different color combinations available as possible.
For people with some reading or vision disabilities, long lines of text can become a significant barrier. They have trouble keeping their place and following the flow of text. Having a narrow block of text makes it easier for them to continue on to the next line in a block. Lines should not exceed 80 characters.
People with some cognitive disabilities find it difficult to track text where the lines are close together. Providing extra space between lines and paragraphs allows them to better track the next line and to recognize when they have reached the end of a paragraph. It is best if there are several different options, for instance, space-and-a-half and double spacing for line spacing.
People with certain cognitive disabilities have problems reading text that is both left and right justified. The uneven spacing between words in fully justified text can cause "rivers of white" space to run down the page making reading difficult and in some cases impossible. Text justification can also cause words to be spaced closely together, so that it is difficult for them to locate word boundaries.
The resizing provision ensures that visually rendered text [begin add](text characters that have been displayed so that they can be seen [vs. text characters that are still in data form such as ASCII]) [1978] [end add] 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 people with low vision and people with cognitive disabilities 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. See Understanding Success Criterion 2.4.4 (Link Purpose (In Context)) for additional discussion of resizing text.
This success criterion helps low vision users by letting them see text without distracting presentational features. It lets them configure text in ways that will be easier for them to see by letting them control the color and size of blocks of text.
This success criterion helps people with cognitive, language and learning disabilities perceive text and track their location within blocks of text.
People with some cognitive disabilities can read text better when they select their own foreground and background color combinations.
People with some cognitive disabilities can track their locations more easily when blocks of text are narrow and when they can configure the amount of space between lines and paragraphs.
People with some cognitive disabilities can read text more easily when the spacing between words is regular.
None currently documented
Resources are for information purposes only, no endorsement implied.
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.
Techniques to ensure foreground and background colors can be selected by the user
Specifying foreground and background colors in CSS (future link) OR
Providing a color selection tool that allows a pastel background (future link) OR
Providing a multi color selection tool on the page for foreground and background colors (JavaScript, Future Link) OR
Using a technology that has commonly-available user agents that can change the foreground and background of blocks of text (General, future link)
Techniques to ensure width is no more than 80 characters
Not interfering with the user agent's reflow of text as the viewing window is narrowed (General, Future Link) OR
Using ems to set the column width
Techniques to ensure text is not aligned on both the left and the right
Specifying alignment in CSS (CSS) (also allows for tools that use custom stylesheets) OR
Providing a feature to remove full justification of text (future link) OR
Aligning text on only one side (according to the text-direction of the language of the content) (General, future link)
Techniques to ensure line spacing is at least space-and-a-half within paragraphs, and paragraph spacing is larger than line spacing
Providing a button on the page to increase line spaces and paragraph spaces. (HTML, CSS, future link) OR
Specifying line spacing in CSS or not specifying any line spacing (HTML, CSS, future link)
Techniques to ensure text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text
Not interfering with the browser's reflow of text as the viewing window is narrowed (General, Future Link) OR
G146: Using liquid layout AND using measurements that are relative to other measurements in the content by using one or more of the following techniques:
C12: Using percent for font sizes (CSS) OR
C13: Using named font sizes (CSS) OR
C14: Using em units for font sizes (CSS) OR
Using page-percent for container sizes (future link) OR
Calculating size and position in a way that scales with text size (Scripting, future link) OR
Providing options within the content to switch between layouts that use a variety of font sizes (future link)
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 hover effect to highlight a paragraph, list items, or table cells (HTML, CSS) (future link)
Presenting text in sans serif font or providing a mechanism to achieve this (CSS) (future link)
Using vertical (bulleted or numbered) lists rather than inline lists (future link)
Using upper and lower case according to the spelling conventions of the text language (future link)
Providing large fonts by default (future link)
Avoiding the use of text in raster images (future link)
Avoiding scaling font sizes smaller than the user-agent default (future link)
Providing sufficient inter-column spacing (future link)
Avoiding centrally aligned text (future link)
Avoiding chunks of italic text (future link)
Avoiding overuse of different styles on individual pages and in sites (future link)
Making links visually distinct (future link)
Providing expandable bullets (future link)
Show/hide bullet points (future link)
Putting an em-space or two spaces after sentences (future link)
The following are common mistakes that are considered failures of Success Criterion 1.4.8 by the WCAG Working Group.
(No failures currently documented)
more than one sentence of text
1.4.9 Images of Text (Essential): Images of text are only used for pure decoration or where a particular presentation of text is essential to the information being conveyed. (Level AAA)
Note: Logotypes (text that is part of a logo or brand name) are considered essential.
The intent of this success criterion is to enable people who require a particular visual presentation of text to be able to adjust the text presentation as required. This includes people who require the text in a particular font size, foreground and background color, font family, line spacing or alignment.
This means implementing the text in a manner that allows its presentation to be changed or providing a mechanism by which users can select an alternate presentation. Using images of text is an example of an implementation that does not allow users to alter the presentation of the text within it.
In some situations, a particular visual presentation of the text is essential to the information being conveyed. This means that information would be lost without that particular visual presentation. In this case implementing the text in a manner that allows its presentation to be changed is not required. This includes text that demonstrates a particular visual aspect of the text, such as a particular font family, or text that conveys an identity, such as text within a company logo.
Text that is decorative does not require implementing the text in a manner that allows its presentation to be changed.
People with low vision (who may have trouble reading the text with the authored font family, size and/or color).
People with visual tracking problems (who may have trouble reading the text with the authored line spacing and/or alignment).
A quote
A web page contains a quote. The quote itself is presented as italicized text, indented from the left margin. The name of the person to whom the quote is attributed is below the quote with 1.5x the line space and further indented from the left margin. CSS is used to position the text; set the spacing between lines; as well as display the text's font family, size, color and decoration.
Navigation items
A web page contains a menu of navigation links that have both an icon and text to describe their target. CSS is used to display the text's font family, size and foreground and background colors; as well as the spacing between the navigation links.
A logo containing text
A web site contains the organisation's logo in the top left corner of each web page. The logo contains logotype (text as part, or all, of the logo). The visual presentation of the text is essential to the identity of the logo and is included as a gif image which does not allow the text characteristics to be changed. The image has a text alternative.
Representation of a font family
A web page contains information about a particular font family. Substituting the font family with another font would defeat the purpose of the representation. The representation is included as a jpeg image which does not allow the text characteristics to be changed. The image has a text alternative.
A representation of a letter
A web page contains a representation of an original letter. The depiction of the letter in its original format is essential to information being conveyed about the time period in which it was written. The letter is included as a gif image which does not allow the text characteristics to be changed. The image has a text alternative.
Symbolic text characters
A form allows users to enter blocks of text. The form provides a number of buttons, including functions to style the text and check spelling. Some of the buttons use text characters that do not form a sequence that expresses something in human language. For example "B" to increase font weight, "I" to italicize the text and "ABC" to check the spelling. The symbolic text characters are included as gif images which do not allow the text characteristics to be changed. The buttons have text alternatives.
Resources are for information purposes only, no endorsement implied.
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.
Using CSS to control visual presentation of text (future link)
Providing controls on the Web page that change the visual presentation of text (future link)
G140: Separating information and structure from presentation so that Web pages can be presented different ways without losing information OR Separating information and structure from presentation to enable modification of presentation without altering content (future link)
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 server-side scripts to resize images of text (future link)
C8: Using CSS letter-spacing to control spacing within a word (CSS)
Avoid applying text styling to text characters within a word (future link)
Changing line height (future link)
Specifying the font family (future link)
Changing letter-spacing (future link)
Aligning text (future link)
Changing the case of text (future link)
Indenting paragraphs (future link)
Layering text over images (future link)
Italicizing text (future link)
Increasing font weight of text (future link)
Styling the first line of a block of text (future link)
Styling the first letter of a block of text (future link)
Adding a drop-shadow to text (future link)
The following are common mistakes that are considered failures of Success Criterion 1.4.9 by the WCAG Working Group.
(No failures currently documented)
serving only an aesthetic purpose, providing no information, and having no functionality
Note: Text is only purely decorative if the words can be rearranged or substituted without changing their purpose.
Example: The cover page of a dictionary has random words in very light text in the background.
sequence of characters that can be programmatically determined, where the sequence is expressing something in human language
Guideline 2.1: Make all functionality available from a keyboard
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.
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.
2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.
Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
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.
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.
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.
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.
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).
It is assumed that the design of user input features takes into account that operating system keyboard accessibility features may be in use. For example, modifier key locking may be turned on. Content continues to function in such an environment, not sending events that would collide with the modifier key lock to produce unexpected results.
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)
Some people with hand tremors find using a mouse very difficult and therefore usually use a keyboard
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.
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.
Ensuring keyboard control by using one of the following techniques.
Using HTML form controls and links (future link)
G90: Providing keyboard-triggered event handlers using one of the following techniques:
SCR20: Using both keyboard and other device-specific functions (Scripting)
Making JavaScript actions keyboard accessible (future link)
Creating device-independent image effects (future link)
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) (Scripting)
Using the onactivate event (future link) (Scripting)
Avoiding use of common user-agent keyboard commands for other purposes (future link)
The following are common mistakes that are considered failures of Success Criterion 2.1.1 by the WCAG Working Group.
processes and outcomes achievable through user action
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.
2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys, the user is advised of the method for moving focus away. (Level A)
Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
The intent of this success criterion is to ensure that that content does not "trap" keyboard focus within subsections of content on a Web page. This is a common problem when multiple formats are combined within a page and rendered using plug-ins or embedded applications.
People who rely on a keyboard or keyboard interface to use the Web including people who are blind and people with physical disabilities.
A calendar widget
A calendar widget allows users to add, remove or update items in their calendar using the keyboard. The controls in the widget are part of the tab order within the Web page, allowing users to tab through the controls in the widget as well as to any links or controls that follow.
A puzzle applet
Once a user tabs into an applet, further tabs and other keystrokes are handled by the applet. Instructions describing the keystroke used to exit the applet are provided prior to the applet as well as within the applet itself.
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.
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)
The following are common mistakes that are considered failures of Success Criterion 2.1.2 by the WCAG Working Group.
(No failures currently documented)
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.
2.1.3 Keyboard (No Exception): All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA)
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.
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.
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.
processes and outcomes achievable through user action
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.
Guideline 2.2: Provide users with disabilities enough time to read and use content
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.
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.
2.2.1 Timing Adjustable: For each time limit that is set by the content, at least one of the following is true: (Level A)
Turn off: the user is allowed to turn off the time limit before encountering it; or
Adjust: the user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
Extend: the user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar "), and the user is allowed to extend the time limit at least ten times; or
Real-time Exception: the time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
Essential Exception: the time limit cannot be extended without invalidating the activity; or
20 Hour Exception: the time limit is longer than 20 hours.
Note: This success criterion acts to ensure that changes in content or context as a result of a time limit will not occur unexpectedly, preventing users from completing tasks. While exceptions to success criterion 2.2.1 where timing is essential exist, guideline 2.2 in general limits changes in content for no reason. This success criterion should be considered in conjunction with Success Criterion 3.2.1 which puts limits on changes of content or context as a result of user action.
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 read content or 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 time limit 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 time limits, or request more time before a time limit occurs helps those users who require more time than expected to successfully complete tasks. These options are listed in the order that will be most helpful for the user. Disabling time limits is better than customizing the length of time limits, which is better than requesting more time before a time limit occurs.
Any process that happens without user initiation after a set time or on a periodic basis is a time limit. This includes partial or full updates of content (for example, page refresh), changes to content, or the expiration of a window of opportunity for a user to react to a request for input.
In some cases, however, it is not possible to change the time limit (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 time limits like login expiration are dealt with in success criterion 2.2.5 .
Non-timed server redirects (e.g. 3xx response codes) are not applicable because there is no time limit: they work instantly.
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.
Ten 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.
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.
20 hours was chosen as an upper limit because it is longer than a full waking day.
In cases where timing is not an intrinsic requirement but giving users control over timed events would invalidate the outcome, a third party can control the time limits for the user (for example, granting double time on a test).
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.
A Web site uses a client side time limit 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.
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 ten times the default. The control can be operated with either a mouse or a keyboard.
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.
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.
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.
Resources are for information purposes only, no endorsement implied.
(none currently documented)
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.
Instructions: Select the situation below that matches your content. Each situation includes numbered techniques (or combinations of techniques) that the Working Group deems to be sufficient for that situation.
Providing a way for the user to turn the time limit off (future link)
Providing the user with a means to set the time limit to 10 times the default time limit (future link)
SCR16: Providing a script that warns the user a time limit is about to expire (Scripting) AND SCR1: Allowing the user to extend the default time limit (Scripting)
Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.
Using a script to poll the server and notify a user if a time limit is present (future link) (Scripting)
The following are common mistakes that are considered failures of Success Criterion 2.2.1 by the WCAG Working Group.
activity where moving, blinking, scrolling, or auto-updating is central to the design of the activity and removal would fundamentally change the functionality of the content
2.2.2 Pausing: Moving, blinking, scrolling, or auto-updating information on a Web page that lasts for more than three seconds can be paused by the user unless the movement, blinking, scrolling, or auto-updating is part of an activity where the changes are essential. Moving or blinking content that is pure decoration can be stopped or hidden by the user. (Level AA)
Note 1: For requirements related to flickering or flashing content, refer to Guideline 2.3.
Note 2: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
Note 3: Content that is updated from a process, real-time or remote stream is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.
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, synchronized media 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.
Editorial Note: SC 2.2.2 and 2.2.3 were combined, the original intent for 2.2.2 is pasted below for reference.
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 cannot wait it out if necessary in order to use the page and the blinking blocks their ability to focus on the page.
Note: In some cases, what we refer to as “blinking” and what we refer to as “flashing” may overlap slightly. We are using different terms for the two because one causes a distraction problem which you can allow for a short time as long as it stops (or can be stopped) whereas the other is a seizure trigger and cannot be allowed or it will cause a seizure. The seizure would occur faster than most users could turn it off. “Blink” therefore refers to slow repeating changes that would distract. Flash refers to changes that could cause a seizure if they were bright enough or persisted long enough. Blinking usually doesn’t occur at speeds of 3 per second (or more), so blink and flash do not usually overlap. However, blinking can occur faster than 3 per second so there could be an overlap. See 2.3 for more information on flash.
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.
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.
An essential animation can be paused without effecting the activity
A Web site helps users understand 'how things work' through animations that demonstrate processes. Animations have "pause" and "restart" buttons.
A stock ticker.
A stock ticker has "pause" and "restart" buttons. Pausing the ticker causes it to pause on the 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.
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.
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)
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.
Editorial Note: SC 2.2.2 and 2.2.3 were combined, but the updated understanding document is still in progress. Original techniques pasted below for reference.
G4: Allowing the content to be paused and restarted from where it was stopped
Using script to scroll content, and providing a mechanism to pause it (future link)
Allowing purely decorative content to be stopped (future link)
Using a technology to include blinking content that can be turned off via the user agent (future link)
Using a control in the Web page that stops blinking content (future link) using one of the following techniques:
Setting animated gif images to stop blinking after n cycles (within 3 seconds) (future link)
Providing a link, button, or other mechanism that reloads the page without the blinking content (future link)
SCR22: Using scripts to control blinking and stop it in three seconds or less (Scripting)
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)
The following are common mistakes that are considered failures of Success Criterion 2.2.2 by the WCAG Working Group.
activity where moving, blinking, scrolling, or auto-updating is central to the design of the activity and removal would fundamentally change the functionality of the content
switch back and forth between two visual states in a way that is meant to draw attention
Note: See also flash (It is possible for something to be large enough and blink brightly enough at the right frequency to be also classified as a flash).
stopped by user request and not resumed until requested by user
a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent
Note 1: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.
Note 2: For the purposes of conformance with these guidelines, a resource must be "non-embedded" within the scope of conformance to be considered a Web page.
Example 1: A Web resource including all embedded images and media.
Example 2: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://example.com/mail, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.
Example 3: A customizable portal site, where users can choose content to display from a set of different content modules.
Example 4: 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 and into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.
2.2.3 No Timing: Timing is not an essential part of the event or activity presented by the content, except for non-interactive synchronized media and real-time events. (Level AAA)
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.
Note: Video only, such as sign language, is covered in Guideline 1.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.
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.
Resources are for information purposes only, no endorsement implied.
(none currently documented)
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.
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)
The following are common mistakes that are considered failures of Success Criterion 2.2.3 by the WCAG Working Group.
(No failures currently documented)
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 (occurs at the same time as the viewing and is not prerecorded).
Example 2: An on-line auction with people bidding (occurs at the same time as the viewing).
Example 3: Live humans interacting in a fantasy world using avatars (is not completely generated by the content and occurs at the same time as the viewing).
audio or video synchronized with another format for presenting information and/or with time-based interactive components
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.
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).
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.
Resources are for information purposes only, no endorsement implied.
(none currently documented)
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.
G75: Providing a mechanism to postpone any updating of content
Allowing users to request updates instead of automatically updating content (future link)
SCR14: Using scripts to make nonessential alerts optional (Scripting)
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)
The following are common mistakes that are considered failures of Success Criterion 2.2.4 by the WCAG Working Group.
a sudden, unexpected situation or occurrence that requires immediate action to preserve health, safety, or property
2.2.5 Re-authenticating: When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating. (Level AAA)
The intent of this success criterion is to allow all users to complete authenticated transactions that have inactivity time limits. For security reasons, many sites implement an authentication time limit after a certain period of inactivity. These time limits 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.
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.
A shopping site checkout
A user with extremely limited use of the hands is logged into a shopping site. It takes so long to enter credit card information into the application that a time limit 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 time limit
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 in the list of accessibility-supported content technologies that are relied on, the user can elect to be alerted via a pop-up if the session is close to timing out.
Resources are for information purposes only, no endorsement implied.
(none currently documented)
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.
Providing options to continue without loss of data using one of the following techniques:
G105: Saving data so that it can be used after a user re-authenticates
Encoding user data as hidden data in re-authorization page (future link)
Note: Refer to Techniques for Addressing Success Criterion 2.2.1 for techniques related to providing notifications about time limits.
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)
The following are common mistakes that are considered failures of Success Criterion 2.2.5 by the WCAG Working Group.
Guideline 2.3: Do not design content in a way that is known to cause seizures 2312
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.
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.
Ensuring that content does not violate spatial pattern thresholds (future link)
2.3.1 Three Flashes or Below Threshold: Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. (Level A)
Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
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).
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.
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 the UK 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.
Note: In some cases, what we refer to as "blinking" and what we refer to as "flashing" may overlap slightly. We are using different terms for the two because "blinking" causes a distraction problem which you can allow for a short time as long as it stops (or can be stopped) whereas "flashing" is a seizure trigger and cannot be allowed or it will cause a seizure. The seizure would occur faster than most users could turn it off. "Blink" therefore refers to slow repeating changes that would distract. "Flash" refers to changes that could cause a seizure if they were bright enough or persisted long enough. Blinking usually doesn’t occur at speeds of 3 per second or more so blink and flash do not overlap. However, blinking can occur faster than 3 per second so there could be an overlap. See Understanding Succes Criterion 2.2.2 for more information on blink.
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.
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.
A movie with a scene involving very bright lightning flashes is edited so that the lightning only flashes three times in any one second period.
Resources are for information purposes only, no endorsement implied.
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.
Instructions: Select the situation below that matches your content. Each situation includes numbered techniques (or combinations of techniques) that the Working Group deems to be sufficient for that situation.
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 G15: Ensuring that content does not violate the general flash threshold or red flash threshold
Note: There is a tool that is available to carry out this test.
G19: Ensuring that no component of the content flashes more than three times in any 1-second period
Using actual viewing distance to calculate a 10 degree field of view in pixels AND G15: Ensuring that content does not violate the general flash threshold or red flash threshold
Note: There is a tool that is available to carry out this test.
G19: Ensuring that no component of the content flashes more than three times in any 1-second period
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)
Providing a mechanism to suppress any flashing content before it begins (future link)
Slowing down live material to avoid rapid flashes (as in flashbulbs) (future link)
Freezing the image momentarily if 3 flashes within one second are detected (future link)
Dropping the contrast ratio if 3 flashes within one second are detected (future link)
The following are common mistakes that are considered failures of Success Criterion 2.3.1 by the WCAG Working Group.
(No failures currently documented)
a sequence of flashes or rapidly changing image sequences where all three of the following are true:
there are more than three General Flashes and / or more than three Red Flashes within any one-second period; and
the flashing is below 50 Hz; and
the combined area of flashes occurring concurrently occupies more than a total of .006 steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field on the screen) at typical viewing distance, where:
A General 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; where an "a pair of opposing changes" is an increase followed by a decrease, or a decrease followed by an increase, and
A Red Flash is defined as any pair of opposing transitions involving a saturated red.
Exception: Flashing that is a fine, balanced, pattern such as white noise or an alternating checkerboard pattern with "squares" smaller than 0.1 degree on a side does not violate the thresholds.
Note 1: For general software or 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 (e.g. 15-17 inch screen at 22-26 inches). (Higher resolutions yield smaller and safer images so it is lower resolutions that are used to define the thresholds.)
Note 2: The current working definition in the field for "pair of opposing transitions involving a saturated red" is where, for either or both states involved in each transition, R/(R+ G + B) >= 0.8, and the change in the value of (R-G-B)x320 is > 20 (negative values of (R-G-B)x320 are set to zero) for both transitions. R, G, B values range from 0-1 as specified in “relative luminance” definition. (Harding and Binnie 2002)
Note 3: Tools are available that will carry out analysis from video screen capture.
Note 4: No tool is necessary to evaluate for this condition if flashing is less than or equal to 3 flashes in any one second or greater than 50 Hz. Content automatically passes (see #1 and #2 above).
Note 5: 50 Hz is used to coincide with the AC line frequency in Europe and other countries. However almost half of the population is susceptible to 50 Hz flashing whereas only 15 % are susceptible to 60 Hz. 75 Hz or higher is recommended where possible.
a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent
Note 1: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.
Note 2: For the purposes of conformance with these guidelines, a resource must be "non-embedded" within the scope of conformance to be considered a Web page.
Example 1: A Web resource including all embedded images and media.
Example 2: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://example.com/mail, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.
Example 3: A customizable portal site, where users can choose content to display from a set of different content modules.
Example 4: 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 and into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.
2.3.2 Three Flashes: Web pages do not contain anything that flashes more than three times in any one second period. (Level AAA)
The purpose of this success criterion is to further reduce the chance of seizures. Seizures cannot be completely eliminated since some people are so sensitive. However, by eliminating all 3-per-second flashing over any area of the screen, the chances of a person having a seizure are further reduced than when just meeting the measures ordinarily used today in standards internationally, as we do at Level A.
Note: In some cases, what we refer to as "blinking" and what we refer to as "flashing" may overlap slightly. We are using different terms for the two because "blinking" causes a distraction problem which you can allow for a short time as long as it stops (or can be stopped) whereas "flashing" is a seizure trigger and cannot be allowed or it will cause a seizure. The seizure would occur faster than most users could turn it off. "Blink" therefore refers to slow repeating changes that would distract. "Flash" refers to changes that could cause a seizure if they were bright enough or persisted long enough. Blinking usually doesn’t occur at speeds of 3 per second or more so blink and flash do not overlap. However, blinking can occur faster than 3 per second so there could be an overlap. See Understanding Succes Criterion 2.2.2 for more information on blink.
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.
A movie with a scene involving very bright lightning flashes is edited so that the lightning only flashes three times in any one second period.
Resources are for information purposes only, no endorsement implied.
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.
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)
Slowing down live material to avoid rapid flashes (as in flashbulbs) (future link)
Freezing the image momentarily if 3 flashes within one second are detected (future link)
Dropping the contrast ratio if 3 flashes within one second are detected (future link)
The following are common mistakes that are considered failures of Success Criterion 2.3.2 by the WCAG Working Group.
(No failures currently documented)
a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent
Note 1: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.
Note 2: For the purposes of conformance with these guidelines, a resource must be "non-embedded" within the scope of conformance to be considered a Web page.
Example 1: A Web resource including all embedded images and media.
Example 2: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://example.com/mail, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.
Example 3: A customizable portal site, where users can choose content to display from a set of different content modules.
Example 4: 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 and into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.
Guideline 2.4: Provide ways to help users with disabilities navigate, find content and determine where they are
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. Unusual user interface features or behaviors may confuse people with cognitive disabilities.
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. 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.
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.
Limiting the number of links per page (future link)
Providing mechanisms to navigate to different sections of the content of a Web page (future link)
Making links visually distinct (future link)
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. Small repeated sections such as individual words, phrases or single links are not considered blocks for the purposes of this provision.
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.
Note: Although this success criteria deals with blocks of content that are repeated on multiple pages, we also strongly promote structural markup on individual pages as per Success Criteria 1.3.1.
When this success criterion is not satisfied, it may be difficult for people with some disabilities to reach the main content of a Web page quickly and easily.
Screen reader users who visit several pages on the same site can avoid having to hear all heading graphics and dozens of navigation links on every page before the main content is spoken.
People who use only the keyboard or a keyboard interface can reach content with fewer keystrokes. Otherwise, they might have to make dozens of keystrokes before reaching a link in the main content area. This can take a long time and may cause severe physical pain for some users.
People who use screen magnifiers do not have to search through the same headings or other blocks of information to find where the content begins each time they enter a new page.
People with cognitive limitations as well as people who use screen readers may benefit when links are grouped into lists
A news organization's home page contains a main story in the middle of the page, surrounded by many blocks and sidebars for advertising, searching, and other services. There is a link at the top of the page that jumps to the main story. Without using this link, a keyboard user needs to tab through approximately 40 links to reach the main story; the screen reader user has to listen to 200 words; and the screen magnifier user must search around for the location of the main body.
Resources are for information purposes only, no endorsement implied.
(none currently documented)
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.
Creating links to skip blocks of repeated material using one of the following techniques:
G1: Adding a link at the top of each page that goes directly to the main content area
G123: Adding a link at the beginning of a block of repeated content to go to the end of the block
G124: Adding links at the top of the page to each area of the content
Providing a link to "jump to top of page" if the repeated material is at the bottom of the page
Grouping blocks of repeated material in a way that can be skipped, using one of the following techniques:
H69: Providing heading elements at the beginning of each section of content (HTML)
H70: Using frame elements to group blocks of repeated material (HTML) AND H64: Using the title attribute of the frame and iframe elements (HTML)
Using an expandable and collapsible menu (future link)
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)
Providing skip links to enhance page navigation (future link)
Providing access keys (future link)
Using accessibility supported technologies which allow structured navigation by user agents and assistive technologies (future link)
The following are common mistakes that are considered failures of Success Criterion 2.4.1 by the WCAG Working Group.
(No failures currently documented)
a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent
Note 1: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.
Note 2: For the purposes of conformance with these guidelines, a resource must be "non-embedded" within the scope of conformance to be considered a Web page.
Example 1: A Web resource including all embedded images and media.
Example 2: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://example.com/mail, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.
Example 3: A customizable portal site, where users can choose content to display from a set of different content modules.
Example 4: 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 and into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.
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 descriptive 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. User agents make the title of the page easily available to the user for identifying the page. For instance, a user agent may display the page title in the window title bar or as the name of the tab containing the page.
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.
People with visual disabilities will benefit from being able to differentiate content when multiple Web pages are open.
People with cognitive disabilities, limited short-term memory and reading disabilities also benefit from the ability to identify content by its title.
This criterion also benefits people with severe mobility impairments whose mode of operation relies on audio when navigating between Web pages.
An HTML Web page
The descriptive title of an HTML web page is marked up with the <title> element so that it will be displayed in the title bar of the user agent.
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."
A Web application.
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".
Resources are for information purposes only, no endorsement implied.
Writing Better Web Page Titles How to write titles for Web pages that will enhance search engine effectiveness.
Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers. Theofanos, M.F., and Redish, J. (2003). Interactions, Volume X, Issue 6, November-December 2003, pages 38-51, http://portal.acm.org/citation.cfm?doid=947226.947227
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.
G88: Providing descriptive titles for Web pages AND associating a title with a Web page 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.
G127: Identifying a Web page's relationship to a larger collection of Web pages using a technology-specific technique
Identifying the subject of the Web page (future link)
Providing a meaningful name for identifying frames (future link)
Using unique titles for Web pages (future link)
Providing a descriptive top-level page heading (future link)
The following are common mistakes that are considered failures of Success Criterion 2.4.2 by the WCAG Working Group.
a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent
Note 1: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.
Note 2: For the purposes of conformance with these guidelines, a resource must be "non-embedded" within the scope of conformance to be considered a Web page.
Example 1: A Web resource including all embedded images and media.
Example 2: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://example.com/mail, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.
Example 3: A customizable portal site, where users can choose content to display from a set of different content modules.
Example 4: 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 and into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.
2.4.3 Focus Order (Relationships): If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)
The intent of this success criterion is to ensure that when users navigate sequentially through content, they encounter information in an order that is consistent with the meaning of the content and can be operated from the keyboard. This reduces confusion by letting users form a consistent mental model of the content. 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 may satisfy this success criterion.
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. 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").
An example of keyboard navigation that is not the sequential navigation addressed by this success criterion 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.
The focus order may not be identical to the programmatically determined reading order (see SC 1.3.2) as long as the user can still understand and operate the Web page. Since there may be several possible logical reading orders for the content, the focus order may match any of them. However, when the order of a particular presentation differs from the programmatically determined reading order, users of one of these presentations may find it difficult to understand or operate the Web page. Authors should carefully consider all these users as they design their Web pages.
For example, a screen reader user interacts with the programmatically determined reading order, while a sighted keyboard user interacts with the visual presentation of the Web page. Care should be taken so that the focus order makes sense to both of these sets of users and does not appear to either of them to jump around randomly.
These techniques benefit keyboard users who navigate documents sequentially and expect the focus order to be consistent with the sequential reading order.
People with mobility impairments who must rely on keyboard access for operating a page benefit from a logical, usable focus order.
People with disabilities that make reading difficult can become disoriented when tabbing takes focus someplace unexpected. They benefit from a logical focus order.
People with visual impairments can become disoriented when tabbing takes focus someplace unexpected or when they cannot easily find the content surrounding an interactive element.
Only a small portion of the page may be visible to an individual using a screen magnifier at a high level of magnification. Such a user may interpret a field in the wrong context if the focus order is not logical.
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").
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.
A Web page implements modeless dialogs via scripting. When the trigger button is activated, a dialog opens. The interactive elements in the dialog are inserted in the focus order immediately after the button. When the dialog is open, the focus order goes from the button to the elements of the dialog, then to the interactive element following the button. When the dialog is closed, the focus order goes from the button to the following element.
A Web page implements modal dialogs via scripting. When the trigger button is activated, a dialog opens and focus is set to the first interactive element in the dialog. As long as the dialog is open, focus is limited to the elements of the dialog. When the dialog is dismissed, focus returns to the button or the element following the button.
An HTML web page is created with the left hand navigation occurring in the HTML after the main body content, and styled with CSS to appear on the left hand side of the page. This is done to allow focus to move to the main body content first without requiring tabIndex attributes or JavaScript.
Note: While this example passes the SC, it is not necessarily true that all CSS positioning would. More complex positioning examples may or may not preserve meaning and operability
The following example fails to meet the success criterion:
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, so that focus moves from the name field to a checkbox, then to the street address, then to another checkbox.
Resources are for information purposes only, no endorsement implied.
(none currently documented)
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.
Giving focus to elements in an order that follows sequences and relationships within the content using one of the following techniques:
H4: Creating a logical tab order through links, form controls, and objects (HTML)
Making the source order match the visual order (future link)
Changing a web page dynamically using one of the following techniques:
SCR26: Inserting dynamic content into the Document Object Model immediately following its trigger element (Scripting)
Creating custom dialogs in a device independent way (future link)
SCR27: Reordering page sections using the Document Object Model (Scripting)
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 highly visible highlighting mechanism for links or controls when they receive keyboard focus (future link)
Creating alternative presentation orders (future link)
The following are common mistakes that are considered failures of Success Criterion 2.4.3 by the WCAG Working Group.
Failure of SC 2.4.3 due to using menus or dialogs that are not adjacent to their trigger control in the sequential navigation order
navigated in the order defined for advancing focus (from one element to the next) using the keyboard
a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent
Note 1: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.
Note 2: For the purposes of conformance with these guidelines, a resource must be "non-embedded" within the scope of conformance to be considered a Web page.
Example 1: A Web resource including all embedded images and media.
Example 2: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://example.com/mail, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.
Example 3: A customizable portal site, where users can choose content to display from a set of different content modules.
Example 4: 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 and into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.
2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)
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. Whenever possible, provide link text that identifies the purpose of the link without needing additional context. 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.
In some situations, authors may want to provide part of the description of the link in logically related text that provides the context for the link. 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, the heading immediately preceding the link, or table cell as the link, or in the table header cell for a link in a data table, because these are directly associated with the link itself.
This context will be most usable if it 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.) 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).
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.
The success criterion includes an exception for links for which the purpose of the link cannot be determined from the information on the web page. In this situation, the person with the disability is not at a disadvantage; there is no additional context available to understand the link purpose. However, whatever amount of context is available on the web page that can be used to interpret the purpose of the link must be made available in the link text or programmatically associated with the link to satisfy the success criterion.
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.
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.
People with visual disabilities will be able to determine the purpose of a link by exploring the link's context.
A link contains text that gives a description of the information at that URL
A page contains the sentence "There was much bloodshed during the Medieval period of history." Where "Medieval period of history" is a link.
A link is preceded by a text description of the information at that URL
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.
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. 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.
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). 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."
News article summaries
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.
Resources are for information purposes only, no endorsement implied.
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.
G91: Providing link text that describes the purpose of a link
Allowing the user to choose short or long link text USING one of the technology specific techniques below:
Using HTML and page reloads to offer different link texts (future link)
Using JavaScript to change the link texts (future link)
Providing a supplemental description of the purpose of a link using one of the following techniques:
Identifying the purpose of a link using link text combined with programmatically determined link context using one of the following techniques:
Optimizing Web pages for the "link list" feature in assistive technology (future link)
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.
The following are common mistakes that are considered failures of Success Criterion 2.4.4 by the WCAG Working Group.
the purpose cannot be determined from the link and all information of the Web page presented to the user simultaneously with the link (i.e. readers without disabilities would not know what a link would do until they activated it)
Example: The word guava in the following sentence "One of the notable exports is guava" is a link. The link could lead to a definition of guava, a chart listing the quantity of guava exported or a photograph of people harvesting guava. Until the link is activated, all readers are unsure and the person with a disability is not at any disadvantage.
nature of the result obtained by activating a hyperlink
additional information that can be programmatically determined from relationships with a link, combined with the link text, and presented to users in different modalities
Example: In HTML, information that is programmatically determinable from a link in English includes text that is in the same 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.
Note: Since screen readers interpret punctuation, they can also provide the context from the current sentence, when the focus is on a link in that sentence.
2.4.5 Multiple Ways: More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. (Level AA)
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.
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)
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.
Using two or more of the following techniques:
Providing a search engine to help users find content (future link)
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.
Including information about presentation modes in tables of contents and concept maps (future link)
The following are common mistakes that are considered failures of Success Criterion 2.4.5 by the WCAG Working Group.
(No failures currently documented)
series of user actions where each action is required in order to complete an activity
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.
Example 2: An account registration page requires successful completion of a Turing test before the registration form can be accessed.
collection of Web pages that share a common purpose and that are created by the same author, group or organization
Note: Different language versions would be considered different sets of Web pages .
a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent
Note 1: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.
Note 2: For the purposes of conformance with these guidelines, a resource must be "non-embedded" within the scope of conformance to be considered a Web page.
Example 1: A Web resource including all embedded images and media.
Example 2: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://example.com/mail, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.
Example 3: A customizable portal site, where users can choose content to display from a set of different content modules.
Example 4: 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 and into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.
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 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.
Descriptive headings 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 labels and headings are meaningful when read out of context, for example, in a Table of Contents, or when jumping from heading to heading within a page.
This success criterion may also help users with low vision who can see only a few words at a time.
A news site.
The home page of a news site lists the headlines for the top stories of the hour. Under each heading are the first 35 words of the story and a link to the full article. Each headline gives a clear idea of the article's subject.
A guide on how to write well
A guide on writing contains the following section titles: How To Write Well, Cut Out Useless Words, 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.
How Users Read on the Web A study showing that most users scan Web pages rather than reading them word by word.
Applying Writing Guidelines to Web Pages A report on the effects of making Web sites concise, easy to scan, and objective.
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: Headings and labels must be programmatically determined, per success criterion 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.
Using unique section headings in a Web Page (future link)
Starting section headings with unique information (future link)
The following are common mistakes that are considered failures of Success Criterion 2.4.6 by the WCAG Working Group.
(No failures currently documented)
text or other component with a text alternative that is presented to a user to identify a component within Web content
Note 1: A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.
Note 2: The term label is not limited to the label element in HTML.
2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)
The intent of this success criterion is to ensure that there is at least one mode of operation where the keyboard focus indicator can be visually located.
This success criterion helps anyone who relies on the keyboard to operate the page, by letting them visually determine the component on which keyboard operations will interact at any point in time.
People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.
When text fields receive focus, a vertical bar is displayed in the field, indicating that the user can insert text, OR all of the text is highlighted, indicating that the user can type over the text.
When a user interface control receives focus, a visible border is displayed around it.
Resources are for information purposes only, no endorsement implied.
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.
G149: Using user interface components that are highlighted by the user agent when they receive focus
C15: Using CSS to change the presentation of a user interface component when it receives focus (CSS)
Using the default focus indicator for the platform so that high visibility default focus indicators will carry over (future link)
Using an author-supplied, highly visible focus indicator (future link)
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.
Highlighting a link or control when the mouse hovers over it (future link)
Providing a highly visible highlighting mechanism for links or controls when they receive keyboard focus (future link)
The following are common mistakes that are considered failures of Success Criterion 2.4.7 by the WCAG Working Group.
2.4.8 Location: Information about the user's location within a set of Web pages is available. (Level AAA)
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.
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.
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.
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)
Providing an easy-to-read version of information about the organization of a set of Web pages (future link)
Providing a sign language version of information about the organization of a set of Web pages (future link)
Providing an easy-to-read summary at the beginning of each section of content (future link)
The following are common mistakes that are considered failures of Success Criterion 2.4.8 by the WCAG Working Group.
(No failures currently documented)
collection of Web pages that share a common purpose and that are created by the same author, group or organization
Note: Different language versions would be considered different sets of Web pages .
2.4.9 Link Purpose (Link Only): A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general. (Level AAA)
The intent of this success criterion is to help users understand the purpose of each link in the content, so they can decide whether they want to follow it. Links with the same 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.
The success criterion includes an exception for links for which the purpose of the link cannot be determined from the information on the web page. In this situation, the person with the disability is not at a disadvantage; there is no additional context available to understand the link purpose. However, whatever amount of context is available on the web page that can be used to interpret the purpose of the link must be made available in the link text to satisfy the success criterion.
The word "mechanism" is used to allow authors to either make all links fully understandable out of context by default or to provide a way to make them this way. This is done because for some pages, making the links all unambiguous by themselves makes the pages easier for some users and harder for others. Providing the ability to make the links unambiguous (by them selves) or not provides both users with disabilities with the ability to use the page in the format that best meets their needs.
For example: A page listing 100 book titles along with links to download the books in HTML, PDF, DOC, TXT, MP3, or AAC might ordinarily be viewed as the title of the book as a link with the words "in HTML" after it. then the sentence "Also available in: " followed by a series of short links with text of "HTML", "PDF", "DOC", "TXT", "MP3", and "AAC". At Level 3, some users could opt to view the page this way - because they would find the page harder to understand or slower to use if the full title of the book were included in each of the links. Others could opt to view the page with the full title as part of each of the links so that each link was understandable in itself. Both the former and the latter groups could include people with visual or cognitive disabilities that used different techniques to browse or that had different types or severities of disability.
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.
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.
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.
G91: Providing link text that describes the purpose of a link using one of the following techniques:
Allowing the user to choose short or long link text USING one of the technology specific techniques below:
Using HTML and page reloads to offer different link texts (future link)
Using JavaScript to change the link texts (future link)
Providing a supplemental description of the purpose of a 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.
The following are common mistakes that are considered failures of Success Criterion 2.4.9 by the WCAG Working Group.
(No failures currently documented)