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.
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 firstname.lastname@example.org. The archives for this
list are publicly available.
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
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:
- 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.
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:
- Someone who can not hear will want see the information.
- Someone who can not see will want to hear or touch the information.
- Someone who does not have the strength to move quickly or easily will
want to use as little movement as possible to see or hear or feel the
- Someone who does not read well may want to hear the information and see
words highlighted as they are read.
For more in-depth scenarios, please read "How People
with Disabilities Use the Web".
Think about the process used to build a new office building. The structure
of the building - its skeleton - is built before the decorations are
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.
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
Design for ease of comprehension
Design for compatibility and interoperability
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
- will be more efficiently organized,
- may adjust the priority of some checkpoints,
- may modify, remove, or add requirements due to changes in Web
technologies since the publication of WCAG 1.0,
- will incorporate the Errata from WCAG 1.0,
- will reflect the experience gained in implementing WCAG 1.0.
For a checkpoint by checkpoint comparison, refer to the Checkpoint
Mapping Between WCAG 1.0 and WCAG 2.0 Working Draft.
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
- 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
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
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
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
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:
- User capabilities: sight, hearing, movement, comprehension, accessing
information only visually, only auditorily, only tactilely, or through
some combination of audio, visual, and tactile.
- Device and user agent capabilities: screen size, interaction methods
such as: interacting with information using only a keyboard (i.e. without
a mouse), only through voice, without voice, or using an assistive
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
- A text equivalent
- Communicates the same information as the non-text content.
- Serves the same function as the non-text content.
- May contain structured content or metadata.
- May be easily converted to braille or speech, or displayed in a
larger font or different colors. Thereby providing access to the
information for someone who can not see at all, who can not see
well, or who needs to supplement visual information with auditory
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.
- Example 1. a short label
A right arrow icon is used to link to the next slide in a slideshow.
The text equivalent is "Next."
- Example 2. a short label and a longer explanation: A bar chart
compares how many widgets were sold in June, July, and August. The
short label says, "Graph of the numbers of widgets sold in June,
July, and August." The longer explanation provides the data
presented in the chart.
- Example 3. a short label and a longer explanation: An animation
shows how to tie a knot. The short label says, "An animation showing
how to tie a square knot." The longer explanation describes the hand
movements needed to tie the knot.
- 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.
- When text equivalents of auditory information are synchronized
with the multimedia presentation they are called "captions."
- When text equivalents of visual information are spoken aloud
(either by a human or a speech synthesizer) and synchronized with
the multimedia presentation they are called "auditory descriptions."
Refer to checkpoint 1.3.
- 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
- Example 1. A clip from a movie is published on a Web site that
contains a scene where a child is trying to lure an alien to the
child's bedroom by laying a trail of candy. The child is talking to
himself as he lays the trail, but it is not obvious when not
watching the video that this is what he is doing. Therefore, a short
description is interspersed with the child's talking that says
"Charlie lays a piece of candy on each stair leading to his room."
Similar descriptions are included throughout the rest of the
- Example 2. A video clip accompanies a news story about the recent
flooding in a major city. The reporter describes what is seen, for
everyone. No further description is necessary.
- Example 3. An animation shows a clown slipping on a banana and
falling down. There is no audio track for this animation. No
synchronized description is required. Instead, provide a static
description according to checkpoint 1.1.
- 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,
- 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.
- 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.
- 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
When the logical structure is documented in markup or a data
- a reader may use software to jump between changes in context. For
example, a reader could jump from chapter title to chapter title in
the book, between scenes in the play, or between parts of the
- a reader may change how chapter titles are displayed or how text
is emphasized, based on their personal preferences.
- the content can be presented on a variety of devices because the
device software can choose only those elements of the content that
it is able to display and display them in the most effective way for
- 1.5 Separate content and structure from
- 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
- a table of contents,
- a site map,
- an index,
- menus or navigation bars,
- a link that jumps over navigation links and positions the user at
the beginning of the primary content on the page,
- image maps,
- a search function.
[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:
- rollover effects,
- popup menus,
- submitting a form after the user activates the submit button,
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:
- opening a new browser window,
- frames that do not track history making the "back" button of most
This can be satisfied by providing an option to deactivate the
changes in context. User agents may also offer control over this
- 2.4 Give users control over how long
they can spend reading or interacting with content.
- Mechanisms that required a timed response include:
- automatic refresh,
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
- 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
- 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
- orient himself or herself within the document,
- focus on important content,
- allow the author to highlight key ideas within the context of
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
- 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
- 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
- 3.5 Summarize complex
- Examples of complex information:
- data tables,
- concepts that are esoteric or difficult to understand,
- content that involves several layers.
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
- For example,
- Divide user interface controls into logically organized
- Paragraphs and sections should have clear, accurate, and
informative headers. Limiting each paragraph to one main idea will
help people process the information.
- Use headings, paragraphs, lists etc., appropriately to communicate
relationships among items, topics or ideas.
- 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:
- permit equivalents to be associated with or synchronized with
auditory, graphical, and multimedia content;
- allow the logical structure of the content to be defined
independently of presentation;
- support device-independence;
- are documented in published specifications and can be implemented
by user agent and assistive technology developers;
- are supported by user agents and assistive technologies.
- 4.2 Use languages, API's, and
protocols according to specification.
- This checkpoint requires
- that markup conforms to the validity tests of the language
(whether it be conforming to a schema, DTD, or other tests described
in the specification), and
- that structural elements and attributes are used as defined in the
specification. For example, do not use structural elements for
purposes of presentation. Likewise, do not use presentation elements
for purposes of structure.
- 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
- 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:
- a transformation filter,
- a mechanism to enable the content to be processed by the user,
- multiple versions of the same content in order to ensure backward
In determining the extent to which older technologies should be
supported, keep in mind that
- assistive hardware and software are often slow to adapt to
- for significant groups of users, it may not be possible to obtain
the latest software or the hardware required to operate it.
- 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
- Not yet defined.
- Not yet defined.
- Not yet defined.
- Not yet defined. The definition must include the idea of timelines and
slide shows (per 30
November 2000 telecon)
- 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
- Not yet defined.
- Not yet defined.
- Transform gracefully
- Not yet defined.
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
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