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


[contents]

W3C

Web Content Accessibility Guidelines 2.0

W3C Working Draft 17 May 2007 -- Review Version

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

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


Abstract

Web Content Accessibility Guidelines 2.0 (WCAG 2.0) covers a wide range of [begin delete]issues and [end delete]recommendations for making Web content more accessible. [begin delete]This document contains principles, guidelines, and success criteria that define and explain the requirements for making Web-based information and applications accessible. "Accessible" means usable by a wide range of[end delete] [begin add]Following these guidelines will make content accessible to a wider range of[end add] people with disabilities, including blindness and low vision, deafness and hearing loss, [begin delete]language, [end delete]learning [begin change]disabilities[end change], cognitive limitations, limited movement, speech difficulties, photosensitivity and combinations of these. Following these guidelines will also make your Web content more accessible to the vast majority of users, including [begin add]some [LC-586] [end add] older users. [begin delete]It will also enable people to access Web content using many different devices - including a wide variety of Assistive technology (as used in this document 732 ). [LC-860] [end delete] [begin add]These guidelines however are not able to address the needs of all people with disabilities.[end add]

WCAG 2.0 success criteria are written as testable statements that are not technology-specific. Guidance about satisfying the success criteria in specific technologies as well as general information about interpreting the success criteria are provided in separate documents. An Overview of Web Content Accessibility Guidelines (WCAG) 2.0 Last Call Documents is also available.

Until WCAG 2.0 advances to W3C Recommendation, the current and referenceable document is Web Content Accessibility Guidelines 1.0 [WCAG10], published as a W3C Recommendation May 1999.

Status of this Document

May be Superseded

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

Public Working Draft of WCAG 2.0

This Public Working Draft from the Web Content Accessibility Guidelines Working Group integrates changes to the "Web Content Accessibility Guidelines 2.0" (WCAG 2.0) in response to comments received on the 27 April 2006 Last Call Working Draft. Because there were a number of substantive changes, WCAG 2.0 has been returned to Public Working Draft status, and we expect to advance WCAG 2.0 to a second Last Call Working Draft after this Working Draft. See How WAI Develops Accessibility Guidelines through the W3C Process for more background on document maturity levels.

A summary of changes to the previous draft based on comments received and responses made is available. Also available is a diff-marked version of WCAG 2.0 and History of Changes to WCAG 2.0 Working Drafts.

Please comment by 29 June 2007

The Working Group seeks feedback on the following points for this draft:

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

Web Accessibility Initiative

This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals of the WCAG Working Group are discussed in the WCAG Working Group charter. The WCAG Working Group is part of the WAI Technical Activity.

No Endorsement

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Patents

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.


Table of Contents

Appendices


Introduction

This section is informative.

[begin add]

This is a Working Draft of the Web Content Accessibility Guidelines (WCAG) version 2.0. WCAG is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a single shared standard for Web accessibility that meets the needs of individuals, organizations, and governments internationally.

[end add]
[begin add]

WCAG 2.0 builds upon the work of WCAG 1.0 [WCAG10] with provisions that are more testable and that extend to a broader range of technologies including many that are new and evolving. WCAG 2.0 has been created to be technology independent. That is, the guidelines and success criteria in WCAG 2.0 can be applied across a wide range of existing and emerging Web technologies. Rather than specifying what technologies to use, WCAG 2.0 lays out general guidelines for using technologies along with specific testable success criteria for guiding and evaluating the use of the technologies.

[end add]
[begin change]

[begin delete]You are reading [begin add]a working draft of[end add] the Web Content Accessibility Guidelines (WCAG) version 2.0. This is the central document that defines the[end delete] [begin add]WCAG 2.0 provides[end add] requirements for making Web content [begin add]more[end add] accessible to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning [begin change]disabilities[end change], cognitive limitations, limited movement, speech [begin change]disabilities[end change], and others. [begin add]Because many people develop vision, hearing, [begin add]cognitive[end add] or motion impairments as they age,[end add] following these guidelines will make your Web content more usable by many [begin delete]other users, including[end delete] older users. [begin delete]It will also enable people to access Web content using many different devices - including a wide variety of Assistive technology (as used in this document 732 ) and mobile technologies.[end delete] [begin add]However, even content that completely conforms to WCAG may not be fully accessible to every person with a disability. [end add] [LC-860]

