W3C logo

Web Content Accessibility Guidelines 2.0

W3C Working Draft 28 March 2001

This version:
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20010328.html
Latest version:
http://www.w3.org/WAI/GL/WCAG20/
Previous version:
http://www.w3.org/TR/2001/WD-WCAG20-20010125.html
Editors:
Jason White, University of Melbourne
Wendy Chisholm, W3C
Gregg Vanderheiden, Trace R&D Center

Copyright 2000 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document useand software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.


Abstract

This Working Draft is the first step towards incorporating feedback received on Web Content Accessibility Guidelines 1.0 (WCAG 1.0) since its publication in May 1999. Primarily, this is the first attempt to write checkpoints that may be applied to a wider range of technologies and that may be understood by a more varied audience. Since this Working Draft builds on WCAG 1.0 it has the same aim: explain how to make Web content accessible to people with disabilities.

Status of this document

This document is prepared by the Web Content Accessibility Guidelines Working Group (WCAG WG) to show how more generalized (less HTML-specific) WCAG checkpoints might read. This draft is not based on consensus of the WCAG Working Group nor has it gone through W3C process thus it in no way supersedes the checkpoints in WCAG 1.0.

Several edits have been made to the document and have been marked as "[Proposed]." Once these have been reviewed and accepted by the WCAG Working Group they will be marked as "[New]" for a couple of drafts thereafter.

Please refer to "Issue Tracking for WCAG 2.0" for a list of open issues related to this Working Draft. The "History of Changes to WCAG 2.0 Working Drafts" is also available.

This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C Recommendations and other technical documents is available.

Please send comments on this document to w3c-wai-gl@w3.org. The archives for this list are publicly available.

Table of Contents


[Proposed - still rough and unfinished] Introduction

Every Web site has been created because some person or group of people wanted to accomplish something - whether it be providing the weather report for a community or showcasing photos from vacation or selling cars. The purpose and design of a site will vary as much as the people who create it. A site that is usable, attractive, and meets the needs of its audience is designed that way. The author has followed design principles to guide design decisions.

This document provides the author with design principles to guide design decisions so that the usable, attractive, and functional site is also accessible to people with disabilities. These principles are closely related to also making Web content accessible to a variety of devices and to people using those devices in a variety of situations.

The four design principles in this document are:

  1. Presentation
  2. Interaction
  3. Comprehension
  4. Technology considerations

Note: These guidelines apply only to Web content presented to a human reader. A structured database or metadata collection where the data is intended for use by another machine and thus requires no interface lies outside the scope of these guidelines.

Presentation and Interaction

Have you ever adjusted the height of a chair because it was too low or too high? Have you ever adjusted the volume on a stereo? Have you ever used a magnifying glass to read small print?

We adjust objects in our environment to meet our needs. We use tools to help us do things we can not do on our own. Both in real life and on the Web, some people rely on these adjustments to work, to contribute to society, and to enjoy life.

Here are a few scenarios, by no means an exhaustive list of the variations and types of disabilities and needs:

For more in-depth scenarios, please read "How People with Disabilities Use the Web".

A process for building content

Think about the process used to build a new office building. The structure of the building - its skeleton - is built before the decorations are added.

Similarly, the first place to start in your design is with the structure. How many chapters does your document have? Which navigation links are the most important and where should they go? What is the best way to express this idea - do I need an animated simulation to help people understand?

Once the structure is finished, the walls are painted and pictures are hung. On your web site, this is like deciding the color of chapter titles and how text will flow around images.

Steps and ladders

The architect designed the building with both elevators and stairs. Some people prefer to take stairs, while some people find the stairs too challenging or impossible. On your Web site, some people will prefer images, animations, multimedia, fast-paced interactive games, while others will find them too challenging or impossible to use. As with elevators and stairs, provide a variety of ways for people to access and to navigate through your Web content.

Comprehension

Design for ease of comprehension

Technology considerations

Design for compatibility and interoperability

The differences between WCAG 1.0 and WCAG 2.0

