W3C

Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT)

W3C Editors' Draft 5 September 2013

This version:
http://www.w3.org/WAI/GL/2013/WD-wcag2ict-20130905/
Latest version:
http://www.w3.org/WAI/GL/wcag2ict/
Previous version:
http://www.w3.org/WAI/GL/2013/WD-wcag2ict-20130711/
Latest editors' draft:
http://www.w3.org/WAI/GL/wcag2ict/
Editors:
Michael Cooper, W3C
Peter Korn, Oracle Corporation
Andi Snow-Weaver, IBM Corporation
Gregg Vanderheiden, Invited Expert, Trace Research and Development Center
Authors:
Peter Korn, Oracle Corporation
Loïc Martínez Normand, Universidad Politécnica de Madrid
Mike Pluke, Invited Expert
Andi Snow-Weaver, IBM Corporation
Gregg Vanderheiden, Invited Expert, Trace Research and Development Center

This document is available in an expandable / collapsible alternate version in which the “Intent” sections copied from Understanding WCAG 2.0 are hidden and individually expandable, for easier reading.


Abstract

This document, “Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT)” describes how the Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20] and its principles, guidelines, and success criteria can be applied to non-web Information and Communications Technologies (ICT), specifically to non-web documents and software. It provides informative guidance (guidance that is not normative and does not set requirements).

This document is intended to become a Working Group Note, and is part of a series of technical and educational documents published by the W3C Web Accessibility Initiative (WAI) and available from the WCAG 2.0 Overview.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is an Editors' Draft being developed by the WCAG2ICT Task Force (“Task Force”) operating under the terms of its Work Statement, and under the coordination and review of the Web Content Accessibility Guidelines Working Group (WCAG WG), which is part of the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). The WCAG2ICT Task Force's work is consistent with the WCAG WG Charter that includes the following under its scope: “Coordinating with other entities adopting and using WCAG 2.0”.

This document includes many excerpts from “Understanding WCAG 2.0,” each of which is prefaced with the words “Intent from…” and which are also visually indicated with a yellow background. Understanding WCAG 2.0 and other WCAG 2.0 supporting documents will continue to focus on web technologies. For comments on Understanding WCAG, please follow the comment instructions in that document.

Please note that WCAG 2.0 itself is a stable web standard. Comments on this document will not affect WCAG 2.0 wording.

Publication as an Editors' 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 was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. Introduction

This document provides informative guidance (guidance that is not normative, and that does not set requirements) with regard to the interpretation and application of Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20] to non-web information and communications technologies (ICT). This document is a Working Group Note (in contrast to WCAG 2.0, which is a W3C Recommendation and also an International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) standard). Specifically, this document provides informative guidance on applying WCAG 2.0 Level A and AA success criteria to non-web ICT, specifically to non-web documents and software.

This document is intended to help clarify how to use WCAG 2.0 to make non-web documents and software more accessible to people with disabilities. Addressing accessibility involves addressing the needs of people with auditory, cognitive, neurological, physical, speech, and visual disabilities, and the needs of people with accessibility requirements due to the effects of aging. Although this document covers a wide range of issues, it is not able to address all the needs of all people with disabilities. Because WCAG 2.0 was developed for the Web, addressing accessibility for non-web documents and software may involve provisions beyond those included in this document. Authors and developers are encouraged to seek relevant advice about current best practices to ensure that non-web documents and software are accessible, as far as possible, to people with disabilities.

While WCAG 2.0 was designed to be technology-neutral, it assumes the presence of a “user agent” such as a browser, media player, or assistive technology as a means to access web content. Therefore, the application of WCAG 2.0 to documents and software in non-web contexts required some interpretation in order to determine how the intent of each WCAG 2.0 success criterion could be met in these different contexts of use. The bulk of the Task Force's work therefore involved evaluating how each WCAG 2.0 success criterion would apply in the context of non-web ICT, if it were applied to non-web ICT.

The Task Force found that the majority of success criteria from WCAG 2.0 can apply to non-web documents and software with no or only minimal changes. Specifically, of the thirty-eight Level A and AA success criteria, twenty-six did not include any web related terms and apply directly as written and as described in the “Intent” sections from the updated Understanding WCAG 2.0 [UNDERSTANDING-WCAG20]. Thirteen of these twenty-six applied without any additional notes. The other thirteen applied as written but additional notes were also provided for assistance in applying them to either or both non-web documents and software.

Of the remaining twelve success criteria, the Task Force found that eight of them apply as written when replacing certain Web-specific terms or phrases like “web page(s)” with non-web terms or phrases like “non-web document(s) and software” or “for non-web documents and software that use markup languages, in such a way that…” etc. Additional notes were also provided to assist in the application of these.

The remaining four success criteria apply in situations when “a set of web pages”, or “multiple web pages” share some characteristic or behavior. In WCAG 2.0 the “unit of conformance” is the web page. While WCAG2ICT is not a standard, and thus conformance does not apply, it is still useful to look at what a “unit of evaluation” would be for non-web ICT. For non-web documents, WCAG2ICT uses a single document as the “unit of evaluation”, as it is the best analog to a web page. This became the basis for the notion of a “set of documents”, which is used for the remaining four success criteria which in WCAG speak to “sets of web pages”. For non-web software it wasn't possible to unambiguously carve up software into discrete pieces, and so the “unit of evaluation” for non-web software is the software program. This became the basis for the notion of a “set of software programs”, which is used for the remaining four success criteria.

The 83 glossary terms were also reviewed. 51 applied to non-Web documents and software as written. Another 28 applied with additional notes or edits (largely related to phrases like “Web page(s)”), and the remaining 4 terms were only used in Level AAA success criteria which are not addressed by this Note.

1.1. Excluded from Scope

The following are out of scope for this document:

1.2. Document Overview

This document includes excerpted text from WCAG 2.0 principles, guidelines, and success criteria, as quoted from WCAG 2.0 without any changes. It also includes excerpted text from the “Intent” sections of the WCAG 2.0 supporting document Understanding WCAG 2.0 (Public Review Draft) [UNDERSTANDING-WCAG20], as clarified based on input from Task Force discussions and responses to public comments after review and approval by the WCAG Working Group. The guidance provided by this document for each success criteria is preceded by a title beginning “Additional Guidance…”. This guidance was created by the WCAG2ICT Task Force, then reviewed and approved by the WCAG Working Group.

Additional supporting documents for WCAG 2.0, such as the WCAG 2.0 Overview, Techniques for WCAG 2.0 [WCAG20-TECHS], and How to Meet WCAG 2.0: A customizable quick reference, remain available for web content, but have not been changed to apply to non-web documents and software.

1.3. Document Conventions

The following stylistic conventions are used in this document:

2. Key Terms

Of the 83 glossary terms used in WCAG 2.0 there are two key glossary terms that need to be interpreted significantly differently when applied to non-web ICT. These are: “content” and “user agent”. Further, the glossary term “Web page” in WCAG 2.0 is replaced with newly defined terms “document” and “software”, and both “set of web pages” and “multiple web pages” are replaced with the newly defined terms “set of documents” and “set of software programs”. Finally, as part of addressing the fact that non-Web software doesn't leverage the WCAG 2.0 notion of a user agent, we introduce the new term “accessibility services of platform software”. The remaining 79 glossary terms from WCAG 2.0 are addressed in Chapter 7 Comments on Definitions in WCAG 2.0 Glossary in Appendix A. Terms defined and used in WCAG2ICT are applicable only to the interpretation of the guidance in this document. The particular definitions should not be interpreted as having applicability to situations beyond the scope of WCAG2ICT. Further information on usage of these terms follows.

2.1. Accessibility Services of Platform Software

The term accessibility services of platform software, as used in WCAG2ICT, has the meaning below:

accessibility services of platform software (as used in WCAG2ICT)

services provided by an operating system, user agent, or other platform software that enable non-web documents or software to expose information about the user interface and events to assistive technologies and accessibility features of software

Note: These services are commonly provided in the form of accessibility APIs (application programming interfaces), and they provide two-way communication with assistive technologies, including exposing information about objects and events.

2.2. Content (on and off the Web)

WCAG 2.0 defines CONTENT as:

content (web content)

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions

For non-web content it is necessary to view this a bit more broadly. Within WCAG2ICT, the term “content” is used as follows:

content (non-web content) (as used in WCAG2ICT)

information and sensory experience to be communicated to the user by means of software, including code or markup that defines the content's structure, presentation, and interactions

Note: non-web content occurs in two places; documents and software. When content occurs in a document, a user agent is needed in order to communicate the content's information and sensory experience to the user. When content occurs in software, a separate user agent isn't required—the software itself performs that function.

Within WCAG2ICT wherever “content” or “web content” appears in a success criterion or Intent it should be replaced with “content” using the definition above.

2.3. Document

The term document, as used in WCAG2ICT, has the meaning below:

document (as used in WCAG2ICT)

assembly of content, such as a file, set of files, or streamed media that functions as a single item rather than a collection, that is not part of software and that does not include its own user agent

Note 1: A document always requires a user agent to present its content to the user.

Note 2: Letters, spreadsheets, emails, books, pictures, presentations, and movies are examples of documents.

Note 3: Software configuration and storage files such as databases and virus definitions, as well as computer instruction files such as source code, batch/script files, and firmware, are examples of files that function as part of software and thus are not examples of documents. If and where software retrieves “information and sensory experience to be communicated to the user” from such files, it is just another part of the content that occurs in software and is covered by WCAG2ICT like any other parts of the software. Where such files contain one or more embedded documents, the embedded documents remain documents under this definition.