[end change]

WCAG 2.0 covers a wide range of recommendations for making Web content more accessible. The guidelines do not include standard usability recommendations except where they have [begin delete]specific impact on accessibility.[end delete] [begin add]a significantly greater impact on people with disabilities than on other people. [LC-984] [end add]

[begin add]

Although some of the accessibility issues of people with cognitive, language, and learning disabilities are addressed by WCAG 2.0, either directly or through assistive technologies, the WCAG 2.0 guidelines do not address many areas of need for people with these disabilities. There is a need for more research and development in this important area.

[end add]
[begin delete]

The WCAG 2.0 document itself consists of:

[end delete]
[begin delete]
  • This introduction

  • Information about conformance to WCAG 2.0

  • Guidelines with success criteria for each guideline

  • "How to meet" [begin change]links to information about how to meet each success criterion, including a description of the intent of the success criterion, sufficient techniques for meeting it, examples, and benefits. [LC-1012] [end change]

  • A link to information about the Working Group's approach to accessibility-supported content technologies and defining assumptions about the technologies that are available to end users

  • Appendices containing definitions, [begin delete]a checklist, [end delete]references, and other support information.

[end delete]
[begin add]

Components of Web Accessibility

It is important to note that Web content is just one aspect of accessibility. Just as important as accessible Web content is the availability of accessible browsers (and other user agents) that can adapt and present the content in the best form for the user. Accessible Web technologies and accessible tools for creating Web content are also important. For an overview of the different components of accessibility and how they work together see:

[end add]

[begin change]WCAG 2.0 Supporting Documents[end change]

[begin add]

WCAG 2.0 itself is a technical standard designed primarily for Web developers and designers, authoring tool developers, evaluation tool developers, and others who need a technical standard for Web accessibility. Due to the technical and technology-independent nature of the guidelines and success criteria, and because they say what needs to be done rather than how to do it, it may sometimes be difficult to use the guidelines or success criteria for specific advice for a particular technology (e.g. HTML, XHTML, JavaScript etc).

[end add]
[begin add]

In order to provide more concrete examples as well as specific techniques for meeting each of the success criteria, three support documents or collections have been developed by the working group to accompany the guidelines. These documents provide very specific guidance that can be used directly to meet the WCAG 2.0 guidelines.

[end add]
[begin add]

The overall set of documents from the working group consists of:

[end add]
[begin add]
  1. The WCAG 2.0 Guidelines - (this document) - This document provides the guidelines, success criteria, conformance specifications as well as the definitions of terms used in the guidelines. The actual guidelines (including success criteria) are only 9 pages long.

  2. WCAG 2.0 Quick Reference - A concise summary that includes all of the WCAG 2.0 guidelines and success criteria (from above) along with a listing of different techniques that are sufficient to meet every success criterion. It also optionally lists advisory techniques and provides links to further information on each guideline and success criterion (in Understanding WCAG 2.0). Web authors may find this the most useful document when trying to make accessible Web sites and it is a good place to start if looking for practical guidance on all of the WCAG 2.0 requirements and specific techniques to meet them.

  3. Understanding WCAG 2.0 - A collection of short (two to four page) "Understanding" documents for each section, guideline and success criterion in WCAG 2.0. Each of these short documents focuses on one guideline or success criterion. It provides the intent of the success criterion, definitions of key words, people who benefit, how to meet the success criteria, links to sufficient techniques and additional advisory techniques and examples. This collection is equivalent to an applications manual or book on WCAG 2.0.

    Editorial Note: For this release, the collection is only available as a single long document. With the next release, the individual short documents will be available as well as the full collection as one large document if desired.

  4. Techniques and Failures for WCAG 2.0 - A collection of documents each detailing one of the techniques (or known common failures) that have been documented so far. The techniques collection is continually expanding, with new techniques being added as they are completed. Due to the design of WCAG 2.0, the techniques collection can continue to grow even after the guidelines are released. The "Quick Reference" and "Understanding" documents tie the guidelines to the new techniques as they are created. Each technique document provides an overview of a single technique, notes about user agent (including assistive technology) support, examples (sometimes including code) and a test methodology for sufficient techniques (advisory techniques do not all have tests).

    Editorial Note: For this release, the Techniques collection is also only available as a single long document. With the next release, the individual technique documents will be available as well as the full collection as one large document if desired.