Since the release of WCAG 1.0 in May 1999, the WCAG Working Group has received feedback on priorities of checkpoints, the usability of the set of documents, and requests for clarifications on the meaning of specific checkpoints and what is needed to satisfy them. Thus, it is intended that WCAG 2.0:

For a checkpoint by checkpoint comparison, refer to the Checkpoint Mapping Between WCAG 1.0 and WCAG 2.0 Working Draft.

Improvements in WCAG 2.0

We hope that WCAG 2.0 will have several improvements over WCAG 1.0.

More easily used with a wide range of languages
When WCAG 1.0 was written, most of the Web used HTML. The guidelines were designed with that in mind, and applying the guidelines to other languages has identified some areas that can be improved. The new version should be easier to apply to a wider range of languages and content types.
More easily used by authoring tool developers
The Authoring Tool Accessibility Guidelines rely heavily on WCAG to define how to make Web content accessible. Simplifying the guidelines will improve their usability for this important group.
Easier to determine conformance
In WCAG 1.0 there were a number of checkpoints that began "until user agents...". In the new version there are no such checkpoints. This reduces the confusion as to when a checkpoint has been met as well as the resource commitment required to keep the information produced up to date.

Priorities and Techniques

This WCAG 2.0 Working Draft does not assign priorities to checkpoints, nor does it include links to technology-specific examples and techniques. Later versions of this document will assign priorities and will link to techniques. This Working Draft presents an initial reorganization and begins to incorporate other feedback received since the publication of WCAG 1.0 in May 1999.

In some cases, WCAG 1.0 checkpoints of various priorities are combined into a single checkpoint in the WCAG 2.0 Working Draft. In these instances, a priority can not be assigned to the new checkpoint until the WCAG Working Group has extensively discussed the priority for that checkpoint. Priorities will be included in a future Working Draft.

The WCAG Working Group is proceeding carefully to minimize substantial differences between the WCAG 1.0 Recommendation and the WCAG 2.0 Working Draft. Refer to the Checkpoint Mapping Between WCAG 1.0 and WCAG 2.0 Working Draft for more detail on current correspondences.

WCAG 1.0 is accompanied by supporting techniques documents (non-normative) which include examples of how to implement WCAG 1.0 in HTML and CSS. The WCAG Working Group will continue to develop the HTML and CSS technique documents as well as create new documents for other languages such as SMIL and SVG. Links to these documents will be added in future versions of the WCAG 2.0 Working Draft.

Guidelines and Checkpoints

Guideline 1. Presentation: Design content that allows presentation according to the user's needs and preferences

The pieces of the puzzle can either be put together by the user's client, by your server, by something in between, or a mix of all of these.

User needs and preferences are determined by:

For more information about user capabilities, device capabilities, assistive technologies, and usage scenarios refer to the Working Draft "How People with Disabilities Use the Web."

1.1 Provide a text equivalent for all non-text content.
A text equivalent

Depending on the purpose and content of the non-text content, a short label may be appropriate while in other circumstances, a more thorough explanation may be required.

Non-normative examples:

1.2 Synchronize text equivalents with multimedia presentations.

The need for synchronized text equivalents applies to multimedia presentations that include both audio and video tracks. If one of the tracks (either the audio or the video) does not present any significant information, then a synchronized equivalent does not need to be synchronized. However, a text equivalent, such as a text transcript, is still required. Refer to checkpoint 1.1.

1.3 Synchronize a description of the essential visual information in multimedia presentations.
Commonly called an auditory description, the description is either a prerecorded human voice or a synthesized voice that has either been prerecorded or is generated as the presentation plays. The auditory description is synchronized with the audio track of the presentation, usually during natural pauses in the audio track. Auditory descriptions include information about actions, body language, graphics, and scene changes.

Non-normative examples