Note 4: A collection of files zipped together into an archive, stored within a single virtual hard drive file, or stored in a single encrypted file system file, do not constitute a single document when so collected together. The software that archives/encrypts those files or manages the contents of the virtual hard drive does not function as a user agent for the individually collected files in that collection because that software is not providing a non-fully functioning presentation of that content.

Note 5: Anything that can present its own content without involving a user agent, such as a self playing book, is not a document but is software.

Note 6: A single document may be composed of multiple files such as the video content, closed caption text, etc. This fact is not usually apparent to the end-user consuming the document / content. This is similar to how a single web page can be composed of content from multiple URIs (e.g. the page text, images, the JavaScript, a CSS file etc.).

Example: An assembly of files that represented the video, audio, captions and timing files for a movie would be a document.

Counterexample: A binder file used to bind together the various exhibits for a legal case would not be a document.

2.4. Set of Documents

The term set of documents, as used in WCAG2ICT has the meaning below:

set of documents (non-web) (as used in WCAG2ICT)

group of documents that are published together, and where the items all refer to each other by name or link

Note 1: Republishing or bundling previously published documents as a collection does not constitute a set of documents.

Note 2: If a set is broken apart, the individual parts are no longer part of a set, and would be evaluated as any other individual document is evaluated.

One example of a set of documents would be a three-part report where each part is a separate file. At the beginning of each file the table of contents for “navigating” to the other parts is repeated.

2.5. Set of Software Programs

The term set of software programs, as used in WCAG2ICT has the meaning below:

set of software programs (as used in WCAG2ICT)

group of software programs that are distributed together and that can be launched and used independently from each other, but that are interlinked each with every other one such that users can navigate from one program to another via a consistent method that appears in each member of the set

Note 1: This definition of “set of software programs” is derived from the characteristics of a “set” of web pages, and is used for mapping WCAG success criteria to software. Although such sets occur frequently for web pages, such sets appear to be extremely rare for software.

Note 2: Redistributing or bundling previously distributed software as a collection does not constitute a set of software programs.

Note 3: Consistent does not mean identical. For example, if a list of choices is provided it might not include the name of the current program.

Note 4: If a member of the set is separated from the set, it is no longer part of a set, and would be evaluated as any other individual software program.

Note 5: Any software program that is not part of a set, per this definition, would automatically satisfy any success criterion that is specified to apply to “sets of” software (as is true for any success criterion that is scoped to only apply to some other type of content).

Note 6: If there is any ambiguity whether the group is a set, then the group is not a set

Note 7: If there is no independent method to launch the software programs (as is common in closed products), those programs would not meet the definition of a set of programs.

Note 8: Although the term “software” is used throughout this document because this would apply to stand alone software programs as well as individual software components and the software components in software-hardware combinations, the concept of “set of software programs” would only apply (by definition) to programs that can be launched separately from each other. Therefore, for the provisions that use the phrase “set of” (success criteria 2.4.1, 2.4.5, 3.2.3, and 3.2.4), the phrase “set of software programs” is used.

Example: One example of a set of software programs would be a group of programs that can be launched and used separately but are distributed together and all have a menu that allows users to launch, or switch to, each of the other programs in the group.

Counterexamples: Examples of things that are not sets of software programs:

2.6. Software

The term software as used in WCAG2ICT, has the meaning below:

software (as used in WCAG2ICT)

software products or software aspects of hardware-software products that have a user interface and do not require a separate user agent to present any of its content

Note 1. For software, the user interface and any other embedded content is covered by these guidelines. The software provides a function equivalent to a user agent for the embedded content.

Note 2. Software without a user interface does not have content and is not covered by these guidelines. For example, driver software with no user interface would not be covered.

Note 3. Because software with a user interface provides a function equivalent to a user agent in addition to content, the application of some WCAG 2.0 success criteria would be different for content embedded in software versus content in a document, where it is viewed through a separate user agent (e.g. browser, player, viewer, etc.).

2.7. User Agent

WCAG 2.0 defines user agent as follows:

user agent

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.

For non-web ICT, “user agent” needs to be viewed differently. In WCAG 2.0, the term “user agent” only refers to retrieval and display of web content. For non-web ICT, the term “user agent” refers to retrieval and display of separate content that is not on the Web, which WCAG2ICT refers to as a “document”. Within WCAG2ICT, the term “user agent” is used as follows:

user agent (as used in WCAG2ICT)

any software that retrieves and presents documents for users

Note 1. Software that only displays the content contained within it is not considered to be a user agent. It is just considered to be software.

Note 2. An example of software that is not a user agent is a calculator application that doesn't retrieve the calculations from outside the software to present it to a user. In this case, the calculator software is not a user agent, it is simply software with a user interface.

Note 3: Software that only shows a preview of content such as a thumbnail or other non-fully functioning presentation is not providing user agent functionality.

3. Closed Functionality

As noted in the Introduction, WCAG 2.0 assumes the presence of a “user agent” such as a browser, media player, or assistive technology as a means to access web content. Furthermore, many of the success criteria in WCAG 2.0 assume web content will be accessed by ICT that has assistive technologies connected to it, where the assistive technologies present the web content to the people with disabilities in accessible form. ICT products with “closed functionality” do not allow the use of some assistive technologies for all of their functions. In many cases such ICT products also lack a “user agent” or their equivalent. As a result, ICT following these success criteria by themselves will not make information accessible on ICT with closed functionality. Something else needs to be provided or be required in order to make the information addressed in these success criteria accessible. It is outside the task force work statement to say what the additional measures are, but this Note points out which success criteria depend on assistive technologies—and therefore would not work by themselves in products with closed functionality.

Because closed functionality, by definition, does not allow a user to attach assistive technology, WCAG success criteria that assume the presence of assistive technology will not facilitate accessibility as WCAG 2.0 intends. Where assistive technologies cannot be used, other output and input solutions are needed to achieve the intent of these success criteria.

Examples of products with closed functionality include:

See Appendix A: Success Criteria Problematic for Closed Functionality for a list of success criteria for which this is relevant.

4. Text / Command-line / Terminal Applications and Interfaces

Text applications are a class of software ICT that appeared decades ago, prior to the emergence of the graphical user interface (GUI) and the Web. The interface of a text application is generated using only text characters, and either a hardware terminal or a software terminal application handles the rendering of the text application—similar to how a web user agent handles the rendering of a web application. Text applications only accept text input (though some terminal applications which render text applications in the GUI may utilize a mouse or other input devices). Command-line applications are a subset of text applications with further specific properties.

Historically, assistive technologies developed alongside text applications, and several of these use a variety of analysis and scripting techniques to make text applications accessible. Although there are far fewer new text applications being developed compared to new GUI or web applications, text applications remain in use today, and both text applications and the assistive technologies designed for text applications are in active development.

Though this class of applications predates the Web, WCAG can be applied to them. As noted in Appendix B. Background on Text / Command-line / Terminal Applications and Interfaces, applying WCAG to text / command-line applications involves understanding how text applications are rendered, how text applications have been made accessible via assistive technologies, and how to apply the concepts of “accessibility supported” and “programmatically determined” to text applications.

5. Comments on Conformance

WCAG2ICT is not a standard, so it is not possible to conform to WCAG2ICT. However, some entities may wish to use the information in WCAG2ICT to help establish standards or regulations regarding accessibility in ICT that are based on WCAG 2.0. While such standards or regulations will need to address matters of conformance themselves, the following notes may be of assistance to those wishing to draft their own requirements:

  1. The WCAG 2.0 success criteria and the conformance requirements were designed to work together, such that the language of the success criteria is based on the nature of the conformance requirements. The choice of what level to use for a given criteria (A vs. AA vs. AAA) was further influenced by a number of factors specific to the web domain, as set forth in Understanding Levels of Compliance.
  2. In the WCAG 2.0 conformance model, a success criteria is satisfied if the item being evaluated does not fail it. If the success criterion is in relation to something that does not exist for the item being evaluated (e.g. a success criterion is about captioning audio and there is no audio) then the success criterion is automatically met. This approach is central to the way the success criteria in WCAG are structured and worded.
  3. WCAG 2.0 conformance is applied to the item being evaluated (i.e. web page) as a whole, except when a process includes use of several items, in which case all of the items that are needed in order to complete the process must conform.
  4. In WCAG 2.0, when conformance relies on accessibility features of the platform (i.e. browser for web content) or on assistive technologies, WCAG 2.0 requires that there are assistive technologies, etc. that work with the product (web page). That is, conformance with WCAG 2.0 requires that the approaches used are supported by assistive technologies.
  5. WCAG 2.0 allows information on part of a page to not conform if the same information is available elsewhere on the page in conforming fashion. However WCAG 2.0 identifies 4 success criteria that must be met on all areas of the page because they can interfere with the user's ability to access and use other parts of the page:

Also, as noted in the Introduction, it wasn't possible to unambiguously carve up software into discrete pieces, and so the unit of evaluation for non-web software is the whole software program. As with any software testing this can be a very large unit of evaluation, and methods similar to standard software testing might be used.

6. Comments by Guideline and Success Criterion