[end add]
[begin delete]

In addition to the Web Content Accessibility Guidelines 2.0 (this document), there are a number of WCAG 2.0 related support documents that provide additional information and examples. These documents are informative only and do not define conformance to WCAG 2.0. Only the normative Web Content Accessibility Guidelines document itself can be used for determining conformance to these guidelines. Readers should consult WCAG 2.0 in order to determine the exact wording of the success criteria and for information about documenting conformance.

[end delete]
[begin delete]

The WCAG 2.0 related support documents in this set are provided to help readers understand WCAG 2.0 and how to produce conforming content. These informative documents are written to be used by a diverse audience, including, but not limited to people who create Web content, developers who write code, quality assurance or accessibility evaluators, policy makers, managers, and Web users.

[end delete]
[begin delete]

Currently, the WCAG 2.0 related support documents include: [LC-1009]

[end delete]
[begin delete]
  • people who create Web content,

  • developers who write code,

  • quality assurance or accessibility evaluators,

  • policy makers,

  • managers,

  • users

[end delete]
[begin delete]

Currently, these informative documents include:

[end delete]
[begin delete]
  • Essential Components of Web Accessibility - Explains how the Web Content Accessibility Guidelines work with the other WAI guidelines (the User Agent Accessibility Guidelines and the Authoring Tool Accessibility Guidelines) and with assistive technologies to provide access to the Web by people with disabilities.

  • Overview of Web Content Accessibility Guidelines (WCAG) 2.0 Documents - Provides an overview of WCAG 2.0 and its various informative support documents.

  • About Baselines for WCAG 2.0 - Provides additional information on baselines.

  • Understanding WCAG 2.0 - Provides information about each success criterion, including:

    • its intent,

    • key terms from the WCAG 2.0 Glossary needed to understand the success criterion,

    • names of and links to techniques that the working group deems sufficient to meet the success criterion, and

    • examples and benefits of the success criterion.

    Note: Each of the "How to meet Success Criterion x.x.x" links in WCAG 2.0 links to the relevant section of the Understanding WCAG 2.0 document.

  • Techniques and Failures for WCAG 2.0 - Provide specific details on different techniques, including examples, code, and tests.

    Note: The development of techniques documents is an ongoing process. Developers are encouraged to submit new techniques at any time.

  • Application Notes - Provide detailed application information in different areas. For example, an application note on forms will provide a collection of techniques and strategies for creating accessible forms. It will also summarize the different success criteria that relate to forms.

    Note: Application notes are a future component that will be developed in conjunction with the Education and Outreach Working Group.

  • [begin add] WCAG 2.0 Quick Reference - A summary of all WCAG 2.0 requirements (success criteria) and techniques sufficient to meet them. [LC-817] [end add]

[end delete]
[begin delete]

The Working Group plans to publish a number of other technology-specific techniques documents and encourages development of techniques documents that show how to meet WCAG 2.0 using non-W3C technologies. Please visit the Working Group home page for a complete list of these and other informative documents related to WCAG 2.0.

[end delete]
[begin delete]

Every attempt has been made to make WCAG 2.0 and the related documents listed above as readable and usable as possible while retaining the accuracy and clarity needed in a technical specification. Sometimes technical terms are needed for clarity or testability. In these cases, the terms are defined in . To assist readers, there is a How to Meet link beside every success criterion that puts readers one click away from detailed information on that success criterion and two clicks away from the specific technique descriptions related to the success criterion.

[end delete]
[begin delete]

The Working Group recognizes that readers who are new to accessibility may need or want additional information. For these readers, the work of the Web Accessibility Initiative and its Education and Outreach Working Group is highly recommended. The articles called Getting Started: Making a Web Site Accessible and How People with Disabilities Use the Web are especially useful.

[end delete]
[begin add]

Additional Resource Documents on WCAG 2.0 and Web Accessibility

In addition to WCAG and its primary reference documents prepared by the WCAG Working group, there are a number of additional resource documents available on WCAG 2.0 and its relationship to Web accessibility. This set of documents will continue to grow even after the WCAG 2.0 is released. Documents available at the time of this document's release include:

Other documents under development include:

  • Transitioning from WCAG 1.0 to 2.0 - Information to facilitate transitioning from use of WCAG 1.0 to WCAG 2.0.

  • Application Notes - Provides detailed application information in different areas such as "Designing Accessible Web Forms," or "Creating Basic HTML Web Pages that are Accessible."

