The presentation of this document has been augmented to identify changes from a previous version. Three kinds of changes are highlighted: [begin add] new, added text [end add], [begin change] changed text [end change], and [begin delete] deleted text [end delete].
[contents]
This document is also available in these non-normative formats:
Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document, "Understanding WCAG 2.0," is an essential guide to understanding and using Web Content Accessibility Guidelines 2.0 [WCAG20]. It is part of a series of documents that support WCAG 2.0. Please note that the contents of this document are informative (they provide guidance), and not normative (they do not set requirements for conforming to WCAG 2.0).
WCAG 2.0 establishes a set of success criteria to define conformance to the WCAG 2.0 Guidelines. A success criterion is a testable statement that will be either true or false when applied to specific Web content. "Understanding WCAG 2.0" provides detailed information about each success criterion, including its intent, the key terms that are used in the success criterion, and how the success criteria in WCAG 2.0 help people with different types of disabilities. This document also provides examples of Web content that meet the success criterion using various Web technologies (for instance, HTML, CSS, XML), and common examples of Web content that does not meet the success criterion.
This document indicates specific techniques to meet each success criterion. Details for how to implement each technique are available in Techniques and Failures for WCAG 2.0, but "Understanding WCAG 2.0" provides the information about the relationship of each technique to the success criteria. Techniques are categorized by the level of support they provide for the success criteria. "Sufficient techniques" are sufficient to meet a particular success criterion (either by themselves or in combination with other techniques), while other techniques are advisory and therefore optional. None of the techniques are required to meet WCAG 2.0, although some may be the only known method if a particular technology is used. "Advisory techniques" are not sufficient to meet the success criteria on their own (because they are not testable or provide incomplete support) but it is encouraged that authors follow them when possible to provide enhanced accessibility. Another support category is "Failure techniques", which describe authoring practices known to cause Web content not to conform to WCAG 2.0. Although failure techniques provide advisory information about certain authoring practices, authors must avoid those practices in order to meet the WCAG 2.0 success criteria.
This document is part of a series of documents published by the W3C Web Accessibility Initiative (WAI) to support WCAG 2.0.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This draft is a Public Working Draft of "Understanding WCAG 2.0." The Web Content Accessibility Guidelines Working Group considers this document to be important for understanding the success criteria in the Web Content Accessibility Guidelines 2.0 (WCAG 2.0), and encourages feedback on this draft.
This version of Understanding WCAG 2.0 includes clarifications about success criteria whose purpose and implementation were not clearly understandable in the previous Working Draft. New success criteria are supported by new sections in this document. In many cases, the techniques applicable to success criteria changed and reference to those techniques from this document updated accordingly.
The WCAG Working Group has not yet had time to list all available techniques for conforming to WCAG 2.0, but intends to make the techniques as comprehensive as possible. Therefore, the WCAG Working Group welcomes contributions of additional techniques for consideration for inclusion in this document. Please submit these in the same manner as other comments as described below.
Please note that the format of this document is still in transition; the WCAG Working Group plans to create separate files for each success criterion, and to link to relevant techniques providing sample code. The WCAG Working Group is also developing a navigation structure that will make it easy to move between the various documents that support WCAG 2.0 documents.
The WCAG Working Group seeks feedback on the following questions:
In general, does this document help you understand what WCAG 2.0 is, and how to use it?
Does this document adequately clarify each success criterion? If not, what additional clarification is needed?
Comments on this working draft are due on or before 29 June 2007. The Working Group requests that comments be made using the provided online or downloadable comment form. If this is not possible, comments can also be sent to public-comments-wcag20@w3.org. The archives for the public comments list are publicly available. Archives of the WCAG WG mailing list discussions are also publicly available.
This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals of the WCAG Working Group are discussed in the WCAG Working Group charter. The WCAG Working Group is part of the WAI Technical Activity.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This document will be published as a W3C Working Group Note at the time that WCAG 2.0 becomes a W3C Recommendation.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Understanding WCAG 2.0 is an essential guide to understanding and using "Web Content Accessibility Guidelines 2.0" [WCAG20] Although the definition and requirements for WCAG 2.0 can all be found in the WCAG 2.0 document itself, the concepts and provisions may be new to some people. Understanding WCAG 2.0 provides an extended commentary on each guideline and each success criterion to help readers better understand the intent and how the guidelines and success criteria work together. It also provides examples of techniques or combinations of techniques that the Working Group has identified as being sufficient to meet each success criterion. Links are then provided to write-ups for each of the techniques.
Editorial Note: Where the committee has not yet been able to write up the description of a techniques, the techniques are listed with "(future link)" following their title.
This is not an introductory document. It is a detailed technical description of the guidelines and their success criteria. For an introduction to WCAG 2.0 and the complete set of documents associated with the guidelines, see Overview of Web Content Accessibility Guidelines (WCAG) 2.0 Documents. [LC-1016]
[end add]Understanding WCAG 2.0 is organized by guideline. There is an Understanding Guideline X.X section for each guideline. The intent and any advisory techniques that are related to the guideline but not specifically related to any of its success criteria are listed there as well.
The Understanding Guidelines X.X section is then followed by a How to Meet Success Criterion X.X.X section for each success criterion of that guideline. These How to Meet sections each contain:
The success criterion as it appears in WCAG 2.0
Key terms for this success criterion (taken from the WCAG 2.0 Glossary)
Intent of the success criterion
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. [begin add]Use of advisory techniques does not impact the level of conformance claimed.[end add]
Benefits (how the success criterion helps people with disabilities)
Examples
[begin add]Related Resources[end add]
Links are provided from each Guideline in WCAG 2.0 directly to each Understanding Guideline X.X in this document. Similarly, there is a link from each success criterion in WCAG 2.0 to the How to Meet Success Criterion X.X.X section in this document.
For information about individual techniques, follow the links throughout this document to the techniques of interest in the Techniques for WCAG 2.0 document.
The guidelines and success criteria are organized around the following four principles. These four principles lay the foundation necessary for anyone to access and use Web content. Anyone who wants to use the Web must have content that is:
Perceivable - Information and user interface components must be perceivable by users
This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses)
Operable - User interface components must be operable by users
This means that users must be able to operate the interface (the interface cannot require interaction that the user can not perform)
Understandable - Information and operation of user interface must be understandable by users
This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)
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.
The purpose of this guideline is to ensure that all non-text content is also available in text. "Text" refers to electronic text, not an image of text. Electronic text has the unique advantage that it can be rendered visually, auditorially, tactilely, or by any combination. As a result, information rendered in electronic text can be presented in whatever form best meets the needs of the user. It can also be easily enlarged, spoken in a voice that is easy to understand, or rendered in whatever tactile form best meets the needs of a user.
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.1.1 All non-text content has a text alternative that presents equivalent information, except for the situations listed below[begin delete]Except for the situations listed below, a text alternative that presents equivalent information is provided for all non-text content[end delete]. [LC-956] [LC-1281] [LC-1524] (Level A)
[end change]Controls-Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (See also Guideline 4.1.) [LC-738]
Media, Test, Sensory: If non-text content is multimedia [begin change],[end change] live audio-only or live video-only content[begin change],[end change] a [begin change]test or exercise that must be presented in non-text format [LC-1506] [end change] [begin change],[end change] or primarily intended to create a specific sensory experience [begin change],[end change] then text alternatives at least identify the non-text content with a descriptive text label. (For multimedia, see also Guideline 1.2.) [LC-801]
CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, [begin add]then [LC-738] [LC-1282] [end add] [begin change]text alternatives that identify and describe the purpose of the non-text content are provided and alternative[end change] forms [begin add]in different modalities are[end add] provided to accommodate [begin change]different [LC-800] [LC-1155] [end change] disabilities.
Decoration, Formatting, Invisible: If non-text content is pure decoration, or used only for visual formatting, or if it is not presented to users, [begin add]then [LC-738] [end add] it is implemented such that it can be ignored by assistive technology.
any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language [LC-954]
[end add]content that is not represented by a Unicode character or sequence of Unicode characters when rendered in a user agent according to the formal specification of the content type
[end delete]programmatically determined text that is used in place of non-text content, or text that is used in addition to non-text content and referred to from the programmatically determined text
Example: An image of a chart is described in text in the paragraph after the chart. The short text-alternative for the chart indicates that a description follows. [LC-1507]
text by which software can identify a component within Web content to the user
Note 1: The name may be hidden and only exposed by assistive technology, whereas a label is presented [begin add]to all users.[end add] [begin delete]even without Assistive technology (as used in this document 732 ) [end delete] In many (but not all) cases, the label [begin add]and the name are the same.[end add] [begin delete]is a display of the name[end delete]
Note 2: This is unrelated to the name attribute in HTML.
[end add]audio or video synchronized with another [begin delete]type of media[end delete] [begin add]format for presenting information[end add] and/or with time-based interactive components [LC-1499]
A time-based live presentation that contains only audio (no video and no interaction)
A time-based live presentation that contains only video (no audio and no interaction)
would be invalid if presented in text [LC-1506]
Example: Color blindness test, hearing test, vision exercise, spelling test.
a sensory experience that is not purely decorative and does not primarily convey important information or perform a function
Example: [begin add]Examples include a performance of a flute solo, works of visual art etc. [LC-1189] [end add]
text [begin delete], image, or sound[end delete] [begin add]or other component with a text alternative [end add] that is presented to a user to identify a component within Web content
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]
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 user agent that [begin add]both[end add]:
provides services to meet the requirements of users with disabilities that go beyond those offered by the mainstream user agents. Such services include alternative presentations (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible)[begin add], and[end add] [LC-1178]
[end change]usually relies on services (such as retrieving Web content and parsing markup) provided by one or more other mainstream user agents. Assistive technologies communicate data and messages with mainstream user agents by using and monitoring APIs
Note 1: [begin add]In this definition, user agents are user agents in the general sense of the term. That is, any software that retrieves and [begin change]presents[end change] Web content for users. The mainstream user agent may provide important services to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles. [LC-732] [end add]
Note 2: [begin add]Mainstream user agents may also provide services directly that meet the requirements of users with disabilities. [LC-732] [end add]
Note 3: This definition is based on User Agent Accessibility Guidelines 1.0 Glossary.
Example: Examples of assistive technologies that are important in the context of this document include the following:
screen magnifiers, [begin change]and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc in order [LC-604] [end change] improve the visual readability of rendered text and images;
screen readers, which are used by people who are blind [begin change]to read textual information through synthesized speech or braille[end change];
text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
[end add]voice recognition software, which may be used by people who have some physical disabilities;
alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard;
alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.
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.
Non-text content can take a number of forms, and this success criterion specifies how each is to be handled.
For non-text content that [begin change]is not covered by one of the other situations listed below[end change], such as charts, diagrams, audio recordings, pictures, and animations, text alternatives can make the same information available in a form that can be rendered through any modality (for example, visual, auditory or tactile). Short and long text alternatives can be used as needed to convey the information in the non-text content. Note that pre-recorded audio-only and pre-recorded video-only files are covered here. Live-audio-only and Live-video-only files are covered below (see 3rd paragraph following this one).
For non-text content that is a control or accepts user input , such as images used as submit buttons or complex animations, a name is provided to describe the purpose of the non-text content so that the person at least knows what the non-text content is and why it is there.
[end change]Non-text content that is multimedia is made accessible through guideline 1.2. However it is important that users know what it is when they encounter it on a page so they can decide what action if any they want to take with it. A text alternative that describes the multimedia and/or gives its title is therefore provided.
Live Audio-only and live video-only files - It is much more difficult to provide text alternatives that convey the same information as live audio-only and live video-only content. For these types of non-text content, text alternatives provide a descriptive label.
Sometimes a test or exercise must use a particular sense. Audio or visual information is provided that cannot be changed to text because the test or exercise must be conducted using that sense. For example, a hearing test would be invalid if a text alternative were provided. A visual skill development exercise would similarly make no sense in text form. And a spelling test with text alternatives would not be very effective. For these cases, text alternatives should be provided to describe the purpose of the non-text content; of course, the text alternatives would not provide the same information needed to pass the test.
Sometimes content is primarily intended to create a specific sensory experience that words cannot fully capture. Examples include a symphony performance, works of visual art etc. [begin change]For such content, text alternatives at least identify the non-text content with a descriptive label and where possible, some descriptive text. If the reason for including the content in the page is known and can be described it is helpful to include that information. [LC-787] [end change]
Sometimes there are non-text exercises that are used to prove you are human. To avoid spam robots and other software from gaining access to a site a device called a CAPTCHA is used. These usually involve visual or auditory tasks that are beyond the current capabilities of web robots. Providing a text alternative to them would however make them operable by Robots, thus defeating their purpose. In this case a text alternative would describe the purpose of the CAPTCHA, and alternate forms using different modalities would be provided to address the needs of people with different disabilities.
[end add]Sometimes there is non-text content that really is not meant to be seen or understood by the user. Transparent images used to move text over on a page; a one pixel transparent "web-bug" that tells the author when the page is viewed; and a swirl in the corner that conveys no information but just fills up a blank space to create an aesthetic effect are all examples of this. Putting alternative text on such items just distracts people using screen readers from the content on the page. Not marking the content in any way, though, leaves users guessing what the non-text content is and what information they may have missed (even though they have not missed anything in reality). This type of non-text content, therefore, is marked or implemented in a way that assistive technologies (AT) will ignore it and not present anything to the user.
This success criterion helps people who have difficulty perceiving visual content. Assistive technology can read text alternatives aloud, present them visually, or convert them to braille.
[end change]Text alternatives may help some people who have difficulty understanding the meaning of photographs, drawings, and other images (e.g. line drawings, graphic designs, paintings, three-dimensional representations), graphs, charts, animations, etc.
[end change]People who are deaf, are hard of hearing, or who are having trouble understanding audio information for any reason can read the text presentation. Research is ongoing regarding automatic translation of text into sign language. [LC-790]
People who are deaf-blind can read the text in braille.
Additionally, text alternatives support the ability to search for non-text content and to repurpose content in a variety of ways.
Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.
Instructions: Select the situation below that matches your content. Each situation includes techniques or combinations of techniques that are known and documented to be sufficient for that situation.
G94: Providing short text alternative for non-text content that serves the same purpose and presents the same information as the non-text content using a short text alternative technique listed below
G95: Providing short text alternatives that provide a brief description of the non-text content using a short text alternative technique listed below AND one of the following techniques for long description:
G92: Providing long description for non-text content that serves the same purpose and presents the same information using a long text alternative technique listed below
G82: Providing a text alternative that identifies the purpose of the non-text content using a short text alternative technique listed below
Using HTML form controls and links (future link)
[end add]H65: Using the title attribute to identify form controls when the label element cannot be used (HTML)
[end add]Using (X)HTML according to spec (future link)
[end add]Providing a descriptive label using a short text alternative technique listed below
G68: Providing a descriptive label that describes the purpose of live audio-only and live video-only content using a short text alternative technique listed below
G100: Providing the accepted name or a descriptive name of the non-text content using a short text alternative technique listed below
Implementing or marking the non-text content so that it will be ignored by assistive technology using one of the technology-specific techniques listed below
H36: Using alt attributes on images used as submit buttons (HTML)
H24: Providing text alternatives for the area elements of image maps (HTML)
[begin add]Providing text alternatives for strings where look-alike glyphs are used in place of letters (e.g. leetspeak) (future link) [LC-796] [end add]
[begin add]Providing text alternatives for ASCII art (future link) [LC-796] [end add]
The following are common mistakes that are considered failures of Success Criterion 1.1.1 by the WCAG Working Group.
F3: Failure of SC 1.1.1 due to using CSS to include images that convey important information
[begin add] F71: Failure of SC 1.1.1 due to using text look-alikes to represent text without providing a text alternative [LC-796] [end add]
[begin add] F72: Failure of SC 1.1.1 due to using ASCII art without providing a text alternative [LC-796] [end add]
[begin add]Failure of SC 1.1.1 due to providing a title attribute without also providing a non-null alt attribute (future link) [LC-850] [end add]
Although not required for conformance, the following additional 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)
[begin change]Linking to textual information that provides comparable information (e.g. for a traffic Webcam, a municipality could provide a link to the text traffic report.) (future link) [LC-788] [end change]
Providing a transcript of a live audio only presentation after the fact (future link)
Writing for browsers that do not support frame (future link)
Providing alternative content for iframe (future link)
Providing text and non-text alternatives for object (future link)
Not using long descriptions for iframe (future link)
Providing redundant text links for client-side image maps (future link)
A data chart
A bar chart compares how many widgets were sold in June, July, and August. The short label says, "Figure one - Sales in June, July and August." The longer description identifies the type of chart, provides a high-level summary of the data [begin add], trends and implications[end add] comparable to those available from the chart[begin delete], and provides the data in a table[end delete]. [begin add]Where possible and practical, the actual data is provided in a table. [LC-789] [end add]
An audio recording of a speech (no video)
The link to an audio clip says, "Chairman's speech to the assembly." A link to a text transcript is provided immediately after the link to the audio clip.
An animation that illustrates how a car engine works
An animation shows how a car engine works. There is no audio and the animation is part of a tutorial that describes how an engine works. [begin change]Since the text of the tutorial already provides a full explanation, the text alternative has a brief description of the image and refers to the tutorial text for more information. [LC-1074] [end change]
A traffic Web camera
A Web site allows users to select from a variety of Web cameras positioned throughout a major city. After a camera is selected, the image updates every two minutes. A short text alternative identifies the Web camera as "traffic Web camera." The site also provides a table of travel times for each of the routes covered by the Web cameras. The table is also updated every two minutes.
A photograph of an historic event in a news story
A photograph of two world leaders shaking hands accompanies a news story about an international summit meeting. The text alternative says, "President X of Country X shakes hands with Prime Minister Y of country Y."
A photograph of a historic event in content discussing diplomatic relationships
The same image is used in a different context intended to explain nuances in diplomatic encounters. The image of the president shaking hands with the prime minister appears on a Web site discussing intricate diplomatic relationships. The first text alternative reads, "President X of country X shakes hands with Prime Minister Y of country Y on January 2, 2009." An additional text alternative describes the room where the leaders are standing as well as the expressions on the leaders' faces, and identifies the other people in the room. The additional description might be included on the same page as the photograph or in a separate file associated with the image through a link or other standard programmatic mechanism.
An audio recording
The Web page described in the previous example includes a link to an audio recording of the leaders' press conference. The page also links to a text transcript of the press conference. The transcript includes a verbatim record of everything the speakers say. It identifies who is speaking as well as noting other significant sounds that are part of the recording, such as applause, laughter, questions from the audience, and so on.
[begin add]An e-learning application[end add]
[begin add]An e-learning application uses sound effects to indicate whether or not the answers are correct. The chime sound indicates that the answer is correct and the beep sound indicates that the answer is incorrect. A text description is also included so that people who can't hear or understand the sound understand whether the answer is correct or incorrect. [end add] [LC-1326]
[begin add]A linked thumbnail image[end add]
[end add]A thumbnail image of the front page of a newspaper links to the home page of the "Smallville Times". The text alternative says "Smallville Times". [LC-858]
Resources are for information purposes only, no endorsement implied.
Excerpts from the NBA Tape Recording Manual, Third Edition. Information on describing complex images to people who are blind.
Inaccessibility of CAPTCHA. Examines a number of potential solutions that allow systems to test for human users while preserving access by users with disabilities. [LC-556]
[end add]The purpose of this guideline is to provide access to multimedia. Multimedia is defined in the glossary as:
multimedia: audio or video synchronized with another type of media and/or with time-based interactive components
Note that an audio file accompanied by interaction is covered here, as is a video-only file that involves interaction. These are covered because interaction must take place at a particular time. Having a text transcript that said, "for more information, click now," would not be very helpful since the reader would have no idea when the audio said, "now." As a result, synchronized captions would be needed.
Sometimes, there is so much dialogue that audio description cannot fit into existing pauses in the dialogue. The option at Level A to provide a full text alternative for multimedia including any interaction instead of audio description for multimedia would allow access to all of the information in the multimedia. This option also allows access to the visual information in non-visual form when audio description is not provided for some other reason.
For multimedia that includes interaction, interactive elements (for example links) could be embedded in the full text alternative for multimedia.
This guideline also includes (at Level AAA) sign language interpretation for multimedia as well as an approach called extended audio description. In extended audio description, the video is frozen periodically to allow more audio description to take place than is possible in the existing pauses in the dialogue. [begin add]This is a case where higher-level success criteria build upon the requirements of lower-level SC with the intention of having cumulative, progressively stronger, requirements. [LC-1223] [end add]
Specific techniques for meeting each success criterion for this guideline are listed in the understanding sections for each success criterion (listed below). If there are techniques, however, for addressing this guideline that do not fall under any of the success criteria, they are listed here. These techniques are not required or sufficient for meeting any success criteria, but can make certain types of Web content more accessible to more people.
1.2.1 Captions are provided for prerecorded multimedia, [begin add]except for multimedia alternatives to text that are clearly labeled as such. [LC-608] [end add] (Level A)
text presented and synchronized with multimedia to provide not only the speech, but also [begin change]non-speech information conveyed through sound, including meaningful sound effects and identification of speakers [LC-846] [end change]
Note: In some countries, the term "subtitle" is used to refer to dialogue only and "captions" is used as the term for dialogue plus sounds and speaker identification. In other countries, subtitle (or its translation) is used to refer to both.
audio or video synchronized with another [begin delete]type of media[end delete] [begin add]format for presenting information[end add] and/or with time-based interactive components [LC-1499]
multimedia that presents no more information than is already presented in text (directly or via text alternatives) [LC-608]
[end add]Note: Multimedia alternatives to text are provided for those who benefit from alternate representations of text.
The intent of this success criterion is to enable people who are deaf or hard of hearing to watch multimedia presentations. Captions provide the part of the content available via the audio track. Captions not only include dialogue, but identify who is speaking and include non-speech information conveyed through sound, including meaningful sound effects.
It is acknowledged that at the present time there may be difficulty in creating captions for time-sensitive material and this may result in the author being faced with the choice of delaying the information until captions are available, or publishing time-sensitive content that is inaccessible to the deaf, at least for the interval until captions are available. Over time, the tools for captioning as well as building the captioning into the delivery process can shorten or eliminate such delays. [LC-1332]
[end add]Captions are not needed when the multimedia is, itself, an alternate presentation of information that is also presented via text on the Web page. For example, if information on a page is accompanied by a multimedia presentation that [begin add]presents no more information than is already presented in text,[end add] but is easier for people with cognitive, language, or learning disabilities to understand, then it would not need to be captioned since the information is already presented on the page in text or in text alternatives (e.g. for images). [LC-608]
[end add]People who are deaf or have a hearing loss can access the auditory information in the multimedia content through captions.
Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.
G87: Providing closed captions using any readily available media format that has a video player that [begin delete]is free of charge and[end delete] supports closed captioning [LC-792]
G87: Providing closed captions using any of the technology-specific techniques below
The following are common mistakes that are considered failures of Success Criterion 1.2.1 by the WCAG Working Group.
Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.
Providing 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)
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 multimedia clips for different paragraphs that show a person speaking the contents of the paragraph. Each clip is associated with its corresponding paragraph. No captions are provided for the multimedia. [LC-608]
[end add]An instruction manual containing a description of a part and its necessary orientation is accompanied by a multimedia clip showing the part in its correct orientation. No captions are provided for the multimedia clip. [LC-608]
[end add]Resources are for information purposes only, no endorsement implied.
(none currently documented)
1.2.2 Audio description of video, or a [begin change]full text alternative for multimedia including any interaction[end change] , is provided for prerecorded multimedia. (Level A)
Note: [begin add]For 1.2.2, 1.2.4, and 1.2.7, if all of the information in the video track is already provided in the audio track, no audio description is necessary. [LC-1224] [end add]
narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone
Note 1: [begin change]Audio description of video provides information about actions, characters, scene changes, on-screen text, and other visual content. [LC-845] [end change]
Note 2: In standard audio description, narration is added during existing pauses in dialogue. (See also extended audio description.)
Note 3: Also called "video description" and "descriptive narration."
[end add]document including correctly sequenced text descriptions of all visual settings, actions, speakers, and non-speech sounds, and transcript of all dialogue combined with a means of achieving any outcomes that are achieved using interaction (if any) during the multimedia
[end change]Note: A screenplay used to create the multimedia content would meet this definition only if it was corrected to accurately represent the final multimedia after editing.
audio or video synchronized with another [begin delete]type of media[end delete] [begin add]format for presenting information[end add] and/or with time-based interactive components [LC-1499]
The intent of this success criterion is to provide people who are blind or visually impaired access to the visual information in a multimedia presentation. This success criterion describes two approaches, either of which can be used.
One approach is to provide audio description of the video content. The audio description augments the audio portion of the presentation with the information needed when the video portion is not available. During existing pauses in dialogue, audio description provides information about actions, characters, scene changes, and on-screen text that are important and are not described or spoken in the main sound track.
The second approach involves providing all of the information in the multimedia (both visual and auditory) in text form. A full text alternative for multimedia including any interaction provides a running description of all that is going on in the multimedia content. The full text alternative for multimedia including any interaction reads something like a screenplay or book. Unlike audio description, the description of the video portion is not constrained to just the pauses in the existing dialogue. Full descriptions are provided of all visual information, including visual context, actions and expressions of actors, and any other visual material. In addition, non-speech sounds (laughter, off-screen voices, etc.) are described, and transcripts of all dialogue are included. The sequence of description and dialogue transcripts are the same as the sequence in the multimedia itself. As a result, the full text alternative for multimedia can provide a much more complete representation of the multimedia content than audio description alone.
If there is any interaction as part of the multimedia presentation (e.g. "press now to answer the question") then the full text alternative for multimedia would provide hyperlinks or whatever is needed to provide the same functionality.
Note: [begin add]For 1.2.2, 1.2.3, and 1.2.7, if all of the information in the video track is already provided in the audio track, no audio description is necessary. [LC-1224] [end add]
This success criterion may help some people who have difficulty watching video or other multimedia content, including people who have difficulty perceiving or understanding moving images.
[end change]Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.
G69: Providing a full multimedia text alternative including any interaction
G78: Providing a sound track that includes audio description as the primary sound track
G78: Providing a sound track that includes audio description AND associating it with the multimedia content using one of the following techniques:
Providing audio description in its own sound track (future link) AND merging the description track with the original soundtrack of the multimedia content at runtime using one of the following techniques
Using SMIL 1.0 to merge a description track with sound track (future link)
Using SMIL 2.0 to merge a description track with sound track (future link)
The following are common mistakes that are considered failures of Success Criterion 1.2.2 by the WCAG Working Group.
(No failures currently documented)
Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.
Providing audio description in multiple languages in SMIL 1.0 (future link)
Providing audio description in multiple languages in SMIL 2.0 (future link)
A movie with audio description.
Describer: A title, "Teaching Evolution Case Studies. Bonnie Chen." A teacher shows photographs of birds with long, thin beaks.
Bonnie Chen: "These photos were all taken at the Everglades."
Describer: The teacher hands each student two flat, thin wooden sticks.
Bonnie Chen: "Today you will pretend to be a species of wading bird that has a beak like this."
Describer: The teacher holds two of the sticks to her mouth making the shape of a beak.
Transcript of audio based on the first few minutes of "Teaching Evolution Case Studies, Bonnie Chen" (copyright WGBH and Clear Blue Sky Productions, Inc.)
A full text alternative for multimedia including any interaction for a training video
A company purchases a Training video for use by its employees and puts it on the companies intranet. The video involves explaining use of a new technology and has a person talking and showing things at the same time. Since there is no place to insert audio description of the visual demonstrations during gaps in dialogue, the company provides a full text alternative for multimedia that all employees, including those who cannot see the demonstrations, can use to better understand what is being presented.
Resources are for information purposes only, no endorsement implied.
1.2.3 Captions are provided for live multimedia. (Level AA)
Note: [begin add]If multimedia is completely computer generated, it is not live and is subject to the requirements for pre-recorded multimedia in WCAG 2.0. [LC-925] [end add]
text presented and synchronized with multimedia to provide not only the speech, but also [begin change]non-speech information conveyed through sound, including meaningful sound effects and identification of speakers [LC-846] [end change]
Note: In some countries, the term "subtitle" is used to refer to dialogue only and "captions" is used as the term for dialogue plus sounds and speaker identification. In other countries, subtitle (or its translation) is used to refer to both.
audio or video synchronized with another [begin delete]type of media[end delete] [begin add]format for presenting information[end add] and/or with time-based interactive components [LC-1499]
The intent of this success criterion is to enable people who are deaf or hard of hearing to watch real-time presentations. Captions provide the part of the content available via the audio track. Captions not only include dialogue, but also identify who is speaking and notate sound effects and other significant audio.
People who are deaf or have a hearing loss can access the auditory information in the multimedia content through captions.
Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.
G9: Creating captions for live multimedia AND G93: Providing open (always visible) captions
G9: Creating captions for live multimedia AND G87: Providing closed captions using any readily available media format that has a video player that [begin delete]is free of charge and[end delete] supports closed captioning [LC-792]
G9: Creating captions for live multimedia AND G87: Providing closed captions using one of the following techniques:
Note: Captions may be generated using real-time text translation service. [begin delete](stenographic or, in the future, speech-to-text with corrections)[end delete] [LC-790]
The following are common mistakes that are considered failures of Success Criterion 1.2.3 by the WCAG Working Group.
(No failures currently documented)<