You are reading the Web Content Accessibility Guidelines (WCAG) 2.0. This is one of several documents that define and explain the requirements for making Web-based information and applications accessible to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations, limited movement, speech difficulties, and others. Following these guidelines will also make your Web content more accessible to the vast majority of users, including older users. It will also enable people to access Web content using many different devices - including a wide variety of assistive technologies.
WCAG 2.0 covers a wide range of issues and recommendations for making Web content more accessible. In general, however, the guidelines do not include standard usability recommendations except where they have specific impact on accessibility.
WCAG 2.0 includes:
This introduction
Accessibility principles
Guidelines for each principle
Success criteria for each guideline
Links to information on intent, sufficient techniques, examples and benefits for each success criterion
Information about conformance to WCAG 2.0
Information about the Working Group's approach to defining baseline assumptions about the technologies that are available to end users
An appendix containing definitions, references, and other support information.
The four principles of accessibility are as follows:
Content must be perceivable to each user.
User interface components in the content must be operable by each user.
Content and controls must be understandable to each user.
Content must be robust enough to work with current and future technologies.
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. The success criteria are written as statements that will be either true or false when specific Web content is tested against the success criteria. The success criteria are grouped into three levels of conformance each representing a higher level of accessibility for that guideline. (For more information about conformance, see the section titled Conformance , below.)
The principles, guidelines, and success criteria represent concepts that apply to all Web-based content. They 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, including those that do not yet exist.
The principles and guidelines give direction and guidance to Web authors. The success criteria are written as true/false statements so that they can be used in determining conformance. Only the success criteria are testable.
Success criteria should be interpreted in the context of the intention expressed in the guideline to which they belong. Likewise, each guideline should be understood in the context of the principle under which it appears.
In addition to WCAG 2.0 (this document) there are a number of related support documents that provide additional information and examples. These other documents are informative only and do not define conformance to WCAG 2.0. Only this document (WCAG 2.0) is normative. That is, only this document can be used for determining conformance to these guidelines. Readers should consult WCAG 2.0 in order to determine the exact wording of the guidelines and success criteria and for information about documenting conformance.
The other informative documents in this set are provided to help readers understand WCAG 2.0 and how to produce conforming content. These informative documents are written for different audiences, including but not limited to:
people who create Web content
developers who write code
policy makers
managers
Currently, these informative documents include:
Essential Components of Web Accessibility - Explains how the Web Content Accessibility Guidelines work with the other WAI guidelines (User Agent Accessibility Guidelines, and the Authoring Tool Accessibility Guidelines) and with assistive technologies to provide access to the Web by people with disabilities
Introduction to Web Content Accessibility Guidelines (WCAG) 2.0 Working Draft Documents - Provides an overview of WCAG 2.0 and its various informative support documents.
Understanding WCAG 2.0 - Provides information about each success criterion including; its intent, key terms needed to understand it, names of and links to techniques that the working group feels are sufficient to meet the success criterion, examples and benefits of the success criterion. The "How to meet SC x.x.x" links in WCAG 2.0 link to the relevant section of the Understanding WCAG 2.0 document for that success criterion.
Technique and Tests documents - Provide specific details on different techniques including examples, code and tests where available. Note: For this review we only have a sample of the techniques formatted in the new form.
Application Notes - Provide detailed application information in different areas. For example the Application Note on Forms provides a collection of techniques, and strategies for creating accessible forms. It also summarizes the different success criteria that relate to forms. Note: No examples completed as of this release.
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.
Every attempt has been made to make WCAG 2.0 and the related documents listed above as readable and usable as possible while still 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 Appendix A Glossary . The Working Group recognizes that readers who are new to accessibility may need or want additional information. For these readers, the work of the Education and Outreach Working Group of the Web Accessibility Initiative is highly recommended. The articles called Getting Started: Making a Web Site Accessible and How People with Disabilities Use the Web are especially useful.
Conformance means that Web content satisfies the success criteria defined in this document. This section outlines the conformance scheme used throughout this document.
The success criteria for each guideline are organized into three (3) levels of conformance.
Level 1 success criteria:
Achieve a minimum level of accessibility through markup, scripting, or other technologies that interact with or enable access through user agents, including assistive technologies.
Can reasonably be applied to all Web resources.
Level 2 success criteria:
Achieve an enhanced level of accessibility through one or both of the following:
markup, scripting, or other technologies that interact with or enable access through user agents, including assistive technologies
the design of the content and presentation
Can reasonably be applied to all Web resources.
Level 3 success criteria:
Achieve additional accessibility enhancements for people with disabilities.
Are not applicable to all Web resources.
Note: Some guidelines do not contain level 1 success criteria, and others do not contain level 2 success criteria.
This method of grouping success criteria differs in important ways from the approach taken in WCAG 1.0. In WCAG 1.0, each checkpoint is assigned a "priority" according to its impact on accessibility for users. Thus Priority 3 checkpoints appear to be less important than Priority 1 checkpoints. The Working Group now believes that all success criteria of WCAG 2.0 are essential for some people. Thus, the system of checkpoints and priorities used in WCAG 1.0 has been replaced by success criteria grouped under Levels 1, 2, and 3 as described above.
The Working Group believes that all success criteria should be testable. Tests can be done by computer programs or by people who understand this document. When multiple people who understand WCAG 2.0 test the same content using the same success criteria, the same results should be obtained.
WCAG 2.0 defines accessibility guidelines (goals) and success criteria (testable criteria for conformance at different levels of accessibility). The guidelines and success criteria are described in a technology independent way in order to allow conformance using any Web technology that supports accessibility. WCAG 2.0 therefore does not require or prohibit the use of any specific technology. It is possible to conform to WCAG 2.0 using both W3C and non-W3C technologies, as long as they are supported by accessible user agents.
WCAG 2.0 uses the term user agent to mean: Any software that retrieves and renders Web content for users. This may include Web browsers, media players, plug-ins, and other programs - including assistive technologies - that help in retrieving and rendering Web content. .
It is important to note that assistive technologies are included in this definition. (Assistive technologies include screen readers, screen magnifiers, on screen and alternative keyboards, single switches, and a wide variety of input and output devices that meet the needs of people with disabilities.)
IIn choosing technologies to rely upon, developers need to know what technologies they can assume are supported by, and active in, accessible user agents. A set of such technologies is called a baseline. Developers must ensure that all information and functionality comprising the Web content conform to WCAG 2.0 assuming (a) that user agents support only the technologies in the baseline specified for the content and (b) that those technologies are active.
Baselines are defined outside the WCAG 2.0 guidelines as part of a more comprehensive accessibility policy. Baseline considerations will be significantly different if the entity defining the baseline can guarantee the availability of specific user agents.
Example 1: A government site that provides information to the public
A government agency publishes information intended for the general public. The specified baseline includes only technologies that have been widely supported by more than one accessible and affordable user agent for more than one release.
Example 2: A government adopts a guideline for use with accessible user agents in use by its citizens
A government periodically changes the baseline it requires for developers of public sites to reflect the increasing ability of affordable user agents (including assistive technology) to work with newer technologies.
Example 3: A government provides accessible user agents to all citizens
A government provides all citizens with user agents that support newer technologies. The government specifies a baseline that includes newer technologies that are supported in the user agents provided by that government.
Example 4: A private intranet
A company or government agency provides its employees with the information technology tools they need to do their jobs. The baseline for intranet sites used only by employees includes newer technologies that are supported only in the user agent which the organization provides for its employees. Because the company controls the user agents that will view its internal content - the author has very accurate knowledge of the technologies that those user agents support.
(Note that in example 4, the author is not specifying the baseline in terms of a user agent. The organization had specified the user agent to be used by organization employees in advance. The author just has knowledge that only that agent is used so the author has very good knowledge of the technologies the user agent supports and creates a baseline based on those technologies. Care must be taken here however since that agent would have to be cross-disability accessible or else the author's assumptions may be bad because users with disabilities may have to use other user agents to access the content.)
Developers may also use technologies that are not in the specified baseline provided that the following are true:
All content and functionality must be available using only the technologies in the specified baseline.
The non-baseline technologies must not interfere with (break or block access to) the content
when used with user agents that only support the baseline technologies
when used with user agents that support both the baseline and the additional technologies.
Additional information can be found on the baseline at Questions and Answers about Baseline and WCAG 2.0.
WCAG 2.0 conformance at level A means that all level 1 success criteria in the guidelines are met assuming user agent support for only the technologies in the chosen baseline.
WCAG 2.0 conformance at level Double-A means that all level 1 and all level 2 success criteria in the guidelines are met assuming user agent support for only the technologies in the chosen baseline.
WCAG 2.0 conformance at level Triple-A means that all level 1, level 2 and level 3 success criteria in the guidelines are met assuming user agent support for only the technologies in the chosen baseline.
Editorial Note: The working group is looking at AAA conformance as being an indication that the content goes beyond AA conformance in a major way but do no necessarily require conformance to all level 3 success criteria. Some Level 3 success criteria cannot be applied to all web content and some are not necessary in certain circumstances. We are considering different criteria for claiming AAA conformance. Comments and suggestions are invited.
Conformance claims apply to delivery units and sets of delivery units. (In many cases, a "delivery unit" is the same as a "page." In other cases, however, such as Web applications, the term "page" may be inappropriate, so the Working Group has adopted the term "delivery unit" from the Device Independence Working Group.)
The date of the claim
The guidelines title/version: "Web Content Accessibility Guidelines 2.0"
The URI of the guidelines: http://www.w3.org/TR/2005/REC-WCAG20-YYYYMMDD/
The conformance level satisfied: (Level A, AA or AAA)
The Baseline used to make the conformance claim. (If baseline is a published baseline it can be named along with a URI that points to it. The baseline technologies can also be spelled out individually in the conformance claim. )
Scope of the claim (a URI, list of URI's or a regular expression)
A list of the specific technologies "relied upon" to create the content for which the claim is being made. (This includes markup languages, style sheet languages, scripting/programming languages, image formats, and multimedia formats.)
relied upon means that the content would not meet WCAG 2.0 at the claimed level if that technology is turned off or not supported)
the set of "Relied Upon" technologies must be a proper subset of the Baseline.
A list of the specific technologies that are "used" but not "relied upon"
If a technology is "used" but not "relied upon" the content would still meet WCAG 2.0 at the stated conformanc level even if that technology is turned off or not supported.
A list of user agents that the content has been tested on. This should include assistive technologies.
Information about audience assumptions or target audience. This could include language, geographic information. It CANNOT specify physical, sensory or cognitive requirements.
Example 1: On 13 March 2005, www.johnpointer.com conforms to W3C's WCAG 2.0, Conformance Level 1.The baseline for this claim is XHTML 1.0. The specification that this content *relies upon* is: XHTML 1.0. The specifications that this content *uses* are: CSS2, Real Video, Real Audio, MP3, and gif. This content was tested using the following user agents and assistive technologies: Firefox 1.01 (Windows, Linux), IE 3.0 and 6.0 (Windows, Mac), Jaws 3.7 and Jaws 6.0 (windows), Safari 1.2 (Mac), Opera 7.5 (OSX).
Example 2: On 1 August 2006, "S5: An Introduction" http://meyerweb.com/eric/tools/s5/s5-intro.html conforms to W3C's WCAG 2.0. Conformance Level 1. The baseline for this claim is UDBaseline#1-2006 at http://UDLabs.org/Baseline#1-2006.html. The specification that this content *relies upon* is: XHTML 1.0 (Strict). The specifications that this content *uses* are: JavaScript 1.2, CSS2, png, and jpg.
Example 3: On 1 July 2005, "Photo gallery application" http://foo.makeyourownslideshow.com conforms to W3C's WCAG 2.0, Conformance Level 1. The baseline is ISA-Baseline#2-2005 at http://ISA.gov/Baselines/BL2-2005. The specifications that this content *relies upon* are: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, jpg. The specification that this content *uses* is: gif. The techniques profile that this content uses is, "HTML/ECMAScript for latest browsers."
A delivery unit conforms to WCAG 2.0 at a given conformance level only if all content provided by that delivery unit conforms at that level.
Note: If multiple representations can be retrieved from a URI through content negotiation, then the conformance claim would be for the delivery unit that is returned when no negotiation is conducted (unless the server returns an error for that condition, in which case one of the negotiated forms must comply).
Editorial Note: There is some question as to whether URI is specific enough a reference to the material for which the claim is being made.
Editorial Note: A question has been raised as to whether the information required in items 1-3 above should all be transmitted in the HTTP header or in some other way.
Editorial Note: The working group is considering adding the following note to the conformance section to differentiate Web Content from standard stand alone software and other products that are downloaded over the Internet and not used via a user agent.. Note: If data, software or other materials are downloaded over the internet but are not used via a user agent then they are not considered Web content and are not covered by these guidelines.
Sometimes a delivery unit is assembled ("aggregated") from multiple sources that each have their own level of conformance. These sources are called authored units. The conformance level for a delivery unit that contains authored units is equal to the lowest conformance level claimed for the delivery unit content and any of the authored units it contains - including claims of aggregated units.
A delivery unit referred to by a URI conforms to WCAG 2.0 at a given conformance level only if all content provided by that delivery unit conforms at that level. For example, if the delivery unit provides information retrieved from a database in response to users' queries, all delivery units containing such information must satisfy the success criteria of WCAG 2.0 to the level at which conformance is claimed. In the case of content negotiation, WCAG 2.0 conformance is not required if the user agent requests a version of the content that does not meet WCAG 2.0 at the specified conformance level.
Editorial Note: We are currently looking at how to handle unknown or community-contributed, authored units that are created using an aggregator supplied tool. We are currently considering whether aggregated content would be judged to conform to WCAG if the aggregator supplied tool can conform to the Authoring Tool Accessibility Guidelines (ATAG) 2.0.
Conformance claims can be limited, or "scoped," to pertain to only some parts of a Web site. All conformance claims, however, must be directed to a URI or a range of URIs. Scoping to exclude a particular type of content (for example, images or scripts) from a site is not allowed since it would allow exclusion of individual success criteria. Scoping by URI to exclude sections of a site is allowed so that authors can make claims for just some parts of a site.
This Working Draft of WCAG 2.0 builds upon WCAG 1.0 and reflects feedback received since the publication of WCAG 1.0 in May 1999.
The Web Content Accessibility Guidelines Working Group is working to ensure that organizations and individuals who are currently using WCAG 1.0 (which remains stable and normative at this time) will be able to smoothly transition to WCAG 2.0. For more information about the similarities and differences between WCAG 1.0 Checkpoints and WCAG 2.0 Guidelines and success criteria, please refer to the (draft) Mapping between WCAG 1.0 and the WCAG 2.0 Working Draft.
Authors whose content currently conforms to WCAG 1.0 may wish to capitalize on past accessibility efforts when making the transition to WCAG 2.0. A qualified conformance statement could allow them this flexibility. For example, a conformance claim might include the following statement: "Materials created or modified before 31 December 2005 conform to WCAG 1.0. Materials created or modified on or after 31 December 2005 conform to WCAG 2.0."
Editorial Note: In some instances, the WCAG 2.0 Working Draft may be easier to conform to than the WCAG 1.0 Recommendation while other criteria might be harder to meet in WCAG 2.0 than in WCAG 1.0. The WCAG WG will consider the differences between WCAG 1.0 and WCAG 2.0 conformance and offer advice to developers who currently conform to WCAG 1.0. This advice might take the form of a WCAG 1.0 conformance profile to WCAG 2.0 and information about migrating from WCAG 1.0 to WCAG 2.0. This advice is not yet available.
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 will play an important role in creating Web content that conforms to the Web Content Accessibility Guidelines. 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 help to make their tools more aware of the Web Content Accessibility Guidelines by following the Authoring Tool Accessibility Guidelines. We encourage users and purchasers of authoring tools to consider conformance to the Authoring Tool Accessibility Guidelines as a criterion when selecting tools.
Editorial Note: The Authoring Tool Accessibility Guidelines Working Group has published Working Drafts of ATAG 2.0. The above references will need to be updated as ATAG 2.0 moves through recommendation track.