The sections that follow are organized according to the principles, guidelines, and success criteria from WCAG 2.0. The text of each item from WCAG 2.0 is copied as quoted text. Following that, the WCAG2ICT guidance is provided. Finally, the “Intent” from Understanding WCAG 2.0 is copied as quoted text; the Task Force makes no substitutions or edits in this text. In visual presentations, the WCAG2ICT guidance is set out in a box with a blue bar to the left, to highlight that this is the content specific to this document.

Principle 1: Perceivable

Information and user interface components must be presentable to users in ways they can perceive.

Additional Guidance When Applying Principle 1 to Non-Web Documents and Software:

In WCAG 2.0, the Principles are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Principle 1 applies directly as written.

Guideline 1.1: Text Alternatives

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

Additional Guidance When Applying Guideline 1.1 to Non-Web Documents and Software:

In WCAG 2.0, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 1.1 applies directly as written.

Intent from Understanding Guideline 1.1 in Understanding WCAG 2.0 (View full version of guidance for Guideline 1.1):

The purpose of this guideline is to ensure that all non-text content is also available in text. "Text" refers to electronic text, not an image of text. Electronic text has the unique advantage that it 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.

Success Criterion 1.1.1: Non-text Content (Level A)

From Success Criterion 1.1.1:

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.

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

Additional Guidance When Applying Success Criterion 1.1.1 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.1.1 (also provided below).

Note 1: CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is accurate.

Note 2: See also the discussion on Closed Functionality in the Introduction.

Intent from Understanding Success Criterion 1.1.1 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.1.1):

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.

Note on CAPTCHA

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

Additional information

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

For non-text content that 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.

Specific Benefits of Success Criterion 1.1.1
  • 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.

Guideline 1.2: Time-based Media

From Guideline 1.2:

Provide alternatives for time-based media.

Additional Guidance When Applying Guideline 1.2 to Non-Web Documents and Software:

In WCAG 2.0, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 1.2 applies directly as written.

Intent from Understanding Guideline 1.2 in Understanding WCAG 2.0 (View full version of guidance for Guideline 1.2):

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:

synchronized media

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.

Success Criterion 1.2.1: Audio-only and Video-only (Prerecorded) (Level A)

From Success Criterion 1.2.1:

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:

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

Additional Guidance When Applying Success Criterion 1.2.1 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.1 (also provided below).

Note 1: The alternative can be provided directly in the non-web document or software – or provided in an alternate version that meets the success criteria.

Note 2: See also the discussion on Closed Functionality in the Introduction.

Intent from Understanding Success Criterion 1.2.1 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.2.1):

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)

Specific Benefits of Success Criterion 1.2.1
  • 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.

Success Criterion 1.2.2: Captions (Prerecorded) (Level A)

From Success Criterion 1.2.2:

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.

Additional Guidance When Applying Success Criterion 1.2.2 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.2 (also provided below).

Note: The WCAG 2.0 definition of “captions” notes that “in some countries, captions are called subtitles”. They are also sometimes referred to as “subtitles for the hearing impaired.” Per the definition in WCAG 2.0, to meet this success criterion, whether called captions or subtitles, they would have to provide “synchronized visual and / or text alternative for both speech and non-speech audio information needed to understand the media content” where non-speech information includes “sound effects, music, laughter, speaker identification and location”.

Intent from Understanding Success Criterion 1.2.2 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.2.2):

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

Specific Benefits of Success Criterion 1.2.2
  • People who are deaf or have a hearing loss can access the auditory information in the synchronized media content through captions.

Success Criterion 1.2.3: Audio Description or Media Alternative (Prerecorded) (Level A)

From Success Criterion 1.2.3:

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.

Additional Guidance When Applying Success Criterion 1.2.3 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.3 (also provided below).

Note 1: The WCAG 2.0 definition of “audio description” says that “audio description” is “also called ‘video description’ and ‘descriptive narration’”.

Note 2: Secondary or alternate audio tracks are commonly used for this purpose.

Note 3: See also the discussion on Closed Functionality in the Introduction.

Intent from Understanding Success Criterion 1.2.3 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.2.3):

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

Specific Benefits of Success Criterion 1.2.3
  • 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.

Success Criterion 1.2.4: Captions (Live) (Level AA)

From Success Criterion 1.2.4:

Captions are provided for all live audio content in synchronized media.

Additional Guidance When Applying Success Criterion 1.2.4 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.4 (also provided below).

Note: The WCAG 2.0 definition of “captions” notes that “In some countries, captions are called subtitles”. They are also sometimes referred to as “subtitles for the hearing impaired.” Per the definition in WCAG 2.0, to meet this success criterion, whether called captions or subtitles, they would have to provide “synchronized visual and / or text alternative for both speech and non-speech audio information needed to understand the media content” where non-speech information includes “sound effects, music, laughter, speaker identification and location”.

Intent from Understanding Success Criterion 1.2.4 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.2.4):

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.

Specific Benefits of Success Criterion 1.2.4
  • People who are deaf or have a hearing loss can access the auditory information in the synchronized media content through captions.

Success Criterion 1.2.5: Audio Description (Prerecorded) (Level AA)

From Success Criterion 1.2.5:

Audio description is provided for all prerecorded video content in synchronized media.

Additional Guidance When Applying Success Criterion 1.2.5 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.5 (also provided below).

Note1: The WCAG 2.0 definition of “audio description” says that audio description is “also called ‘video description’ and ‘descriptive narration’”.

Note2: Secondary or alternate audio tracks are commonly used for this purpose.

Intent from Understanding Success Criterion 1.2.5 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.2.5):

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.

Specific Benefits of Success Criterion 1.2.5
  • 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.

Guideline 1.3: Adaptable

From Guideline 1.3:

Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

Additional Guidance When Applying Guideline 1.3 to Non-Web Documents and Software:

In WCAG 2.0, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 1.3 applies directly as written.

Intent from Understanding Guideline 1.3 in Understanding WCAG 2.0 (View full version of guidance for Guideline 1.3):

The purpose of this guideline is to ensure that all information is available in a form that can be perceived by all users, 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.

  • structure: the way the parts of a Web page are organized in relation to each other; and the way a collection of Web pages is organized

  • presentation: rendering of the content in a form that can be perceived by users

Success Criterion 1.3.1: Info and Relationships (Level A)

From Success Criterion 1.3.1:

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

Additional Guidance When Applying Success Criterion 1.3.1 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.1 (also provided below).

Note 1: In software, programmatic determinability is best achieved through the use of accessibility services provided by platform software to enable interoperability between software and assistive technologies and accessibility features of software.

Note 2: See also the discussion on Closed Functionality in the Introduction.

Intent from Understanding Success Criterion 1.3.1 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.3.1):

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.

Specific Benefits of 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.

Success Criterion 1.3.2: Meaningful Sequence (Level A)

From Success Criterion 1.3.2:

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

Additional Guidance When Applying Success Criterion 1.3.2 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.2 (also provided below).

Note: See also the discussion on Closed Functionality in the Introduction.

Intent from Understanding Success Criterion 1.3.2 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.3.2):

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:

  1. Providing a particular linear order is only required where it affects meaning.

  2. There may be more than one order that is "correct" (according to the WCAG 2.0 definition).

  3. Only one correct order needs to be provided.

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

Success Criterion 1.3.3: Sensory Characteristics (Level A)

From Success Criterion 1.3.3:

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.

Note: For requirements related to color, refer to Guideline 1.4.

Additional Guidance When Applying Success Criterion 1.3.3 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.3 (also provided below).

Intent from Understanding Success Criterion 1.3.3 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.3.3):

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.

Specific Benefits of Success Criterion 1.3.3
  • People who are blind and people who have low vision may not be able to understand information if it is conveyed by shape and/or location. Providing additional information other than shape and/or location will allow them to understand the information conveyed by shape and/or alone.

Guideline 1.4: Distinguishable

From Guideline 1.4:

Make it easier for users to see and hear content including separating foreground from background.

Additional Guidance When Applying Guideline 1.4 to Non-Web Documents and Software:

In WCAG 2.0, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 1.4 applies directly as written.

Intent from Understanding Guideline 1.4 in Understanding WCAG 2.0 (View full version of guidance for Guideline 1.4):

While some guidelines are focused on making information available in a form that can be presented in alternate formats, this guideline is concerned with making the default presentation as 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.

Success Criterion 1.4.1: Use of Color (Level A)

From Success Criterion 1.4.1:

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

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.

Additional Guidance When Applying Success Criterion 1.4.1 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.1 (also provided below).

Intent from Understanding Success Criterion 1.4.1 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.4.1):

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.

Specific Benefits of Success Criterion 1.4.1
  • 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.

Success Criterion 1.4.2: Audio Control (Level A)

From Success Criterion 1.4.2:

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.

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.

Additional Guidance When Applying Success Criterion 1.4.2 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.2 (also provided below), replacing “on a Web page” with “in a non-web document or software”, “any content” with “any part of a non-web document or software”, “whole page” with “whole document or software”, “on the Web page” with “in the document or software”, and removing “See Conformance Requirement 5: Non-Interference”.

With these substitutions, it would read:

1.4.2 Audio Control: If any audio in a non-web document or software 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 part of a non-web document or software that does not meet this success criterion can interfere with a user's ability to use the whole document or software, all content in the document or software (whether or not it is used to meet other success criteria) must meet this success criterion.

Intent from Understanding Success Criterion 1.4.2 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.4.2):

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.

