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:
The four principles of accessibility are as follows:
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.
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:
Currently, these informative documents include:
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 the 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.
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.)
In 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.
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.
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.
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.
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 user agent; the company had specified the user agent 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. 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:
Additional information can be found on the baseline at
[insert URI for the new baseline doc]
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.)
A conformance claim MUST include the following assertions:
Optional components of a conformance Claim:
Examples of conformance claims:
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.
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 tools 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.