Status

This document is prepared by the W3C
Web Content Accessibility Guidelines Working Group (WCAG WG) to show how
more generalized (less HTML-specific) WCAG checkpoints
mightread. This draft is not based on consensus of the
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 working group they will be marked as "[New]" for a couple of drafts thereafter.

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 can be found at http://www.w3.org/TR/.

Introduction

This draft is intended for internal discussion by the working group.
Consequently, all introductory and explanatory material, together with the
technology-specific checks, have been omitted.

[New] The differences between WCAG 1.0 and WCAG 2.0

Since the release of WCAG 1.0 in May 1999, the 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, WCAG 2.0:

is more efficiently organized,

may adjust the priority of some checkpoints,

modifies, removes, or adds requirements due to changes in Web
technologies since the publication of WCAG 1.0,

Improvements in WCAG 2.0

We hope that WCAG 2.0 has 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.

Guidelines and Checkpoints

Guideline
1. Design content that can be presented visually, auditorily or tactually,
according to the needs and preferences of the user.

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
information.

Depending on the purpose and content of the non-text element, 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.

This checkpoint applies to multimedia presentations with auditory and
visual components. Where one component (either the audio or video track)
contains no significant information, a synchronized caption or
description need not be provided, though a text
equivalent, for example a description which can be retrieved by the
user in place of the multimedia presentation, is still required (see
checkpoint 1.1).

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

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
clip.

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.

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.

2.2 Use style languages, where
available, to control layout and presentation. Where practicable, provide
(or link to) multiple style sheets, each supporting a different output
device.

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.

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
"frame."

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

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
bicycle.

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
that device.

Note: this guideline is applicable only in circumstances in which the web
content is intended to be presented to a human reader. A structured data base
or collection of metadata, in circumstances where the user interface is
supplied entirely by the client application, lies outside the scope of this
guideline.

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.

[Proposed - added text to explanation]3.2 Emphasize
the logical structure of the content through presentation.

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
supplementary text..

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).

3.4 Label blocks of
information to help users identify significant structural divisions within
the content.

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.

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.7 Supplement text
with graphic or auditory presentations where they will facilitate
comprehension of the content.

Auditory and graphical presentations can do much to improve the
comprehensibility of a web site, especially to people with cognitive
disabilities or to those who are unfamiliar with the language in which
text is written. Note that material provided in auditory or visual forms
must also be available as text (see checkpoint 1.1).

3.8 Provide an
overview or summary of highly structured materials, such as tables and
groups of user interface controls.

A structure should be considered complex if it is not immediately
obvious what each piece of information is and the reason for its
position within the structure. Insinuations and trends that are intended
to be identified by analyzing the structure, should be explicitly stated
in the summary.

3.9 Define key terms and
provide expansions for abbreviations and acronyms, which should be
identified using appropriate markup.

Note: only the first occurrence of an abbreviation or acronym
occurring in a document need be expanded. Expansion dictionaries, for
instance in metadata, may be provided as an alternative to an expansion
in the text of a document.

Such mechanisms may include logically organized groups of hypertext
links, an overview or table of contents, a site map (with an appropriate
text equivalent; see checkpoint 1.1), an index, menu bars, etc.
Navigation mechanisms should be easy to locate and consistent.
Navigation techniques for documents can help the user skim a document.
For example, in-page anchors at each heading, grouping collections of
links and allowing them to be bypassed.

4.2 If search functionsare provided,
provide a variety of search options for different skill levels and
preferences.

Users with spelling disabilities or users who are learning a new
language, may have a difficult time finding information if a search
engine requires perfect spelling. Search engines might include a spell
checker, offer "best guess" alternatives, query-by-example searches,
similarity searches, etc.

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.

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.

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 (guideline 1);

allow the logical structure of the content to be defined
independently of presentation (guideline 2);

support device-independence (guideline 5);

are documented in published specifications and can be implemented
by user agent and assistive technology developers;

are supported by user agents and assistive technologies.

Glossary

@@need definitions

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.

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.