Specific Benefits of Success Criterion 1.4.2
  • Individuals who use screen reading technologies can hear the screen reader without other sounds playing. This is especially important for those who are hard of hearing and for those whose screen readers use the system volume (so they cannot turn sound down and screen reader up).

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

Success Criterion 1.4.3: Contrast (Minimum) (Level AA)

From Success Criterion 1.4.3:

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

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

Additional Guidance When Applying Success Criterion 1.4.3 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.3 (also provided below).

Intent from Understanding Success Criterion 1.4.3 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.4.3):

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: 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 1: Some people with cognitive disabilities require color combinations or hues that have low contrast, and therefore we allow and encourage authors to provide mechanisms to adjust the foreground and background colors of the content. Some of the combinations that could be chosen may have contrast levels that will be lower than those found in the Success Criteria. This is not a violation of this Success Criteria provided there is a mechanism that will return to the default values set out in the Success Criteria.

Note 2: Images of text do not scale as well as text because they tend to pixelate. It is also harder to change foreground and background contrast and color combinations for images of text, which is necessary for some users. Therefore, we suggest using text wherever possible, and when not, consider supplying an image of higher resolution.

Although this Success Criterion only applies to text, similar issues occur for data presented in charts or graphs. Good color contrast should also be provided for data presented in these forms.

See also Understanding Success Criterion 1.4.6 Contrast (Enhanced).

Rationale for the Ratios Chosen

A contrast ratio of 3:1 is the minimum level recommended by [ISO-9241-3] and [ANSI-HFES-100-1988] for standard text and vision. The 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.

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.

Notes on formula

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

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

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

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

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

Specific Benefits of Success Criterion 1.4.3
  • People with low vision often have difficulty reading text that does not contrast with its background. This can be exacerbated if the person has a color vision deficiency that lowers the contrast even further. Providing a minimum luminance contrast ratio between the text and its background can make the text more readable even if the person does not see the full range of colors. It also works for the rare individuals who see no color.

Success Criterion 1.4.4: Resize text (Level AA)

From Success Criterion 1.4.4:

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Additional Guidance When Applying Success Criterion 1.4.4 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.4 (also provided below).

Note 1: Content for which there are software players, viewers or editors with a 200 percent zoom feature would automatically meet this success criterion when used with such players, unless the content will not work with zoom.

Note 2: The Intent section refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality or that the application works with the platform features that meet this requirement.

Note 3: See also the discussion on Closed Functionality in the Introduction.

Intent from Understanding Success Criterion 1.4.4 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.4.4):

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.

Specific Benefits of Success Criterion 1.4.4
  • This Success Criterion helps people with low vision by letting them increase text size in content so that they can read it.

Success Criterion 1.4.5: Images of Text (Level AA)

From Success Criterion 1.4.5:

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:

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

Additional Guidance When Applying Success Criterion 1.4.5 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.5 (also provided below).

Note: See also the discussion on Closed Functionality in the Introduction.

Intent from Understanding Success Criterion 1.4.5 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 1.4.5):

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

Specific Benefits of Success Criterion 1.4.5
  • 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.

Principle 2: Operable

User interface components and navigation must be operable.

Additional Guidance When Applying Principle 2 to Non-Web Documents and Software:

In WCAG 2.0, the Principles are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Principle 2 applies directly as written.

Guideline 2.1: Keyboard Accessible

From Guideline 2.1:

Make all functionality available from a keyboard.

Additional Guidance When Applying Guideline 2.1 to Non-Web Documents and Software:

In WCAG 2.0, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 2.1 applies directly as written.

Intent from Understanding Guideline 2.1 in Understanding WCAG 2.0 (View full version of guidance for Guideline 2.1):

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

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

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

Success Criterion 2.1.1: Keyboard (Level A)

From Success Criterion 2.1.1:

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.

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.

Additional Guidance When Applying Success Criterion 2.1.1 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.1 (also provided below).

Note 1: This does not imply that software must directly support a keyboard or “keyboard interface”. Nor does it imply that software must provide a soft keyboard. Underlying platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard and would comply.

Note 2: See also the discussion on Closed Functionality in the Introduction.

Intent from Understanding Success Criterion 2.1.1 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 2.1.1):

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.

Specific Benefits of Success Criterion 2.1.1
  • People who are blind (who cannot use devices such as mice that require eye-hand coordination)

  • People with low vision (who may have trouble finding or tracking a pointer indicator on screen)

  • Some people with hand tremors find using a mouse very difficult and therefore usually use a keyboard

Success Criterion 2.1.2: No Keyboard Trap (Level A)

From Success Criterion 2.1.2:

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.

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.

Additional Guidance When Applying Success Criterion 2.1.2 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.2 (also provided below), replacing “page” and “Web page” with “non-web document or software” and removing “See Conformance Requirement 5: Non-Interference”.

With these substitutions, it would read:

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the non-web document or software 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 non-web document or software, all content on the non-web document or software (whether it is used to meet other success criteria or not) must meet this success criterion.

Note: Standard exit methods may vary by platform. For example, on many desktop platforms, the Escape key is a standard method for exiting.

Intent from Understanding Success Criterion 2.1.2 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 2.1.2):

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.

Specific Benefits of Success Criterion 2.1.2
  • People who rely on a keyboard or keyboard interface to use the Web including people who are blind and people with physical disabilities.

Guideline 2.2: Enough Time

From Guideline 2.2:

Provide users enough time to read and use content.

Additional Guidance When Applying Guideline 2.2 to Non-Web Documents and Software:

In WCAG 2.0, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 2.2 applies directly as written.

Intent from Understanding Guideline 2.2 in Understanding WCAG 2.0 (View full version of guidance for Guideline 2.2):

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

Success Criterion 2.2.1: Timing Adjustable (Level A)

From Success Criterion 2.2.1:

For each time limit that is set by the content, at least one of the following is true:

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

Additional Guidance When Applying Success Criterion 2.2.1 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.1 (also provided below), replacing “the content” with “non-web documents or software”.

With this substitution, it would read:

2.2.1 Timing Adjustable: For each time limit that is set by non-web documents or software, 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.

Intent from Understanding Success Criterion 2.2.1 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 2.2.1):

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.

Specific Benefits of Success Criterion 2.2.1
  • People with physical disabilities often need more time to react, to type and to complete activities. People with low vision need more time to locate things on screen and to read. People who are blind and using screen readers may need more time to understand screen layouts, to find information and to operate controls. People who have cognitive or language limitations need more time to read and to understand. People who are deaf and communicate in sign language may need more time to read information printed in text (which may be a second language for some).

  • In circumstances where a sign-language interpreter may be relating audio content to a user who is deaf, control over time limits is also important.

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

Success Criterion 2.2.2: Pause, Stop, Hide (Level A)

From Success Criterion 2.2.2:

For moving, blinking, scrolling, or auto-updating information, all of the following are true:

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

Additional Guidance When Applying Success Criterion 2.2.2 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.2 (also provided below), replacing “page” and “Web page” with “non-web documents and software” and removing “See Conformance Requirement 5: Non-Interference” in Note 2 of the success criterion.

With this substitution, it would read:

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 non-web documents and software, all content on the non-web documents and software (whether it is used to meet other success criteria or not) must meet this success criterion.

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.

Note: While the success criteria uses the term “information”, the WCAG 2.0 Intent section makes it clear that this is to be applied to all content. Any content, whether informative or decorative, that is updated automatically, blinks, or moves may create an accessibility barrier.

Intent from Understanding Success Criterion 2.2.2 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 2.2.2):

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.

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

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

Specific Benefits of Success Criterion 2.2.2
  • 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.

Guideline 2.3: Seizures

From Guideline 2.3:

Do not design content in a way that is known to cause seizures.

Additional Guidance When Applying Guideline 2.3 to Non-Web Documents and Software:

In WCAG 2.0, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 2.3 applies directly as written.

Intent from Understanding Guideline 2.3 in Understanding WCAG 2.0 (View full version of guidance for Guideline 2.3):

Some people with seizure disorders can have a seizure triggered by flashing visual content. Most people are unaware that they have this disorder until it strikes. In 1997, a cartoon on television in Japan sent over 700 children to the hospital, including about 500 who had seizures. 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.

Success Criterion 2.3.1: Three Flashes or Below Threshold (Level A)

From Success Criterion 2.3.1:

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.

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.

Additional Guidance When Applying Success Criterion 2.3.1 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.3.1 (also provided below), replacing “Web pages” with “non-web documents or software” , “the whole page” with “the whole non-web document or software”, “the Web page” with “the non-web document or software”, and removing “See Conformance Requirement 5: Non-Interference”.

With these substitutions, it would read:

2.3.1 Three Flashes or Below Threshold: Non-web documents or software 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 non-web document or software, all content on the non-web document or software (whether it is used to meet other success criteria or not) must meet this success criterion.

Intent from Understanding Success Criterion 2.3.1 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 2.3.1):

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.

Specific Benefits of Success Criterion 2.3.1
  • Individuals who have seizures when viewing flashing material will be able to view all of the material on a site without having a seizure and without having to miss the full experience of the content by being limited to text alternatives. This includes people with photosensitive epilepsy as well as other photosensitive seizure disorders.

Principle 3: Understandable

Information and the operation of user interface must be understandable.

Additional Guidance When Applying Principle 3 to Non-Web Documents and Software:

In WCAG 2.0, the Principles are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Principle 3 applies directly as written.

Guideline 3.1: Readable