1.4 Use markup or a data model to provide the logical structure of content.
The logical structure of content represents changes in context. For example,
  1. A book is divided into chapters, paragraphs, lists, etc. Chapter titles help the reader anticipate the meaning of the following paragraphs. Lists clearly indicate separate, yet related ideas. An italicized phrase emphasizes an important idea. All of these divisions help the reader anticipate changes in context.
  2. A theatrical play is divided into scenes and acts. The curtain lowering, characters leaving the stage, or a short burst of music are a few ways to highlight changes in context during a play.
  3. A bicycle is divided into wheels and a frame. Further, a wheel is divided into a tire and a rim. In an image of the bicycle, one group of circles and lines becomes "wheel" while another group becomes "frame."

When the logical structure is documented in markup or a data model,

1.5 Separate content and structure from presentation.
Content and presentation can be separated because the rules that control how content is displayed can be separated from the markup that denotes the structure of the content.

Typically, style rules are stored separately from the content to which they apply, in resources which are referred to in these guidelines as style sheets. To facilitate the presentation of Web content by a range of devices (high and low-resolution displays, printers, speech devices, etc.), it is advisable to associate a variety of style sheets with your Web content.

[Proposed] 2.1 Provide more than one path or method to find content.
One of the most basic features of the Web is to interact with information. The most common form of interaction is navigating - to make your way through Web space to find a particular story, article, person, etc. Providing more than one navigation method helps users choose the most comfortable path or style of navigation. Navigation methods include:
[Proposed] 2.2 Provide consistent responses to user actions.
Providing responses to user actions is important feedback for the user. This lets them know that your site is working properly and encourages them to keep interacting. When the user receives an unexpected response, they might think something is wrong or broken. Some people might get so confused they will not be able to use your site. Common responses to user actions:

These actions should be predictable and sensible to the end user; this is achieved by making the interactions consistent, both within the site and with commonly used models of computer interaction.

2.3 Give users control of mechanisms that cause extreme changes in context.
Mechanisms that cause extreme changes in context include:

This can be satisfied by providing an option to deactivate the changes in context. User agents may also offer control over this effect.

2.4 Give users control over how long they can spend reading or interacting with content.
Mechanisms that required a timed response include:

This can be satisfied by providing an option to deactivate automatic updating, or to control the rate at which it occurs. User agents may also offer control over this effect. Note that flicker effects can cause seizures in people with photoepilepsy.

[Proposed] 2.5 Use device-independent event handlers.
When writing scripts or applications that have a user interface, ensure that the interface may be used with any type of input device. For example, if a user interface control can be activated by a mouse click it should also be activated by a keyboard event such as pressing the Enter key.

Guideline 3. Comprehension: Make it as easy as possible to use and understand

3.1 Use consistent presentation.
Consistency helps users determine the relationships between items in the content. This ability to understand the structure helps users navigate, orient themselves, and thus understand.
3.2 Emphasize structure through presentation, positioning, and labels.
Emphasizing the structure through presentation will help the user

If the default presentation of the structured content does not meet the needs of your audience use graphics, colors, sounds, etc. to emphasize the structure. For example, section headings may appear in a different color and spoken in a different voice than the rest of the text. However, ensure that the structural and semantic distinctions are captured in the markup (checkpoint 2.3).

  • Identify important topics or subdivisions within a document (e.g., in XHTML use the Hn elements, identify groups of user interface controls).
  • Identify important groupings of data (e.g., label groups of rows or columns with a header),
  • In addition to full, descriptive labels, it may also be appropriate to provide abbreviated labels to be used when displaying content on small displays or via speech output. For example, an abbreviated heading for a column of data.
3.3 Write clearly and simply.
This checkpoint addresses the need to facilitate comprehension of the content by all readers, especially those with cognitive disabilities. It should not be interpreted as discouraging the expression of complex or technical ideas. However, authors should strive for clarity and simplicity in their writing.
3.4 Use multimedia to illustrate concepts.
Sounds, graphics, videos and animations can help make a concepts presented in a Web site easier to understand, especially for people with cognitive disabilities or those who are unfamiliar with the language of the text of the site. Material provided in auditory or visual forms must also be available as text (see Guideline 1).
For example, this image tries to represent the idea that a text equivalent equals its non-text equivalent as described in Checkpoint 1.1.
A text equivalent is equal to its non-text element [D]
3.5 Summarize complex information.
Examples of complex information:

