Introduction to WCAG 2.0
Draft 2005-06-22
Submitted by
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 technology.
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:
1. Content must be perceivable.
2. User interface components in the content must be operable.
3. Content and controls must be understandable.
4. 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 apply the principle. Under each guideline there are several success criteria that express what it means to follow the 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. (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 explain what it means for web content to be accessible, 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.
When WCAG 2.0 becomes a W3C Recommendation, normative sections of this document will specify what is required for conformance and will have undergone the full process that is required for W3C Recommendations. The principles, guidelines, and success criteria are all normative. The Glossary and the Conformance section are also normative.
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.
WCAG 2.0 also includes material that is designated as “informative” rather than normative. Informative sections of this document are clearly marked, both visually and by the label “Informative.” Informative material is not required for conformance. However, informative sections of this document and related informative documents may aid in understanding the intent of the success criteria and how to apply them.
Besides this Introduction, informative sections of WCAG 2.0 include:
Only WCAG 2.0 (this document) contains normative material. Therefore, 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 documents in this set are informative: their entire purpose is to help readers understand what WCAG 2.0 requires 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 in addition to those listed above, 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.
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.
Level 2 success criteria increase 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.
· design of the content and presentation.
Level 3 success criteria achieve additional accessibility enhancements for people with disabilities. Level 3 items may not be applicable to all web content
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.
Editorial Note: To facilitate discussion related to the levels assigned to each success criterion, a square bracket notation is included at the end of each criterion. "[I]" (invisible) indicates that a criterion does not specify how content should be presented. The other notation, "[V]" (visible) indicates that addressing the criterion may affect the default presentation of content or the content itself—possibly both.
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 and success criteria as functional outcomes. These outcomes 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.0uses the term user
agents according to the definition published in the Glossary for the W3C’s
User Agent Accessibility Guidelines (UAAG) 1.0. UAAG 1.0 defines user agents
in two ways.
1. . The software and documentation components that together, conform to the requirements of [UAAG 1.0]. ...
2. 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.
UAAG 1.0 most often uses the first definition. By contrast, WCAG 2.0 most often uses the second definition. 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.
Developers may also use technologies that are not in the specified baseline provided that the following are true:
1. The Web content still conforms using user agents that only support the technologies that are in the specified baseline (that is, the use of technologies that are not in the baseline does not "break" access to the Web content by user agents that don't support those technologies).
2. All content and functionality must be available using only the technologies in the specified baseline .
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.) All conformance claims must include at least the following information:
1. The version of the guidelines to which the conformance claim is made.
2. A list of one or more URIs or URI patterns, identifying the delivery units for which the claim is made.
3. The level of conformance being claimed.
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 Uri’s. 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
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.
Editorial note: The WCAG Working Group continues to wrestle with the challenge of defining the roles and responsibilities of authors and user agents, respectively, in making Web content accessible. In WCAG 1.0, we identified shortcomings in user agents and created guidelines that contained phrases like, "until user agents..." Many of the same issues exist today, but we are looking for a more effective mechanism to address them than creating "temporary bridge" guidelines designed to make up for the shortcomings of user agents.
The Working Group is well aware that there is intense interest in our approach to the challenge of defining “baseline” assumptions about the technologies available to users. This Working Draft of WCAG 2.0 represents a continued evolution of that approach, and the Working Group welcomes comments and suggestions from the community.
At a meeting in October 2004, the WCAG WG agreed to explore the advantages and disadvantages of adopting the Priority 1 checkpoints of the User Agent Accessibility Guidelines (UAAG) 1.0 as a baseline for WCAG 2.0. The Working Group then went on to investigate the implications of writing WCAG 2.0 guidelines under the assumption that all users had user agents that conform to all of the priority 1 checkpoints from UAAG 1.0.
Today, however, no single user agent meets all of the UAAG 1.0 priority 1 checkpoints. If WCAG 2.0 adopts an assumption that user agents conform to UAAG 1.0 priority 1 checkpoints, there will be some shortfall between Web content that meets WCAG 2.0 and currently available user agents. In addition, our analysis of UAAG 1.0 determined that adopting UAAG 1.0 as a baseline for WCAG 2.0 would not resolve certain questions that are crucial for content authors. Specifically, adopting UAAG 1.0 as a baseline would not allow authors to assume that user agents and assistive technologies would be able to interact effectively with scripted content or content that relies upon Cascading Style Sheets.
At a meeting in March 2005, the WCAG Working Group reluctantly concluded that UAAG 1.0 did not provide an appropriate baseline for WCAG 2.0. Further, after vigorous debate, the Working Group agreed to explore a very different approach: we agreed to explore the implications of not setting a baseline in the WCAG 2.0 guidelines while at the same time continuing to search for ways to support UAAG 1.0 in our guidelines and success criteria. Following that meeting, Working Group participants analyzed the implications of this approach from many different angles. We explored how not setting a baseline might require us to provide guidance for authors, policy makers, and others about several baselines. We analyzed the impact of this approach on the wording of guidelines and success criteria. We also explored the implications for our technology-specific Techniques documents, concluding that it might be necessary to provide information about how each technique works within one or more baselines. To date, our analyses and subsequent work on guidelines, success criteria, and techniques appear to support the new approach. This Working Draft reflects the results so far. The Working Group continues to test its assumptions and decisions, and we welcome this opportunity to learn from the community’s response to our work.
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.