From Guideline 3.1:

Make text content readable and understandable.

Additional Guidance When Applying Guideline 3.1 to Non-Web Documents and Software:

In WCAG 2.0, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 3.1 applies directly as written.

Intent from Understanding Guideline 3.1 in Understanding WCAG 2.0 (View full version of guidance for Guideline 3.1):

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

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

Success Criterion 3.1.1: Language of Page (Level A)

From Success Criterion 3.1.1:

The default human language of each Web page can be programmatically determined.

Additional Guidance When Applying Success Criterion 3.1.1 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.1 (also provided below) replacing “each web page” with non-web documents or software.

With these substitutions, it would read:

3.1.1 Language of Page: The default human language of non-web documents or software can be programmatically determined. (Level A)

Note 1: Where software platforms provide a “locale / language” setting, applications that use that setting and render their interface in that “locale / language” would comply with this success criterion. Applications that do not use the platform “locale / language” setting but instead use an accessibility-supported method for exposing the human language of the software would also comply with this success criterion. Applications implemented in technologies where assistive technologies cannot determine the human language and that do not support the platform “locale / language” setting may not be able to meet this success criterion in that locale / language.

Note 2: See also the discussion on Closed Functionality in the Introduction.

Intent from Understanding Success Criterion 3.1.1 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 3.1.1):

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.

Specific Benefits of Success Criterion 3.1.1

This Success Criterion helps:

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

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

Success Criterion 3.1.2: Language of Parts (Level AA)

From Success Criterion 3.1.2:

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.

Additional Guidance When Applying Success Criterion 3.1.2 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.2 (also provided below) replacing “content” with “non-web document or software”.

With these substitutions, it would read:

3.1.2 Language of Parts: The human language of each passage or phrase in the non-web document or software 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)

Note 1: There are some software and non-web document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the non-web document or software, and it would not be possible to meet this success criterion with those technologies.

Note 2: See also the discussion on Closed Functionality in the Introduction.

Intent from Understanding Success Criterion 3.1.2 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 3.1.2):

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.

Specific Benefits of Success Criterion 3.1.2

This Success Criterion helps:

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

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

Guideline 3.2: Predictable

From Guideline 3.2:

Make Web pages appear and operate in predictable ways.

Additional Guidance When Applying Guideline 3.2 to Non-Web Documents and Software:

In WCAG 2.0, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 3.2 applies directly as written, replacing “web pages” with “non-web documents or software”.

With this substitution, this guideline would read:

Guideline 3.2 Predictable: Make non-web documents or software appear and operate in predictable ways.

Intent from Understanding Guideline 3.2 in Understanding WCAG 2.0 (View full version of guidance for Guideline 3.2):

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.

Success Criterion 3.2.1: On Focus (Level A)

From Success Criterion 3.2.1:

When any component receives focus, it does not initiate a change of context.

Additional Guidance When Applying Success Criterion 3.2.1 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.2.1 (also provided below).

Note: Some compound documents and their user agents are designed to provide significantly different viewing and editing functionality depending upon what portion of the compound document is being interacted with (e.g. a presentation that contains an embedded spreadsheet, where the menus and toolbars of the user agent change depending upon whether the user is interacting with the presentation content, or the embedded spreadsheet content). If the user uses a mechanism other than putting focus on that portion of the compound document with which they mean to interact (e.g. by a menu choice or special keyboard gesture), any resulting change of context wouldn't be subject to this success criterion because it was not caused by a change of focus.

Intent from Understanding Success Criterion 3.2.1 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 3.2.1):

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

Specific Benefits of Success Criterion 3.2.1
  • This Success Criterion helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a change of context will occur unexpectedly.

Success Criterion 3.2.2: On Input (Level A)

From Success Criterion 3.2.2:

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.

Additional Guidance When Applying Success Criterion 3.2.2 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.2.2 (also provided below).

Intent from Understanding Success Criterion 3.2.2 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 3.2.2):

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 state in the control that will persist when the user is no longer interacting with it. So checking a checkbox or entering text into a text field 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".

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

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

    • Individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as a new window popping up. In this case, warning users of context changes in advance minimizes confusion when the user discovers that the back button no longer behaves as expected.

  • Some individuals with low vision, with reading and intellectual disabilities, and others who have difficulty interpreting visual cues may benefit from additional cues in order to detect changes of context.

Success Criterion 3.2.3: Consistent Navigation (Level AA)

From Success Criterion 3.2.3:

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.

Additional Guidance When Applying Success Criterion 3.2.3 to Non-Web Documents and Software:

This applies directly as written and described in Intent from Understanding Success Criterion 3.2.3 (also provided below), replacing “web pages” with “non-web documents” and “software programs”.

With these substitutions, this success criterion would read:

(for non-web documents)

3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple non-web documents within a set of non-web documents occur in the same relative order each time they are repeated, unless a change is initiated by the user.

(for software programs)

3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple software programs within a set of software programs occur in the same relative order each time they are repeated, unless a change is initiated by the user.

Note 1: See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or software programs is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.)

Note 2: Although not required by this success criterion, ensuring that navigation elements have consistent order when repeated within non-web documents or software programs directly addresses user needs identified in the Intent section for this Success Criterion, and is generally considered best practice.

Intent from Understanding Success Criterion 3.2.3 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 3.2.3):

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.

Specific Benefits of Success Criterion 3.2.3
  • Ensuring that repeated components occur in the same order on each page of a site helps users become comfortable that they will able to predict where they can find things on each page. This helps users with cognitive limitations, users with low vision, users with intellectual disabilities, and also those who are blind.

Success Criterion 3.2.4: Consistent Identification (Level AA)

From Success Criterion 3.2.4:

Components that have the same functionality within a set of Web pages are identified consistently.

Additional Guidance When Applying Success Criterion 3.2.4 to Non-Web Documents and Software:

This applies directly as written and described in Intent from Understanding Success Criterion 3.2.4 (also provided below), replacing “web pages” with “non-web documents” and “software programs”.

With these substitutions, this success criterion would read:

(for non-web documents)

3.2.4 Consistent Identification: Components that have the same functionality within a set of non-web documents are identified consistently.

(for programs)

3.2.4 Consistent Identification: Components that have the same functionality within a set of software programs are identified consistently.

Note 1: See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or software programs is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.)

Note 2: Although not required by this success criterion, ensuring that component identification be consistent when they occur more than once within non-web documents or software programs directly addresses user needs identified in the Intent section for this Success Criterion, and is generally considered best practice.

Intent from Understanding Success Criterion 3.2.4 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 3.2.4):

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.

Specific Benefits of Success Criterion 3.2.4
  • People who learn functionality on one page on a site can find the desired functions on other pages if they are present.

  • When non-text content is used in a consistent way to identify components with the same functionality, people with difficulty reading text or detecting text alternatives can interact with the Web without depending on text alternatives.

  • People who depend on text alternatives can have a more predictable experience. They can also search for the component if it has a consistent label on different pages.

Guideline 3.3: Input Assistance

From Guideline 3.3:

Help users avoid and correct mistakes.

Additional Guidance When Applying Guideline 3.3 to Non-Web Documents and Software:

In WCAG 2.0, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 3.3 applies directly as written.

Intent from Understanding Guideline 3.3 in Understanding WCAG 2.0 (View full version of guidance for Guideline 3.3):

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

Success Criterion 3.3.1: Error Identification (Level A)

From Success Criterion 3.3.1:

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.

Additional Guidance When Applying Success Criterion 3.3.1 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.1 (also provided below).

Note: See also the discussion on Closed Functionality in the Introduction.

Intent from Understanding Success Criterion 3.3.1 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 3.3.1):

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.

Specific Benefits of Success Criterion 3.3.1
  • Providing information about input errors in text allows users who are blind or colorblind to perceive the fact that an error occurred.

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

Success Criterion 3.3.2: Labels or Instructions (Level A)

From Success Criterion 3.3.2:

Labels or instructions are provided when content requires user input.

Additional Guidance When Applying Success Criterion 3.3.2 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.2 (also provided below).

Intent from Understanding Success Criterion 3.3.2 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 3.3.2):

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.

Specific Benefits of Success Criterion 3.3.2
  • 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.

Success Criterion 3.3.3: Error Suggestion (Level AA)

From Success Criterion 3.3.3:

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.

Additional Guidance When Applying Success Criterion 3.3.3 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.3 (also provided below).

Intent from Understanding Success Criterion 3.3.3 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 3.3.3):

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.

Specific Benefits of Success Criterion 3.3.3
  • 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.

Success Criterion 3.3.4: Error Prevention (Legal, Financial, Data) (Level AA)

From Success Criterion 3.3.4:

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:

  1. Reversible: Submissions are reversible.

  2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.

  3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Additional Guidance When Applying Success Criterion 3.3.4 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.4 (also provided below) replacing “web pages” with “non-web documents or software”.

With this substitution, it would read:

3.3.4 Error Prevention (Legal, Financial, Data): For non-web documents or software 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)

  1. Reversible: Submissions are reversible.

  2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.

  3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Intent from Understanding Success Criterion 3.3.4 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 3.3.4):

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.

Specific Benefits of Success Criterion 3.3.4
  • Providing safeguards to avoid serious consequences resulting from mistakes helps users with all disabilities who may be more likely to make mistakes.

Principle 4: Robust

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

Additional Guidance When Applying Principle 4 to Non-Web Documents and Software:

