This document is also available in these non-normative formats:
Copyright © 2023 World Wide Web Consortium. 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 (WCAG) 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). See Web Content Accessibility Guidelines (WCAG) Overview for an introduction to WCAG, supporting technical documents, and educational material.
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 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.
In addition to techniques for addressing the success criteria, "Common Failures" are also documented. These "Common Failures" are authoring practices that are known to cause Web content to fail to conform to WCAG 2.0. 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 was published as a Working Group Note at the same time WCAG 2.0 was published as a W3C Recommendation. Unlike WCAG 2.0, is expected that the information in Understanding WCAG 2.0 will be updated from time to time. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction to WCAG, supporting technical documents, and educational material.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a Working Group Note "Understanding WCAG 2.0". The Web Content Accessibility Guidelines Working Group considers this document to be important for understanding the success criteria in the Web Content Accessibility Guidelines (WCAG) 2.0 Recommendation. 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).
Understanding WCAG 2.0 was previously published on 11 December 2008 as a Working Group Note and updated 14 October 2010, 3 January 2012, 5 September 2013, 3 March 2014, 8 April 2014, 16 September 2014, 26 February 2015, and 17 March 2016. This new version updates the support information provided for WCAG 2.0. Note that WCAG 2.0 itself remains unchanged, only the informative support materials have been updated. The only change in this version is to add explanation about partial conformance claims due to third-party content.
The changes are highlighted in the diff-marked version.
The Working Group requests that any comments be made using the options documented in Instructions for Commenting on WCAG 2.0 Documents. If this is not possible, comments can also be sent to public-comments-wcag20@w3.org. The archives for the public comments list are publicly available. Comments received on this document may be addressed in future versions of this document, or in another manner. Archives of the WCAG WG mailing list discussions are also publicly available, and future work undertaken by the Working Group may address comments received on this document.
This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals of the WCAG Working Group are discussed in the WCAG Working Group charter. The WCAG Working Group is part of the WAI Technical Activity.
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 September 2015 W3C Process Document.
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. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction to WCAG, supporting technical documents, and educational material.
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 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 Understanding 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 objectives 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 How to Meet document that provides:
sufficient techniques for meeting the Success Criterion,
optional advisory techniques, and
descriptions of the intent of the Success Criteria, including benefits, and examples.
The next section, Understanding Techniques for WCAG Success Criteria, provides important information about the techniques.
WCAG 2.0 guidelines and success criteria are designed to be broadly applicable to current and future web technologies, including dynamic applications, mobile, digital television, etc. They are stable and do not change.
Specific guidance for authors and evaluators on meeting the WCAG success criteria is provided in techniques, which include code examples, resources, and tests. W3C's Techniques for WCAG 2.0 document is updated periodically, about twice per year, to cover more current best practices and changes in technologies and tools.
The three types of guidance in Techniques for WCAG 2.0 are explained below:
Sufficient techniques
Advisory techniques
Failures
Also explained below:
General and technology-specific techniques - which can be sufficient or advisory
Other techniques - beyond what is in W3C's published document
Technique tests
User agent and assistive technology support
Using the techniques - with important considerations
Understanding Conformance provides related information, including on understanding accessibility support.
Techniques are informative—that means they are not required. The basis for determining conformance to WCAG 2.0 is the success criteria from the WCAG 2.0 standard—not the techniques.
Note 1: W3C cautions against requiring W3C's sufficient techniques. The only thing that should be required is meeting the WCAG 2.0 success criteria. To learn more, see:
What would be the negative consequences of allowing only W3C's published techniques to be used for conformance to WCAG 2.0? in the WCAG 2 FAQ
Note 2: Techniques for WCAG 2.0 uses the words "must" and "should" only to clarify guidance within the techniques, not to convey requirements for WCAG.
Sufficient techniques are reliable ways to meet the success criteria.
From an author's perspective: If you use the sufficient techniques for a given criterion correctly and it is accessibility-supported for your users, you can be confident that you met the success criterion.
From an evaluator's perspective: If web content implements the sufficient techniques for a given criterion correctly and it is accessibility-supported for the content's users, it conforms to that success criterion. (The converse is not true; if content does not implement these sufficient techniques, it does not necessarily fail the success criteria, as explained in Testing Techniques below.)
There may be other ways to meet success criteria besides the sufficient techniques in W3C's Techniques for WCAG 2.0 document, as explained in Other Techniques below. (See also Techniques are Informative above.)
The W3C-documented sufficient techniques are provided in a numbered list where each list item provides a technique or combination of techniques that can be used to meet the success criterion. Where there are multiple techniques on a numbered list item connected by "AND" then all of the techniques must be used to be sufficient. For example, Sufficient Techniques for 1.3.1 has: "G115: Using semantic elements to mark up structure AND H49: Using semantic markup to mark emphasized or special text (HTML)".
Advisory techniques are suggested ways to improve accessibility. They are often very helpful to some users, and may be the only way that some users can access some types of content.
Advisory techniques are not designated as sufficient techniques for various reasons such as:
they may not be sufficient to meet the full requirements of the success criteria;
they may be based on technology that is not yet stable;
they may not be accessibility supported in many cases (for example, assistive technologies do not work with them yet);
they may not be testable;
in some circumstances they may not be applicable or practical, and may even decrease accessibility for some users while increasing it for others;
they may not address the success criterion itself, and instead provide related accessibility benefits.
Authors are encouraged to apply all of the techniques where appropriate to best address the widest range of users' needs.
Failures are things that cause accessibility barriers and fail specific success criteria. The documented failures are useful for:
Authors to know what to avoid,
Evaluators to use for checking if content does not meet WCAG success criteria.
Content that has a failure does not meet WCAG success criteria, unless an alternate version is provided without the failure.
If anyone identifies a situation where a documented failure is not correct, please report the situation as a WCAG comment so that it can be corrected or deleted as appropriate.
General techniques describe basic practices that apply to all technologies. Technology-specific techniques apply to a specific technology.
Some success criteria do not have technology-specific techniques and are covered only with general techniques. Therefore, both the general techniques and the relevant technology-specific techniques should be considered.
Publication of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WCAG 2.0 success criteria and conformance requirements. Developers need to be aware of the limitations of specific technologies and provide content in a way that is accessible to people with disabilities.
In addition to the techniques in W3C's Techniques for WCAG 2.0 document, there are other ways to meet WCAG success criteria. W3C's techniques are not comprehensive and may not cover newer technologies and situations.
Web content does not have to use W3C's published techniques in order to conform to WCAG 2.0. (See also Techniques are Informative above.)
Content authors can develop different techniques. For example, an author could develop a technique for HTML5, WAI-ARIA, or other new technology. Other organizations may develop sets of techniques to meet WCAG 2.0 success criteria.
Any techniques can be sufficient if:
they satisfy the success criterion, and
all of the WCAG 2.0 conformance requirements are met.
The WCAG Working Group encourages people to submit new techniques so that they can be considered for inclusion in updates of the Techniques for WCAG 2.0 document. Please submit techniques for consideration using the Techniques Submission Form.
Each technique has tests that help:
authors verify that they implemented the technique properly, and
evaluators determine if web content meets the technique.
The tests are only for a technique, they are not tests for conformance to WCAG success criteria.
Failing a technique test does not necessarily mean failing WCAG, because the techniques are discrete (that is, they address one specific point) and they are not required.
Content can meet WCAG success criteria in different ways other than W3C's published sufficient techniques.
Content that passes the sufficient techniques for a specific technology does not necessarily meet all WCAG success criteria. Some success criteria have only general techniques, not technology-specific techniques.
The content must be accessibility supported for the content's users. Some sufficient techniques require browser, assistive technology, or other support that some users might not have.
Thus while the techniques are useful for evaluating content, evaluations must go beyond just checking the sufficient technique tests in order to evaluate how content conforms to WCAG success criteria.
Failures are particularly useful for evaluations because they do indicate non-conformance (unless an alternate version is provided without the failure).
Some techniques require that web content users have specific browsers or assistive technologies in order for the technique to be accessibility-supported. The User Agent and Assistive Technology Support Notes sections of individual techniques include some information to help determine accessibility support.
As time passes, the versions of user agents (browsers, etc.) or assistive technologies listed may not be the current versions. The Working Group may not update most of these notes as new versions are released. Authors should test techniques with the user agents and assistive technologies currently available to their users. See also Understanding Accessibility Support.
Techniques for WCAG 2.0 is not intended to be used as a stand-alone document. Instead, it is expected that content authors will usually use How to Meet WCAG 2.0: A customizable quick reference to read the WCAG success criteria, and follow links from there to specific topics in Understanding WCAG 2.0 and to specific techniques.
Some techniques describe how to provide alternate ways for users to get content. For example, G73: Providing a long description in another location... mentions a transcript as an alternative for an audio file. Some alternatives must also conform to WCAG. For example, the transcript itself must meet all relevant success criteria.
The code examples in the techniques are intended to demonstrate only the specific point discussed in the technique. They might not demonstrate best practice for other aspects of accessibility, usability, or coding not related to the technique. They are not intended to be copied and used as the basis for developing web content.
Many techniques point to "working examples" that are more robust and may be appropriate for copying and integrating into web content.
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 aloud so that it is easier for people with reading disabilities to understand, or rendered in whatever tactile form best meets the needs of a user.
Note: While changing the content into symbols includes changing it into graphic symbols for people with developmental disorders and speech comprehension difficulties, it is not limited to this use of symbols.
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 that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)
Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.)
Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
CAPTCHA: If the purpose of non-text content 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 non-text content is pure decoration, is used only for visual formatting, or 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 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, image maps 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 time-based media is made accessible through 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 time-based media and/or gives its title is therefore provided.
For Live Audio-only and live video-only content, it can be much more difficult to provide text alternatives that provide equivalent 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 be partially or completely presented in non-text format. 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, additional 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; an invisible image that is used to track usage statistics; 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 aloud, present it visually, or convert it 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
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 image is an alternative for text and the text alternative includes only a brief description of the animation 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 of a press conference
A Web page includes a link to an audio recording of a press conference. The link text identifies the audio recording. 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".
The same image used on different sites
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".
An image map
An image of a building floor plan is interactive, allowing the user to select a particular room and navigate to a page containing information about that room. The short text alternative describes the image and its interactive purpose: "Building floor plan. Select a room for more information."
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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 one of the following Short text alternative techniques for Situation A :
Short text alternative techniques for Situation A:
ARIA6: Using aria-label to provide labels for objects (ARIA)
ARIA10: Using aria-labelledby to provide a text alternative for non-text content (ARIA)
FLASH1: Setting the name property for a non-text object (Flash)
FLASH5: Combining adjacent image and text buttons for the same resource (Flash)
FLASH28: Providing text alternatives for ASCII art, emoticons, and leetspeak in Flash (Flash)
H2: Combining adjacent image and text links for the same resource (HTML)
H86: Providing text alternatives for ASCII art, emoticons, and leetspeak (HTML)
PDF1: Applying text alternatives to images with the Alt entry in PDF documents (PDF)
SL5: Defining a Focusable Image Class for Silverlight (Silverlight)
G95: Providing short text alternatives that provide a brief description of the non-text content using one of the following Short text alternative techniques for Situation B AND one of the following Long text alternative techniques for Situation B :
Short text alternative techniques for Situation B:
ARIA6: Using aria-label to provide labels for objects (ARIA)
ARIA10: Using aria-labelledby to provide a text alternative for non-text content (ARIA)
FLASH1: Setting the name property for a non-text object (Flash)
FLASH5: Combining adjacent image and text buttons for the same resource (Flash)
FLASH28: Providing text alternatives for ASCII art, emoticons, and leetspeak in Flash (Flash)
H2: Combining adjacent image and text links for the same resource (HTML)
H86: Providing text alternatives for ASCII art, emoticons, and leetspeak (HTML)
PDF1: Applying text alternatives to images with the Alt entry in PDF documents (PDF)
SL5: Defining a Focusable Image Class for Silverlight (Silverlight)
Long text alternative techniques for Situation B:
ARIA15: Using aria-describedby to provide descriptions of images (ARIA)
FLASH2: Setting the description property for a non-text object in Flash (Flash)
FLASH11: Providing a longer text description of an object (Flash)
H45: Using longdesc (HTML)
SL8: Displaying HelpText in Silverlight User Interfaces (Silverlight)
G82: Providing a text alternative that identifies the purpose of the non-text content using one of the following Text alternative techniques for controls and input for Situation C :
Text alternative techniques for controls and input for Situation C:
ARIA6: Using aria-label to provide labels for objects (ARIA)
ARIA9: Using aria-labelledby to concatenate a label from several text nodes (ARIA)
FLASH6: Creating accessible hotspots using invisible buttons (Flash)
FLASH25: Labeling a form control by setting its accessible name (Flash)
FLASH27: Providing button labels that describe the purpose of a button (Flash)
FLASH29: Setting the label property for form components (Flash)
FLASH30: Specifying accessible names for image buttons (Flash)
FLASH32: Using auto labeling to associate text labels with form controls (Flash)
H24: Providing text alternatives for the area elements of image maps (HTML)
H30: Providing link text that describes the purpose of a link for anchor elements (HTML)
H36: Using alt attributes on images used as submit buttons (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)
SL18: Providing Text Equivalent for Nontext Silverlight Controls With AutomationProperties.Name (Silverlight)
SL26: Using LabeledBy to Associate Labels and Targets in Silverlight (Silverlight)
SL30: Using Silverlight Control Compositing and AutomationProperties.Name (Silverlight)
Providing a descriptive label using one of the following Short text alternative techniques for Situation D :
G68: Providing a short text alternative that describes the purpose of live audio-only and live video-only content using one of the following Short text alternative techniques for Situation D :
G100: Providing a short text alternative which is the accepted name or a descriptive name of the non-text content using one of the following Short text alternative techniques for Situation D :
Short text alternative techniques for Situation D:
ARIA6: Using aria-label to provide labels for objects (ARIA)
ARIA10: Using aria-labelledby to provide a text alternative for non-text content (ARIA)
FLASH1: Setting the name property for a non-text object (Flash)
FLASH5: Combining adjacent image and text buttons for the same resource (Flash)
FLASH28: Providing text alternatives for ASCII art, emoticons, and leetspeak in Flash (Flash)
H2: Combining adjacent image and text links for the same resource (HTML)
H86: Providing text alternatives for ASCII art, emoticons, and leetspeak (HTML)
PDF1: Applying text alternatives to images with the Alt entry in PDF documents (PDF)
SL5: Defining a Focusable Image Class for Silverlight (Silverlight)
Implementing or marking the non-text content so that it will be ignored by assistive technology using one of the following Techniques to indicate that text alternatives are not required for Situation F :
Techniques to indicate that text alternatives are not required for Situation F:
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 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 (future link)
Providing alternative content for iframe (future link)
Not using long descriptions for iframe (future link)
Providing redundant text links for client-side image maps (future link)
C18: Using CSS margin and padding rules instead of spacer images for layout design (CSS)
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, URI(s) that points to an audio description and a text transcript of a video.
EXAMPLE: Providing, in metadata, URI(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.
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]
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: 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;
speech 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.
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 uses 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.
sequence of characters that can be programmatically determined, where the sequence is expressing something in human language
Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. Programmatically associated text is text whose location can be programmatically determined from the non-text content.
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.
Note: Refer to Understanding Text Alternatives for more information.
Guideline 1.2: Provide alternatives for time-based media.
The purpose of this guideline is to provide access to time-based and synchronized media.This includes media that is:
audio-only
video-only
audio-video
audio and/or video combined with interaction
To make it easy for authors to quickly determine which success criteria apply to their content, the type of media each success criterion applies to is included in its short name.
For audio-only or video-only media, you only need to apply the success criteria that say "audio-only" or "video-only" in their short name. If your media is not audio-only or video-only, then all the rest of the success criteria apply.
Media can also be live or prerecorded. Each of the success criterion short names clearly tells you if the success criterion applies to live or prerecorded 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, unless the media is a media alternative for text that is clearly labeled as such
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 an alternative for time-based media 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 alternative for time-based 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 Success Criterion 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 Audio-only and Video-only (Prerecorded): For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such: (Level A)
Prerecorded Audio-only: An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.
Prerecorded Video-only: Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content.
The intent of this Success Criterion is to make information conveyed by prerecorded audio-only and prerecorded video-only content available to all users. Alternatives for time-based media that are text based make information accessible because text can be rendered through any sensory modality (for example, visual, auditory or tactile) to match the needs of the user. In the future, text could also be translated into symbols, sign language or simpler forms of the language (future).
An example of pre-recorded video with no audio information or user interaction is a silent movie. The purpose of the transcript is to provide an equivalent to what is presented visually. For prerecorded video content, authors have the option to provide an audio track. The purpose of the audio alternative is to be an equivalent to the video. This makes it possible for users with and without vision impairment to review content simultaneously. The approach can also make it easier for those with cognitive, language and learning disabilities to understand the content because it would provide parallel presentation.
Note: A text equivalent is not required for audio that is provided as an equivalent for video with no audio information. For example, it is not required to caption video description that is provided as an alternative to a silent movie.
See also Understanding Success Criterion 1.2.9 Audio-only (Live)
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.
Alternatives for timed-based media that are text based may help some people who have difficulty understanding the meaning of prerecorded video content.
People who are deaf, are hard of hearing, or who are having trouble understanding audio information for any reason can read the text presentation. Research is ongoing regarding automatic translation of text into sign language.
People who are deaf-blind can read the text in braille.
Additionally, text supports the ability to search for non-text content and to repurpose content in a variety of ways.
An audio recording of a speech
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 audio recording of a press conference
A Web page includes a link to an audio recording of a press conference that identifies the audio recording. 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 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 media is an alternative for text and the text alternative includes only a brief description of the animation and refers to the tutorial text for more information.
A video-only file with an audio track
A silent movie includes an audio track which includes a description of the action in the video.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
H96: Using the track element to provide audio descriptions (HTML)
Providing a transcript of a live audio only presentation after the fact (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)
The following are common mistakes that are considered failures of Success Criterion 1.2.1 by the WCAG Working Group.
document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction
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.
a time-based presentation that contains only audio (no video and no interaction)
media that presents no more information than is already presented in text (directly or via text alternatives)
Note: A media alternative for text is provided for those who benefit from alternate representations of text. Media alternatives for text may be audio-only, video-only (including sign-language video), or audio-video.
information that is not live
a time-based presentation that contains only video (no audio and no interaction)
1.2.2 Captions (Prerecorded): Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for 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).
See also Understanding Success Criterion 1.2.4 Captions (Live).
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.
An orchestra provides captions for videos of performances. In addition to capturing dialog and lyrics verbatim, captions identify non-vocal music by title, movement, composer, and any information that will help the user comprehend the nature of the audio. For instance captions read,
"[Orchestral Suite No. 3.2 in D major, BWV 1068, Air]
[Johann Sebastian Bach, Composer]
♪ Calm melody with a slow tempo ♪"
Note: Style guides for captions may differ among different languages.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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
SM11: Providing captions through synchronized text streams in SMIL 1.0 (SMIL)
SM12: Providing captions through synchronized text streams in SMIL 2.0 (SMIL)
FLASH9: Applying captions to prerecorded synchronized media (Flash)
SL16: Providing Script-Embedded Text Captions for MediaElement Content (Silverlight)
SL28: Using Separate Text-Format Text Captions for MediaElement Content (Silverlight)
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.2 by the WCAG Working Group.
the technology of sound reproduction
Note: Audio can be created synthetically (including speech synthesis), recorded from real world sounds, or both.
synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content
Note 1: Captions are similar to dialogue-only subtitles except captions convey not only the content of spoken dialogue, but also equivalents for non-dialogue audio information needed to understand the program content, including sound effects, music, laughter, speaker identification and location.
Note 2: Closed Captions are equivalents that can be turned on and off with some players.
Note 3: Open Captions are any captions that cannot be turned off. For example, if the captions are visual equivalent images of text embedded in video.
Note 4: Captions should not obscure or obstruct relevant information in the video.
Note 5: In some countries, captions are called subtitles.
Note 6: 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 for text is provided for those who benefit from alternate representations of text. Media alternatives for text may be audio-only, video-only (including sign-language video), or audio-video.
information that is not live
audio or video synchronized with another format for presenting information and/or with time-based interactive components, unless the media is a media alternative for text that is clearly labeled as such
1.2.3 Audio Description or Media Alternative (Prerecorded): An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such. (Level A)
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. An alternative for time-based media provides a running description of all that is going on in the synchronized media content. The alternative for time-based media 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 alternative for time-based 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 alternative for time-based media would provide hyperlinks or whatever is needed to provide the same functionality.
Note 1: For 1.2.3, 1.2.5, 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.3, 1.2.5, and 1.2.8 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 Success Criterion 1.2.3, 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 Success Criterion 1.2.5 authors must provide an audio description - a requirement already met if they chose that alternative for 1.2.3, otherwise an additional requirement. At Level AAA under Success Criterion 1.2.8 they must provide an extended text description. This is an additional requirement if both 1.2.3 and 1.2.5 were met by providing an audio description only. If 1.2.3 was met, however, by providing a text description, and the 1.2.5 requirement for an audio description was met, then 1.2.8 does not add new requirements.
See also Understanding Success Criterion 1.2.5 Audio Description (Prerecorded), Understanding Success Criterion 1.2.7 Extended Audio Description (Prerecorded) and Understanding Success Criterion 1.2.8 Media Alternative (Prerecorded).
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.)
An alternative for time-based media 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 an alternative for time-based 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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
G69: Providing an alternative for time based media using one of the following techniques
Linking to the alternative for time-based media using one of the following techniques
G78: Providing a second, user-selectable, audio track that includes audio descriptions
G78: Providing a second, user-selectable, audio track that includes audio descriptions AND SL1: Accessing Alternate Audio Tracks in Silverlight Media (Silverlight)
G173: Providing a version of a movie with audio descriptions using one of the following:
SL1: Accessing Alternate Audio Tracks in Silverlight Media (Silverlight)
Using any player that supports audio and video
G8: Providing a movie with extended audio descriptions using one of the following:
SL1: Accessing Alternate Audio Tracks in Silverlight Media (Silverlight)
Using any player that supports audio and video
G203: Using a static text alternative to describe a talking head video
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.
H96: Using the track element to provide audio descriptions (HTML)
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.3 by the WCAG Working Group.
(No failures currently documented)
document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction
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.
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: Where all of the video information is already provided in existing audio, no additional audio description is necessary.
Note 4: Also called "video description" and "descriptive narration."
media that presents no more information than is already presented in text (directly or via text alternatives)
Note: A media alternative for text is provided for those who benefit from alternate representations of text. Media alternatives for text may be audio-only, video-only (including sign-language video), or audio-video.
information that is not live
audio or video synchronized with another format for presenting information and/or with time-based interactive components, unless the media is a media alternative for text that is clearly labeled as such
the technology of moving or sequenced pictures or images
Note: Video can be made up of animated or photographic images, or both.
1.2.4 Captions (Live): Captions are provided for all live audio content in synchronized media. (Level AA)
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.
This success criterion was intended to apply to broadcast of synchronized media and is not intended to require that two-way multimedia calls between two or more individuals through web apps must be captioned regardless of the needs of users. Responsibility for providing captions would fall to the content providers (the callers) or the “host” caller, and not the application.
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.
A music Web cast
An orchestra provides Communication Access Realtime Translation (CART) captioning of each real-time Web performance. The CART service captures lyrics and dialog as well as identifies non-vocal music by title, movement, composer, and any information that will help the user comprehend the nature of the audio.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.4 by the WCAG Working Group.
(No failures currently documented)
the technology of sound reproduction
Note: Audio can be created synthetically (including speech synthesis), recorded from real world sounds, or both.
synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content
Note 1: Captions are similar to dialogue-only subtitles except captions convey not only the content of spoken dialogue, but also equivalents for non-dialogue audio information needed to understand the program content, including sound effects, music, laughter, speaker identification and location.
Note 2: Closed Captions are equivalents that can be turned on and off with some players.
Note 3: Open Captions are any captions that cannot be turned off. For example, if the captions are visual equivalent images of text embedded in video.
Note 4: Captions should not obscure or obstruct relevant information in the video.
Note 5: In some countries, captions are called subtitles.
Note 6: Audio descriptions can be, but do not need to be, captioned since they are descriptions of information that is already presented visually.
information captured from a real-world event and transmitted to the receiver with no more than a broadcast delay
Note 1: A broadcast delay is a short (usually automated) delay, for example used in order to give the broadcaster time to queue or censor the audio (or video) feed, but not sufficient to allow significant editing.
Note 2: If information is completely computer generated, it is not live.
audio or video synchronized with another format for presenting information and/or with time-based interactive components, unless the media is a media alternative for text that is clearly labeled as such
1.2.5 Audio Description (Prerecorded): Audio description is provided for all prerecorded video content in 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.3, 1.2.5, 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.3, 1.2.5, and 1.2.8 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 Success Criterion 1.2.3, 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 Success Criterion 1.2.5 authors must provide an audio description - a requirement already met if they chose that alternative for 1.2.3, otherwise an additional requirement. At Level AAA under Success Criterion 1.2.8 they must provide an extended text description. This is an additional requirement if both 1.2.3 and 1.2.5 were met by providing an audio description only. If 1.2.3 was met, however, by providing a text description, and the 1.2.5 requirement for an audio description was met, then 1.2.8 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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
G78: Providing a second, user-selectable, audio track that includes audio descriptions
G78: Providing a second, user-selectable, audio track that includes audio descriptions AND SL1: Accessing Alternate Audio Tracks in Silverlight Media (Silverlight)
G173: Providing a version of a movie with audio descriptions using one of the following:
Using any player that supports audio and video
G8: Providing a movie with extended audio descriptions using one of the following:
Using any player that supports audio and video
G203: Using a static text alternative to describe a talking head video
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.
H96: Using the track element to provide audio descriptions (HTML)
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.5 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: Where all of the video information is already provided in existing audio, no additional audio description is necessary.
Note 4: Also called "video description" and "descriptive narration."
information that is not live
audio or video synchronized with another format for presenting information and/or with time-based interactive components, unless the media is a media alternative for text that is clearly labeled as such
the technology of moving or sequenced pictures or images
Note: Video can be made up of animated or photographic images, or both.
1.2.6 Sign Language (Prerecorded): Sign language interpretation is provided for all prerecorded audio content in 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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.6 by the WCAG Working Group.
(No failures currently documented)
the technology of sound reproduction
Note: Audio can be created synthetically (including speech synthesis), recorded from real world sounds, or both.
information that is not live
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, unless the media is a media alternative for text that is clearly labeled as such
1.2.7 Extended Audio Description (Prerecorded): Where pauses in foreground audio are insufficient to allow audio descriptions to convey the sense of the video, extended audio description is provided for all prerecorded video content in 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 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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
G8: Providing a movie with extended audio descriptions using one of the following:
Using any player that supports audio and video
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.
H96: Using the track element to provide audio descriptions (HTML)
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.7 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: Where all of the video information is already provided in existing audio, no additional audio description is necessary.
Note 4: Also called "video description" and "descriptive narration."
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 and the pauses between dialogue/narration are too short.
information that is not live
audio or video synchronized with another format for presenting information and/or with time-based interactive components, unless the media is a media alternative for text that is clearly labeled as such
the technology of moving or sequenced pictures or images
Note: Video can be made up of animated or photographic images, or both.
1.2.8 Media Alternative (Prerecorded): An alternative for time-based media is provided for all prerecorded synchronized media and for all prerecorded video-only media. (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 an alternative for time-based media.
This approach involves providing all of the information in the synchronized media (both visual and auditory) in text form. An alternative for time-based media provides a running description of all that is going on in the synchronized media content. The alternative for time-based 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 alternative for time-based 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 alternative for time-based 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 alternative for time-based media by using a refreshable braille display.
Note 1: For 1.2.3, 1.2.5, 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.3, 1.2.5, and 1.2.8 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 Success Criterion 1.2.3, 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 Success Criterion 1.2.5 authors must provide an audio description - a requirement already met if they chose that alternative for 1.2.3, otherwise an additional requirement. At Level AAA under Success Criterion 1.2.8 they must provide an extended text description. This is an additional requirement if both 1.2.3 and 1.2.5 were met by providing an audio description only. If 1.2.3 was met, however, by providing a text description, and the 1.2.5 requirement for an audio description was met, then 1.2.8 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. alternative for time-based 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 an alternative for time-based 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.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
G69: Providing an alternative for time based media using one of the following techniques
Linking to the alternative for time-based media 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.8 by the WCAG Working Group.
document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction
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.
information that is not live
audio or video synchronized with another format for presenting information and/or with time-based interactive components, unless the media is a media alternative for text that is clearly labeled as such
a time-based presentation that contains only video (no audio and no interaction)
1.2.9 Audio-only (Live): An alternative for time-based media that presents equivalent information for live audio-only content is provided. (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.
This success criterion was intended to apply to broadcast of audio and is not intended to require that two-way audio calls between two or more individuals through web apps must be captioned regardless of the needs of users. Responsibility for providing captions would fall to the content providers (the callers) or the “host” caller, and not the application.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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 metadata to associate text transcriptions with audio-only content (future link)
Example: Providing, in metadata, URI(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.2.9 by the WCAG Working Group.
(No failures currently documented)
document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction
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.
a time-based presentation that contains only audio (no video and no interaction)
information captured from a real-world event and transmitted to the receiver with no more than a broadcast delay
Note 1: A broadcast delay is a short (usually automated) delay, for example used in order to give the broadcaster time to queue or censor the audio (or video) feed, but not sufficient to allow significant editing.
Note 2: If information is completely computer generated, it is not live.
Guideline 1.3: Create content that can be presented in different ways (for example simpler layout) 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.
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 and relationships 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; items that share a common characteristic are organized into a table where the relationship of cells sharing the same row or column and the relationship of each cell to its row and/or column header are necessary for understanding; and so on. Having these structures and these relationships programmatically determined or available in text ensures that information important for comprehension will be perceivable to all.
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 as to whether the relationships should be programmatically determined or be presented in text. However, when technologies support programmatic relationships, it is strongly encouraged that information and relationships be programmatically determined rather than described in text.
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.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
ARIA11: Using ARIA landmarks to identify regions of a page (ARIA)
ARIA13: Using aria-labelledby to name regions and landmarks (ARIA)
ARIA16: Using aria-labelledby to provide a name for user interface controls (ARIA)
ARIA17: Using grouping roles to identify related form controls (ARIA)
ARIA20: Using the region role to identify a region of the page (ARIA)
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
G140: Separating information and structure from presentation to enable different presentations
Making information and relationships conveyed through presentation programmatically determinable using the following techniques:
H51: Using table markup to present tabular information (HTML)
PDF6: Using table elements for table markup in PDF Documents (PDF)
PDF20: Using Adobe Acrobat Pro's Table Editor to repair mistagged tables (PDF)
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)
FLASH21: Using the DataGrid component to associate column headers with cells (Flash)
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)
PDF10: Providing labels for interactive form controls in PDF documents (PDF)
PDF12: Providing name, role, value information for form fields in PDF documents (PDF)
FLASH32: Using auto labeling to associate text labels with form controls (Flash)
FLASH29: Setting the label property for form components (Flash)
FLASH25: Labeling a form control by setting its accessible name (Flash)
H71: Providing a description for groups of form controls using fieldset and legend elements (HTML)
SL20: Relying on Silverlight AutomationPeer Behavior to Set AutomationProperties.Name (Silverlight)
SL26: Using LabeledBy to Associate Labels and Targets in Silverlight (Silverlight)
H85: Using OPTGROUP to group OPTION elements inside a SELECT (HTML)
H48: Using ol, ul and dl for lists or groups of links (HTML)
PDF9: Providing headings by marking content with heading tags in PDF documents (PDF)
SCR21: Using functions of the Document Object Model (DOM) to add content to a page (Scripting)
PDF17: Specifying consistent page numbering for PDF documents (PDF)
G117: Using text to convey information that is conveyed by variations in presentation of text
FLASH8: Adding a group name to the accessible name of a form control (Flash)
Making information and relationships conveyed through presentation programmatically determinable or available in text using 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.
Using CSS rather than tables for page layout (future link)
G162: Positioning labels to maximize predictability of relationships
ARIA2: Identifying a required field with the aria-required property (ARIA)
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.
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 1: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.
Example 2: 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
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 understand the 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 a number of different reading orders for a Web page that can satisfy the Success Criterion.
For clarity:
Providing a particular linear order is only required where it affects meaning.
There may be more than one order that is "correct" (according to the WCAG 2.0 definition).
Only one correct order needs to be provided.
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.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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
PDF3: Ensuring correct tab and reading order in PDF documents (PDF)
SL34: Using the Silverlight Default Tab Sequence and Altering Tab Sequences With Properties (Silverlight)
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)
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.
any sequence where words and paragraphs are presented in an order that does not change the meaning of the content
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 1: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.
Example 2: 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)
Note: For requirements related to color, refer to Guideline 1.4.
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.
WCAG was designed to apply only to controls that were displayed on a web page. The intent was to avoid describing controls solely via references to visual or auditory cues. When applying this to instructions for operating physical hardware controls (e.g. a web kiosk with dedicated content), tactile cues on the hardware might be described (e.g. the arrow shaped key, the round key on the right side). This success criterion is not intended to prevent the use of tactile cues in instructions.
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 corner below the last survey question." This example uses both positioning, color and labeling to help identify the icon.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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 users 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 easy to perceive 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: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.
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". Examples of indications of an action include: using color to indicate that a link will open in a new window or that a database entry has been updated successfully. An example of prompting a response would be: using highlighting on form fields to indicate that a required field had been left blank.
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.
Users who have problems distinguishing between colors can look or listen for text cues.
People using Braille displays or other tactile interfaces can detect text cues by touch.
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 and numbers 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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
Conveying information redundantly using color (future link)
C15: Using CSS to change the presentation of a user interface component when it receives 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 independently from the overall 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 or not it is used to meet other success criteria) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
Individuals who use screen reading software can find it hard to hear 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.
Note: Playing audio automatically when landing on a page may affect a screen reader user's ability to find the mechanism to stop it because they navigate by listening and automatically started sounds might interfere with that navigation. Therefore, we discourage the practice of automatically starting sounds (especially if they last more than 3 seconds), and encourage that the sound be started by an action initiated by the user after they reach the page, rather than requiring that the sound be stopped by an action of the user after they land on the page.
See also Understanding Success Criterion 1.4.7 Low or No Background Audio.
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.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
G60: Playing a sound that turns off automatically within three seconds
SL24: Using AutoPlay to Keep Silverlight Media from Playing Automatically (Silverlight)
FLASH18: Providing a control to turn off sounds that play automatically in Flash (Flash)
FLASH34: Turning off sounds that play automatically when an assistive technology is detected (Flash)
SL3: Controlling Silverlight MediaElement Audio Volume (Silverlight)
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 site-wide 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 upon to be provided by either the platform or by user agents, including assistive technologies.
Note 2: The mechanism needs to meet all success criteria for the conformance level claimed.
1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)
Large Text: Large-scale text and images of large-scale 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 not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
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 requirement 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. (See The American Printing House for the Blind Guidelines for Large Printing and The Library of Congress Guidelines for Large Print under Resources). "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 1: When evaluating this success criterion, the font size in points should be obtained from the user agent or calculated on font metrics in the way that user agents do. Point sizes are based on the CSS pt size as defined in CSS3 Values. The ratio between sizes in points and CSS pixels is 1pt = 1.333px, therefore 14pt and 18pt are equivalent to approximately 18.5px and 24px.
Note 2: Because different image editing applications default to different pixel densities (e.g. 72 PPI or 96 PPI), specifying point sizes for fonts from within an image editing application can be unreliable when it comes to presenting text at a specific size. When creating images of large-scale text, authors should ensure that the text in the resulting image is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text. For example, for a 72 PPI image, an author would need to use approximately 19 pt and 24 pt font sizes in order to successfully present images of large-scale text to a user.
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. Corporate visual guidelines beyond logo and logotype are not included in the exception.
In this provision there is an exception that reads "that are part of a picture that contains significant other visual content,". This exception is intended to separate pictures that have text in them from images of text that are done to replace text in order to get a particular look.
Note: 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.
The minimum contrast success criterion (1.4.3) applies to text in the page, including placeholder text and text that is shown when a pointer is hovering over an object or when an object has keyboard focus. If any of these are used in a page, the text needs to provide sufficient contrast.
Although this Success Criterion only applies to text, similar issues occur for content presented in charts, graphs, diagrams, and other non-text-based information. Content presented in this manner should also have good contrast to ensure that more users can access the information.
See also Understanding Success Criterion 1.4.6 Contrast (Enhanced).
Text that is larger and has wider character strokes is easier to read at lower contrast. The contrast requirement 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. (See The American Printing House for the Blind Guidelines for Large Printing and The Library of Congress Guidelines for Large Print under Resources). "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 1: When evaluating this success criterion, the font size in points should be obtained from the user agent or calculated on font metrics in the way that user agents do. Point sizes are based on the CSS pt size as defined in CSS3 Values. The ratio between sizes in points and CSS pixels is 1pt = 1.333px, therefore 14pt and 18pt are equivalent to approximately 18.5px and 24px.
Note 2: Because different image editing applications default to different pixel densities (e.g. 72 PPI or 96 PPI), specifying point sizes for fonts from within an image editing application can be unreliable when it comes to presenting text at a specific size. When creating images of large-scale text, authors should ensure that the text in the resulting image is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text as rendered by the browser.
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].
Note: 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.
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 4.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 based on a) adoption of the 3:1 contrast ratio for minimum acceptable contrast for normal observers, in the ANSI standard, and b) the empirical finding that in the population, visual acuity of 20/40 is associated with a contrast sensitivity loss of roughly 1.5 [ARDITI-FAYE]. A user with 20/40 would thus require a contrast ratio of 3 * 1.5 = 4.5 to 1. Following analogous empirical findings and the same logic, the user with 20/80 visual acuity would require contrast of about 7:1.
The contrast ratio of 4.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.) 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 1: Refer to related resources for a list of tools that utilize the contrast ratio to analyze the contrast of Web content.
Note 2: See also Understanding Success Criterion 2.4.7 Focus Visible for techniques for indicating keyboard focus.
Note 3: It is sometimes helpful for authors to not specify colors for certain sections of a page in order to help users who need to view content with specific color combinations to view the content in their preferred color scheme. Refer to Understanding Success Criterion 1.4.5 Images of Text for more information.
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.
(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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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 higher contrast values for lines in diagrams (future link)
Using greater contrast level for red-black text/background combinations (future link)
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 contrast ratio in graphs and charts (future link)
Using a 3:1 contrast ratio or higher as the default presentation (future link)
Providing sufficient color contrast for empty text fields (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 colors, and
L2 is the relative luminance of the darker of the colors.
Note 1: Contrast ratios can range from 1 to 21 (commonly written 1:1 to 21:1).
Note 2: Because authors do not have control over user settings as to how text is rendered (for example font smoothing or anti-aliasing), the contrast ratio for text can be evaluated with anti-aliasing turned off.
Note 3: For the purpose of Success Criteria 1.4.3 and 1.4.6, contrast is measured with respect to the specified background over which the text is rendered in normal usage. If no background color is specified, then white is assumed.
Note 4: 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 the text 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 text color is specified when a background color is specified.
Note 5: When there is a border around the letter, the border can add contrast and would be used in calculating the contrast between the letter and its background. A narrow border around the letter would be used as the letter. A wide border around the letter that fills in the inner details of the letters acts as a halo and would be considered background.
Note 6: WCAG conformance should be evaluated for color pairs specified in the content that an author would expect to appear adjacent in typical presentation. Authors need not consider unusual presentations, such as color changes made by the user agent, except where caused by authors' code.
text that has been rendered in a non-text form (e.g., an image) in order to achieve a particular visual effect
Note: This does not include text that is part of a picture that contains significant other visual content.
Example: A person's name on a nametag in a photograph.
with at least 18 point or 14 point bold or font size that would yield equivalent size 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 is dependent both on the author-defined size and the user's display or user-agent settings. For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors would need to check this for the particular fonts in use. When fonts are defined in relative units, the actual point size is calculated by the user agent for display. The point size should be obtained from the user agent, or calculated based on font metrics as the user agent does, when evaluating this success criterion. Users who have low vision would be responsible for choosing appropriate settings.
Note 4: When using text without specifying the font size, the smallest font size used on major browsers for unspecified text would be a reasonable size to assume for the font. If a level 1 heading is rendered in 14pt bold or higher on major browsers, then it would be reasonable to assume it is large text. Relative scaling can be calculated from the default sizes in a similar fashion.
Note 5: The 18 and 14 point sizes for roman texts are taken from the minimum size for large print (14pt) and the larger standard font size (18pt). For other fonts such as CJK languages, the "equivalent" sizes would be the minimum large print size used for those languages and the next larger standard large print size.
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
a part of the content that is perceived by users as a single control for a distinct function
Note 1: Multiple user interface components may be implemented as a single programmatic element. Components here is not tied to programming techniques, but rather to what the user perceives as separate controls.
Note 2: User interface components include form elements and links as well as components generated by scripts.
Example: An applet has a "control" that can be used to move through content by line or page or random access. Since each of these would need to have a name and be settable independently, they would each be a "user interface component."
1.4.4 Resize text: Except for captions and images of text, 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 an environment that requires them to use IE 6.
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.
Some user interface components that function as a label and require activation by the user to access content are not wide enough to accommodate the label's content. For example, in Web mail applications the subject column may not be wide enough to accommodate every possible subject header, but activating the subject header takes the user to the full message with the full subject header. In Web-based spreadsheets, cell content that is too long to be displayed in a column can be truncated, and the full content of the cell is available to the user when the cell receives focus. The content of a user interface component may also become too wide in user interfaces where the user can resize the column width. In this type of user interface component, line wrapping is not required; truncation is acceptable if the component's full content is available on focus or after user activation and an indication that this information can be accessed, is provided to the user in some way besides the fact that it is truncated.
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.
See also Understanding Success Criterion 1.4.8 Visual Presentation.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
G142: Using a technology that has commonly-available user agents that support zoom
SL22: Supporting Browser Zoom in Silverlight (Silverlight)
SL23: Using A Style Switcher to Increase Font Size of Silverlight Text Elements (Silverlight)
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:
C28: Specifying the size of text containers using em units (CSS)
Techniques for relative measurements
Techniques for text container resizing
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)
Providing a mechanism to allow captions to be enlarged (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: 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;
speech 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.
synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content
Note 1: Captions are similar to dialogue-only subtitles except captions convey not only the content of spoken dialogue, but also equivalents for non-dialogue audio information needed to understand the program content, including sound effects, music, laughter, speaker identification and location.
Note 2: Closed Captions are equivalents that can be turned on and off with some players.
Note 3: Open Captions are any captions that cannot be turned off. For example, if the captions are visual equivalent images of text embedded in video.
Note 4: Captions should not obscure or obstruct relevant information in the video.
Note 5: In some countries, captions are called subtitles.
Note 6: Audio descriptions can be, but do not need to be, captioned since they are descriptions of information that is already presented visually.
text that has been rendered in a non-text form (e.g., an image) in order to achieve a particular visual effect
Note: This does not include text that is part of a picture that contains significant other visual content.
Example: A person's name on a nametag in a photograph.
sequence of characters that can be programmatically determined, where the sequence is expressing something in human language
1.4.5 Images of Text: If the 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 visually customized 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 which are capable of achieving their desired default visual presentation, to enable people who require a particular visual presentation of text to be able to adjust the text presentation as needed. 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 criteria 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, branding, etc. Images of text may also be used in order to use a particular font that is either not widely deployed or which the author doesn't have the right to redistribute, or to ensure that the text would be anti-aliased on all user agents.
Images of text can also be used where it is possible for users to customize the image of text to match their requirements.
The definition of image of text contains the note: "Note: This does not include text that is part of a picture that contains significant other visual content." Examples of such pictures include graphs, screenshots, and diagrams which visually convey important information through more than just text.
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.
See also Understanding Success Criterion 1.4.9 Images of Text (No Exception).
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).
People with cognitive disabilities that affect reading.
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 organization'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.
Customizable font settings in images of text
A Web site allows users to specify font settings and all images of text on the site are then provided based on those settings.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
SL31: Using Silverlight Font Properties to Control Text Presentation (Silverlight)
C30: Using CSS to replace text with images of text and providing user interface controls to switch (CSS)
G140: Separating information and structure from presentation to enable different presentations
PDF7: Performing OCR on a scanned PDF document to provide actual text (PDF)
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)
The following are common mistakes that are considered failures of Success Criterion 1.4.5 by the WCAG Working Group.
(No failures currently documented)
if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform
text that has been rendered in a non-text form (e.g., an image) in order to achieve a particular visual effect
Note: This does not include text that is part of a picture that contains significant other visual content.
Example: A person's name on a nametag in a photograph.
sequence of characters that can be programmatically determined, where the sequence is expressing something in human language
the font, size, color, and background can be set
1.4.6 Contrast (Enhanced): The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following: (Level AAA)
Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1;
Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
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 requirement 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. (See The American Printing House for the Blind Guidelines for Large Printing and The Library of Congress Guidelines for Large Print under Resources). "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 1: The point size should be obtained from the user agent, or calculated based on font metrics as the user agent does when evaluating this success criterion. Point sizes are based on the CSS pt size as defined in CSS3 Values. The ratio between sizes in points and CSS pixels is 1pt = 1.333px, therefore 14pt and 18pt are equivalent to approximately 18.5px and 24px.
Note 2: 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.
Note 3: Because different image editing applications default to different pixel densities (ex. 72 PPI or 96 PPI), specifying point sizes for fonts from within an image editing application can be unreliable when it comes to presenting text at a specific size. When creating images of large-scale text, authors should ensure that the text in the resulting image is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text as rendered by the browser.
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. Corporate visual guidelines beyond logo and logotype are not included in the exception.
In this provision there is an exception that reads "that are part of a picture that contains significant other visual content,". This exception is intended to separate pictures that have text in them from images of text that are done to replace text in order to get a particular look.
Although this Success Criterion only applies to text, similar issues occur for content presented in charts, graphs, diagrams, and other non-text-based information. Content presented in this manner should also have good contrast to ensure that more users can access the information.
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 4.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 based on a) adoption of the 3:1 contrast ratio for minimum acceptable contrast for normal observers, in the ANSI standard, and b) the empirical finding that in the population, visual acuity of 20/40 is associated with a contrast sensitivity loss of roughly 1.5 [ARDITI-FAYE]. A user with 20/40 would thus require a contrast ratio of 3 * 1.5 = 4.5 to 1. Following analogous empirical findings and the same logic, 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 4.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.) 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 1: Refer to related resources for a list of tools that utilize the contrast ratio to analyze the contrast of Web content.
Note 2: See also Understanding Success Criterion 2.4.7 Focus Visible for techniques for indicating keyboard focus.
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.
(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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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 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 contrast ratio in graphs and charts (future link)
Using a 3:1 contrast ratio or higher as the default presentation (future link)
Providing sufficient color contrast for empty text fields (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 colors, and
L2 is the relative luminance of the darker of the colors.
Note 1: Contrast ratios can range from 1 to 21 (commonly written 1:1 to 21:1).
Note 2: Because authors do not have control over user settings as to how text is rendered (for example font smoothing or anti-aliasing), the contrast ratio for text can be evaluated with anti-aliasing turned off.
Note 3: For the purpose of Success Criteria 1.4.3 and 1.4.6, contrast is measured with respect to the specified background over which the text is rendered in normal usage. If no background color is specified, then white is assumed.
Note 4: 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 the text 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 text color is specified when a background color is specified.
Note 5: When there is a border around the letter, the border can add contrast and would be used in calculating the contrast between the letter and its background. A narrow border around the letter would be used as the letter. A wide border around the letter that fills in the inner details of the letters acts as a halo and would be considered background.
Note 6: WCAG conformance should be evaluated for color pairs specified in the content that an author would expect to appear adjacent in typical presentation. Authors need not consider unusual presentations, such as color changes made by the user agent, except where caused by authors' code.
text that has been rendered in a non-text form (e.g., an image) in order to achieve a particular visual effect
Note: This does not include text that is part of a picture that contains significant other visual content.
Example: A person's name on a nametag in a photograph.
with at least 18 point or 14 point bold or font size that would yield equivalent size 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 is dependent both on the author-defined size and the user's display or user-agent settings. For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors would need to check this for the particular fonts in use. When fonts are defined in relative units, the actual point size is calculated by the user agent for display. The point size should be obtained from the user agent, or calculated based on font metrics as the user agent does, when evaluating this success criterion. Users who have low vision would be responsible for choosing appropriate settings.
Note 4: When using text without specifying the font size, the smallest font size used on major browsers for unspecified text would be a reasonable size to assume for the font. If a level 1 heading is rendered in 14pt bold or higher on major browsers, then it would be reasonable to assume it is large text. Relative scaling can be calculated from the default sizes in a similar fashion.
Note 5: The 18 and 14 point sizes for roman texts are taken from the minimum size for large print (14pt) and the larger standard font size (18pt). For other fonts such as CJK languages, the "equivalent" sizes would be the minimum large print size used for those languages and the next larger standard large print size.
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
a part of the content that is perceived by users as a single control for a distinct function
Note 1: Multiple user interface components may be implemented as a single programmatic element. Components here is not tied to programming techniques, but rather to what the user perceives as separate controls.
Note 2: User interface components include form elements and links as well as components generated by scripts.
Example: An applet has a "control" that can be used to move through content by line or page or random access. Since each of these would need to have a name and be settable independently, they would each be a "user interface component."
1.4.7 Low or No Background Audio: For prerecorded audio-only content that (1) contains primarily speech in the foreground, (2) is not an audio CAPTCHA or audio logo, and (3) is not vocalization intended to be primarily musical expression such as singing or rapping, at least one of the following is true: (Level AAA)
No Background: The audio does not contain background sounds.
Turn Off: The background sounds can be turned off.
20 dB: The background sounds are at least 20 decibels lower than the foreground speech content, with the exception of occasional sounds that last for only one or two seconds.
Note: Per the definition of "decibel," background sound that meets this requirement will be approximately four times quieter than 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 separate the speech from background sounds or other noise 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.
(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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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)
Providing an audio track for synchronized media that includes background sounds that are at least 20 decibels lower than speech (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)
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 presentation that contains only audio (no video and no interaction)
information that is not live
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 or glyphs (40 if CJK).
Text is not justified (aligned to both the left and the right margins).
Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.
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 on a full-screen window.
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 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 or glyphs (40 if CJK), where glyphs are the element of writing in the writing system for the text. Studies have shown that Chinese, Japanese and Korean (CJK) characters are approximately twice as wide as non-CJK characters when both types of characters are displayed with characteristics that achieve the same readability, so the maximum line width for CJK characters is half that of non-CJK 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. By space and a half within paragraphs we mean that top of one line is 150% further from the top of the line below it than would be true when the text is 'single spaced' (the default spacing for the font). By Paragraph spacing that is 1.5 times larger than the line spacing we mean that the spacing from the top of the last line of 1 paragraph is 250% farther from the Top of the first line of the next paragraph (i.e., that there is a blank line between the two paragraphs that is 150% of the single space blank line).
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 (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 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 1.4.4 Resize text for additional discussion of resizing text.
The horizontal scrolling requirement is not intended to apply to small-screen devices where long words may be displayed on a single line and require users to scroll horizontally. For the purposes of this requirement, authors should ensure that content meets this requirement on standard desktop/laptop displays with the browser window maximized. Since people generally keep their computers for several years, it is best not to rely on the latest desktop/laptop display resolutions but to consider the common desktop/laptop display resolutions over the course of several years when making this evaluation.
Wrapping should always be possible as long as words are not so long that a single word is more than half the width of a full screen. Very long URIs may run off the side of an enlarged screen, but they would not be considered text for "reading" and, therefore, would not violate this provision.
This provision does not mean that a user would never need to use horizontal scrolling. It only means that they would not need to use horizontal scrolling back and forth to read a line of text. For example, if a page consisted of two equal sized columns of text, it would automatically meet this provision. Enlarging the page would mean that the first column was completely on screen and the user could just scroll vertically down the page to read it. To read the second column, they would horizontally scroll to the right, where the right hand column would then fit entirely within the width of the screen, and read that column without further horizontal scrolling.
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.
The following images show examples of single-spacing, space-and-a-half and double-spaced text in a paragraph.
Examples of glyphs include "A", "→" (an arrow symbol), and "さ" (a Japanese character).
Resources are for information purposes only, no endorsement implied.
Developing sites for users with Cognitive disabilities and learning difficulties
MULTIFUNK: Bringing computer-supported reading one step further, Date: April 2002, ISBN: 82-539-0491-6, Author: Gjertrud W. Kamstrup, Eva Mjøvik, Anne-Lise Rygvold og Bjørn Gunnar Saltnes
Effective Monitor Display Design on the ERIC Web portal
Cognitive difficulties and access to information systems - an interaction design perspective", Peter Gregor and Anna Dickinson, Applied Computing, University of Dundee
Legge, G.E., Pelli, D.G., Rubin, G.S., & Schleske, M.M.:Psychophysics of reading. I. Normal Vision,Vision Research, 25, 239-252, 1985.
Legge, G.E., Rubin, G.S., Pelli, D.G., & Schleske, M.M.:Psychophysics of reading. II. Low Vision,Vision Research, 25, 253-266, 1985.
Osaka,N. and Oda, K. (1991). Effective visual field size necessary for vertical reading during Japanese text processing. Bulletin of Psychonomic Society,29(4),345-347.
Beckmann, P.J. & Legge, G.E. (1996). Psychophysics of reading. XIV. The page-navigation problem in using magnifiers. Vision Research, 36, 3723-3733.
川嶋英嗣・小田浩一(2003).読書におけるスクロール方向とウィンドウ幅の影響 日本心理学会第67回大会, 502.
小田浩一・今橋真理子(1995). 文字認知の閾値と読みの閾値. VISION, 7, 165-168.
Osaka,N. (1994). Size of saccade and fixation duration of eye movements during reading: psychophysics of Japanese text processing. Journal of Optical Society of America A, 9(1), 5-13.
山中今日子・小田浩一 (2007). 漢字の画数と書体のウェイトが視認性に及ぼす 影響. 視覚学会2007年夏季大会ポスター 1p1 Vision, P.167.
An Accessibility Frontier: Cognitive disabilities and learning difficulties
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Instructions: Since this is a multi-part success criterion, you must satisfy one of the numbered items for each of the requirements below.
G204: Not interfering with the user agent's reflow of text as the viewing window is narrowed 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
C24: Using percentage values in CSS for container sizes (CSS) OR
FLASH33: Using relative values for Flash object dimensions (Flash)
SCR34: Calculating size and position in a way that scales with text size (Scripting) OR
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 (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.
more than one sentence of text
process or technique for achieving a result
Note 1: The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies.
Note 2: The mechanism needs to meet all success criteria for the conformance level claimed.
on the most common sized desktop/laptop display with the viewport maximized
Note: Since people generally keep their computers for several years, it is best not to rely on the latest desktop/laptop display resolutions but to consider the common desktop/laptop display resolutions over the course of several years when making this evaluation.
1.4.9 Images of Text (No Exception): 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.
The definition of image of text contains the note: "Note: This does not include text that is part of a picture that contains significant other visual content." Examples of such pictures include graphs, screenshots, and diagrams which visually convey important information through more than just text.
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).
People with cognitive disabilities that affect reading.
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 organization'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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
SL31: Using Silverlight Font Properties to Control Text Presentation (Silverlight)
C30: Using CSS to replace text with images of text and providing user interface controls to switch (CSS)
G140: Separating information and structure from presentation to enable different presentations
PDF7: Performing OCR on a scanned PDF document to provide actual text (PDF)
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)
The following are common mistakes that are considered failures of Success Criterion 1.4.9 by the WCAG Working Group.
(No failures currently documented)
if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform
text that has been rendered in a non-text form (e.g., an image) in order to achieve a particular visual effect
Note: This does not include text that is part of a picture that contains significant other visual content.
Example: A person's name on a nametag in a photograph.
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.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Ensuring keyboard control by using one of the following techniques.
G90: Providing keyboard-triggered event handlers using one of the following techniques:
SCR20: Using both keyboard and other device-specific functions (Scripting)
SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons (Scripting)
SCR2: Using redundant keyboard and mouse event handlers (Scripting)
SL9: Handling Key Events to Enable Keyboard Functionality in Silverlight (Silverlight)
SL14: Providing Custom Control Key Handling for Keyboard Functionality in Silverlight (Silverlight)
FLASH17: Providing keyboard access to a Flash object and avoiding a keyboard trap (Flash) AND using the following techniques as applicable:
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 XHTML role, state, and value attributes if repurposing static elements as interactive user interface components (future link) AND SCR29: Adding keyboard-accessible actions to static HTML elements (Scripting)
Providing keyboard shortcuts 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: A keyboard interface allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.
Example: A touchscreen 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 or other standard exit methods, 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.
There may be times when the functionality of the Web page restricts the focus to a subsection of the content, as long as the user knows how to leave that state and "untrap" the focus.
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.
A modal dialog box
A Web application brings up a dialog box. At the bottom of the dialog are two buttons, Cancel and OK. When the dialog has been opened, focus is trapped within the dialog; tabbing from the last control in the dialog takes focus to the first control in the dialog. The dialog is dismissed by activating the Cancel button or the OK 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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
interface used by software to obtain keystroke input
Note 1: A keyboard interface allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.
Example: A touchscreen 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 path-dependent input cannot conform to this Success Criterion and therefore cannot meet Guideline 2.1 at Level AAA.
(none currently documented)
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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 path-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: A keyboard interface allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.
Example: A touchscreen 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 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 is essential and extending it would invalidate the activity; or
20 Hour Exception: The time limit is longer than 20 hours.
Note: This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. 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, low vision, dexterity impairments, and cognitive limitations may require more time to read content or to perform functions such as filling out on-line forms. If Web functions are time-dependent, it will be difficult for some users to perform the required action before a 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.
It also includes content that is advancing or updating at a rate beyond the user's ability to read and/or understand it. In other words, animated, moving or scrolling content introduces a time limit on a users ability to read content.
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.
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. For example, if a time limit is included in order to address security concerns, it would be considered to have been set by the content because it is designed to be part of the presentation and interaction experience for that content. 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/organization's control and are covered. (Success Criteria 2.2.3, 2.2.4 and 2.2.5 may also apply.)
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).
See also Understanding Success Criterion 2.2.3 No Timing.
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.
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.
A Web site uses a client side time limit to help protect users 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.
A Web page includes an animation which includes text that appears and disappears throughout. In some cases, the text is scrolling across the screen and in others, it is only displayed for a short time before it fades into the background. The page includes a pause button so that users who have trouble reading the text before it disappears can read it.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
G198: Providing a way for the user to turn the time limit off
G180: Providing the user with a means to set the time limit to 10 times the default time limit
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)
FLASH24: Allowing the user to extend the default time limit (Flash)
SL21: Replacing A Silverlight Timed Animation With a Nonanimated Element (Silverlight)
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)
Using sounds to focus user's attention (future link)
The following are common mistakes that are considered failures of Success Criterion 2.2.1 by the WCAG Working Group.
if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform
2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true: (Level A)
Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
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 periodically by software or that is streamed to the user agent 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.
Note 4: An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken.
The intent of this Success Criterion is to avoid distracting users during their interaction with a Web page.
"Moving, blinking and scrolling" 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. "Auto-updating" 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. The requirements for moving, blinking and scrolling content and for auto-updating content are the same except that:
authors have the option of providing the user with a means to control the frequency of updates when content is auto-updating and
there is no five second exception for auto-updating since it makes little sense to auto-update for just three seconds and then stop
Content that moves or auto-updates can be a barrier to anyone who has trouble reading stationary text quickly as well as anyone who has trouble tracking moving objects. It can also cause problems for screen readers.
Moving content can also be a severe distraction for some people. 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. Five seconds was chosen because it is long enough to get a user's attention, but not so long that a user cannot wait out the distraction if necessary to use the page.
Content that is paused can either resume in real-time or continue playing from the point in the presentation where the user left off.
Pausing and resuming where the user left off is best for users who want to pause to read content and works best when the content is not associated with a real-time event or status.
Note: See Understanding Success Criterion 2.2.1 Timing Adjustable for additional requirements related to time-limits for reading.
Pausing and jumping to current display (when pause is released) is better for information that is real-time or "status" in nature. For example, weather radar, a stock ticker, a traffic camera, or an auction timer, would present misleading information if a pause caused it to display old information when the content was restarted.
Note: Hiding content would have the same result as pausing and jumping to current display (when pause is released).
For a mechanism to be considered "a mechanism for the user to pause," it must provide the user with a means to pause that does not tie up the user or the focus so that the page cannot be used. The word "pause" here is meant in the sense of a "pause button" although other mechanisms than a button can be used. Having an animation stop only so long as a user has focus on it (where it restarts as soon as the user moves the focus away) would not be considered a "mechanism for the user to pause" because it makes the page unusable in the process and would not meet this SC.
It is important to note that the terms "blinking" and "flashing" can sometimes refer to the same content.
"Blinking" refers to content that causes a distraction problem. Blinking can be allowed for a short time as long as it stops (or can be stopped)
"Flashing" refers to content that can trigger a seizure (if it is more than 3 per second and large and bright enough). This cannot be allowed even for a second or it could cause a seizure. And turning the flash off is also not an option since the seizure could occur faster than most users could turn it off.
Blinking usually does not occur at speeds of 3 per second or more, but it can. If blinking occurs faster than 3 per second, it would also be considered a flash.
Providing content that stops blinking after five 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 affecting 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.
A Web advertisement
An advertisement blinks to get viewers attention but stops after 5 seconds
A form prompt
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 5 seconds.
An animation
An animation runs in the upper portion of the page but has a "freeze animation" button near the bottom of the animation.
A "loading" animation
A preloader animation is shown on a page which requires a certain percentage of a large file to be downloaded before playback can begin. The animation is the only content on the page and instructs the user to please wait while the video loads. Because the moving content is not presented in parallel with other content, no mechanism to pause, stop or hide it needs to be provided, even though the animation may run for more than 5 seconds for users with slower connections.
A full-page advertisement
A site requires that all users view a 15 second advertisement before they can access free content available from their site. Because viewing the advertisement is a requirement for all users and because it is not presented in parallel with other content, no mechanism to pause, stop or hide it needs to be provided.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
G4: Allowing the content to be paused and restarted from where it was paused
SL11: Pausing or Stopping A Decorative Silverlight Animation (Silverlight)
SL12: Pausing, Stopping, or Playing Media in Silverlight MediaElements (Silverlight)
SCR33: Using script to scroll content, and providing a mechanism to pause it (Scripting)
FLASH35: Using script to scroll Flash content, and providing a mechanism to pause it (Flash)
G187: Using a technology to include blinking content that can be turned off via the user agent
G152: Setting animated gif images to stop blinking after n cycles (within 5 seconds)
SCR22: Using scripts to control blinking and stop it in five seconds or less (Scripting)
FLASH36: Using scripts to control blinking and stop it in five seconds or less (Flash)
G186: Using a control in the Web page that stops moving, blinking, or auto-updating content
SL24: Using AutoPlay to Keep Silverlight Media from Playing Automatically (Silverlight)
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 5 seconds (future link)
The following are common mistakes that are considered failures of Success Criterion 2.2.2 by the WCAG Working Group.
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.
if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform
stopped by user request and not resumed until requested by user
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 affect 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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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)
if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform
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 virtual 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, unless the media is a media alternative for text that is clearly labeled as such
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 by enabling them 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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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 or other circumstances that would cause a user to be logged out while in the midst of completing the transaction.
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.
Other sites will log a person out of a session if a person logs in on the Web site from another computer or if other activities arise that make the site suspicious of whether the person is still the same legitimate person who logged in originally. When users are logged out while still in the midst of a transaction - it is important that they 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 upon, 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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Providing options to continue without loss of data using one of the following techniques:
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.
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. 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: The terms "blinking" and "flashing" can sometimes refer to the same content.
"Blinking" refers to content that causes a distraction problem. Blinking can be allowed for a short time as long as it stops (or can be stopped)
"Flashing" refers to content that can trigger a seizure (if it is more than 3 per second and large and bright enough). This cannot be allowed even for a second or it could cause a seizure. And turning the flash off is also not an option since the seizure could occur faster than most users could turn it off.
Blinking usually does not occur at speeds of 3 per second or more, but it can. If blinking occurs faster than 3 per second, it would also be considered a flash.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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)
Allowing users to set a custom flash rate limit (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 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 URI 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 around in 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. This might be a single-page Web site or just one page within a Web site.
a pair of opposing changes in relative luminance that can cause seizures in some people if it is large enough and in the right frequency range
Note 1: See general flash and red flash thresholds for information about types of flash that are not allowed.
Note 2: See also blinking.
a flash or rapidly changing image sequence is below the threshold (i.e., content passes) if any of the following are true:
there are no more than three general flashes and / or no more than three red flashes within any one-second period; or
the combined area of flashes occurring concurrently occupies no 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 of the maximum relative luminance where the relative luminance of the darker image is below 0.80; and where "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 (of visual field at typical viewing distance) 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 displays showing the same rendering of the content yield smaller and safer images so it is lower resolutions that are used to define the thresholds.)
Note 2: A transition is the change in relative luminance (or relative luminance/color for red flashing) between adjacent peaks and valleys in a plot of relative luminance (or relative luminance/color for red flashing) measurement against time. A flash consists of two opposing transitions.
Note 3: 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-BINNIE]
Note 4: Tools are available that will carry out analysis from video screen capture. However, no tool is necessary to evaluate for this condition if flashing is less than or equal to 3 flashes in any one second. Content automatically passes (see #1 and #2 above).
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.
Whereas Success Criterion 2.3.1 allows flashing if it is dim enough or has a small enough area, Success Criterion 2.3.2 does not allow flashing greater than 3 per second, regardless of brightness or size. As a result, even a single flashing pixel would violate this criterion. The intent is to guard against flashing larger than a single pixel, but since an unknown amount of magnification or high contrast setting may be applied, the prohibition is against any flashing.
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 Success Criterion 2.2.2 Pause, Stop, Hide 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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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 URI 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 around in 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. This might be a single-page Web site or just one page within a Web site.
a pair of opposing changes in relative luminance that can cause seizures in some people if it is large enough and in the right frequency range
Note 1: See general flash and red flash thresholds for information about types of flash that are not allowed.
Note 2: See also blinking.
Guideline 2.4: Provide ways to help users 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.
As described in The Motive Web Design Glossary, navigation has two main functions:
to tell the user where they are
to enable the user to go somewhere else
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)
Highlighting search terms (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.
It is not the intent of this Success Criterion to require authors to provide methods that are redundant to functionality provided by the user agent. Most web browsers provide keyboard shortcuts to move the user focus to the top of the page, so if a set of navigation links is provided at the bottom of a web page providing a "skip" link may be unnecessary.
Note: Although this Success Criterion 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.
Although the success criterion does not specifically use the term “within a set of web pages”, the concept of the pages belonging to a set is implied. An author would not be expected to avoid any possible duplication of content in any two pages that are not in some way related to each other; that are not "Web pages that share a common purpose and that are created by the same author, group or organization” (the definition of set of web pages).
Note: Even for web pages that are not in a set, if a web page has blocks of text that are repeated within the page it may be helpful (but not required) to provide a means to skip over them.
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.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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
SL25: Using Controls and Programmatic Focus to Bypass Blocks of Content in Silverlight (Silverlight)
Grouping blocks of repeated material in a way that can be skipped, using one of the following techniques:
ARIA11: Using ARIA landmarks to identify regions of a page (ARIA)
H69: Providing heading elements at the beginning of each section of content (HTML)
PDF9: Providing headings by marking content with heading tags in PDF documents (PDF)
H70: Using frame elements to group blocks of repeated material (HTML) AND H64: Using the title attribute of the frame and iframe elements (HTML)
SCR28: Using an expandable and collapsible menu to bypass block of content (Scripting)
SL29: Using Silverlight "List" Controls to Define Blocks that can be Bypassed (Silverlight)
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 URI 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 around in 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. This might be a single-page Web site or just one page within a Web site.
process or technique for achieving a result
Note 1: The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies.
Note 2: The mechanism needs to meet all success criteria for the conformance level claimed.
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.
In cases where the page is a document or a web application, the name of the document or web application would be sufficient to describe the purpose of the page. Note that it is not required to use the name of the document or web application; other things may also describe the purpose or the topic of the page.
Success Criteria 2.4.4 and 2.4.9 deal with the purpose of links, many of which are links to web pages. Here also, the name of a document or web application being linked to would be sufficient to describe the purpose of the link. Having the link and the title agree, or be very similar, is good practice and provides continuity between the link 'clicked on' and the web page that the user lands on.
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 collection.
The title of Understanding WCAG 2.0 is "Understanding WCAG 2.0."
The introduction page has the title "Introduction to Understanding WCAG 2.0."
Major sections of the document are pages titled "Understanding Guideline X" and "Understanding Success Criterion X."
Appendix A has the title "Glossary."
Appendix B has the title "Acknowledgements."
Appendix C has the title "References."
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://dl.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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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
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 URI 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 around in 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. This might be a single-page Web site or just one page within a Web site.
2.4.3 Focus Order: 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, moving 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 right 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 Success Criterion 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.
For clarity:
Focusable components need to receive focus in an order that preserves meaning and operability only when navigation sequences affect meaning and operability.
In those cases where it is required, there may be more than one order that will preserve meaning and operability.
If there is more than one order that preserves meaning and operability, only one of them needs to be provided.
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.
On a web page that contains a tree of interactive controls, the user can use the up and down arrow keys to move from tree node to tree node. Pressing the right arrow key expands a node, then using the down arrow key moves into the newly expanded nodes.
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 Success Criterion, 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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Giving focus to elements in an order that follows sequences and relationships within the content using one of the following techniques:
Changing a Web page dynamically 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 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.
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 URI 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 around in 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. This might be a single-page Web site or just one page within a Web site.
navigated in the order defined for advancing focus (from one element to the next) using a keyboard interface
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.
The text of, or associated with, the link is intended to describe the purpose of the link. In cases where the link takes one to a document or a web application, the name of the document or web application would be sufficient to describe the purpose of the link (which is to take you to the document or web application). Note that it is not required to use the name of the document or web application; other things may also describe the purpose of the link.
Success Criterion 2.4.2 deals with the titles of pages. Here also, the name of a document or web application being presented on the page would be sufficient to describe the purpose of the page. Having the link and the title agree, or be very similar, is good practice and provides continuity between the link 'clicked on' and the web page that the user lands on.
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, 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. Alternatively, authors may choose to use an ARIA technique to associate additional text on the page with the link.
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).
It is a best practice for links with the same destination to have consistent descriptions (and this is a requirement per Success Criterion 3.2.4 for pages in a set). It is also a best practice for links with different purposes and destinations to 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.
See also Understanding Success Criterion 2.4.9 Link Purpose (Link Only).
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 URI
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 URI
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
G91: Providing link text that describes the purpose of a link
H30: Providing link text that describes the purpose of a link for anchor elements (HTML)
H24: Providing text alternatives for the area elements of image maps (HTML)
FLASH27: Providing button labels that describe the purpose of a button (Flash)
Allowing the user to choose short or long link text using one of the techniques below:
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:
G91: Providing link text that describes the purpose of a link AND Semantically indicating links 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.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.
Even small sites should provide users some means of orientation. For a three or four page site, with all pages linked from the home page, it may be sufficient simply to provide links from and to the home page where the links on the home page can also serve as a site map.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Using two or more 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.
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)
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 URI 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 around in 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. This might be a single-page Web site or just one page within a Web site.
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.
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.
Labels and headings do not need to be lengthy. A word, or even a single character, may suffice if it provides an appropriate cue to finding and navigating content.
Note: This success criterion does not require headings or labels. This success criterion requires that if headings or labels are provided, they be descriptive. Also note that, if headings or labels are provided, they must meet Understanding Success Criterion 1.3.1 Info and Relationships.
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.
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.
A form asking the name of the user
A form asks the name of the user. It consists of two input fields to ask for the first and last name. The first field is labeled "First name", the second is labeled "Last name"."
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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 purpose of this success criterion is to help a person know which element has the keyboard focus.
The purpose of this success criterion is to help a person know which element among multiple elements has the keyboard focus. If there is only one keyboard actionable control on the screen, the success criterion would be met because the visual design presents only one keyboard actionable item.
Note that a keyboard focus indicator can take different forms. One common way is a caret within the text field to indicate that the text field has the keyboard focus. Another is a visual change to a button to indicate that that button has the keyboard focus.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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)
G195: Using an author-supplied, highly visible focus indicator
SCR31: Using script to change the background color or border of the element with focus (Scripting)
FLASH20: Reskinning Flash components to provide highly visible focus indication (Flash)
SL2: Changing The Visual Focus Indicator in Silverlight (Silverlight)
SL7: Designing a Focused Visual State for Custom Silverlight Controls (Silverlight)
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
PDF14: Providing running headers and footers in PDF documents (PDF)
PDF17: Specifying consistent page numbering for PDF documents (PDF)
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. Best practice is that links with the same destination would have the same descriptions, but links with different purposes and destinations would have different descriptions (see also Success Criterion 3.2.4 which calls for consistency in identifying components that have the same functionality). 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 text in the link is intended to describe the purpose of the link. In cases where the link takes one to a document or a web application, the name of the document or web application would be sufficient to describe the purpose of the link (which is to take you to the document or web application). Note that it is not required to use the name of the document or web application; other things may also describe the purpose of the link.
Success Criterion 2.4.2 deals with the titles of pages. Here also, the name of a document or web application being presented on the page would be sufficient to describe the purpose of the page. Having the link and the title agree, or be very similar, is good practice and provides continuity between the link 'clicked on' and the web page that the user lands on.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
G91: Providing link text that describes the purpose of a link
H30: Providing link text that describes the purpose of a link for anchor elements (HTML)
H24: Providing text alternatives for the area elements of image maps (HTML)
FLASH27: Providing button labels that describe the purpose of a button (Flash)
Allowing the user to choose short or long link text using one of the techniques below:
Providing a supplemental description of the purpose of a link using one of the following techniques:
Semantically indicating links 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.
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.
process or technique for achieving a result
Note 1: The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies.
Note 2: The mechanism needs to meet all success criteria for the conformance level claimed.
2.4.10 Section Headings: Section headings are used to organize the content. (Level AAA)
Note 1: "Heading" is used in its general sense and includes titles and other ways to add a heading to different types of content.
Note 2: This success criterion covers sections within writing, not user interface components. User Interface components are covered under Success Criterion 4.1.2.
The intent of this Success Criterion is to provide headings for sections of a Web page, when the page is organized into sections. For instance, long documents are often divided into a variety of chapters, chapters have subtopics and subtopics are divided into various sections, sections into paragraphs, etc. When such sections exist, they need to have headings that introduce them. This clearly indicates the organization of the content, facilitates navigation within the content, and provides mental "handles" that aid in comprehension of the content. Other page elements may complement headings to improve presentation (e.g., horizontal rules and boxes), but visual presentation is not sufficient to identify document sections.
This provision is included at Level AAA because it cannot be applied to all types of content and it may not always be possible to insert headings. For example, when posting a pre-existing document to the Web, headings that an author did not include in the original document cannot be inserted. Or, a long letter would often cover different topics, but putting headings into a letter would be very strange. However, if a document can be broken up into sections with headings, it facilitates both understanding and navigation.
People who are blind will know when they have moved from one section of a Web page to another and will know the purpose of each section.
People with some learning disabilities will be able to use the headings to understand the overall organization of the page content more easily.
People who navigate content by keyboard will be able to jump the focus from heading to heading, enabling them to find quickly content of interest.
In pages where content in part of the page updates, headings can be used to quickly access updated content.
A menu contains different sections for different courses. Each section has a heading: Appetizers, Salad, Soup, Entree, Dessert.
A Web application contains a settings page that is divided into groups of related settings. Each section contains a heading describing the class of settings.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.
Using the 'live' property to mark live regions (future link) (ARIA)
Providing mechanisms to navigate to different sections of the content of a Web page (future link)
The following are common mistakes that are considered failures of Success Criterion 2.4.10 by the WCAG Working Group.
(No failures currently documented)
A self-contained portion of written content that deals with one or more related topics or thoughts
Note: A section may consist of one or more paragraphs and include graphics, tables, lists and sub-sections.
a part of the content that is perceived by users as a single control for a distinct function
Note 1: Multiple user interface components may be implemented as a single programmatic element. Components here is not tied to programming techniques, but rather to what the user perceives as separate controls.
Note 2: User interface components include form elements and links as well as components generated by scripts.
Example: An applet has a "control" that can be used to move through content by line or page or random access. Since each of these would need to have a name and be settable independently, they would each be a "user interface component."
Guideline 3.1: Make text content readable and understandable.
The intent of this guideline is to allow text content to be read by users and by assistive technology, and to ensure that information necessary for understanding it is available.
People with disabilities experience text in many different ways. For some the experience is visual; for some it is auditory; for some it is tactile; for still others it is both visual and auditory. Some users experience great difficulty in recognizing written words yet understand extremely complex and sophisticated documents when the text is read aloud, or when key processes and ideas are illustrated visually or interpreted as sign language. For some users, it is difficult to infer the meaning of a word or phrase from context, especially when the word or phrase is used in an unusual way or has been given a specialized meaning; for these users the ability to read and understand may depend on the availability of specific definitions or the expanded forms of acronyms or abbreviations. User agents, including speech-enabled as well as graphical applications, may be unable to present text correctly unless the language and direction of the text are identified; while these may be minor problems for most users, they can be enormous barriers for users with disabilities. In cases where meaning cannot be determined without pronunciation information (for example, certain Japanese Kanji characters), pronunciation information must be available as well
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.
Setting expectations about content in the page from uncontrolled sources (future link)
Providing sign language interpretation for all content (future link)
Using the clearest and simplest language appropriate for the content (future link)
Avoiding centrally aligned text (future link)
Avoiding text that is fully justified (to both left and right margins) in a way that causes poor spacing between words or characters (future link)
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)
Limiting text column width (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)
Using images, illustrations, video, audio, or symbols to clarify meaning (future link)
Providing practical examples to clarify content (future link)
Using a light pastel background rather than a white background behind black text (future link)
Avoiding the use of unique interface controls unnecessarily (future link)
Using upper and lower case according to the spelling rules of the text language (future link)
Avoiding unusual foreign words (future link)
Providing sign language versions of information, ideas, and processes that must be understood in order to use the content (future link)
Making any reference to a location in a Web page into a link to that location (future link)
Making references to a heading or title include the full text of the title (future link)
Providing easy-to-read versions of basic information about a set of Web pages, including information about how to contact the Webmaster (future link)
Providing a sign language version of basic information about a set of Web pages, including information about how to contact the Webmaster (future link)
3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. (Level A)
The intent of this Success Criterion is to ensure that content developers provide information in the Web page that user agents need to present text and other linguistic content correctly. Both assistive technologies and conventional user agents can render text more accurately when the language of the Web page is identified. Screen readers can load the correct pronunciation rules. Visual browsers can display characters and scripts correctly. Media players can show captions correctly. As a result, users with disabilities will be better able to understand the content.
The default human language of the Web page is the default text-processing language as discussed in Internationalization Best Practices: Specifying Language in XHTML & HTML Content. When a Web page uses several languages, the default text-processing language is the language which is used most. (If several languages are used equally, the first language used should be chosen as the default human language.)
Note: For multilingual sites targeting Conformance Level A, the Working Group strongly encourages developers to follow Success Criterion 3.1.2 as well even though that is a Level AA Success Criterion.
This Success Criterion helps:
people who use screen readers or other technologies that convert text into synthetic speech;
people who find it difficult to read written material with fluency and accuracy, such as recognizing characters and alphabets or decoding words;
people with certain cognitive, language and learning disabilities who use text-to-speech software
people who rely on captions for synchronized media.
Example 1. A Web page with content in two languages
A Web page produced in Germany and written in HTML includes content in both German and English, but most of the content is in German. The default human language is identified as German (de) by the lang attribute on the html element.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
SVR5: Specifying the default language in the HTTP header (SERVER)
Using http or the Content-Language meta tag for metadata (future link)
The following are common mistakes that are considered failures of Success Criterion 3.1.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 URI 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 around in 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. This might be a single-page Web site or just one page within a Web site.
language that is spoken, written or signed (through visual or tactile means) to communicate with humans
Note: See also sign language.
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 1: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.
Example 2: 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.
3.1.2 Language of Parts: The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. (Level AA)
The intent of this Success Criterion is to ensure that user agents can correctly present content written in multiple languages. This makes it possible for user agents and assistive technologies to present content according to the presentation and pronunciation rules for that language. This applies to graphical browsers as well as screen readers, braille displays, and other voice browsers.
Both assistive technologies and conventional user agents can render text more accurately if the language of each passage of text is identified. Screen readers can use the pronunciation rules of the language of the text. Visual browsers can display characters and scripts in appropriate ways. This is especially important when switching between languages that read from left to right and languages that read from right to left, or when text is rendered in a language that uses a different alphabet. Users with disabilities who know all the languages used in the Web page will be better able to understand the content when each passage is rendered appropriately.
When no other language has been specified for a phrase or passage of text, its human language is the default human language of the Web page (see Success Criterion 3.1.1). So the human language of all content in single language documents can be programmatically determined.
Individual words or phrases in one language can become part of another language. For example, "rendezvous" is a French word that has been adopted in English, appears in English dictionaries, and is properly pronounced by English screen readers. Hence a passage of English text may contain the word "rendezvous" without specifying that its human language is French and still satisfy this Success Criterion. Frequently, when the human language of text appears to be changing for a single word, that word has become part of the language of the surrounding text. Because this is so common in some languages, single words should be considered part of the language of the surrounding text unless it is clear that a change in language was intended. If there is doubt whether a change in language is intended, consider whether the word would be pronounced the same (except for accent or intonation) in the language of the immediately surrounding text.
Most professions require frequent use of technical terms which may originate from a foreign language. Such terms are usually not translated to all languages. The universal nature of technical terms also facilitate communication between professionals.
Some common examples of technical terms include: Homo sapiens, Alpha Centauri, hertz, and habeas corpus.
Identifying changes in language is important for a number of reasons:
It allows braille translation software to follow changes in language, e.g., substitute control codes for accented characters, and insert control codes necessary to prevent erroneous creation of Grade 2 braille contractions.
Speech synthesizers that support multiple languages will be able to speak the text in the appropriate accent with proper pronunciation. If changes are not marked, the synthesizer will try its best to speak the words in the default language it works in. Thus, the French word for car, "voiture" would be pronounced "voyture" by a speech synthesizer that uses English as its default language.
Marking changes in language can benefit future developments in technology, for example users who are unable to translate between languages themselves will be able to use machines to translate unfamiliar languages.
Marking changes in language can also assist user agents in providing definitions using a dictionary.
This Success Criterion helps:
people who use screen readers or other technologies that convert text into synthetic speech;
people who find it difficult to read written material with fluency and accuracy, such as recognizing characters and alphabets, decoding words, and understanding words and phrases;
people with certain cognitive, language and learning disabilities who use text-to-speech software;
people who rely on captions to recognize language changes in the soundtrack of synchronized media content.
A German phrase in an English sentence.
In the sentence, "He maintained that the DDR (German Democratic Republic) was just a 'Treppenwitz der Weltgeschichte'," the German phrase 'Treppenwitz der Weltgeschichte' is marked as German. Depending on the markup language, English may either be marked as the language for the entire document except where specified, or marked at the paragraph level. When a screen reader encounters the German phrase, it changes pronunciation rules from English to German to pronounce the word correctly.
Alternative language links
An HTML Web page includes links to versions of the page in other languages (e.g., Deutsch, Français, Nederlands, Castellano, etc.). The text of each link is the name of the language, in that language. The language of each link is indicated via a lang
attribute.
"Podcast" used in a French sentence.
Because "podcast" is part of the vernacular of the immediately surrounding text in the following excerpt, "À l'occasion de l'exposition "Energie éternelle. 1500 ans d'art indien", le Palais des Beaux-Arts de Bruxelles a lancé son premier podcast. Vous pouvez télécharger ce podcast au format M4A et MP3," no indication of language change is required.
Resources are for information purposes only, no endorsement implied.
Language tags in HTML and XML - W3C Internationalization Working Group
Internationalization Best Practices: Specifying Language in XHTML & HTML Content
Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
H58: Using language attributes to identify changes in the human language (HTML)
FLASH13: Using HTML language attributes to specify language in Flash content (Flash)
PDF19: Specifying the language for a passage or phrase with the Lang entry in PDF documents (PDF)
SL4: Declaring Discrete Silverlight Objects to Specify Language Parts in the HTML DOM (Silverlight)
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.
SL27: Using Language/Culture Properties as Exposed by Silverlight Applications and Assistive Technologies (Silverlight)
Making text that is not in the default human language of the Web page visually distinct (future link)
Giving the names of any languages used in foreign passages or phrases (future link)
Providing language markup on proper names to facilitate correct pronunciation by screen readers (future link)
The following are common mistakes that are considered failures of Success Criterion 3.1.2 by the WCAG Working Group.
(No failures currently documented)
language that is spoken, written or signed (through visual or tactile means) to communicate with humans
Note: See also sign language.
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 1: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.
Example 2: 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.
3.1.3 Unusual Words: A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon. (Level AAA)
Certain disabilities make it difficult to understand nonliteral word usage and specialized words or usage. Certain disabilities make it difficult to understand figurative language or specialized usage. Providing such mechanisms is vital for these audiences. Specialized information intended for non-specialist readers is encouraged to satisfy this Success Criterion, even when claiming only Single-A or Double-A conformance.
This Success Criterion may help people with cognitive, language and learning disabilities who:
have difficulty decoding words
have difficulty understanding words and phrases
have difficulty using context to aid understanding
It would also help people with visual disabilities who:
lose context when zoomed-in with a screen magnifier
Text that includes a definition for a word used in an unusual way.
Organize the list or "cascade" of dictionaries and other resources so that the definition search will find the intended definitions instead of displaying definitions from other sources in the "cascade." (The "cascade" lists the dictionaries and other reference materials in the order most likely to bring up the right definition. This controls the order to follow when searching for definitions.)
Including definitions in the glossary.
WCAG 2.0 uses the word "text" in a specific way. Thus, when the word "text" is used within WCAG 2.0 it is linked to the definition of "text" provided in a glossary within the same Web page.
The specific definition of a word is provided at the bottom of the page.
The internal link from the word to the corresponding definition is also provided within the page.
Resources are for information purposes only, no endorsement implied.
Note: The inclusion of a product or vendor name in the list below does not constitute an endorsement by the Web Content Accessibility Guidelines Working Group or the Web Accessibility Initiative of the World Wide Web Consortium. This list is provided simply for convenience and to give users an idea of what resources may be available
Free bilingual dictionaries for a number of languages are available from the Freedict.org Web site. The dictionaries are of uneven quality and size as noted on the site. Retrieved 9 April 2005.
The WorldStar Free Dictionaries, Translators and Search Engines site provides access to free on-line dictionaries and search engines in many languages. Retrieved 18 November 2005.
More dictionaries are at your dictionary, freelang.com (in English, Spanish and French!) and many other places.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
G101: Providing the definition of a word or phrase used in an unusual or restricted way for the first occurrence of the word or phrase in a Web page using one of the following techniques:
G101: Providing the definition of a word or phrase used in an unusual or restricted way for each occurrence of the word or phrase in a Web page using one of the following techniques:
G101: Providing the definition of a word or phrase used in an unusual or restricted way for each occurrence of the word or phrase in a Web page using one of the following techniques:
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 markup and visual formatting to help users recognize words that have special meaning (future link)
Providing a voice-enabled dictionary search so that users who have difficulty typing or spelling can speak the word whose definition they need (future link)
Providing a sign language dictionary to help users who are deaf find the necessary definitions (future link)
Providing a mechanism for finding definitions for all words in text content (future link)
Providing a mechanism to determine the meaning of each word or phrase in text content (future link)
Avoiding unusual foreign words (future link)
Using a series of dictionaries in cascading fashion to provide meanings (future link)
The following are common mistakes that are considered failures of Success Criterion 3.1.3 by the WCAG Working Group.
(No failures currently documented)
phrase whose meaning cannot be deduced from the meaning of the individual words and the specific words cannot be changed without losing the meaning
Note: idioms cannot be translated directly, word for word, without losing their (cultural or language-dependent) meaning.
Example 1: In English, "spilling the beans" means "revealing a secret." However, "knocking over the beans" or "spilling the vegetables" does not mean the same thing.
Example 2: In Japanese, the phrase "さじを投げる" literally translates into "he throws a spoon," but it means that there is nothing he can do and finally he gives up.
Example 3: In Dutch, "Hij ging met de kippen op stok" literally translates into "He went to roost with the chickens," but it means that he went to bed early.
words used in a particular way by people in a particular field
Example: The word StickyKeys is jargon from the field of assistive technology/accessibility.
process or technique for achieving a result
Note 1: The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies.
Note 2: The mechanism needs to meet all success criteria for the conformance level claimed.
words used in such a way that requires users to know exactly which definition to apply in order to understand the content correctly
Example: The term "gig" means something different if it occurs in a discussion of music concerts than it does in article about computer hard drive space, but the appropriate definition can be determined from context. By contrast, the word "text" is used in a very specific way in WCAG 2.0, so a definition is supplied in the glossary.
3.1.4 Abbreviations: A mechanism for identifying the expanded form or meaning of abbreviations is available. (Level AAA)
The intent of this Success Criterion is to ensure that users can access the expanded form of abbreviations.
This Success Criterion may help people who:
have difficulty decoding words;
rely on screen magnifiers (magnification may reduce contextual cues);
have limited memory;
have difficulty using context to aid understanding.
Abbreviations may confuse some readers in different ways:
Some abbreviations do not look like normal words and cannot be pronounced according to the usual rules of the language. For example, the English word "room" is abbreviated as "rm," which does not correspond to any English word or phoneme. The user has to know that "rm" is an abbreviation for the word "room" in order to say it correctly.
Sometimes, the same abbreviation means different things in different contexts. For example, in the English sentence "Dr. Johnson lives on Boswell Dr.," the first "Dr." is an abbreviation for "Doctor" and the second instance is an abbreviation for the word "Drive" (a word that means "street"). Users must be able to understand the context in order to know what the abbreviations mean.
Some acronyms spell common words but are used in different ways. For example, "JAWS" is an acronym for a screen reader whose full name is "Job Access with Speech." It is also a common English word referring to the part of the mouth that holds the teeth. The acronym is used differently than the common word.
Some acronyms sound like common words but are spelled differently. For example, the acronym for Synchronized Multimedia Integration Language, S M I L, is pronounced like the English word "smile."
It would also help people with visual disabilities who:
Lose context when zoomed-in with a screen magnifier
An abbreviation whose expansion is provided the first time the abbreviation appears in the content.
The name, "World Wide Web Consortium," appears as the first heading on the organization's home page. The abbreviation, "W3C," is enclosed in parentheses in the same heading.
A dictionary search form.
A Web site includes a search form provided by an on-line acronym service. Users enter an acronym and the form returns a list of possible expansions from the sources that it searched.
A medical Web site.
A medical Web site provides information for both doctors and patients. The site includes a set of cascading dictionaries; a very specialized medical dictionary is first, followed by a second medical dictionary for the general public. The cascade also includes a list of acronyms and abbreviations that are unique to the site, and finally there is a standard dictionary as well. The standard dictionary at the end of the list provides definitions for most words in the text. The specialized medical dictionary yields definitions of unusual medical terms. Definitions for words that appear in more than one dictionary are listed in the order of the cascade. The meaning of acronyms and abbreviations is provided by the list of acronyms and abbreviations.
Expanded forms of Abbreviations.
The expanded form of each abbreviation is available in a programmatically determinable manner. User agents that speak the text can use the expanded form to announce the abbreviation. Other user agents might make the expanded form available as a tooltip or as contextual help for the abbreviation.
Resources are for information purposes only, no endorsement implied.
Acronym finder - You can search with the exact acronym, the beginning of the acronym, wildcards and reverse lookup.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
G102: Providing the expansion or explanation of an abbreviation for the first occurrence of the abbreviation in a Web page using one of the following techniques:
G102: Providing the expansion or explanation of an abbreviation for all occurrences of the abbreviation in a Web page using one of the following techniques:
G102: Providing the expansion or explanation of an abbreviation for all occurrences of abbreviations in 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.
Using unique abbreviations in a Web page (future link)
Using visual formatting to help users recognize abbreviations (future link)
Providing access to a talking dictionary to support users who might have difficulty decoding written definitions (future link)
Providing a voice-enabled dictionary search so that users who have difficulty typing or spelling can speak the word whose definition they need (future link)
The following are common mistakes that are considered failures of Success Criterion 3.1.4 by the WCAG Working Group.
(No failures currently documented)
shortened form of a word, phrase, or name where the abbreviation has not become part of the language
Note 1: This includes initialisms and acronyms where:
initialisms are shortened forms of a name or phrase made from the initial letters of words or syllables contained in that name or phrase
Note 1: Not defined in all languages.
Example 1: SNCF is a French initialism that contains the initial letters of the Société Nationale des Chemins de Fer, the French national railroad.
Example 2: ESP is an initialism for extrasensory perception.
acronyms are abbreviated forms made from the initial letters or parts of other words (in a name or phrase) which may be pronounced as a word
Example: NOAA is an acronym made from the initial letters of the National Oceanic and Atmospheric Administration in the United States.
Note 2: Some companies have adopted what used to be an initialism as their company name. In these cases, the new name of the company is the letters (for example, Ecma) and the word is no longer considered an abbreviation.
process or technique for achieving a result
Note 1: The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies.
Note 2: The mechanism needs to meet all success criteria for the conformance level claimed.
3.1.5 Reading Level: When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available. (Level AAA)
Content should be written as clearly and simply as possible. The intent of this Success Criterion is:
to ensure that additional content is available to aid the understanding of difficult or complex text;
to establish a testable measure indicating when such additional content is required.
This Success Criterion helps people with reading disabilities while also allowing authors to publish difficult or complex Web content. Text difficulty is described in terms of the level of education required to read the text. Education levels are defined according to the International Standard Classification of Education [UNESCO], which was created to allow international comparison among systems of education.
Difficult or complex text may be appropriate for most members of the intended audience (that is, most of the people for whom the content has been created). But there are people with disabilities, including reading disabilities, even among highly educated users with specialized knowledge of the subject matter. It may be possible to accommodate these users by making the text more readable. If the text cannot be made more readable, then supplemental content is needed. Supplemental content is required when text demands reading ability more advanced than the lower secondary education level—that is, more than nine years of school. Such text presents severe obstacles to people with reading disabilities and is considered difficult even for people without disabilities who have completed upper secondary education.
Reading disabilities such as dyslexia make it difficult to recognize written or printed words and associate them with the correct sounds. This is called "decoding" the text. Decoding must be automatic in order for people to read fluently. The act of decoding text word by word consumes much of the mental energy that most people are able to use for understanding what they read. Text that uses short, common words and short sentences is easier to decode and usually requires less advanced reading ability than text that uses long sentences and long or unfamiliar words.
The education level required to read text content (also called "readability") is measured by analyzing selected passages of text from the Web page. If the Web page includes text written for different purposes or different styles are used, the selected passages include samples of the types of content in the Web page and the different styles in which the content is written. (In many cases, the Web page contains only one kind of text content—e.g., technical documentation, a legal notice, marketing material, etc.—and all the content uses the same style.)
Educators can also measure the education level required to read text content. For example, qualified teachers can evaluate text according to local education standards to determine if it requires reading ability beyond what is expected for students in the last year of lower secondary education.
Because people's names, the names of cities or other proper names cannot be changed to shorter names with fewer syllables, and because doing so or just referring to everyone by pronouns can make sentences harder to understand, the success criterion specifies that proper names can be ignored or removed from the text before assessing whether it meets the reading ability requirement. Titles refer to the name of documents, books, movies, etc. Titles are removed or ignored for the analysis because changing the words in titles might make the titles easier to read but would make it impossible to understand the item to which the title refers. This would make it harder to read and understand the content. (e.g., a book, academic paper, article, etc.). Therefore, titles are also exempted specifically.
When a Web page contains multiple languages, a readability result should be calculated for each language that constitutes at least 5% of the content and that is used in full sentences or paragraphs (not just individual words or phrases). The overall readability of the page should be judged on the language that yields the worst readability results.
The readability of content may also be determined by applying a readability formula to the selected passage. Many (though not all) readability formulas base their calculations on passages of 100 words. Such formulas have been developed for many languages. The number of words in the passage is counted and the length of the words is determined by counting either the number of syllables or the number of characters. Most readability formulas also count the number and length of sentences. The average length of words and sentences in the content is then used to calculate a readability score. (Some languages, such as Japanese, may include multiple scripts within the same passage. Readability formulas for these languages may use the number and length of such "runs" in their calculations.) The result may be presented as a number (for example, on a scale from 0-100) or as a grade level. These results can then be interpreted using the education levels described in the International Standard Classification of Education. Readability formulas are available for at least some languages when running the spell checkers in popular software if you specify in the options of this engine that you want to have the statistics when it has finished checking your documents.
Primary education | Lower secondary education | Upper secondary education | Advanced education |
---|---|---|---|
First 6 years of school | 7-9 years of school | 10-12 years of school | More than 12 years of school |
Adapted from International Standard Classification of Education [UNESCO]
Note: According to the Open Society Mental Health Initiative, the concept of Easy to Read cannot be universal, and it will not be possible to write a text that will suit the abilities of all people with literacy and comprehension problems. Using the clearest and simplest language appropriate is highly desirable, but the WCAG Working Group could not find a way to test whether this had been achieved. The use of reading level is a way to introduce testability into a Success Criterion that encourages clear writing. Supplementary content can be a powerful technique for people with some classes of cognitive disability.
This Success Criterion may help people who:
Have difficulty comprehending and interpreting written language (e.g., articles, instructions, or newspapers in text or braille), for the purpose of obtaining general knowledge or specific information
A scientific journal including readable summaries of complex research articles
A scientific journal includes articles written in highly technical language aimed at specialists in the field. The journal's Table of Contents page includes a plain-language summary of each article. The summaries are intended for a general audience with eight years of school. The metadata for the journal uses the Dublin Core specification to identify the education level of the articles' intended audience as "advanced," and the education level of the intended audience for the summaries as "lower secondary education."
Medical information for members of the public.
A medical school operates a Web site that explains recent medical and scientific discoveries. The articles on the site are written for people without medical training. Each article uses the Dublin Core metadata specification to identify the education level of the intended audience as "lower secondary education" and includes the Flesch Reading Ease score for the article. A link on each page displays the education level and other metadata. No supplemental content is required because people who read at the lower secondary education level can read the articles.
An e-learning application.
An on-line course about Spanish cultural history includes a unit on Moorish architecture. The unit includes text written for students with different reading abilities. Photographs and drawings of buildings illustrate architectural concepts and styles. Graphic organizers are used to illustrate complex relationships, and an audio version using synthetic speech is available. The metadata for each version describes the academic level of the content and includes a readability score based on formulas developed for Spanish-language text. The learning application uses this metadata and metadata about the students to provide versions of instructional content that match the needs of individual students.
Science information that requires a reading ability at the lower secondary education level.
The text below (116 words total) requires a reading ability of grade 4.2 in the United States according to the Flesch-Kincaid formula. In the US, grade 4.2 is at the primary education level.
Science is about testing — and about looking closely. Some scientists use microscopes to take a close look. We're going to use a simple piece of paper.
Here's what you do: Print this page and cut out the square to make a "window" one inch square. (It's easiest to fold the page in half before you cut.)
Choose something interesting: a tree trunk, a leaf, flower, the soil surface, or a slice of soil from a shovel.
Put your window over the thing and look at it closely. Take your time — this is not a race.
To help you see more details, draw a picture of what's inside your square.
Now let's think about what you've found.
(Source: Howard Hughes Medical Institute "CoolScience for Kids" Project)
Resources are for information purposes only, no endorsement implied.
The Plain Language Association INternational (PLAIN) Web site provides many useful resources to help writers produce documents that communicate clearly in a variety of cultural and rhetorical contexts. Refer to: http://plainlanguagenetwork.org/.
The US Government's plain language Web site provides general information about plain language as well as information about use of plain language in US Government documents, including legal requirements
The Plain English Campaign Web site provides useful information and guidance for authors writing in English.
Juicy Studio's Readability Test analyzes the readability of all rendered content.
Entry for Audience Education Level. Using Dublin Core – Dublin Core Qualifiers
TextQuest.de lists references for readability formulas for different languages, including English, German, Spanish, Dutch, French, and Swedish.
Richtlijnen Keurmerk Makkelijk Lezen are the guidelines used by the Stichting Makkelijk Lezen (Easy Reading Foundation).
Leesbaar Nederlands ("Readable Dutch") contains guidelines for writing text that is accessible for people with a reading disability. These guidelines address language, content and design.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Note: Different sites may address this Success Criterion in different ways. An audio version of the content may be helpful to some users. For some people who are deaf, a sign language version of the page may be easier to understand than a written language version since sign language may be their first language. Some sites may decide to do both or other combinations. No technique will help all users who have difficulty. So different techniques are provided as sufficient techniques here for authors trying to make their sites more accessible. Any numbered technique or combination above can be used by a particular site and it is considered sufficient by the Working Group.
Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.
Providing text for navigational and landing pages that requires reading ability that is less advanced than the lower secondary education level (future link)
Providing text for interior pages that requires reading ability at the lower secondary education level (future link)
Including content summaries in metadata (future link)
Using the clearest and simplest language appropriate for the content (future link)
Using RDF to associate supplements with primary content (future link)
Providing a clear representational image on the site's home page (future link)
Clearly marking, by use of text or icon, content which has been optimized for easy reading (future link)
Using sentences that contain no redundant words, that is, words that do not change the meaning of the sentence (future link)
Using sentences that contain no more than two conjunctions (future link)
Using sentences that are no longer than the typical accepted length for secondary education (Note: In English that is 25 words) (future link)
Using sentences that do not contain complex words or phrases that could be replaced with more commonly used words without changing the meaning of the sentence (future link)
Providing summaries for different sections of text (future link)
Using metadata to associate alternatives at different reading levels. (future link)
Using the Dublin Core accessibility element to associate text content with text, graphical, or spoken supplements (future link)
Using the ISO AfA accessibility element to associate text content with text, graphical, or spoken supplements (future link)
Using the IMS accessibility element to associate text content with text, graphical, or spoken supplements (future link)
Making metadata viewable by humans (future link)
EXAMPLE: Providing, in metadata, URI(s) that point to a pre-primary-reading-level and a primary-reading-level text transcript of a new scientific discovery advanced-reading-level article.
Providing progressive complexity for site and page content (future link)
The following are common mistakes that are considered failures of Success Criterion 3.1.5 by the WCAG Working Group.
(No failures currently documented)
the two or three year period of education that begins after completion of six years of school and ends nine years after the beginning of primary education
Note: This definition is based on the International Standard Classification of Education [UNESCO].
additional content that illustrates or clarifies the primary content
The intent of this Success Criterion is to help people who are blind, people who have low vision, and people with reading disabilities to understand content in cases where meaning depends on pronunciation. Often words or characters have different meanings, each with its own pronunciation. The meaning of such words or characters can usually be determined from the context of the sentence. However, for more complex or ambiguous sentences, or for some languages, the meaning of the word cannot be easily determined or determined at all without knowing the pronunciation. When the sentence is read aloud and the screen reader reads the word using the wrong pronunciation, it can be even more difficult to understand than when read visually. When words are ambiguous or indeterminate unless the pronunciation is known, then providing some means of determining the pronunciation is needed.
For example, in the English language heteronyms are words that are spelled the same but have different pronunciations and meanings, such as the words desert (abandon) and desert (arid region). If the proper pronunciation can be determined from the context of the sentence, then nothing is required. If it cannot then some mechanism for determining the proper pronunciation would be required. Additionally, in some languages certain characters can be pronounced in different ways. In Japanese, for example, there are characters like Han characters(Kanji) that have multiple pronunciations. Screen readers may speak the characters incorrectly without the information on pronunciation. When read incorrectly, the content will not make sense to users.
This Success Criterion may help people who:
have difficulty decoding words
have difficulty using context to aid understanding
use technologies that read the words aloud
Giving the reading of a person's name.
Web content in Japanese provides kana (Japanese phonetic syllabary characters) written next to Han characters (Kanji) show the pronunciation of a person's name. The kana is provided to users in parentheses right after the word. Giving the reading of the words written in Han characters (Kanji) allows both sighted users and screen readers to read/pronounce the words correctly. Note that screen readers will speak the word twice: the Han characters (Kanji) that can be pronounced in a wrong way are read first and then kana is spoken in order to provide the correct reading.
Showing the reading of the words by ruby
element.
Web content using XHTML 1.1 provides kana (phonetic syllabary characters) written above the characters to show the reading (pronunciation) of the words by using the ruby
element.
Providing sound files of the pronunciation.
A document includes some words whose meaning cannot be determined without knowing the correct pronunciation. Each word is linked to a sound file that gives the correct pronunciation. Users can select these links to find out how to pronounce the words.
Including pronunciation information in the glossary.
A Web page includes a glossary section. Some items in the glossary include pronunciation information as well as definitions. Words in the content whose meaning cannot be determined without knowing their pronunciation are linked to the appropriate entries in the glossary.
Text that includes pronunciation information for characters shared by several languages but pronounced differently in each language
A Japanese university Web site includes several short phrases quoted from scholarly texts in Chinese and Korean. The quotations are written using the same script as the Japanese text. Pronunciation information is provided to show the correct reading of the Chinese and Korean characters.
Note: For Japanese, the ruby
element is used for showing the "reading" rather than "pronunciation."
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
G120: Providing the pronunciation immediately following the word
G62: Providing a glossary that includes pronunciation information for words that have a unique pronunciation in the content and have meaning that depends on pronunciation
G163: Using standard diacritical marks that can be turned off
H62: Using the ruby element (HTML) (XHTML 1.1)
Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.
Providing pronunciations in a sound file, so that users can listen to the pronunciations of the word (future link)
Providing a mechanism for finding pronunciations for all foreign words in text content (future link)
Providing a mechanism to determine the pronunciations of each word or phrase in text content (future link)
The following are common mistakes that are considered failures of Success Criterion 3.1.6 by the WCAG Working Group.
(No failures currently documented)
process or technique for achieving a result
Note 1: The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies.
Note 2: The mechanism needs to meet all success criteria for the conformance level claimed.
Guideline 3.2: Make Web pages appear and operate in predictable ways.
The intent of this Guideline is to help users with disabilities by presenting content in a predictable order from Web page to Web page and by making the behavior of functional and interactive components predictable. It is difficult for some users to form an overview of the Web page: screen readers present content as a one-dimensional stream of synthetic speech that makes it difficult to understand spatial relationships. Users with cognitive limitations may become confused if components appear in different places on different pages.
For example, people who use screen magnifiers see only part of the screen at any point in time; a consistent layout makes it easier for them to find navigation bars and other components. Placing repeated components in the same relative order within a set of Web pages allows users with reading disabilities to focus on an area of the screen rather than spending additional time decoding the text of each link. Users with limited use of their hands can more easily determine how to complete their tasks using the fewest keystrokes.
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.
Positioning labels to maximize predictability of relationships
3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. (Level A)
The intent of this Success Criterion is to ensure that functionality is predictable as visitors navigate their way through a document. Any component that is able to trigger an event when it receives focus must not change the context. Examples of changing context when a component receives focus include, but are not limited to:
forms submitted automatically when a component receives focus;
new windows launched when a component receives focus;
focus is changed to another component when that component receives focus;
Focus may be moved to a control either via the keyboard (e.g. tabbing to a control) or the mouse (e.g. clicking on a text field). Moving the mouse over a control does not move the focus unless scripting implements this behavior. Note that for some types of controls, clicking on a control may also activate the control (e.g. button), which may, in turn, initiate a change in context.
Note: What is meant by "component" here is also sometimes called "user interface element" or "user interface component''.
This Success Criterion helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a change of context will occur unexpectedly.
Example 1: A dropdown menu
A dropdown menu on a page allows users to choose between jump destinations. If the person uses the keyboard to move down to a choice and activates it (with a spacebar or enter key) it will jump to a new page. However, if the person moves down to a choice and either hits the escape or the tab key to move out of the pulldown menu – it does not jump to a new screen as the focus shifts out of the dropdown menu.
Example of a Failure: A help dialog
When a field receives focus, a help dialog window describing the field and providing options opens. As a keyboard user tabs through the Web page, the dialog opens, moving the keyboard focus away from the control every time the user attempts to tab past the field.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Note: A change of content is not always a change of context. This success criterion is automatically met if changes in content are not also changes of context.
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.
Not causing persistent changes of state or value when a component receives focus, or providing an alternate means to reset any changes (future link)
G200: Opening new windows and tabs from a link only when necessary
G201: Giving users advanced warning when opening a new window
The following are common mistakes that are considered failures of Success Criterion 3.2.1 by the WCAG Working Group.
major changes in the content of the Web page that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously
Changes in context include changes of:
focus;
Note: A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).
Example: Opening a new window, moving focus to a different component, going to a new page (including anything that would look to a user as if they had moved to a new page) or significantly re-arranging the content of a page are examples of changes of context.
3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)
The intent of this Success Criterion is to ensure that entering data or selecting a form control has predictable effects. Changing the setting of any user interface component is changing some aspect in the control that will persist when the user is no longer interacting with it. So checking a checkbox, entering text into a text field, or changing the selected option in a list control changes its setting, but activating a link or a button does not. Changes in context can confuse users who do not easily perceive the change or are easily distracted by changes. Changes of context are appropriate only when it is clear that such a change will happen in response to the user's action.
Note: This Success Criterion covers changes in context due to changing the setting of a control. Clicking on links or tabs in a tab control is activating the control, not changing the setting of that control.
Note: What is meant by "component" and "user interface component" here is also sometimes called "user interface element".
This Success Criterion helps users with disabilities by making interactive content more predictable. Unexpected changes of context can be so disorienting for users with visual disabilities or cognitive limitations that they are unable to use the content.
Individuals who are unable to detect changes of context are less likely to become disoriented while navigating a site. For example:
Individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as a new window popping up. In this case, warning users of context changes in advance minimizes confusion when the user discovers that the back button no longer behaves as expected.
Some individuals with low vision, with reading and intellectual disabilities, and others who have difficulty interpreting visual cues may benefit from additional cues in order to detect changes of context.
A form is provided for creating calendar entries in a Web based calendaring and scheduling application. Along with the standard fields for subject, time and location, there is a set of radio buttons to select the type of calendar entry to create. The calendar entry type can be meeting, appointment or reminder. If the user selects the radio for meeting, additional fields are displayed on the page for entering the meeting participants. Different fields appear if the reminder button is chosen. Because only parts of the entry change and the overall structure remains the same the basic context remains for the user.
A form contains fields representing US phone numbers. All of the numbers have a three digit area code followed by a three digit prefix and finally a four digit number, and each part of the phone number is entered into a separate field. When the user completes the entry of one field the focus automatically moves to the next field of the phone number. This behavior of phone fields is described for the user at the beginning of the form.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
G80: Providing a submit button to initiate a change of context using a technology-specific technique listed below
SCR19: Using an onchange event on a select element without causing a change of context (Scripting)
Note: A change of content is not always a change of context. This success criterion is automatically met if changes in content are not also changes of context.
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 3.2.2 by the WCAG Working Group.
major changes in the content of the Web page that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously
Changes in context include changes of:
focus;
Note: A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).
Example: Opening a new window, moving focus to a different component, going to a new page (including anything that would look to a user as if they had moved to a new page) or significantly re-arranging the content of a page are examples of changes of context.
a part of the content that is perceived by users as a single control for a distinct function
Note 1: Multiple user interface components may be implemented as a single programmatic element. Components here is not tied to programming techniques, but rather to what the user perceives as separate controls.
Note 2: User interface components include form elements and links as well as components generated by scripts.
Example: An applet has a "control" that can be used to move through content by line or page or random access. Since each of these would need to have a name and be settable independently, they would each be a "user interface component."
3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. (Level AA)
The intent of this Success Criterion is to encourage the use of consistent presentation and layout for users who interact with repeated content within a set of Web pages and need to locate specific information or functionality more than once. Individuals with low vision who use screen magnification to display a small portion of the screen at a time often use visual cues and page boundaries to quickly locate repeated content. Presenting repeated content in the same order is also important for visual users who use spatial memory or visual cues within the design to locate repeated content.
It is important to note that the use of the phrase "same order" in this section is not meant to imply that subnavigation menus cannot be used or that blocks of secondary navigation or page structure cannot be used. Instead, this Success Criterion is intended to assist users who interact with repeated content across Web pages to be able to predict the location of the content they are looking for and find it more quickly when they encounter it again.
Users may initiate a change in the order by using adaptive user agents or by setting preferences so that the information is presented in a way that is most useful to them.
Ensuring that repeated components occur in the same order on each page of a site helps users become comfortable that they will able to predict where they can find things on each page. This helps users with cognitive limitations, users with low vision, users with intellectual disabilities, and also those who are blind.
A consistently located control
A search field is the last item on every Web page in a site. users can quickly locate the search function.
An expanding navigation menu
A navigation menu includes a list of seven items with links to the main sections of a site. When a user selects one of these items, a list of subnavigation items is inserted into the top-level navigation menu.
Consistently positioned skip navigation controls
A "skip navigation" (or "skip to main content") link is included as the first link on every page in a Web site. The link allows users to quickly bypass heading information and navigational content and begin interacting with the main content of a page.
Skip to navigation link
Navigational content is consistently located at the end of each page in a set of Web pages. A "skip to navigation" link is consistently located at the beginning of each page so that keyboard users can easily locate it when needed.
Resources are for information purposes only, no endorsement implied.
Detweiler, M.C. and Omanson, R.C. (1996), Ameritech Web Page User Interface Standards and Design Guidelines.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
PDF14: Providing running headers and footers in PDF documents (PDF)
PDF17: Specifying consistent page numbering for PDF documents (PDF)
Using templates to ensure consistency across multiple Web pages (future link)
Creating layout, positioning, layering, and alignment (future link)
The following are common mistakes that are considered failures of Success Criterion 3.2.3 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 URI 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 around in 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. This might be a single-page Web site or just one page within a Web site.
same position relative to other items
Note: Items are considered to be in the same relative order even if other items are inserted or removed from the original order. For example, expanding navigation menus may insert an additional level of detail or a secondary navigation section may be inserted into the reading order.
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.
3.2.4 Consistent Identification: Components that have the same functionality within a set of Web pages are identified consistently. (Level AA)
The intent of this Success Criterion is to ensure consistent identification of functional components that appear repeatedly within a set of Web pages. A strategy that people who use screen readers use when operating a Web site is to rely heavily on their familiarity with functions that may appear on different Web pages. If identical functions have different labels on different Web pages, the site will be considerably more difficult to use. It may also be confusing and increase the cognitive load for people with cognitive limitations. Therefore, consistent labeling will help.
This consistency extends to the text alternatives. If icons or other non-text items have the same functionality, then their text alternatives should be consistent as well.
If there are two components on a web page that both have the same functionality as a component on another page in a set of web pages, then all 3 must be consistent. Hence the two on the same page will be consistent.
While it is desirable and best practice always to be consistent within a single web page, 3.2.4 only addresses consistency within a set of web pages where something is repeated on more than one page in the set.
People who learn functionality on one page on a site can find the desired functions on other pages if they are present.
When non-text content is used in a consistent way to identify components with the same functionality, people with difficulty reading text or detecting text alternatives can interact with the Web without depending on text alternatives.
People who depend on text alternatives can have a more predictable experience. They can also search for the component if it has a consistent label on different pages.
Example 1: Document Icon
A document icon is used to indicate document download throughout a site. The text alternative for the icon always begins with the word “Download," followed by a shortened form of the document title. Using different text alternatives to identify document names for different documents is a consistent use of text alternatives.
Example 2: Check Mark
A check mark icon functions as "approved", on one page but as "included" on another. Since they serve different functions, they have different text alternatives.
Example 3: Consistent references to other pages
A Web site publishes articles on-line. Each article spans multiple Web pages and each page contains a link to the first page, the next page and the previous page of the article. If the references to the next page read "page 2", "page 3", "page 4" etcetera, the labels are not the same but they are consistent. Therefore, these references are not failures of this Success Criterion.
Example 4: Icons with similar functions
An e-commerce application uses a printer icon that allows the user to print receipts and invoices. In one part of the application, the printer icon is labeled "Print receipt" and is used to print receipts, while in another part it is labeled "Print invoice" and is used to print invoices. The labeling is consistent ("Print x"), but the labels are different to reflect the different functions of the icons. Therefore, this example does not fail the Success Criterion.
Example 5: Save icon
A common "save" icon is used through out the site where page save function is provided on multiple Web pages.
Example 6: Icon and adjacent link to same destination
An icon with alt text and a link are next to each other and go to the same location. The best practice would be to group them into one link as per H2: Combining adjacent image and text links for the same resource (HTML) . However if they are visually positioned one above the other but separated in the source, this may not be possible. To meet the Success Criterion, the link text for these two links need only be consistent, not identical. But best practice is to have identical text so that when users encounter the second one, it is clear that it goes to the same place as the first.
Example 7: Example of a Failure
A submit "search" button on one Web page and a "find" button on another Web page both have a field to enter a term and list topics in the Web site related to the term submitted. In this case, the buttons have the same functionality but are not labeled consistently.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
G197: Using labels, names, and text alternatives consistently for content that has the same functionality AND following the sufficient techniques for Success Criterion 1.1.1 and sufficient techniques for Success Criterion 4.1.2 for providing labels, names, and text alternatives.
Note 1: Text alternatives that are "consistent" are not always "identical." For instance, you may have an graphical arrow at the bottom of a Web page that links to the next Web page. The text alternative may say "Go to page 4." Naturally, it would not be appropriate to repeat this exact text alternative on the next Web page. It would be more appropriate to say "Go to page 5". Although these text alternatives would not be identical, they would be consistent, and therefore would satisfy this Success Criterion.
Note 2: A single non-text-content-item may be used to serve different functions. In such cases, different text alternatives are necessary and should be used. Examples can be commonly found with the use of icons such as check marks, cross marks, and traffic signs. Their functions can be different depending on the context of the Web page. A check mark icon may function as "approved", "completed", or "included", to name a few, depending on the situation. Using "check mark" as text alternative across all Web pages does not help users understand the function of the icon. Different text alternatives can be used when the same non-text content serves multiple functions.
Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.
Ensuring that the text alternative conveys the function of the component and what will happen when the user activates it (future link)
Using the same non-text content for a given function whenever possible (future link)
The following are common mistakes that are considered failures of Success Criterion 3.2.4 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 URI 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 around in 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. This might be a single-page Web site or just one page within a Web site.
same result when used
Example: A submit "search" button on one Web page and a "find" button on another Web page may both have a field to enter a term and list topics in the Web site related to the term submitted. In this case, they would have the same functionality but would not be labeled consistently.
3.2.5 Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes. (Level AAA)
The intent of this Success Criterion is to encourage design of Web content that gives users full control of changes of context. This Success Criterion aims to eliminate potential confusion that may be caused by unexpected changes of context such as automatic launching of new windows, automatic submission of forms after selecting an item from a list, etcetera. Such unexpected changes of context may cause difficulties for people with motor impairments, people with low vision, people who are blind, and people with certain cognitive limitations.
Some types of change of context are not disruptive to some users, or actively benefit some users. For example, single-switch users rely on context changes that are animated by the system, and the preferences of low-vision users may vary depending on how much of the content they can see at once and how much of the session structure they can retain in working memory. Some types of content, such as slide shows, require the ability to change context in order to provide the intended user experience. Content that initiates changes of context automatically only when user preferences allow can conform to this Success Criterion.
Note: It is possible for more than one change of context to occur simultaneously. For example, clicking on a link which automatically opens a new window is an example of two separate changes of context related to the change in content and to the change in the viewport (window). The change in the content in this case is initiated by user request when they click on the link, but unless the user can be aware that the link will open in a new window then that change of context cannot be regarded as user-initiated.
Individuals who are unable to detect changes of context or may not realize that the context has changed are less likely to become disoriented while navigating a site. For example:
individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as a new window popping up. In this case, warning users of context changes in advance minimizes confusion when the user discovers that the back button no longer behaves as expected.
Some individuals with low vision, with reading and intellectual disabilities, and who have difficulty interpreting visual cues may benefit from additional cues in order to detect changes of context.
People with certain cognitive limitations do not get confused if automatic redirects are performed by the Web server instead of the browser.
an "update now" button
Instead of automatically updating the content, the author provides an "Update now" button that requests a refresh of the content.
An automatic redirection
A user is automatically redirected from an old page to a new page in such a way that he or she never realizes the redirect has occurred.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
SVR1: Implementing automatic redirects on the server side instead of on the client side (SERVER)
G110: Using an instant client-side redirect using one of the following techniques:
Including pop-up windows 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.
Opening new windows by providing normal hyperlinks without the target attribute (future link), because many user agents allow users to open links in another window or tab.
G200: Opening new windows and tabs from a link only when necessary
The following are common mistakes that are considered failures of Success Criterion 3.2.5 by the WCAG Working Group.
major changes in the content of the Web page that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously
Changes in context include changes of:
focus;
Note: A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).
Example: Opening a new window, moving focus to a different component, going to a new page (including anything that would look to a user as if they had moved to a new page) or significantly re-arranging the content of a page are examples of changes of context.
process or technique for achieving a result
Note 1: The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies.
Note 2: The mechanism needs to meet all success criteria for the conformance level claimed.
Guideline 3.3: Help users avoid and correct mistakes.
Everyone makes mistakes. However, people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for them to detect that they have made an error. Typical error indication methods may not be obvious to them because of a limited field of view, limited color perception, or use of assistive technology. This guideline seeks to reduce the number of serious or irreversible errors that are made, increase the likelihood that all errors will be noticed by the user, and help users understand what they should do to correct an error.
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.
Hiding optional form fields (future link)
3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A)
The intent of this Success Criterion is to ensure that users are aware that an error has occurred and can determine what is wrong. The error message should be as specific as possible. In the case of an unsuccessful form submission, re-displaying the form and indicating the fields in error is insufficient for some users to perceive that an error has occurred. Screen reader users, for example, will not know there was an error until they encounter one of the indicators. They may abandon the form altogether before encountering the error indicator, thinking that the page simply is not functional. Per the definition in WCAG 2.0, an "input error" is information provided by the user that is not accepted. This includes:
information that is required by the web page but omitted by the user, or
information that is provided by the user but that falls outside the required data format or allowed values.
For example:
the user fails to enter the proper abbreviation in to state, province, region, etc. field;
the user enters a state abbreviation that is not a valid state;
the user enters a non existent zip or postal code;
the user enters a birth date 2 years in the future;
the user enters alphabetic characters or parentheses into their phone number field that only accepts numbers;
the user enters a bid that is below the previous bid or the minimum bid increment.
Note: If a user enters a value that is too high or too low, and the coding on the page automatically changes that value to fall within the allowed range, the user's error would still need to be described to them as required by the success criterion. Such an error description telling the person of the changed value would meet both this success criterion (Error Identification) and Success Criterion 3.3.3 (Error Suggestion).
The identification and description of an error can be combined with programmatic information that user agents or assistive technologies can use to identify an error and provide error information to the user. For example, certain technologies can specify that the user's input must not fall outside a specific range, or that a form field is required. Currently, few technologies support this kind of programmatic information, but the Success Criterion does not require, nor prevent it.
It is perfectly acceptable to indicate the error in other ways such as image, color etc, in addition to the text description.
See also Understanding Success Criterion 3.3.3 Error Suggestion.
Providing information about input errors in text allows users who are blind or colorblind to perceive the fact that an error occurred.
This Success Criterion may help people with cognitive, language, and learning disabilities who have difficulty understanding the meaning represented by icons and other visual cues.
Identifying errors in a form submission
An airline Web site offers a special promotion on discounted flights. The user is asked to complete a simple form that asks for personal information such as name, address, phone number, seating preference and e-mail address. If any of the fields of the form are either not completed or completed incorrectly, an alert is displayed notifying the user which field or fields were missing or incorrect.
Note: This Success Criterion does not mean that color or text styles cannot be used to indicate errors. It simply requires that errors also be identified using text. In this example, two asterisks are used in addition to color.
Providing multiple cues
The user fails to fill in two fields on the form. In addition to describing the error and providing a unique character to make it easy to search for the fields, the fields are highlighted in yellow to make it easier to visually search for them as well.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
G83: Providing text descriptions to identify required fields that were not completed
ARIA21: Using Aria-Invalid to Indicate An Error Field (ARIA)
SCR18: Providing client-side validation and alert (Scripting)
SL35: Using the Validation and ValidationSummary APIs to Implement Client Side Forms Validation in Silverlight (Silverlight)
ARIA19: Using ARIA role=alert or Live Regions to Identify Errors (ARIA)
ARIA21: Using Aria-Invalid to Indicate An Error Field (ARIA)
G85: Providing a text description when user input falls outside the required format or values
SCR18: Providing client-side validation and alert (Scripting)
SCR32: Providing client-side validation and adding error text via the DOM (Scripting)
FLASH12: Providing client-side validation and adding error text via the accessible description (Flash)
PDF22: Indicating when user input falls outside the required format or values in PDF forms (PDF)
SL35: Using the Validation and ValidationSummary APIs to Implement Client Side Forms Validation in Silverlight (Silverlight)
Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.
G139: Creating a mechanism that allows users to jump to errors
Validating form submissions on the server (future link)
Re-displaying a form with a summary of errors (future link)
Providing error notification as the user enters information (future link)
Including error notification information in the page title (future link)
Highlighting or visually emphasizing errors where they occur (future link)
Supplementing text with non-text content when reporting errors (future link)
G199: Providing success feedback when data is submitted successfully
Using sounds to focus user's attention (future link)
The following are common mistakes that are considered failures of Success Criterion 3.3.1 by the WCAG Working Group.
(No failures currently documented)
information provided by the user that is not accepted
Note: This includes:
Information that is required by the Web page but omitted by the user
Information that is provided by the user but that falls outside the required data format or values
The intent of this success criterion is to have content authors place instructions or labels that identify the controls in a form so that users know what input data is expected. Instructions or labels may also specify data formats for fields especially if they are out of the customary formats or if there are specific rules for correct input. Content authors may also choose to make such instructions available to users only when the individual control has focus especially when instructions are long and verbose.
The intent of this Success Criterion is not to clutter the page with unnecessary information but to provide important cues and instructions that will benefit people with disabilities. Too much information or instruction can be just as much of a hindrance as too little. The goal is to make certain that enough information is provided for the user to accomplish the task without undue confusion or navigation.
Note: When labels are provided for input objects, the input object's relationship to the label (or to redundant text serving as the label) must be programmatically determinable or available in text per Understanding Success Criterion 1.3.1 Info and Relationships.
When label elements are associated with input elements the label is spoken by screen readers when the field receives focus and users with impaired motor control are helped by a larger clickable area for the control, since clicking on the label or the control will activate the control.
Field labels located in close proximity to the associated field assist users of screen magnifiers because the field and label are more likely to visible within the magnified area of the page.
Providing examples of expected data formats help users with cognitive, language and learning disabilities to enter information correctly.
Clearly identifying required fields prevents a keyboard only user from submitting an incomplete form and having to navigate the redisplayed form to find the uncompleted field and provide the missing information.
A field which requires the user to enter the two character abbreviation for a US state has a link next to it which will popup an alphabetized list of state names and the correct abbreviation.
A field for entering a date contains initial text which indicates the correct format for the date.
A field for entering a given name is clearly labeled with "Given Name" and the field for family name is labeled "Family Name" to avoid confusion over which name is requested.
A U.S. phone number separates the area code, exchange, and number into three fields. Parentheses surround the area code field, and a dash separates the exchange and number fields. While the punctuation provides visual clues to those familiar with the U.S. telephone number format, the punctuation is not sufficient to label the fields. The single "Phone number" label also cannot label all three fields. To address this, the three fields are grouped in a fieldset
with the legend
"Phone number". Visual labels for the fields (beyond the punctuation) cannot be provided in the design, so invisible labels are provided with the "title" attribute to each of the three fields. The value of this attribute for the three fields are, respectively, "Area Code", "Exchange", and "Number".
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
G131: Providing descriptive labels AND one of the following:
ARIA9: Using aria-labelledby to concatenate a label from several text nodes (ARIA)
ARIA17: Using grouping roles to identify related form controls (ARIA)
G162: Positioning labels to maximize predictability of relationships
G83: Providing text descriptions to identify required fields that were not completed
H90: Indicating required form controls using label or legend (HTML)
H44: Using label elements to associate text labels with form controls (HTML)
FLASH32: Using auto labeling to associate text labels with form controls (Flash)
FLASH29: Setting the label property for form components (Flash)
FLASH25: Labeling a form control by setting its accessible name (Flash)
PDF10: Providing labels for interactive form controls in PDF documents (PDF)
SL26: Using LabeledBy to Associate Labels and Targets in Silverlight (Silverlight)
H71: Providing a description for groups of form controls using fieldset and legend elements (HTML)
FLASH8: Adding a group name to the accessible name of a form control (Flash)
H65: Using the title attribute to identify form controls when the label element cannot be used (HTML)
SL8: Displaying HelpText in Silverlight User Interfaces (Silverlight)
G167: Using an adjacent button to label the purpose of a field
Note: The techniques at the end of the above list should be considered "last resort" and only used when the other techniques cannot be applied to the page. The earlier techniques are preferred because they increase accessibility to a wider user group.
Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.
SL19: Providing User Instructions With AutomationProperties.HelpText in Silverlight (Silverlight)
Providing linear form design and grouping similar items (future link)
The following are common mistakes that are considered failures of Success Criterion 3.3.2 by the WCAG Working Group.
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.
3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)
The intent of this Success Criterion is to ensure that users receive appropriate suggestions for correction of an input error if it is possible. The WCAG 2.0 definition of "input error" says that it is "information provided by the user that is not accepted" by the system. Some examples of information that is not accepted include information that is required but omitted by the user and information that is provided by the user but that falls outside the required data format or allowed values.
Success Criterion 3.3.1 provides for notification of errors. However, persons with cognitive limitations may find it difficult to understand how to correct the errors. People with visual disabilities may not be able to figure out exactly how to correct the error. In the case of an unsuccessful form submission, users may abandon the form because they may be unsure of how to correct the error even though they are aware that it has occurred.
The content author may provide the description of the error, or the user agent may provide the description of the error based on technology-specific, programmatically determined information.
Providing information about how to correct input errors allows users who have learning disabilities to fill in a form successfully. Users who are blind or have impaired vision understand more easily the nature of the input error and how to correct it. People with motion impairment can reduce the number of times they need to change an input value.
Additional Help for Correcting An Input Error
The result of a form that was not successfully submitted describes an input error in place in the page along with the correct input and offers additional help for the form field that caused the input error.
Suggestions from a Limited Set of Values
An input field requires that a month name be entered. If the user enters "12," suggestions for correction may include
A list of the acceptable values, e.g., "Choose one of: January, February, March, April, May, June, July, August, September, October, November, December."
A description of the set of values, e.g., "Please provide the name of the month."
The conversion of the input data interpreted as a different month format, e.g., "Do you mean 'December'?"
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Note: In some cases, more than one of these situations may apply. For example, when a mandatory field also requires the data to be in a specific format.
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.
G85: Providing a text description when user input falls outside the required format or values
SCR18: Providing client-side validation and alert (Scripting)
SCR32: Providing client-side validation and adding error text via the DOM (Scripting)
FLASH12: Providing client-side validation and adding error text via the accessible description (Flash)
PDF22: Indicating when user input falls outside the required format or values in PDF forms (PDF)
SCR18: Providing client-side validation and alert (Scripting)
SCR32: Providing client-side validation and adding error text via the DOM (Scripting)
FLASH12: Providing client-side validation and adding error text via the accessible description (Flash)
PDF22: Indicating when user input falls outside the required format or values in PDF forms (PDF)
Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.
G139: Creating a mechanism that allows users to jump to errors
Making error messages easy to understand and distinguishable from other text in the Web page (future link)
Validating form submissions on the server (future link)
When mandatory information has not been provided, including descriptions or examples of correct information in addition to identifying the field as mandatory (future link)
Repeating and emphasizing suggestions for correcting each input error in the context of its form field (future link)
Providing a way for the user to skip from each item in a list of suggestions to its corresponding form field (future link)
Providing additional contextual help for the form field requiring change (future link)
Accepting input data in a variety of formats (future link)
G199: Providing success feedback when data is submitted successfully
Providing a text description that contains information about the number of input errors, suggestions for corrections to each item, and instructions on how to proceed (future link)
Providing a text description that contains suggestions for correction as the first item (or one of the first items) of content, or emphasizing this information in the content (future link)
Displaying errors and suggestions in the context of the original form (for example, re-displaying a form where input errors and suggestions for correction are highlighted and displayed in the context of the original form) (future link)
Providing "correct examples" for data and data formats as initial text in mandatory form fields (future link)
Providing links to suggested correction text "close to" form fields, or providing the suggested correction text itself directly on the Web page "next to" form fields (future link)
SCR18: Providing client-side validation and alert (Scripting)
Providing client-side validation and adding error text via the DOM (future link)
Calling a function from the submit action of a form to perform client side validation (future link)
The following are common mistakes that are considered failures of Success Criterion 3.3.3 by the WCAG Working Group.
(No failures currently documented)
information provided by the user that is not accepted
Note: This includes:
Information that is required by the Web page but omitted by the user
Information that is provided by the user but that falls outside the required data format or values
3.3.4 Error Prevention (Legal, Financial, Data): For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: (Level AA)
Reversible: Submissions are reversible.
Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
The intent of this Success Criterion is to help users with disabilities avoid serious consequences as the result of a mistake when performing an action that cannot be reversed. For example, purchasing non-refundable airline tickets or submitting an order to purchase stock in a brokerage account are financial transactions with serious consequences. If a user has made a mistake on the date of air travel, he or she could end up with a ticket for the wrong day that cannot be exchanged. If the user made a mistake on the number of stock shares to be purchased, he or she could end up purchasing more stock than intended. Both of these types of mistakes involve transactions that take place immediately and cannot be altered afterwards, and can be very costly. Likewise, it may be an unrecoverable error if users unintentionally modify or delete data stored in a database that they later need to access, such as their entire travel profile in a travel services web site. When referring to modification or deletion of 'user controllable' data, the intent is to prevent mass loss of data such as deleting a file or record. It is not the intent to require a confirmation for each save command or the simple creation or editing of documents, records or other data.
Users with disabilities may be more likely to make mistakes. People with reading disabilities may transpose numbers and letters, and those with motor disabilities may hit keys by mistake. Providing the ability to reverse actions allows users to correct a mistake that could result in serious consequences. Providing the ability to review and correct information gives the user an opportunity to detect a mistake before taking an action that has serious consequences.
User-controllable data is user-viewable data that the user can change and/or delete through an intentional action. Examples of the user controlling such data would be updating the phone number and address for the user's account, or deleting a record of past invoices from a website. It does not refer such things as internet logs and search engine monitoring data that the user can't view or interact with directly.
Providing safeguards to avoid serious consequences resulting from mistakes helps users with all disabilities who may be more likely to make mistakes.
Order confirmation.
A Web retailer offers on-line shopping for customers. When an order is submitted, the order information—including items ordered, quantity of each ordered item, shipping address, and payment method—are displayed so that the user can inspect the order for correctness. The user can either confirm the order or make changes.
Stock sale:
A financial services Web site lets users buy and sell stock online. When a user submits an order to buy or sell stock, the system checks to see whether or not the market is open. If it is after hours, the user is alerted that the transaction will be an after-hours transaction, is told about the risks of trading outside of regular market hours, and given the opportunity to cancel or confirm the order.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
Informing the user what irreversible action is about to happen (future link)
SCR18: Providing client-side validation and alert (Scripting)
SL35: Using the Validation and ValidationSummary APIs to Implement Client Side Forms Validation in Silverlight (Silverlight)
Placing focus in the field containing the error (future link)
Avoiding use of the same words or letter combinations to begin each item of a drop-down list (future link)
G199: Providing success feedback when data is submitted successfully
The following are common mistakes that are considered failures of Success Criterion 3.3.4 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 URI 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 around in 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. This might be a single-page Web site or just one page within a Web site.
information provided by the user that is not accepted
Note: This includes:
Information that is required by the Web page but omitted by the user
Information that is provided by the user but that falls outside the required data format or values
transactions where the person incurs a legally binding obligation or benefit
Example: A marriage license, a stock trade (financial and legal), a will, a loan, adoption, signing up for the army, a contract of any type, etc.
process or technique for achieving a result
Note 1: The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies.
Note 2: The mechanism needs to meet all success criteria for the conformance level claimed.
data that is intended to be accessed by users
Note: This does not refer to such things as Internet logs and search engine monitoring data.
Example: Name and address fields for a user's account.
3.3.5 Help: Context-sensitive help is available. (Level AAA)
The intent of this Success Criterion is to help users avoid making mistakes. Some users with disabilities may be more likely to make mistakes than users without disabilities. Using context-sensitive help, users find out how to perform an operation without losing track of what they are doing.
Context-sensitive help only needs to be provided when the label is not sufficient to describe all functionality. The existence of context-sensitive help should be obvious to the user and they should be able to obtain it whenever they require it.
The content author may provide the help text, or the user agent may provide the help text based on technology-specific, programmatically determined information.
Assistance for text input helps individuals with writing disabilities and people with reading and intellectual disabilities who often have difficulty writing text in forms or other places that need text input.
Additionally, these kinds of assistance help people who are aging and have the same difficulty in text input and/or mouse operation.
on-line job application
Some of the questions may be hard for new job seekers to understand. A help link next to each question provides instructions and explanations for each question.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
H89: Using the title attribute to provide context-sensitive help (HTML)
Checking byte of character and auto-converting to expected byte for text input if applicable (future link)
The following are common mistakes that are considered failures of Success Criterion 3.3.5 by the WCAG Working Group.
(No failures currently documented)
help text that provides information related to the function currently being performed
Note: Clear labels can act as context-sensitive help.
3.3.6 Error Prevention (All): For Web pages that require the user to submit information, at least one of the following is true: (Level AAA)
Reversible: Submissions are reversible.
Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
The intent of this Success Criterion is to help users with disabilities avoid consequences that may result from making a mistake when submitting form data. This criterion builds on Success Criterion 3.3.4 in that it applies to all forms that require users to submit information.
Users with disabilities may be more likely to make mistakes and may have more difficulty detecting or recovering from mistakes. People with reading disabilities may transpose numbers and letters, and those with motor disabilities may hit keys by mistake. Providing the ability to reverse actions allows users to correct a mistake. Providing the ability to review and correct information gives the user an opportunity to detect a mistake before taking an action.
Providing safeguards to avoid consequences resulting from mistakes helps users with all disabilities who may be more likely to make mistakes.
(none currently documented)
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Following the sufficient techniques for Success Criterion 3.3.4 for all forms that require the user to submit information.
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 URI 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 around in 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. This might be a single-page Web site or just one page within a Web site.
information provided by the user that is not accepted
Note: This includes:
Information that is required by the Web page but omitted by the user
Information that is provided by the user but that falls outside the required data format or values
process or technique for achieving a result
Note 1: The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies.
Note 2: The mechanism needs to meet all success criteria for the conformance level claimed.
Guideline 4.1: Maximize compatibility with current and future user agents, including assistive technologies.
The purpose of this guideline is to support compatibility with current and future user agents, especially assistive technologies (AT). This is done both by 1) ensuring that authors do not do things that would break AT (e.g., poorly formed markup) or circumvent AT (e.g., by using unconventional markup or code) and 2) exposing information in the content in standard ways that assistive technologies can recognize and interact with. Since technologies change quickly, and AT developers have much trouble keeping up with rapidly changing technologies, it is important that content follow conventions and be compatible with APIs so that AT can more easily work with new technologies as they evolve.
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.
Avoiding deprecated features of W3C technologies (future link)
Not displaying content that relies on technologies that are not accessibility-supported when the technology is turned off or not supported.
4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)
Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.
The intent of this Success Criterion is to ensure that user agents, including assistive technologies, can accurately interpret and parse content. If the content cannot be parsed into a data structure, then different user agents may present it differently or be completely unable to parse it. Some user agents use "repair techniques" to render poorly coded content.
Since repair techniques vary among user agents, authors cannot assume that content will be accurately parsed into a data structure or that it will be rendered correctly by specialized user agents, including assistive technologies, unless the content is created according to the rules defined in the formal grammar for that technology. In markup languages, errors in element and attribute syntax and failure to provide properly nested start/end tags lead to errors that prevent user agents from parsing the content reliably. Therefore, the Success Criterion requires that the content can be parsed using only the rules of the formal grammar.
Note 1: The concept of "well formed" is close to what is required here. However, exact parsing requirements vary amongst markup languages, and most non XML-based languages do not explicitly define requirements for well formedness. Therefore, it was necessary to be more explicit in the success criterion in order to be generally applicable to markup languages. Because the term "well formed" is only defined in XML, and (because end tags are sometimes optional) valid HTML does not require well formed code, the term is not used in this success criterion.
Note 2: With the exception of one success criterion ( Understanding Success Criterion 1.4.4 Resize text, which specifically mentions that the effect specified by the success criterion must be achieved without relying on an assistive technology) authors can meet the success criteria with content that assumes use of an assistive technology (or access features in use agents) by the user, where such assistive technologies (or access features in user agents) exist and are available to the user.
Ensuring that Web pages have complete start and end tags and are nested according to specification helps ensure that assistive technologies can parse the content accurately and without crashing.
(none currently documented)
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Ensuring that Web pages can be parsed by using one of the following techniques:
SL33: Using Well-Formed XAML to Define a Silverlight User Interface (Silverlight)
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 4.1.1 by the WCAG Working Group.
4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)
Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.
The intent of this Success Criterion is to ensure that Assistive Technologies (AT) can gather information about, activate(or set) and keep up to date on the status of user interface controls in the content.
When standard controls from accessible technologies are used, this process is straightforward. If the user interface elements are used according to specification the conditions of this provision will be met. (See examples of Success Criterion 4.1.2 below)
If custom controls are created, however, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies.
A particularly important state of a user interface control is whether or not it has focus. The focus state of a control can be programmatically determined, and notifications about change of focus are sent to user agents and assistive technology. Other examples of user interface control state are whether or not a checkbox or radio button has been selected, or whether or not a collapsible tree or list node is expanded or collapsed.
Note: Success Criterion 4.1.2 requires a programmatically determinable name for all user interface components. Names may be visible or invisible. Occasionally, the name must be visible, in which case it is identified as a label. Refer to the definition of name and label in the glossary for more information.
Providing role, state, and value information on all user interface components enables compatibility with assistive technology, such as screen readers, screen magnifiers, and speech recognition software, used by people with disabilities.
Accessible APIs
A Java applet uses the accessibility API defined by the language.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
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.
ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used (ARIA)
ARIA16: Using aria-labelledby to provide a name for user interface controls (ARIA)
G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes using technology-specific techniques below:
Exposing the names and roles, allowing user-settable properties to be directly set, and providing notification of changes using one of the following techniques:
G135: Using the accessibility API features of a technology to expose names and roles, to allow user-settable properties to be directly set, and to provide notification of changes using technology-specific techniques below:
FLASH32: Using auto labeling to associate text labels with form controls (Flash)
FLASH29: Setting the label property for form components (Flash)
FLASH30: Specifying accessible names for image buttons (Flash)
PDF10: Providing labels for interactive form controls in PDF documents (PDF)
PDF12: Providing name, role, value information for form fields in PDF documents (PDF)
SL26: Using LabeledBy to Associate Labels and Targets in Silverlight (Silverlight)
SL32: Using Silverlight Text Elements for Appropriate Accessibility Role (Silverlight)
G10: Creating components using a technology that supports the accessibility API features of the platforms on which the user agents will be run to expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes using technology-specific techniques below:
ARIA4: Using a WAI-ARIA role to expose the role of a user interface component (ARIA)
ARIA16: Using aria-labelledby to provide a name for user interface controls (ARIA)
SL6: Defining a UI Automation Peer for a Custom Silverlight Control (Silverlight)
SL18: Providing Text Equivalent for Nontext Silverlight Controls With AutomationProperties.Name (Silverlight)
SL20: Relying on Silverlight AutomationPeer Behavior to Set AutomationProperties.Name (Silverlight)
SL30: Using Silverlight Control Compositing and AutomationProperties.Name (Silverlight)
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 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 4.1.2 by the WCAG Working Group.
Note: This failure may be solved in the future using DHTML roadmap techniques.
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: 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;
speech 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.
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.
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 1: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.
Example 2: 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.
set by software using methods that are supported by user agents, including assistive technologies
text or number by which software can identify the function of a component within Web content
Example: A number that indicates whether an image functions as a hyperlink, command button, or check box.
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.
a part of the content that is perceived by users as a single control for a distinct function
Note 1: Multiple user interface components may be implemented as a single programmatic element. Components here is not tied to programming techniques, but rather to what the user perceives as separate controls.
Note 2: User interface components include form elements and links as well as components generated by scripts.
Example: An applet has a "control" that can be used to move through content by line or page or random access. Since each of these would need to have a name and be settable independently, they would each be a "user interface component."
All WCAG 2.0 Success Criteria are written as testable criteria for objectively determining if content satisfies them. Testing the Success Criteria would involve a combination of automated testing and human evaluation. The content should be tested by those who understand how people with different types of disabilities use the Web.
Testing and testable in the context refer to functional testing, that is verifying that the content functions as expected, or in this case, that it satisfies the Success Criteria. Although content may satisfy all Success Criteria, the content may not always be usable by people with a wide variety of disabilities. Therefore, usability testing is recommended, in addition to the required functional testing. Usability testing aims to determine how well people can use the content for its intended purpose. It is recommended that users with disabilities be included in test groups when performing usability testing.
Conformance to a standard means that you meet or satisfy the 'requirements' of the standard. In WCAG 2.0 the 'requirements' are the Success Criteria. To conform to WCAG 2.0, you need to satisfy the Success Criteria, that is, there is no content which violates the Success Criteria.
Note: This means that if there is no content to which a success criterion applies, the success criterion is satisfied.
Most standards only have one level of conformance. In order to accommodate different situations that may require or allow greater levels of accessibility than others, WCAG 2.0 has three levels of conformance, and therefore, three levels of Success Criteria.
There are five requirements that must be met in order for content to be classified as 'conforming' to WCAG 2.0. This section provides brief notes on those requirements. This section will be expanded over time to address questions that may arise or to provide new examples of ways to meet the different conformance requirements.
1. Conformance Level: One of the following levels of conformance is met in full.
Level A: For Level A conformance (the minimum level of conformance), the Web page satisfies all the Level A Success Criteria, or a conforming alternate version is provided.
Level AA: For Level AA conformance, the Web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternate version is provided.
Level AAA: For Level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA Success Criteria, or a Level AAA conforming alternate version is provided.
Note 1: Although conformance can only be achieved at the stated levels, authors are encouraged to report (in their claim) any progress toward meeting success criteria from all levels beyond the achieved level of conformance.
Note 2: It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.
The first requirement deals with the levels of conformance. It basically says that all information on a page conforms or has a conforming alternate version that is available from the page. The requirement also explains that no conformance is possible without at least satisfying all of the Level A Success Criteria.
The note points out that authors are encouraged to go beyond conformance to a particular level and to complete, and report if they desire, any progress toward higher levels of conformance.
See also Understanding Conforming Alternate Versions which includes techniques for providing Conforming Alternate Versions.
2. Full pages: Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.
Note 1: For the purpose of determining conformance, alternatives to part of a page's content are considered part of the page when the alternatives can be obtained directly from the page, e.g., a long description or an alternative presentation of a video.
Note 2: Authors of Web pages that cannot conform due to content outside of the author's control may consider a Statement of Partial Conformance.
This provision simply requires that the whole page conform. Statements about "part of a page conforming" cannot be made.
Sometimes, supplemental information may be available from another page for information on a page. The longdesc
attribute in HTML is an example. With longdesc
, a long description of a graphic might be on a separate page that the user can jump to from the page with the graphic. This makes it clear that such content is considered part of the Web page, so that requirement #2 is satisfied for the combined set of Web pages considered as a single Web page. Alternatives can also be provided on the same page. For example creating an equivalent to a user interface control.
Note 1: Because of conformance requirement 5, a whole page may conform even if parts of the page use non accessibility-supported content technologies as long as they do not interfere with the rest of the page and all information and function is available elsewhere on or from the page.
Note 2: It is possible to include non-conforming content. See Understanding Conformance Requirement 5.
3. Complete processes: When a Web page is one of a series of Web pages presenting a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), all Web pages in the process conform at the specified level or better. (Conformance is not possible at a particular level if any page in the process does not conform at that level or better.)
Example: An online store has a series of pages that are used to select and purchase products. All pages in the series from start to finish (checkout) conform in order for any page that is part of the process to conform.
This provision prevents a Web page that is part of a larger process from being considered conforming if the process overall is not. This would prevent a shopping site from being classified as conforming if the checkout or other features of the site that are part of the shopping and buying process do not conform.
4. Only Accessibility-Supported Ways of Using Technologies: Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported. (See Understanding accessibility support.)
This conformance requirement is explained below under Understanding Accessibility Support.
5. Non-Interference: If technologies are used in a way that is not accessibility supported, or if they are used in a non-conforming way, then they do not block the ability of users to access the rest of the page. In addition, the Web page as a whole continues to meet the conformance requirements under each of the following conditions:
when any technology that is not relied upon is turned on in a user agent,
when any technology that is not relied upon is turned off in a user agent, and
when any technology that is not relied upon is not supported by a user agent
In addition, the following success criteria apply to all content on the page, including content that is not otherwise relied upon to meet conformance, because failure to meet them could interfere with any use of the page:
1.4.2 - Audio Control,
2.1.2 - No Keyboard Trap,
2.3.1 - Three Flashes or Below Threshold, and
2.2.2 - Pause, Stop, Hide.
This basically says that technologies that are not accessibility supported can be used, as long as all the information is also available using technologies that are accessibility supported and as long as the non-accessibility-supported material does not interfere.
Technologies that are not accessibility supported can be used, or technologies that are accessibility supported can be used in a non conforming manner, as long as all the information is also available using technologies that are accessibility supported, in a manner that does conform, and as long as the non-accessibility-supported material does not interfere.
There are four provisions that particularly deal with issues of interference with use of the page. These four are included in a note here. A note on each of the provisions indicates that these Success Criteria need to be met for all content including content created using technologies that are not accessibility supported.
Example: A Web page incorporates a new interactive graphic technology called "ZAP". Although ZAP is accessibility-supported, the information that is presented in ZAP is also presented on the page in HTML, so ZAP is not relied upon. So, this page would pass conformance requirement #1. However, if the user tries to tab through the ZAP content, the focus drops into the ZAP object and gets stuck there. Once inside, there is nothing the user can do to get the focus back out. So keyboard users cannot use the bottom half of the page. The ZAP content also is continually flashing brightly at different rates and doesn't stop. So, people with attention deficit are distracted and those with photosensitive seizure disorders may have seizures. Conformance requirement #5 prevents situations like these from being possible on a conforming page.
It is not required to make any conformance claim in order to conform. If one does make a claim, however, the rules must be followed.
Sometimes, one may want to make a claim for just the content that was added after a certain date. Or, one may want to claim WCAG 1.0 conformance for content up to a date and WCAG 2.0 for content that was created or modified after that date. There are no prohibitions in WCAG 2.0 to any of these practices as long as it is clear which pages are claiming conformance to which version of WCAG.
Note 1: When talking about technologies that are "relied upon," we're talking about Web content technologies (HTML, CSS, JavaScript, etc.), not user agents (browsers, assistive technologies, etc.).
Note 2: Conformance claims are not usually located on each Web page within the scope of conformance.
When an author makes a decision to use a third party implementation, they should choose products that meet WCAG requirements. If all content on a page, including third party content, meets all WCAG success criteria then the page conforms to WCAG. However, if the page does not conform to WCAG only for reasons that are legitimately outside the author's control then the author can make a claim of partial conformance. It is important to recognize that this is a statement of non-conformance and there are users who may not be able to access some of the content this page.
One reason that content may be outside the author's control is because it is being provided by a third party (blogs, portals, news sites). Web pages may also include content via third party libraries, plugins, or widgets.
Be sure to monitor any content that can change without approval from the web page author, as a page which once conformed may suddenly fail to conform. If it is not possible to monitor and repair the third party content, it is necessary to identify the non-conforming parts of the page for users. If the rest of the web page conforms to WCAG, such a page qualifies for a statement of partial conformance, third party content.
One of the optional components of a conformance claim is "Information about any additional steps taken that go beyond the Success Criteria to enhance accessibility." This can include additional Success Criteria that have been met, advisory techniques that were implemented, information about any additional protocols used to aid access for people with particular disabilities or needs, etc. Any information that would be useful to people in understanding the accessibility of the pages may be included.
The most useful way of attaching conformance claims to content would be to do so in standard machine readable form. When this practice is widespread, search tools or special user agents will be able to make use of this information to find and provide content that is more accessible or so the user agents can adjust to the content. There are a number of metadata based options under development for making claims, and authors and tool developers are encouraged to support them.
In addition, metadata can be used to report conformance to individual Success Criteria once Level A conformance has been achieved.
There are also programmatic reporting formats such as Evaluation and Report Language (EARL) that are being developed that could provide machine readable formats for detailed conformance information. As the reporting formats are formalized and support for them develops, they will be documented here.
Example 1: On 20 September 2009, all Web pages at http://www.example.com conform to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level A conformance.
The documented set of accessibility-supported content technologies relied upon for this claim is a subset of ISA- AsCTset#1-2008 at http://ISA.example.gov/AsCTsets/AS2-2008.
Example 2: (using a regular expression) On 12 August 2009, pages matching the pattern http://www.example.com/(marketing|sales|contact)/.* conform to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level AA conformance.
The technologies that this content "relies upon" is: XHTML 1.0 Transitional, CSS 2.0 and JavaScript 1.2.
Example 3: (using boolean logic) On 6 January 2009, http://example.com/ AND NOT (http://example.com/archive/ OR http://example.com/publications/archive/) conforms to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level AA conformance.
The documented set of accessibility-supported content technologies relied upon for this claim includes XHTML 1.0 and SMIL from ISA- AsCTset#1-2008 at http://ISA.example.gov/AsCTsets/AS2-2008.
Example 1: On 5 May 2009, the page "G7: An Introduction" http://telcor.example.com/nav/G7/intro.html conforms to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level AA conformance.
The following additional Success Criteria have also been met: 1.1.2, 1.2.5, and 1.4.3.
The documented set of accessibility-supported content technologies used for this claim is AsCTset#1-2006 at http://UDLabs.org/AsCTset#1-2006.html.
The technologies that this content "relies upon" is: XHTML 1.0 (Strict), and Real Video.
The technologies that this content "uses but does not rely upon" are: JavaScript 1.2, CSS2.
Example 2: On 21 June 2009, all content beginning with the URI http://example.com/nav and http://example.com/docs conform to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level AAA conformance.
The documented set of accessibility-supported content technologies used for this claim is SMITH- AsCTset#2-2008 at http://smithreports.example.com/AsCTsets/AS2-2008.
The technologies that this content "relies upon" are: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, JPEG, PNG.
The user agents, including assistive technologies, that this content has been tested with can be found at http://example.com/docs/WCAG20/test/technologies.html.
Example 3: On 23 March 2009, all content available on the server at http://www.wondercall.example.com conforms to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Single-A conformance.
The technology that this content "relies upon" is: HTML 4.01.
The technologies that this content "uses but does not rely upon" are: CSS2, and gif.
This content was tested using the following user agents and assistive technologies: Firefox 1.5 on Windows Vista with Screenreader X 4.0, Firefox 1.5 on Windows XP SP 2 with Screenreader X 3.5, IE 6.0 on Windows 2000 SP4 with Screenreader Y 5.0, IE 6.0 on Windows 2000 SP4 with Screenreader Z 2.0, and Firefox 1.5 on Windows XP SP2 with Screenreader X 4.0, Safari 2.0 with OS X 10.4.
First, there are a number of conditions that must be met for a Success Criterion to be included at all. These include:
All Success Criteria must be important access issues for people with disabilities that address problems beyond the usability problems that might be faced by all users. In other words, the access issue must cause a proportionately greater problem for people with disabilities than it causes people without disabilities in order to be considered an accessibility issue (and covered under these accessibility guidelines).
All Success Criteria must also be testable. This is important since otherwise it would not be possible to determine whether a page met or failed to meet the Success Criteria. The Success Criteria can be tested by a combination of machine and human evaluation as long as it is possible to determine whether a Success Criterion has been satisfied with a high level of confidence.
The Success Criteria were assigned to one of the three levels of conformance by the working group after taking into consideration a wide range of interacting issues. Some of the common factors evaluated when setting the level included:
whether the Success Criterion is essential (in other words, if the Success Criterion isn't met, then even assistive technology can't make content accessible)
whether it is possible to satisfy the Success Criterion for all Web sites and types of content that the Success Criteria would apply to (e.g., different topics, types of content, types of Web technology)
whether the Success Criterion requires skills that could reasonably be achieved by the content creators (that is, the knowledge and skill to meet the Success Criteria could be acquired in a week's training or less)
whether the Success Criterion would impose limits on the "look & feel" and/or function of the Web page. (limits on function, presentation, freedom of expression, design or aesthetic that the Success Criteria might place on authors)
whether there are no workarounds if the Success Criterion is not met
Many of the Success Criteria deal with providing accessibility through assistive technologies or special accessibility features in mainstream user agents (for example, a 'show captions' option in a media player). That is, the Success Criteria require that something be done in the Web content that would make it possible for assistive technologies to successfully present the content's information to the user. For example, a picture that you were supposed to click on to go to a topic would not be accessible to a person who was blind unless text alternatives for the picture were provided in a way that user agents including assistive technologies can find and display them. The key here is that the text alternative must be included in a way that user agents including assistive technologies can understand and use – in a way that is "Accessibility Supported."
Another example would be a custom control that is included on a Web page. In this case, a standard user agent would not ordinarily be able to present an alternative to the user. If, however, information about the control including its name, role, value, how to set it etc. are provided in a way that assistive technologies can understand and control them, then users with assistive technologies will be able to use these controls.
When new technologies are introduced, two things must happen in order for people using assistive technologies to be able to access them. First, the technologies must be designed in a way that user agents including assistive technologies could access all the information they need to present the content to the user. Secondly, the user agents and assistive technologies may need to be redesigned or modified to be able to actually work with these new technologies.
"Accessibility Supported" means that both of these have been done and that the technology will work with user agents and assistive technologies.
This topic raises the question of how many or which assistive technologies must support a Web technology in order for that Web technology to be considered "accessibility supported". The WCAG Working group and the W3C do not specify which or how many assistive technologies must support a Web technology in order for it to be classified as accessibility supported. This is a complex topic and one that varies both by environment and by language. There is a need for an external and international dialogue on this topic. Some notes to help in understanding and exploring this topic are:
Accessibility support of Web technologies varies by environment
Web technologies may only need to be supported by those specific user agents and assistive technologies deployed at a company. (These may be older versions of user agents and assistive technologies or the very newest versions).
Content posted to the public Web may need to work with a broader range of user agents and assistive technologies, including older versions.
Accessibility support of Web technologies varies by language (and dialect)
There are different levels of older assistive technologies support in different languages and even countries. Some environments or countries may provide free assistive technologies.
New technologies won't be supported in older assistive technologies
Clearly, a new technology cannot be supported by all past assistive technologies, so requiring that a technology be supported by all assistive technologies is not possible.
Support for a single older assistive technology is usually not sufficient
Support by just one assistive technology (for a given disability) would not usually be enough, especially if most users who need it in order to access content do not have and cannot afford that assistive technology. The exception here would be information distributed to company employees only where they all have one assistive technology (of that type).
Currently assistive technology that is affordable by the general public is often very poor
Creating content that can't be used by the general public with disabilities should be avoided. In many cases, the cost of assistive technologies is too high for users who need it. Also, the capabilities of free or low cost AT is often so poor today that Web content cannot be realistically restricted to this lowest (or even middle) common denominator. This creates a very difficult dilemma that needs to be addressed.
The Working Group, therefore, limited itself to defining what constituted support and defers the judgment of how much, how many, or which AT must support a technology to the community and to entities closer to each situation that set requirements for an organization, purchase, community, etc.
The Working Group encourages more discussion of this topic in the general forum of society since this lack of generally available yet robust assistive technologies is a problem that affects users, technology developers and authors negatively.
Basically, a Web content technology is "accessibility supported" when users' assistive technologies will work with the Web technologies AND when the accessibility features of mainstream technologies will work with the technology. Specifically, to qualify as an accessibility-supported technology, the following must be true for a technology:
supported by users' assistive technologies as well as the accessibility features in browsers and other user agents
To qualify as an accessibility-supported use of a Web content technology (or feature of a technology), both 1 and 2 must be satisfied for a Web content technology (or feature):
The way that the Web content technology is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users' assistive technology in the human language(s) of the content,
AND
The Web content technology must have accessibility-supported user agents that are available to users. This means that at least one of the following four statements is true:
The technology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS);
OR
The technology is supported in a widely-distributed plug-in that is also accessibility supported;
OR
The content is available in a closed environment, such as a university or corporate network, where the user agent required by the technology and used by the organization is also accessibility supported;
OR
The user agent(s) that support the technology are accessibility supported and are available for download or purchase in a way that:
does not cost a person with a disability any more than a person without a disability and
is as easy to find and obtain for a person with a disability as it is for a person without disabilities.
Note 1: The WCAG Working group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a Web technology in order for it to be classified as accessibility supported. (See Level of Assistive Technology Support Needed for "Accessibility Support".)
Note 2: Web technologies can be used in ways that are not accessibility supported as long as they are not relied upon and the page as a whole meets the conformance requirements, including Conformance Requirement 4: Only Accessibility-Supported Ways of Using Technologies and Conformance Requirement 5: Non-Interference, are met.
Note 3: When a Web Technology is used in a way that is "accessibility supported," it does not imply that the entire technology or all uses of the technology are supported. Most technologies, including HTML, lack support for at least one feature or use. Pages conform to WCAG only if the uses of the technology that are accessibility supported can be relied upon to meet WCAG requirements.
Note 4: When citing Web content technologies that have multiple versions, the version(s) supported should be specified.
Note 5: One way for authors to locate uses of a technology that are accessibility supported would be to consult compilations of uses that are documented to be accessibility supported. (See Understanding Accessibility-Supported Web Technology Uses.) Authors, companies, technology vendors, or others may document accessibility-supported ways of using Web content technologies. However, all ways of using technologies in the documentation would need to meet the definition of accessibility-supported Web content technologies above.
Individual authors will not usually be able to do all of the testing necessary to determine which ways of using which Web technologies are actually supported by which versions of assistive technologies and user agents. Authors may therefore rely on publicly documented compilations that document which assistive technologies support which ways of using which Web technologies. By public, we do not mean that the compilation and its documentation are necessarily generated by a public agency, only that they are available to the public. Anyone can create publicly documented compilations of "Web Technology Uses and their Accessibility Support." People may create compilations and give them names that authors can refer to them by. As long as they are publicly documented, authors or customers etc. can easily select uses that meet their needs. Customers or others can pick technologies that fit their environment or language at any point in time and specify those to be used in creating their content. Authors are strongly encouraged to use sources that have an established reputation for accuracy and usefulness. Technology developers are strongly encouraged to provide information about the accessibility support for their technologies. The Working Group anticipates that only documents that provide accurate information and benefit both authors and users will achieve market recognition in the long term.
There is no requirement in WCAG that a publicly documented compilation be used or that only technology uses from such a compilation be used. The publicly documented compilations are described only as a method to make an otherwise critical, but somewhat complicated, aspect of conformance easier for authors who are not themselves experts on assistive technology support (or who just don't have the time to keep up with advances in mainstream and assistive technology support for each other).
Authors, companies or others may wish to create and use their own compilations of accessibility-supported technology uses and this is allowed in meeting WCAG. Customers, companies or others may, however, specify that technology uses from a custom or public compilation be used. See Appendix B Documenting Accessibility Support for Uses of a Web Technology.
Examples of ways in which a conformance claim might document its accessibility support include:
This conformance claim meets the accessibility support requirement based on testing content in language(s) of the content with User Agents A, B, and C, and Assistive Technologies X, Y, and Z. This means that we were able to pass all of the success criteria for level A of WCAG 2.0 using these products.
This conformance claim meets the accessibility support requirement for the language(s) of the content based on the use of techniques and user agent notes documented in Techniques for WCAG 2.0. It is also based on the accessibility support documentation for the technologies (that we relied upon for conformance), which is available in " XYZ Organization's Documentation of Accessibility Support."
This conformance claim meets the accessibility support requirement for the language(s) of the content based on the use of technology Z as documented in "Technology Z accessibility supported techniques for WCAG 2.0."
This conformance claim meets the accessibility support requirement for the language of the content based on the use of Accessibility Guidelines for Technology A and Accessibility Guidelines for Technology B. User agent and assistive technology support information can be found in "Product XYZ Accessibility Support Requirements", which are documented in these guidelines.
Several Success Criteria require that content (or certain aspects of content) can be "programmatically determined." This means that the content is authored in such a way that user agents, including assistive technologies, can access the information.
In order for content created with Web technologies (such as HTML, CSS, PDF, GIF, MPEG, Flash etc.) to be accessible to people with different types of disabilities, it is essential that the technologies used work with the accessibility features of browsers and other user agents, including assistive technologies. In order for something to meet a Success Criterion that requires it to be "programmatically determined," it would need to be implemented using a technology that has assistive technology support.
Content that can be "programmatically determined" can be transformed (by user agents including AT) into different sensory formats (e.g., visual, auditory) or styles of presentation need by individual users. If existing assistive technologies cannot do this, then the information cannot be said to be programmatically determined.
The term was created in order to allow the working group to clearly identify those places where information had to be accessible to assistive technologies (and other user agents acting as accessibility aids) without specifying exactly how this needed to be done. This is important because of the continually changing nature of the technologies. The term allows the guidelines to identify what needs to be "programmatically determined" in order to meet the guidelines, and then have separate documents (the How to Meet, Understanding, and Technique documents), which can be updated over time, list the specific techniques that will work and be sufficient at any point in time based on user agent and assistive technology support.
"Accessibility supported" relates to support by user agents (including assistive technologies) of particular ways of using Web technologies. Uses of Web technologies that are accessibility supported will work with assistive technologies and access features in mainstream user agents (browsers and players etc.).
"Programmatically determined" relates to the information in Web Content. If technologies that are accessibility supported are used properly, then assistive technologies and user agents can access the information in the content (i.e., programmatically determine the information in the content) and present it to the user.
The two concepts work together to ensure that information can be presented to the user by user agents including assistive technologies. Authors must rely only on uses of technologies that are accessibility-supported — and must use them properly in order for the information to be programmatically determinable — and hence presentable, by assistive technologies and user agents to users with disabilities.
Conformance requirement #1 allows non-conforming pages to be included within the scope of conformance as long as they have a "conforming alternate version". The conforming alternative version is defined as:
version that
conforms at the designated level, and
provides all of the same information and functionality in the same human language, and
is as up to date as the non-conforming content, and
for which at least one of the following is true:
the conforming version can be reached from the non-conforming page via an accessibility-supported mechanism, or
the non-conforming version can only be reached from the conforming version, or
the non-conforming version can only be reached from a conforming page that also provides a mechanism to reach the conforming version
Note 1: In this definition, "can only be reached" means that there is some mechanism, such as a conditional redirect, that prevents a user from "reaching" (loading) the non-conforming page unless the user had just come from the conforming version.
Note 2: The alternate version does not need to be matched page for page with the original (e.g., the conforming alternate version may consist of multiple pages).
Note 3: If multiple language versions are available, then conforming alternate versions are required for each language offered.
Note 4: Alternate versions may be provided to accommodate different technology environments or user groups. Each version should be as conformant as possible. One version would need to be fully conformant in order to meet conformance requirement 1.
Note 5: The conforming alternative version does not need to reside within the scope of conformance, or even on the same Web site, as long as it is as freely available as the non-conforming version.
Note 6: Alternate versions should not be confused with supplementary content, which support the original page and enhance comprehension.
Note 7: Setting user preferences within the content to produce a conforming version is an acceptable mechanism for reaching another version as long as the method used to set the preferences is accessibility supported.
This ensures that all of the information and all of the functionality that is on the pages inside of the scope of conformance is available on conforming Web pages.
Why does WCAG permit conforming alternate versions of Web pages to be included in conformance claims? That is, why include pages that do not satisfy the Success Criteria for a conformance level in the scope of conformance or a claim?
Sometimes, pages use technologies that are not yet accessibility supported. When a new technology emerges, assistive technology support may lag behind, or may only be available to some target audiences. So authors may not be able to rely on the new technology for all users. However, there may be other benefits to using the new technology, e.g., better performance, a wider range of modalities available, etc. The alternate version requirement allows authors to include such Web pages in their Web site by providing an accessible alternative page in technologies that are accessibility supported. Users for whom the new technology is adequately supported get the benefits of the new version. Authors who look ahead to future accessibility support can satisfy the Success Criteria now with the alternate version page, and also work with the other page to build in future access when assistive technology (AT) support is available.
For a variety of reasons, it may not be possible to modify some content on a Web page. For instance,
It may be critical to include an exact visual copy of a document for legal or historical reasons
The Web page may be included in a site but the site owner may not have the legal rights to modify the content on the original page
The company may not legally be able to remove, or alter in any way, something that was previously posted.
An author may not have permission to alter a document from another department, agency, or company
Sometimes, the best experience for users with certain types of disabilities is provided by tailoring a Web page specifically to accommodate that disability. In such a situation, it may not be possible or practical to make the Web page accommodate all disabilities by satisfying all of the Success Criteria. The alternate versions requirement permits such specialized pages to be included within a conformance claim as long as there is a fully conformant 'alternate version' page.
Many sites which are committed to accessibility have large quantities of legacy documents. While the information has been made available in accessible formats, there would be significant institutional resistance and procedural obstacles to removing these files en mass. Some organizations, especially governmental bodies, give precedence to traditional print-oriented processes. Even as these organizations have adapted to Internet publishing and embraced the need for accessible formats, they still retain a paper mindset and often insist on formats designed for hard copy as the "primary" version (even for documents that are only ever "published" electronically). Although the Working Group feels these approaches should be deprecated it does not feel they can be forbidden so long as accessible versions are readily available.
A concern when permitting Web pages that do not satisfy the Success Criteria is that people with disabilities will encounter these non-conforming pages, not be able to access their content, and not be able to find the “conforming alternate version." A key part of the Alternate Versions provision, therefore, is the ability to find the conforming page (the alternate version) from the non-conforming page when it is encountered. The conformance requirement that permits alternate pages, therefore, also requires a way for users to find the accessible version among the alternate versions.
Note that providing an alternate version is a fallback option for conformance to WCAG and the preferred method of conformance is to make all content directly accessible.
The most important part of providing a conforming alternate version is providing a mechanism to find it from the non-conforming version. A number of different methods for doing this have been identified since particular techniques may not always be possible for specific technologies or situations. For example, if the author has control of the server there are some powerful techniques that will allow users to always have the choice up front. In many cases however the author may not have control of the services on their Web server. In these cases other techniques are provided. A link on the non-conforming page is another powerful technique but not all non-conforming technologies support hypertext links.
Below are the techniques that have been identified to date. We expect that additional techniques will also be developed over time and they will be added here as they arise and the support for these approaches by user agents including assistive technologies can be demonstrated. For example a developer of a new technology that some assistive technologies cannot access might build in a feature that would allow those technologies to automatically present a link to users that could take them to an alternate version.
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. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Providing reciprocal links between conforming and non-conforming versions (future link)
Excluding non-conforming content from search results (future link)
Using content negotiation (future link)
Not displaying content that relies on technologies that are not accessibility-supported when the technology is turned off or not supported. (future link)
Using metadata to allow location of a conforming alternative version from the URI of a non-conforming page (future link)
An intranet site with multiple versions.
A large company was concerned that the use of emerging Web technologies on an intranet site might limit their ability to address the needs of diverse office locations that have different technology bases and individual employees who use a wide variety of user agents and assistive technologies. To address these concerns, the company created an alternate version of the content that met all Level A Success Criteria using a more limited set of uses of accessibility-supported content technologies. The two versions link to each other.
An informational site ensuring backward compatibility.
An information site covers a wide variety of subjects and wants to enable visitors to quickly find the topics they are looking for. To do this, the site has implemented an interactive menu system that is only supported in the most recent version of two popular user agents. To ensure that visitors who do not use these specific user agents are still able to effectively use the site, a navigation mechanism that does not depend on the interactive menu system is presented to user agents that do not support the newer technology.
The definition of a Web Page is:
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 URI 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 around in 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. This might be a single-page Web site or just one page within a Web site.
It is important to note that, in this standard, the term "Web page" includes much more than static HTML pages. The term 'Web Page' was used in these guidelines to allow the guidelines to be more understandable. But the term has grown in meaning with advancing technologies to encompass a wide range of technologies, many of which are not at all 'page-like'. It also includes the increasingly dynamic Web pages that are emerging on the Web, including "pages" that can present entire virtual interactive communities. For example, the term "Web page" would include an immersive interactive movie-like experience that you find at a single URI.
A text alternative is text that is used in place of non-text content for those who cannot view the non-text content. Non-text content includes such things as pictures, charts, applets, audio files, etc. People who cannot see for example would not be able to see information presented in a picture or chart. A text alternative is therefore provided that allows the user to be able to convert the information (the text) into speech. In the future, having the information in text also makes it possible to translate the information into sign language, into pictures, or into a simpler form of writing.
In order for people with disabilities to be able to use this text - the text must be "programmatically determinable." This means that the text must be able to be read and used by the assistive technologies (and the accessibility features in browsers) that people with disabilities use.
It must also be possible for people using assistive technologies to find these text alternatives when they encounter non-text content that they cannot use. To accomplish this, we say that the text must be "programmatically associated" with the non-text content. This means that the user must be able to use their assistive technology to find the alternative text (that they can use) when they land on the non-text content (that they can't use).
The following examples show how to reference WCAG 2.0 in various situations. For additional guidance, see Referencing and Linking to WAI Guidelines and Technical Documents.
Please note that the following language for referencing WCAG 2.0 can be inserted into your own documents.
When referencing WCAG 2.0 in an informational fashion, the following format can be used.
Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year (http://www.w3.org/TR/200X/REC-WCAG20-20081211/, Latest version at http://www.w3.org/TR/WCAG20/)
When referencing WCAG 2.0 from within a should statement in a standard (or advisory statement in a regulation), then the full WCAG 2.0 should be referenced. This would mean that all three levels of WCAG 2.0 should be considered but that none are required. The format for referencing WCAG 2.0 from a "should" statement therefore, is:
Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year. (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)
When citing WCAG 2.0 as part of a requirement (e.g., a shall or must statement in a standard or regulation), the reference must include the specific parts of WCAG 2.0 that are intended to be required. When referencing WCAG 2.0 in this manner, the following rules apply:
Conformance at any level of WCAG 2.0 requires that all of the Level A Success Criteria be met. References to WCAG 2.0 conformance cannot be for any subset of Level A.
Beyond Level A, a "shall or must" reference may include any subset of provisions in Levels AA and AAA. For example, "all of Level A and [some specific list of Success Criteria in Level AA and Level AAA]" be met.
If Level AA conformance to WCAG 2.0 is specified, then all Level A and all Level AA Success Criteria must be met.
If Level AAA conformance to WCAG 2.0 is specified, then all Level A, all Level AA, and all Level AAA Success Criteria must be met.
Note 1: It is not recommended that Level AAA conformance ever be required for entire sites as a general policy because it is not possible to satisfy all Level AAA Success Criteria for some content.
Note 2: The sets of Success Criteria defined in WCAG are interdependent and individual Success Criteria rely on each other's definitions in ways which may not be immediately obvious to the reader. Any set of Success Criteria must include all of the Level A provisions.
To cite only the Level A Success Criteria (Single-A conformance):
Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria. (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)
To cite the Levels A and AA Success Criteria (Double-A conformance):
Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level A & Level AA Success Criteria. (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)
To cite Level A Success Criteria and selected Success Criteria from Level AA and Level AAA:
Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria plus Success Criteria 1.x.x, 2.y.y, … 3.z.z. (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)
Example of use of a WCAG reference in a "shall or must" statement.
All Web content on publicly available Web sites shall conform to Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria plus Success Criteria 1.2.3, 2.4.5-6, 3.1.2 (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)
Techniques, which are listed in Understanding WCAG 2.0 and described in other supporting documents, are not part of the normative WCAG 2.0 Recommendation and should not be cited using the citation for the WCAG 2.0 Recommendation itself. References to techniques in support documents should be cited separately.
Techniques can be cited based on the individual Technique document or on the master WCAG 2.0 Techniques document. For example, the technique "Using alt attributes on img elements" could be cited as
"Using alt attributes on img elements," W3C World Wide Web Consortium Note. (URI: {URI of technique})
oder
W3C World Wide Web Consortium (200x): WCAG2.0 HTML Techniques (URI: {URI of HTML Techniques})
Techniques are not designed to be referenced as "required" from any standard or regulation.Standards and regulations should not make any specific technique mandatory, though they may choose to recommend techniques.
The documentation of accessibility support for uses of a Web technology provides the information needed to determine whether it is possible to satisfy the WCAG 2.0 Success Criteria for a particular environment.
Accessibility Support documentation for uses of a Web technology includes the following information:
The version or versions of the technology
For each user agent or plug-in that supports this version of the technology:
The version of the user agent or plug-in, including the operating system or platform
Ways of using the technology that are supported by the user agent; ideally, there are ways to meet all of the success criteria, but exceptions should be noted.
Known limitations of the user agent support for uses of the technology to meet Success Criteria
For each assistive technology that supports the Web technology:
The version of the assistive technology, including the operating system or platform
For each host user agent that is supported by this version of the assistive technology:
Ways of using the technology supported by the assistive technology for this user agent
Known limitations in the support of uses of the technology to meet success criteria when using the assistive technology with this user agent
Target environments are defined by the user agents and assistive technologies available to its users. Documentation of accessibility support involves detailed understanding of the ways to use functionality of a technology to meet success criteria, and also of user agents and assistive technology. Because of this, vendors and developers of Web technologies and user agents are encouraged to provide this information about the accessibility support of their products. Similarly, developers and vendors of assistive technology are encouraged to provide this information about the ways to use Web technologies that are supported by their products. Authors should need to document the accessibility supported ways to use a technology only when there is not reliable documentation available from vendors or testing groups for those uses.
For a controlled environment, such as a corporate workplace, the user agents and assistive technologies available may be a specific set of versions of user agents on a specific set of platforms. To determine whether uses of a Web technology are accessibility supported in a target environment, an author checks that the user agents and assistive technologies available are in the set of supported user agents and assistive technologies listed for those uses in the Accessibility Support documentation.
For a target environment like the Internet, authors may need to consider a much larger set of user agents, including older versions, and on a wider variety of platforms.
Environments that use different natural languages are different target environments. For example, the accessibility-supported ways of using technologies for an English language environment may differ from those for an Arabic language environment, since there may be different user agents and assistive technologies that support these languages.
The documentation includes version-specific information about all the assistive technologies and all the user agents and the ways that they interact with one another. If support in these user agents is similar, it will be straightforward for an author to decide if a documented way of using a technology is accessibility supported. If the uses supported are different in different versions, authors can only rely on the uses that are supported in the versions available to their users in determining accessibility support.
If a way of using a technology is not relied upon for conformance, the absence of accessibility support for that use does not prevent conformance of the Web page. So if the unsupported use does not occur in the content, or if there is a conforming version of that content available, the Web page still conforms. For instance, lack of accessibility support for interactive controls in a Web technology would not prevent uses of the Web technology for non-interactive content that are accessibility supported.
This section discusses metadata techniques that can be employed to satisfy WCAG 2.0 Success Criteria. For more information about metadata see resources below.
At its most basic level, metadata is essentially 'data about data' and is used to both describe and find resources.
Metadata is a powerful tool that can be used for describing Web pages and accessible components of Web pages as well as associating alternate versions of Web content to each other. These descriptions in turn allows users to locate specific information they need or prefer.
In conjunction with WCAG, metadata can play a number of roles including:
Metadata can be used to associate conforming alternate versions of Web pages with Web pages which do not conform, in order to allow users to find the conforming alternate version when they land on a non-conforming page that they cannot use.
Metadata can be used to locate and also to describe alternate pages where there are multiple versions of a page which have been developed, especially where the alternate pages are optimized for individuals with different disabilities. The user can use the metadata both to locate the alternate versions and to identify characteristics of the versions, so that they can find the one that best meets their needs.
In addition to being used for whole pages (as in #1 and #2 above), metadata can be used to describe alternate versions of subcomponents of a page. Again, the metadata can be used to find alternate versions of a Web page component as well as to get descriptions of the alternate versions ( if there are several) in order to determine which one would best meet the user's needs.
Metadata descriptions often provide values from defined, agreed vocabularies such as the resource's subject matter or its date of publication, and are machine readable - software that understands the metadata scheme in use can do useful tasks not feasible otherwise. Typically, an object having metadata may have one or more such metadata descriptions.
Well-known specifications (schemas) for metadata include:
There are some tools available to provide resource descriptions, or they can be provided manually. The more easily the metadata can be created and collected at point of creation of a resource or at point of publication, the more efficient the process and the more likely it is to take place.
Some examples include:
Accessibility metadata implementations include:
This publication has been funded in part with U.S. Federal funds from the Department of Education, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067 and currently under contract number HHSP23301500054C. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.
Additional information about participation in the Web Content Accessibility Guidelines Working Group (WCAG WG) can be found on the Working Group home page.
Paul Adam (Deque)
Kathleen Anderson
Jon Avila (SSB Bart Group)
Bruce Bailey (U.S. Access Board)
Laura Carlson
Louis Cheng (Google)
Michael Cooper (W3C)
Wayne Dick
Eric Eggert (W3C)
Michael Elledge
Detlev Fischer
John Foliot (Deque)
Loretta Guarino Reid (Google)
Jon Gunderson
Katie Haritos-Shea
Marc Johlic (IBM)
Barry Johnson (Deque)
Andrew Kirkpatrick (Adobe)
David MacDonald
Erich Manser (IBM)
James Nurthen (Oracle)
Joshue O Connor
Jan Richards
Alan Smith
Adam Solomon
Makoto Ueki
Gregg Vanderheiden
Kathleen Wahlbin
Can Wang (Zhejiang University)
Jason White (Educational Testing Service)
Kenny Zhang (W3C)
Shadi Abou-Zahra, Jim Allan, Jenae Andershonis, Wilhelm Joys Andersen, Andrew Arch, Avi Arditti, Aries Arditi, Jon Avila, Mark Barratt, Mike Barta, Sandy Bartell, Kynn Bartlett, Chris Beer, Charles Belov, Marco Bertoni, Harvey Bingham, Chris Blouch, Paul Bohman, Frederick Boland, Denis Boudreau, Patrice Bourlon, Judy Brewer, Andy Brown, Dick Brown, Doyle Burnett, Raven Calais, Ben Caldwell, Alastair Campbell, Laura Carlson, Tomas Caspers, Roberto Castaldo, Sofia Celic-Li, Sambhavi Chandrashekar, Mike Cherim, Jonathan Chetwynd, Wendy Chisholm, Alan Chuter, David M Clark, Joe Clark, Darcy Clarke, James Coltham, Vivienne Conway, Earl Cousins, James Craig, Tom Croucher, Pierce Crowell, Nir Dagan, Daniel Dardailler, Geoff Deering, Sébastien Delorme, Pete DeVasto, Wayne Dick, Iyad Abu Doush, Sylvie Duchateau, Cherie Eckholm, Roberto Ellero, Don Evans, Gavin Evans, Neal Ewers, Steve Faulkner, Bengt Farre, Lainey Feingold, Wilco Fiers, Michel Fitos, Alan J. Flavell, Nikolaos Floratos, Kentarou Fukuda, Miguel Garcia, P.J. Gardner, Alistair Garrison, Greg Gay, Becky Gibson, Al Gilman, Kerstin Goldsmith, Michael Grade, Karl Groves, Jon Gunderson, Emmanuelle Gutiérrez y Restrepo, Brian Hardy, Eric Hansen, Benjamin Hawkes-Lewis, Sean Hayes, Shawn Henry, Hans Hillen, Donovan Hipke, Bjoern Hoehrmann, Allen Hoffman, Chris Hofstader, Yvette Hoitink, Martijn Houtepen, Carlos Iglesias, Jonas Jacek, Ian Jacobs, Phill Jenkins, Duff Johnson, Jyotsna Kaki, Shilpi Kapoor, Leonard R. Kasday, Kazuhito Kidachi, Ken Kipness, John Kirkwood, Jason Kiss, Johannes Koch, Marja-Riitta Koivunen, Maureen Kraft, Preety Kumar, Kristjan Kure, Andrew LaHart, Gez Lemon, Chuck Letourneau, Aurélien Levy, Harry Loots, Scott Luebking, Tim Lacy, Jim Ley, Alex Li, William Loughborough, Greg Lowney, N Maffeo, Mark Magennis, Kapsi Maria, Luca Mascaro, Matt May, Sheena McCullagh, Liam McGee, Jens Meiert, Niqui Merret, Jonathan Metz, Alessandro Miele, Steven Miller, Mathew J Mirabella, Matt May, Marti McCuller, Sorcha Moore, Mary Jo Mueller, Charles F. Munat, Robert Neff, Charles Nevile, Liddy Nevile, Dylan Nicholson, Bruno von Niman, Tim Noonan, Sebastiano Nutarelli, Graham Oliver, Sean B. Palmer, Sailesh Panchang, Devarshi Pant, Nigel Peck, Anne Pemberton, David Poehlman, Ian Pouncey, Charles Pritchard, Kerstin Probiesch, W Reagan, Adam Victor Reed, Chris Reeve, Chris Ridpath, Lee Roberts, Mark Rogers, Raph de Rooij, Gregory J. Rosmaita, Matthew Ross, Sharron Rush, Joel Sanda, Janina Sajka, Roberto Scano, Gordon Schantz, Tim van Schie, Wolf Schmidt, Stefan Schnabel, Lisa Seeman, Cynthia Shelly, Glenda Sims, John Slatin, Becky Smith, Jared Smith, Andi Snow-Weaver, Neil Soiffer, Jeanne Spellman, Mike Squillace, Michael Stenitzer, Diane Stottlemyer, Christophe Strobbe, Sarah J Swierenga, Jim Thatcher, Terry Thompson, Justin Thorp, David Todd, Mary Utt, Jean Vanderdonckt, Carlos A Velasco, Eric Velleman, Gijs Veyfeyken, Dena Wainwright, Paul Walsch, Daman Wandke, Richard Warren, Elle Waters, Takayuki Watanabe, Léonie Watson, Gian Wild, David Wooley, Wu Wei, Leona Zumbo.