[end add]
[begin delete]

Authoring tools

A large part of Web content is created using authoring tools. These tools often determine how Web content is implemented, either by making authoring decisions directly or by limiting the choices available to the author. As a result, authoring tools [begin delete]will[end delete] play an important role in creating Web content that conforms to the Web Content Accessibility Guidelines [LC-1261] . At the same time, we recommend that all authors become familiar with the Guidelines because this will help in creating accessible content and coverage of the Guidelines may vary between tools.

Developers of authoring tools can make their tools aware of the Web Content Accessibility Guidelines by following the Authoring Tool Accessibility Guidelines. The working group encourages users and purchasers of authoring tools to consider conformance to the Authoring Tool Accessibility Guidelines as a criterion when selecting tools. The current version at WCAG 2.0's release is Authoring Tool Accessibility Guidelines 1.0. However, version 2.0 is nearing completion and it is based on WCAG 2.0. The latest version of the Authoring Tool Accessibility Guidelines 2.0 can be found at http://www.w3.org/TR/ATAG20.

[end delete]
[begin delete]

The Role of User Agents

[begin delete]

Web content is always rendered by a user agent. A user agent is any software that retrieves and [begin change]presents[end change] Web content for users and includes assistive technologies. Web content that conforms to WCAG 2.0 is most likely to be rendered correctly by user agents that conform to the User Agent Accessibility Guidelines (UAAG). For more information about the relationship between WCAG 2.0 and other WAI accessibility guidelines, see Essential Components of Web Accessibility.

[end delete]
[begin add]

Web content is always rendered by a user agent or combination of user agents, including assistive technologies. A user agent is any software that retrieves and [begin change]presents[end change] Web content for users.

[end add]
[begin add]

Different user agents, or user agents that support customization, let users customize the rendering of content into a form that best meets their needs. When Web content conforms to WCAG 2.0, the same information can be presented effectively in a variety of forms and modalities.

[end add]
[begin add]

WCAG 2.0 relies on user agents to present content in a way that meets the needs of users with disabilities. Web content that conforms to WCAG 2.0 is most likely to be accessible to users with disabilities when rendered by user agents that conform to the User Agent Accessibility Guidelines (UAAG). For more information about the relationship between WCAG 2.0 and other WAI accessibility guidelines, see Essential Components of Web Accessibility.

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

Organization of the WCAG 2.0 Document

The Four Principles

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

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

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

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

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

The Guidelines

Under each principle there is a list of guidelines that address the principle. There are a total of 12 guidelines. A convenient list of just the guidelines can be found in the table of contents.

[begin add]

Success Criteria

Under each guideline, there are success criteria that describe specifically what must be achieved in order to conform to this standard. They are similar to the "checkpoints" in WCAG 1.0. Each success criterion is written as a statement that will be either true or false when specific Web content is tested against it.

All WCAG 2.0 success criteria are written to be testable. While some can be tested by computer programs, others require human testers for part or all of the test. The same results should be obtained with a high level of confidence when people who understand how people with different types of disabilities use the Web test the same content.

Each success criterion for a guideline has a link to the section of the Quick Reference document that provides:

  • sufficient techniques for meeting the success criterion,

  • optional advisory techniques, and

  • links to descriptions of the intent of the success criteria, including benefits, and examples.

[end add]
[begin add]

Three levels of conformance

WCAG 2.0 success criteria are organized into three levels of conformance.

  • "A" (single-A) conformance: all Level A success criteria must be satisfied in order to achieve A (single-A) conformance.

  • "AA" (double-A) conformance: all Level A and Level AA success criteria must be satisfied in order to achieve AA (double-A) conformance.

  • "AAA" (triple-A) conformance: all Level A, AA, and AAA must be satisfied in order to achieve AAA (triple-A) conformance.