In WCAG 2.0, the Principles are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Principle 4 applies directly as written replacing “user agents, including assistive technologies” with “assistive technologies and accessibility features of software”.

With this substitution, it would read:

Principle 4: Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of assistive technologies and accessibility features of software.

Guideline 4.1: Compatible

From Guideline 4.1:

Maximize compatibility with current and future user agents, including assistive technologies.

Additional Guidance When Applying Guideline 4.1 to Non-Web Documents and Software:

In WCAG 2.0, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 4.1 applies directly as written, replacing “user agents, including assistive technologies” with “assistive technologies and accessibility features of software”.

With this substitution, it would read:

Guideline 4.1 Compatible: Maximize compatibility with current and future assistive technologies and accessibility features of software.

Intent from Understanding Guideline 4.1 in Understanding WCAG 2.0 (View full version of guidance for Guideline 4.1):

The purpose of this guideline is to support compatibility with current and future user agents, especially assistive technologies (AT). This is done both by 1) ensuring that authors do not do things that would break AT (e.g., poorly formed markup) or circumvent AT (e.g., by using unconventional markup or code) and 2) exposing information in the content in standard ways that assistive technologies can recognize and interact with. Since technologies change quickly, and AT developers have much trouble keeping up 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.

Success Criterion 4.1.1: Parsing (Level A)

From Success Criterion 4.1.1:

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.

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.

Additional Guidance When Applying Success Criterion 4.1.1 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.1 (also provided below), replacing “In content implemented using markup languages” with “For non-web documents or software that use markup languages, in such a way that the markup is separately exposed and available to assistive technologies and accessibility features of software or to a user-selectable user agent”.

With these substitutions, it would read:

4.1.1 Parsing: For non-web documents or software that use markup languages, in such a way that the markup is separately exposed and available to assistive technologies and accessibility features of software or to a user-selectable user agent, 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.

Note: Markup is not always available to assistive technologies or to user selectable user agents such as browsers. Software sometimes uses markup languages internally for persistence of the software user interface, in ways where the markup is never available to assistive technology (either directly or through a document object model (DOM)), or to a user agent (such as a browser). In such cases, conformance to this provision would have no impact on accessibility as it can have for web content where it is exposed.

Examples of markup that is separately exposed and available to assistive technologies and to user agents include: documents encoded in HTML, ODF, and OOXML. In these examples, the markup can be parsed entirely in two ways: (a) by assistive technologies which may directly open the document, (b) by assistive technologies using DOM APIs of user agents for these document formats.

Examples of markup used internally for persistence of the software user interface that are never exposed to assistive technology include but are not limited to: XUL, GladeXML, and FXML. In these examples assistive technology only interacts with the user interface of generated software.

Note: See also the discussion on Closed Functionality in the Introduction.

Intent from Understanding Success Criterion 4.1.1 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 4.1.1):

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.

Specific Benefits of Success Criterion 4.1.1
  • 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.

Success Criterion 4.1.2: Name, Role, Value (Level A)

From Success Criterion 4.1.2:

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.

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.

Additional Guidance When Applying Success Criterion 4.1.2 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.2 (also provided below), replacing the note with: “This success criterion is primarily for software developers who develop or use custom user interface components. For example, standard user interface components on most accessibility-supported platforms already meet this success criterion when used according to specification.”.

With this substitution, it would read:

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 software developers who develop or use custom user interface components. Standard user interface components on most accessibility-supported platforms already meet this success criterion when used according to specification.

Note 1: For conforming to this success criterion, it is usually best practice for software user interfaces to use the accessibility services provided by platform software. These accessibility services enable interoperability between software user interfaces and both assistive technologies and accessibility features of sofware in standardised ways. Most platform accessibility services go beyond programmatic exposure of name and role, and programmatic setting of states, properties and values (and notification of same), and specify additional information that could or should be exposed and / or set (for instance, a list of the available actions for a given user interface component, and a means to programmatically execute one of the listed actions).

Note 2: For document formats that support interoperability with assistive technology, standard user interface components often meet this success criterion when used according to the general design and accessibility guidance for the document format.

Note 3: See also the discussion on Closed Functionality in the Introduction.

Intent from Understanding Success Criterion 4.1.2 in Understanding WCAG 2.0 (View full version of guidance for Success Criterion 4.1.2):

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.

Specific Benefits of Success Criterion 4.1.2
  • Providing role, state, and value information on all user interface components enables compatibility with assistive technology, such as screen readers, screen magnifiers, and speech recognition software, used by people with disabilities.

7. Comments on Definitions in WCAG 2.0 Glossary in Appendix A

The following is a complete list of definitions from the WCAG 2.0 glossary. Some items apply to all technologies and do not require additional guidance in this document; guidance on the remainder follows.

7.1. Glossary Items that Apply to All Technologies

The following glossary items apply to all technologies and do not require further interpretation for non-web Information and Communications Technologies.

7.2. Glossary Items Used only in AAA Success Criteria

This document does not provide guidance on applying AAA Success Criteria to non-web ICT, including the following definitions.

7.3. Glossary Items with Specific Guidance

Additional guidance is provided for the following glossary entries from WCAG 2.0 when applying them to non-web documents and software.

accessibility supported

From the WCAG 2.0 definition for accessibility supported:

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

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

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

    1. The technology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS);

      OR

    2. The technology is supported in a widely-distributed plug-in that is also accessibility supported;

      OR

    3. The content is available in a closed environment, such as a university or corporate network, where the user agent required by the technology and used by the organization is also accessibility supported;

      OR

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

Additional Guidance When Applying the Definition of “accessibility supported” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “browsers and other user agents” with “user agents or other software”, replacing “user agents” with “user agents or other software”, replacing “web content technology” with “non-web document or software technology”, adding “or other software extension” after “plug-in”, and replacing all five of the Notes with a single new Note: “Note: The concepts behind the five Notes and in Understanding Accessibility Supported are applicable to web technologies. The same or similar factors are applicable for non-web technologies.”

With these substitutions and addition, it would read:

accessibility supported

supported by users' assistive technologies as well as the accessibility features in user agents or other software

To qualify as an accessibility-supported use of a non-web document or software technology (or feature of a technology), both 1 and 2 must be satisfied for a non-web document or software technology (or feature):

  1. The way that the non-web document or software 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

  2. The non-web document or software technology must have accessibility-supported user agents or other software that are available to users. This means that at least one of the following four statements is true:

    1. The technology is supported natively in widely-distributed user agents or other software that are also accessibility supported (such as HTML and CSS);

      OR

    2. The technology is supported in a widely-distributed plug-in or other software extension that is also accessibility supported;

      OR

    3. The content is available in a closed environment, such as a university or corporate network, where the user agent or other software required by the technology and used by the organization is also accessibility supported;

      OR

    4. 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: The concepts behind the five Notes and in Understanding Accessibility Supported are applicable to web technologies. The same or similar factors are applicable for non-web technologies.

ambiguous to users in general

From the WCAG 2.0 definition for ambiguous to users in general:

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.

Additional Guidance When Applying the Definition of “ambiguous to users in general” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “Web page” with “non-web document or software”.

With this substitution, it would read:

the purpose cannot be determined from the link and all information of the non-web document or software 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.

assistive technology (as used in this document)

From the WCAG 2.0 definition for assistive technology (as used in this document):

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.

Additional Guidance When Applying the Definition of “assistive technology (as used in this document)” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “acts as a user agent” with “acts stand-alone”, replacing “mainstream user agent[s]” with “mainstream information and communication technologies (ICT)” (later “mainstream ICT[s])”, and replacing “Web content” with “content”.

With these substitutions, it would read:

assistive technology (as used in this document)

hardware and/or software that acts stand-alone, or along with mainstream information and communication technologies (ICT), to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream ICT

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 ICTs by using and monitoring APIs.

Note 3: The distinction between mainstream ICTs and assistive technologies is not absolute. Many mainstream ICTs provide some features to assist individuals with disabilities. The basic difference is that mainstream ICTs 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 ICT may provide important functionality to assistive technologies like retrieving 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.

changes of context

From the WCAG 2.0 definition for changes of context:

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:

  1. user agent;

  2. viewport;

  3. focus;

  4. content that changes the meaning of the Web page.

Note: A change of content is not always a change of context. 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.

Additional Guidance When Applying the Definition of “changes of context” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “Web page” and “page” with “non-web document or content presented by software”.

With this substitution, it would read:

changes of context

major changes in the content of the non-web document or content presented by software that, if made without user awareness, can disorient users who are not able to view the entire non-web document or content presented by software simultaneously

Changes in context include changes of:

  1. user agent;

  2. viewport;

  3. focus;

  4. content that changes the meaning of the non-web document or content presented by software.

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.

Note: a change in the user agent might include bringing up a new window, or might be a significant change in the menus and/or toolbars that are displayed and available for interacting with some portion of the document.

conformance

From the WCAG 2.0 definition for conformance:

satisfying all the requirements of a given standard, guideline or specification

Additional Guidance When Applying the Definition of “conformance” to Non-Web Documents and Software:

The guidance in this document does not use the term “conformance”.

See Section 6 Comments on Conformance.

conforming alternate version

From the WCAG 2.0 definition for conforming alternate version:

version that

  1. conforms at the designated level, and

  2. provides all of the same information and functionality in the same human language, and

  3. is as up to date as the non-conforming content, and

  4. for which at least one of the following is true:

    1. the conforming version can be reached from the non-conforming page via an accessibility-supported mechanism, or

    2. the non-conforming version can only be reached from the conforming version, or

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