Content is considered complex if the relationships between pieces of information are not easy to figure out. If the presentation of the information is intended to highlight trends or relationships between concepts, these should be explicitly stated in the summary.

3.6 Define key terms, abbreviations, acronyms, and specialized language.
Defining key terms and specialized language will help people who are not familiar with the topic you are presenting. Providing the expansion of abbreviations and acronyms not only helps people who are not familiar with the abbreviation or acronym but can clarify which meaning of an abbreviation or acronym is appropriate to use. For example, the acronym "ADA" stands for both the American with Disabilities Act as well as the American Dental Association.
3.7 Divide information into smaller, more manageable units.
For example,

Guideline 4. Technology considerations: Design for compatibility and interoperability

4.1 Choose languages, API's, and protocols that support the use of these guidelines.
Markup languages, multimedia formats, software interface standards, etc., vary in their support of accessibility. When choosing which technologies to use, consider how easy it is apply these guidelines. Where feasible, favor technologies that:
4.2 Use languages, API's, and protocols according to specification.
This checkpoint requires
4.3 Design assistive-technology compatible user interfaces.
Use standard software conventions to control the behaviour and activation of user interface components. Platform-specific guidance may be available for your operating system or application environment.
[Proposed] 4.4 Design content so that when presentation effects are turned off or not supported the content is still usable.
Ensure that when stylistic or scripting technologies are not supported or turned off the content is still usable and readable by the user. This only applies to technologies that associate presentation with structure.

This may be accomplished by providing:

In determining the extent to which older technologies should be supported, keep in mind that


Appendix A: Glossary

Auditory description

An auditory description is either a prerecorded human voice or a synthesized voice that has either been prerecorded or is generated as the presentation plays. The auditory description is synchronized with the audio track of the presentation, usually during natural pauses in the audio track. Auditory descriptions include information about actions, body language, graphics, and scene changes.

Data model
Not yet defined.
Equivalent
Not yet defined.
Markup
Not yet defined.
Multimedia
Not yet defined. The definition must include the idea of timelines and slide shows (per 30 November 2000 telecon)
Normative/Non-normative
Throughout this document we refer to several "non-normative" examples. These are included to help readers understand concepts. Normative items are prescriptions for what must/should/may be done to create accessible content.
Presentation
Not yet defined.
Semantics
Not yet defined.
Transform gracefully
Not yet defined.

Appendix B: Contributors

Regular participants of the WCAG Working Group:

Bruce Bailey, Kynn Bartlett, Dick Brown, Jonathan Chetwynd, Wendy Chisholm, Alan J. Flavell, Al Gilman, Katie Haritos-Shea, Donovan Hipke, Ian Jacobs, Marshall Jansen, Leonard Kasday, William Loughborough, Charles McCathieNevile, Marti McCuller, Matt May, Robert Neff, Sean B. Palmer, Anne Pemberton, Loretta Guarino Reid, Gregory J. Rosmaita, Lisa Seeman, Cynthia Shelly, Andi Snow-Weaver, Gregg Vanderheiden, Jason White

Other contributors:

Dan Aunspach, Harvey Bingham, Judy Brewer, Dan Brickley, David Clark, Michael Cooper, Nir Dagan, Daniel Dardailler, Geoff Freed, Greg Gay, Jon Gunderson, Shawn Lawton Henry, Chuck Hitchcock, Phill Jenkins, Chris Kreussling, Chuck Letourneau, Greg Lowney, Scott Luebking, Lisa Kestenbaum, Marja-Riitta Koivunen, Masafumi NAKANE, Tim Noonan, Anuska Perkins, David Poehlman, Chris Ridpath, Greg Rosenberg, Heather Swayne, David Tanner, Jim Thatcher, Claus Thøgersen, Peter Verhoeven, Cynthia Waddell, Mike Williams