The word "levels" does not mean that some success criteria are more important than others. Each success criterion in WCAG 2.0 is essential to some users, and the levels build upon each other. [begin change]However, even content that conforms at AAA (triple-A) may not be fully accessible to every person with a disability or combination of disabilities, especially certain types of severe disabilities. [LC-1027] [LC-1243] [end change]

  • In general, Level A success criteria achieve accessibility by supporting assistive technology while putting the fewest possible limits on presentation. Thus people with a wide range of disabilities using a wide range of assistive technologies, from voice input and eye-tracking devices to screen readers and screen magnifiers, are able to access content in different ways. In other words, Level A success criteria support the ability of both mainstream and specialized user agents to adapt content to formats that meet their users' needs.

  • The success criteria in Level AA provide additional support for assistive technology. At the same time, they also support direct access to content by the many people who use conventional user agents without assistive technology. In general, Level AA success criteria place more limits on visual presentation and other aspects of content than the success criteria in Level A.

  • Level AAA success criteria increase both direct access and access through assistive technology. They place tighter limits on both presentation and content, which means that some types of content may not be able to satisfy this level of conformance.

It is recommended that even if content does not conform at a specific level, that it conform to the extent possible.

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

The Four Principles of Accessibility

The WCAG 2.0 Guidelines are organized around the following four principles:

[begin change]
  1. Perceivable - Information and user interface must be perceivable by the user

  2. Operable - User interface components must be operable by the user

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

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

[end change]

These four principles lay the foundation necessary for anyone to access and use Web content. WCAG 2.0 offers information about how to increase the ability of people with disabilities to perceive, operate and understand Web content. Under each principle there is a list of guidelines that address the principle. Under each guideline there are success criteria used to evaluate conformance to this standard for that guideline. Each success criterion is written as a statement that will be either true or false when specific Web content is tested against it. The success criteria are grouped into three levels of conformance, each representing a higher level of accessibility for that guideline.

The principles, guidelines, and success criteria represent concepts that address accessibility issues and needs, regardless of the technology used. They are not specific to HTML, XML, or any other technology. This approach makes it possible to apply WCAG 2.0 to a variety of situations and technologies[begin delete], including those that do not yet exist [LC-1207] [end delete].

[begin change]

The principles and guidelines give direction and guidance to Web authors. The success criteria are the basis for determining conformance to WCAG 2.0 and are written as true/false statements. The success criteria define the minimum that needs to be done for the three levels of conformance. Additional advisory techniques are also provided that can allow authors to go further in addressing the guidelines and making pages even more accessible. [LC-870]

[end change]
[begin add]

For more information, refer to Understanding the Four Principles of Accessibility. [LC-1019]

[end add]
[end delete]

Important New Terms Used in WCAG 2.0

WCAG 2.0 includes several important new terms. [begin add]In some cases, these terms are just clarifications of concepts that have been in use but have not been clearly defined in the past. In other cases, they are terms that match new concepts that have been developed to cope with the new technologies that are continually emerging and with the accessibility issues and strategies that are emerging to address them.[end add] [begin delete]These terms are defined in the Glossary (), and links to the definitions are provided whenever these and other important terms are used in the success criteria. The terms are introduced briefly here to make this new vocabulary easier to understand. [end delete]

[begin add]
Sufficient Techniques

For each success criterion, there is a list of techniques deemed by the Working Group to be sufficient to meet the requirement. For each sufficient technique, there is a test to determine whether the technique has been successfully implemented. If the test(s) for a "sufficient" technique (or combination of techniques) are passed, then that success criterion has been [begin change]satisfied[end change].

Passing all tests for all sufficient techniques is not necessary. Most success criteria have multiple "sufficient techniques" listed. Any of the listed "sufficient techniques" can be used to meet the success criterion.

Note that it is not necessary to meet a success criterion using one of the sufficient techniques that have been documented by the WCAG working group. There may be other techniques which are not documented by the working group that would also meet the success criterion. The working group went through the effort to document these "sufficient techniques" in order to make it easy for authors to identify techniques that meet each success criterion and to have confidence (and evidence) that the techniques meet the success criterion. When using other externally-provided techniques to meet WCAG 2.0 requirements, it is important that they be created by individuals or organizations who are knowledgeable about the requirements of WCAG 2.0 and the needs of people with disabilities. The working group will continue to add new "sufficient techniques" as they are identified, developed, or made effective by advances in user agents including assistive technologies.

Advisory Techniques

In addition to the sufficient techniques, there are a number of techniques that may enhance accessibility that did not qualify as sufficient techniques because they are not testable, are not sufficient to meet the full requirements of the success criteria, and/or are good and effective techniques in some circumstances but not effective (and therefore sufficient) in others. These are listed as "Advisory Techniques." Authors are encouraged to use these techniques where appropriate. Although using them does not affect conformance, it can enhance accessibility for some users. Many of the advisory techniques are particularly helpful for people with cognitive, language, and learning disabilities, and use of these techniques will improve the accessibility of the content to people with these disabilities.