Additional Guidance When Applying the Definition of “conforming alternate version” to Non-Web Documents and Software:

The guidance in this document does not use the term “conforming alternate version”.

See Section 6 Coments on Conformance.

content (Web content)

From the WCAG 2.0 definition for content (Web content):

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions

Additional Guidance When Applying the Definition of “content (Web content)” to Non-Web Documents and Software:

See the guidance on content in the Key Terms section.

contrast ratio

From the WCAG 2.0 definition for contrast ratio:

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

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.

Additional Guidance When Applying the Definition of “contrast ratio” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary.

Because relative luminance is defined such that it cannot directly apply to hardware, please note the text in the introduction which reads: “This document does not comment on hardware aspects of products, non-UI aspects of platforms, or the application of WCAG 2.0 for user-interface components as a category, because the basic constructs on which the WCAG 2.0 and / or its conformance are built do not apply to these.”

general flash and red flash thresholds

From the WCAG 2.0 definition for general flash and red flash thresholds:

a flash or rapidly changing image sequence is below the threshold (i.e., content passes) if any of the following are true:

  1. there are no more than three general flashes and / or no more than three red flashes within any one-second period; or

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

Additional Guidance When Applying the Definition of “general flash and red flash thresholds” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary.

Note: because this deals with relative luminance and not luminance, it can only be applied to information on a display, not to hardware sources of light.

input error

From the WCAG 2.0 definition for input error:

information provided by the user that is not accepted

Note: This includes:

  1. Information that is required by the Web page but omitted by the user

  2. Information that is provided by the user but that falls outside the required data format or values

Additional Guidance When Applying the Definition of “input error” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “Web page” with “non-web document or software”.

With this substitution, it would read:

input error

information provided by the user that is not accepted

Note: This includes:

  1. Information that is required by the non-web document or software but omitted by the user

  2. Information that is provided by the user but that falls outside the required data format or values

keyboard interface

From the WCAG 2.0 definition for keyboard interface:

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.

Additional Guidance When Applying the Definition of “keyboard interface” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary.

Please see the note in the guidance for Success Criterion 2.1.1 that uses this definition and which reads: “This does not imply that software must directly support a keyboard or ‘keyboard interface’. Nor does it imply that software must provide a soft keyboard. Underlying platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard and would comply.”

label

From the WCAG 2.0 definition for label:

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.

Additional Guidance When Applying the Definition of “label” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “Web Content” with “content” and adding “or by accessibility features of software” after “assistive technology” in Note 1.

With this substitution, it would read:

label

text or other component with a text alternative that is presented to a user to identify a component within content

Note 1: A label is presented to all users whereas the name may be hidden and only exposed by assistive technology or by accessibility features of software. 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.

name

From the WCAG 2.0 definition for name:

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

Note 1: The name may be hidden and only exposed by assistive technology, whereas a label is presented 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.

Additional Guidance When Applying the Definition of “name” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “Web content” with “content” and adding “or by accessibility features of software” after “assistive technology” in Note 1.

With this substitution, it would read:

name

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

Note 1: The name may be hidden and only exposed by assistive technology or by accessibility features of software, 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.

Note: “AccessibleName” (or whatever it is called in different APIs) of the Accessibility API of the platform is an example of such a name.

process

From the WCAG 2.0 definition for process:

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.

Additional Guidance When Applying the Definition of “process” to Non-Web Documents and Software:

This term is only used in success criterion 2.4.5 Multiple Ways. The definitions of set of documents and set of software programs in WCAG2ICT require every item in the set to be independently reachable, and so nothing in such a set can be a “step in a process” that can't be reached any other way. The purpose of the term's use in 2.4.5 Multiple Ways (that items in a process are exempt from meeting that success criterion) is achieved by the definitions of set of documents and set of software programs.

programmatically determined (programmatically determinable)

From the WCAG 2.0 definition for programmatically determined (programmatically determinable):

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.

Additional Guidance When Applying the Definition of “programmatically determined (programmatically determinable)” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “user agents, including assistive technologies” with “assistive technologies and accessibility features of software” and adding and “accessibility features of software” after “assistive technology”.

With this substitution, it would read:

programmatically determined (programmatically determinable)

determined by software from author-supplied data provided in a way that different assistive technologies and accessibility features of software, 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 and accessibility features of software.

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

Note: Software typically enables content to be programmatically determined through the use of accessibility services of platform software. Non-web documents typically enable content to be programmatically determined through the use of accessibility services of the user agent.

programmatically set

From the WCAG 2.0 definition for programmatically set:

set by software using methods that are supported by user agents, including assistive technologies

Additional Guidance When Applying the Definition of “programmatically set” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “user agents, including assistive technologies” with “assistive technologies and accessibility features of software”.

With this substitution, it would read:

programmatically set

set by software using methods that are supported by assistive technologies and accessibility features of software

Note: Software typically enables content to be programmatically determined through the use of accessibility services of platform software. Non-web documents typically enable content to be programmatically determined through the use of accessibility services of the user agent.

relative luminance

From the WCAG 2.0 definition for relative luminance:

the relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for lightest white

Note 1: For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as:

  • if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4

  • if GsRGB <= 0.03928 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4

  • if BsRGB <= 0.03928 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4

and RsRGB, GsRGB, and BsRGB are defined as:

  • RsRGB = R8bit/255

  • GsRGB = G8bit/255

  • BsRGB = B8bit/255

The "^" character is the exponentiation operator. (Formula taken from [sRGB] and [IEC-4WD]).

Note 2: Almost all systems used today to view Web content assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3.

Note 3: If dithering occurs after delivery, then the source color value is used. For colors that are dithered at the source, the average values of the colors that are dithered should be used (average R, average G, and average B).

Note 4: Tools are available that automatically do the calculations when testing contrast and flash.

Note 5: A MathML version of the relative luminance definition is available.

Additional Guidance When Applying the Definition of “relative luminance” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “Web content” with “content”.

With this substitution, it would read:

relative luminance

the relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for lightest white

Note 1: For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as:

  • if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4

  • if GsRGB <= 0.03928 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4

  • if BsRGB <= 0.03928 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4

and RsRGB, GsRGB, and BsRGB are defined as:

  • RsRGB = R8bit/255

  • GsRGB = G8bit/255

  • BsRGB = B8bit/255

The “^” character is the exponentiation operator. (Formula taken from [sRGB] and [IEC-4WD]).

Note 2: Almost all systems used today to view content assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3.

Note 3: If dithering occurs after delivery, then the source color value is used. For colors that are dithered at the source, the average values of the colors that are dithered should be used (average R, average G, and average B).

Note 4: Tools are available that automatically do the calculations when testing contrast and flash.

Note 5: A MathML version of the relative luminance definition is available.

Because relative luminance is defined such that it cannot directly apply to hardware, please note the text in the introduction which reads: “This document does not comment on hardware aspects of products, non-UI aspects of platforms, or the application of WCAG 2.0 for user-interface components as a category, because the basic constructs on which the WCAG 2.0 and / or its conformance are built do not apply to these.”

role

From the WCAG 2.0 definition for role:

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.

Additional Guidance When Applying the Definition of “role” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “Web content” with “content”.

With this substitution, it would read:

role

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

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

Note: “AccessibleRole” (or however it is called in different APIs) of the Accessibility API of the platform is an example of such a role.

same functionality

From the WCAG 2.0 definition for same functionality :

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.

Additional Guidance When Applying the Definition of “same functionality ” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, adding a second example (and numbering the first).

With these substitutions, it would read:

same functionality

same result when used

Example 1: 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.

Example 2: A ribbon icon that saves the document that looks like an arrow pointing into a folder in one case, and an arrow pointing into a hard drive in another. In this case as well, they would have the same functionality but would not be labeled consistently.

satisfies a success criterion

From the WCAG 2.0 definition for satisfies a success criterion:

the success criterion does not evaluate to 'false' when applied to the page

Additional Guidance When Applying the Definition of “satisfies a success criterion” to Non-Web Documents and Software:

The guidance in this document does not use the term “satisfies a success criterion”.

See Section 6 Comments on Conformance.

set of Web pages

From the WCAG 2.0 definition for set of Web pages:

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.

Additional Guidance When Applying the Definition of “set of Web pages” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary.

Note: For those success criteria that use the term “set of web pages” explicitly or implicitly (2.4.1, 2.4.5, 3.2.3, and 3.2.4) WCAG2ICT provides specific replacement term(s) for “set of Web pages”.

structure

From the WCAG 2.0 definition for structure:

  1. The way the parts of a Web page are organized in relation to each other; and

  2. The way a collection of Web pages is organized

Additional Guidance When Applying the Definition of “structure” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “a Web page” with “non-web documents or software” and replacing “collection of Web pages” with “set of documents or set of software programs”.

With these substitutions, it would read:

structure
  1. The way the parts of non-web documents or software are organized in relation to each other; and

  2. The way a set of documents or set of software programs is organized

Note 1: See the guidance on user sets of documents and sets of software programs in the Key Terms section.

Note 2: “AccessibleRole” (or however it is called in different APIs) of the Accessibility API of the platform is an example of such a role.

technology (Web content)

From the WCAG 2.0 definition for technology (Web content):