Web Page

While not an entirely new term, it is important to note that, in this standard, the term "Web page" includes much more than static HTML pages. It also includes the increasingly dynamic Web pages that are emerging on the Web, including "pages" that can present entire virtual interactive communities. Technically a Web page, as defined in the glossary, is "a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it." What this means is that a Web page is whatever you find at the end of a Web address that you visit. It includes Web applications, Webcasts, multimedia objects and other types of interactive content to which the word "page" may not typically apply. It is in this evolved sense of the concept that the term is used in WCAG 2.0.

For example, the term "Web page" would include a movie-like interactive shopping environment where the user visually moves about a store dragging products off of the shelves around them into a visual shopping cart in front of them where clicking on a product causes it to be demonstrated with a specification sheet alongside.

Programmatically Determined

Several success criteria require that content (or certain aspects of content) can be "programmatically determined." This means that the content is delivered in such a way that user agents, including assistive technologies, can access the information. A critical element in having anything be "programmatically determined" is that assistive technologies are able to retrieve and use the information. This lets user agents and assistive technologies transform the content and present it to the user in different sensory modalities (e.g. vision, hearing) or styles of presentation. If assistive technologies cannot do this, then the information can not be said to be programmatically determined.

The term was created in order to allow the working group to clearly identify those places where information had to be accessible to assistive technologies (and other user agents acting as accessibility aids) without specifying exactly how this needed to be done. This is important because of the continually changing nature of the technologies. It is important neither to declare things as accessible because they might be in the future (when they aren't now) nor to declare things as inaccessible in a permanent way when they may very well become accessible in the future.

The use of the term allows the guidelines to identify what needs to be "programmatically determined" in order to meet the guidelines, and then have separate, updateable documents (the Quick Reference, Understanding, and Technique documents) list those techniques and technologies that meet the requirements over time.

Accessibility Supported

In order for content created with Web technologies (such as HTML, CSS, PDF, GIF, MPEG, Flash etc.) to be accessible to people with different types of disabilities, it is essential that the technologies work with assistive technologies and the accessibility features of browsers and other user agents. In order for something to meet a success criterion that requires it to be "programmatically determined" for example, it would need to be implemented using a technology that has assistive technology support.

"Accessibility supported" means supported by users' assistive technologies as well as the accessibility features in browsers and other user agents.

Authors who don't know which technologies [begin add]or which aspects and features of a technology[end add] have support from assistive technologies should consult documented lists of technologies that are known to have accessibility support. Such lists can make it easier than it is today for an author to identify technologies or features of different technologies that are supported by assistive technologies and can be used to meet the success criteria that require assistive technology support (i.e. require that content can be programmatically determined.)

Editorial Note: The W3C WAI will be compiling existing information on its technologies. It is expected that other organizations will compile such information for their technologies. There will undoubtedly be others who create documented lists as well.

Editorial Note: The Baseline concept has been replaced by the "accessibility support" of Web technologies and "Documented lists of Web technologies that have accessibility support."

Note: The requirements for "accessibility support" of Web technologies are provided in the conformance section of these guidelines (See also Conformance.)

For more information, see Understanding accessibility support in Understanding WCAG 2.0.

[end add]
[begin delete]

While not an entirely new term, it is important to note that the term "Web page" has evolved to accommodate the increasingly dynamic nature of content. A Web page is a resource that is referenced by a Uniform Resource Identifier (URI) and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it. It includes Web applications, Webcasts, multimedia objects and other types of interactive content to which the word "page" may not typically apply. It is in this evolved sense of the concept that the term is used in WCAG 2.0. [LC-1241]

[end delete]
[begin delete]

Example: A movie-like interactive shopping environment where the user visually moves about a store dragging products off of the shelves around them into a visual shopping cart in front of them where clicking on a product causes it to be demonstrated with a specification sheet alongside would be considered a "Web page."

[end delete]
[begin delete]

The statements that define conformance in WCAG 2.0 are called "success criteria." Each success criterion is written as a testable statement and each is not technology-specific. [LC-1044]

[end delete]
[begin delete]

Several success criteria require that content (or certain aspects of content) can be "programmatically determined." [begin change]This means that the content is delivered in such a way that user agents, including assistive technologies, can access it. This lets user agents and assistive technologies transform the content and present it to the user in different sensory modalities or styles of presentation. [LC-923] [LC-1013] [end change] This is important in order to allow assistive technologies to recognize it and present it to the user, even if the user requires a different sensory modality than the original. For example, some assistive technologies convert text into speech or braille. This will also allow content in the future to be translated into simpler forms for people with [begin change]cognitive, language, and learning disabilities[end change], or to allow access by other agent based technologies. This can happen only if the content itself can be programmatically determined.

[end delete]
[begin delete]

WCAG 2.0 also introduces the term "baseline" which allows WCAG 2.0 to adapt to changing technologies and to the needs of different countries and environments. Baselines are described in more detail in the conformance section and in About Baselines for WCAG 2.0.

[end delete]

WCAG 2.0 Guidelines

This section is normative.

[begin change]Principle 1: Perceivable - Information and user interface components must be perceivable by users [LC-1200] [end change]

Guideline 1.1 [begin change]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[end change] Understanding Guideline 1.1

[begin change]
[begin change]

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

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

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

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

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

[end change]

Guideline 1.2 Provide synchronized alternatives for multimedia Understanding Guideline 1.2

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

1.2.2 Audio Description or Full Text Alternative: Audio description of video, or a [begin change]full text alternative for multimedia including any interaction[end change] , is provided for prerecorded multimedia. (Level A) How to meet 1.2.2

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

1.2.3 Captions (Live): Captions are provided for live multimedia. (Level AA) How to meet 1.2.3

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

1.2.4 Audio Description: Audio description of video is provided for prerecorded multimedia. (Level AA) How to meet 1.2.4

1.2.5 Sign Language: Sign language interpretation is provided for multimedia. (Level AAA) How to meet 1.2.5

1.2.6 Audio Description (Extended): Extended audio description of video is provided for prerecorded multimedia. (Level AAA) How to meet 1.2.6

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

Guideline 1.3 [begin change]Create content that can be presented in different ways (for example spoken aloud, simpler layout, etc.) without losing information or structure [LC-488] [LC-1201] [end change] Understanding Guideline 1.3

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

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

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

[begin delete]
[begin delete]

1.3.4 Text Variations: Information that is conveyed by variations in presentation of text is also conveyed in text, or the variations in presentation of text can be programmatically determined. [LC-588] (Level AA) How to meet 1.3.4

[end delete]
[end delete]

Guideline 1.4 [begin change]Make it easier for people with disabilities to see and hear content including separating foreground from background[end change] Understanding Guideline 1.4

[begin change]

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

[end change]
[begin change]

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

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

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

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

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

[end add]
[begin change]

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

[end change]

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

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

[begin add]

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

[end add]

[begin change]Principle 2: Operable - User interface components must be operable by users [LC-1200] [end change]

Guideline 2.1 [begin change]Make all functionality available from a keyboard[end change] Understanding Guideline 2.1

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

[begin add]

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

[end add]
[begin change]

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

[end change]
[begin change]

2.1.2 Keyboard (No Exception): All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA) How to meet 2.1.2

[end change]

Guideline 2.2 [begin change]Provide users with disabilities enough time to read and use content[end change] Understanding Guideline 2.2

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

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

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

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

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

  • Essential Exception: the [begin change]time limit[end change] is part of an activity where timing is essential (for example, [begin delete]competitive gaming or [end delete]time-based testing) and time limits can not be extended further without invalidating the activity.

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

[begin change]

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

[end change]

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

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

Guideline 2.3 [begin change]Do not create content that is known to cause seizures[end change] Understanding Guideline 2.3

[begin change]

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

[end change]

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

Guideline 2.4 [begin change]Provide ways to help users with disabilities navigate, find content and determine where they are[end change] Understanding Guideline 2.4

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

[begin change]Principle 3: Understandable - Information and operation of user interface must be understandable by users [LC-1200] [LC-500] [end change]

Guideline 3.1 [begin change]Make text content readable and understandable[end change] Understanding Guideline 3.1

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

3.1.2 Language of Parts: The human language of each passage or phrase in the [begin delete] Web page [end delete] [begin add]content[end add] can be programmatically determined.