mechanism for encoding instructions to be rendered, played or executed by user agents

Note 1: As used in these guidelines "Web Technology" and the word "technology" (when used alone) both refer to Web Content Technologies.

Note 2: Web content technologies may include markup languages, data formats, or programming languages that authors may use alone or in combination to create end-user experiences that range from static Web pages to synchronized media presentations to dynamic Web applications.

Example: Some common examples of Web content technologies include HTML, CSS, SVG, PNG, PDF, Flash, and JavaScript.

Additional Guidance When Applying the Definition of “technology (Web content)” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “web content” with “non-web document or software”, “user agents” with “user agents or other software”, removing the notes, and replacing the example with “Example: Some common examples of non-web document and software technologies include ODF, OOXML, Java, and C++.”

With these substitutions, it would read:

technology (non-web document or software)

mechanism for encoding instructions to be rendered, played or executed by user agents or other software.

Example: Some common examples of non-web document and software technologies include ODF, OOXML, Java, and C++.

user agent

From the WCAG 2.0 definition for user agent:

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.

Additional Guidance When Applying the Definition of “user agent” to Non-Web Documents and Software:

See the guidance on user agent in the Key Terms section.

user interface component

From the WCAG 2.0 definition for user interface component:

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

Additional Guidance When Applying the Definition of “user interface component” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing the example with “Example: A software program has 2 controls: a text field for entering a file name and a drop down list box for choosing a folder. Each is a user interface component with a name that is settable by the software.”

With this substitution, it would read:

user interface component

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: A software program has 2 controls: a text field for entering a file name and a drop down list box for choosing a folder. Each is a user interface component with a name that is settable by the software.

viewport

From the WCAG 2.0 definition for viewport:

object in which the user agent presents content

Note 1: The user agent presents content through one or more viewports. Viewports include windows, frames, loudspeakers, and virtual magnifying glasses. A viewport may contain another viewport (e.g., nested frames). Interface components created by the user agent such as prompts, menus, and alerts are not viewports.

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

Additional Guidance When Applying the Definition of “viewport” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary, replacing “user agent” with “software”.

With this substitution, it would read:

viewport

object in which the software presents content

Note 1: The software presents content through one or more viewports. Viewports include windows, frames, loudspeakers, and virtual magnifying glasses. A viewport may contain another viewport (e.g., nested frames). Interface components created by the software such as prompts, menus, and alerts are not viewports.

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

Web page

From the WCAG 2.0 definition for Web page:

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.

Additional Guidance When Applying the Definition of “Web page” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.0 glossary.

Note: For those success criteria that use the term “web page”, WCAG2ICT provides specific replacement term(s) for “Web page”.

Appendix A. Success Criteria Problematic for Closed Functionality

The following success criteria will be problematic for developers of closed functionality. They either discuss making information available in text (which can be read by assistive technologies) or making it “programmatically determinable” (rendered by a user agent and readable by assistive technologies) or discuss doing something else to make content compatible with assistive technologies. Alternate accessibility provisions that would be needed to address the purpose of these success criteria for the closed functionality aspects of products:

Note 1: Some of the above success criteria would apply to systems with closed functionality if they are partially closed or if they allow for the connection of some types of devices. For instance, Success Criterion 2.1.1 Keyboard would apply to systems which have closed functionality to screen readers but which have a physical keyboard or a connector for standard keyboards.

Note 2: While these guidelines are not suitable for closed functionality as written, they will inform and aid development of built-in accessible alternatives needed with closed functionality.

Appendix B. Background on Text / Command-line / Terminal Applications and Interfaces

Appendix B.1. How text interfaces are realized

The interface of a text application is realized through a text application directing which characters should be placed on the screen, along with either a hardware terminal or a terminal application that displays the characters produced by the text application. Some text applications render like a TeleTYpewriter (“TTY”); their output is always appended, like an ever growing file. Such text applications are often called “command-line applications” or occasionally “TTY-applications”, and their output can optionally be redirected to a file for later review. Others explicitly place text into a matrix of fixed width character cells on a screen (sometimes with specific foreground and background colors). Similar to a web application, the text application may execute primarily on a remote server or execute locally, and a local client terminal application handles the visual display (similar to a web user agent). Input to the text application itself is provided exclusively through a keyboard interface.

Appendix B.2. How text applications have been made accessible via assistive technology

Strategies for making text applications accessible through assistive technology involve two key tasks: (1) obtaining all of the text displayed in the interface, and (2) performing an analysis on that text to discern structural elements and screen updates.

For example, a text application screen reader might directly access the matrix of character cells in the interface and provide a screen review mechanism for the user to review that matrix of characters (by sending the output to synthetic speech and / or a braille display). Alternately, a text application screen reader might directly consume the output rendered (perhaps by acting as its own terminal application or by analyzing the “TTY” output). The text application screen reader would also analyze the spacing and layout of the text in the matrix to provide features such as reading columns of text in a multi-column layout, discerning headers through analysis of line spacing, indentation and capitalization, and discerning input fields or user interface components, etc. by scanning for the use of inverse video or for text appearing in brackets or text from the character graphics codepage (ASCII codes greater than ‘0x7F’). Some of this analysis might also be done through the use of filter tools that transform the output of a program (e.g. through reformatting “TTY” output rendered to a file or as direct input to a filter too).

Similarly, a text application screen magnifier would gain access to the matrix of character cells in order to magnify them or re-display them in a larger font. It would scan for screen refreshes / updates and apply heuristics to what had changed in order to decide what sub-matrix of character cells should appear in a magnified view. It would also scan for inverse video and a moving text cursor to track text being input by the user (and might combine the text matrix scanning with scanning of the keyboard input to match user input to what is appearing on the screen).

Appendix B.3. Applying WCAG 2.0 to text applications

To apply WCAG to text applications, it is necessary to apply the glossary terms “accessibility supported” and “programmatically determined” in the context of how text applications are rendered and the history of assistive technologies that made them accessible.

As noted above, in a text interface the terminal application renders the characters on the screen, just as a web browser typically renders content for a web application. Thus for example, in success criterion 1.4.4 Resize Text, a text application could achieve 200 percent resizing when the terminal application client that is rendering it has this capability (cf. WCAG 2.0 Technique G142 Using a technology that has commonly-available user agents that support zoom). Many web pages and web applications use this approach to meet success criterion 1.4.4 Resize Text through no explicit action of their own.

A similar approach could also be used for success criterion 1.4.3 Contrast (minimum) (cf. WCAG 2.0 Technique G148: Not specifying background color, not specifying text color, and not using technology features that change those defaults): relying on the terminal application client to render the text with sufficient contrast against the background. In fact, many terminal applications allow the user to force all text to share a single user-chosen foreground color (and a single user-chosen background color), overriding the text application's specified colors in order to meet the user's desires or needs.

Since many assistive technology analysis techniques depend upon discerning the location of the text input cursor, terminal application use of “soft cursors” and “highlight bars” may bypass those analysis techniques and cause failures of success criteria.

Note: It is outside of the scope of this document to define WCAG techniques for non-web ICT. These examples are simply raised here to illustrate how WCAG 2.0 success criteria can be applied to this older class of applications that pre-date the Web.

The way to think about “accessibility supported” and “programmatically determined” may seem a little different for text applications, but the definitions are unchanged. Because assistive technologies developed analysis techniques to recognize many forms of tabular layout, column headers, and section headings, such recognized layouts are by definition “accessibility supported”. Where assistive technology is able to extract and present that information, it is “programmatically determinable”—even though no explicit markup or API was used to make it so. While such assistive technology analysis techniques are not used for supporting newer technologies, the fact that such previous analysis work was done allows us to apply WCAG 2.0 to text / command-line applications.

Note: The terminal application itself is “traditional” non-web software ICT. It is only for the text application that there is a need to take this approach with these glossary terms.

Appendix C. Acknowledgements

Appendix C.1. Participants in the WCAG2ICT Task Force

The following people were active participants in the WCAG2ICT Task Force, which had a primary role in preparation of this document:

Appendix C.2. Participants in the WCAG Working Group

The following people were active participants in the Web Content Accessibility Guidelines Working Group, which reviewed materials to ensure consistency with the intent of WCAG 2.0 and provided final approval of the Working Group Note:

Appendix C.3. Enabling funders

This publication has been funded in part with Federal funds from the U.S. Department of Education, National Institute on Disability and Rehabilitation Research (NIDRR) under contract number ED-OSE-10-C-0067. 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.

Appendix D. References

UNDERSTANDING-WCAG20
Understanding WCAG 2.0, M. Cooper, L. Guarino Reid, G. Vanderheiden, Editors, W3C Working Group Note, 3 January 2012, http://www.w3.org/TR/2012/NOTE-UNDERSTANDING-WCAG20-20120103/. Latest version available at http://www.w3.org/TR/UNDERSTANDING-WCAG20/.
WCAG20
Web Content Accessibility Guidelines (WCAG) 2.0, B. Caldwell, M. Cooper, L. Guarino Reid, G. Vanderheiden, Editors, W3C Recommendation, 11 December 2008, http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Latest version available at http://www.w3.org/TR/WCAG20/.
WCAG20-TECHS
Techniques for WCAG 2.0, M. Cooper, L. Guarino Reid, G. Vanderheiden, Editors, W3C Working Group Note, 3 January 2012, http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/. Latest version available at http://www.w3.org/TR/WCAG20-TECHS/.