Web Content Accessibility Guidelines 2.0
W3C Working Draft 18 October 2000
- This version:
- http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20001018
- Latest version:
- http://www.w3.org/WAI/GL/WCAG20
- Preview version:
- http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20000928
- Editors:
- Jason White, University of Melbourne
Wendy Chisholm, W3C
Gregg Vanderheiden, Trace R&D Center
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 might
read. 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.
Please refer to "Issue Tracking for WCAG
2.0" for a list of open issues related to this 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 can be found at http://www.w3.org/TR/.
Please send comments on this document to w3c-wai-gl@w3.org. The archives for this
list are publicly available.
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.
[Proposed - new section]
What is the difference 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,
- incorporates the Errata from WCAG 1.0,
- reflects 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 checkpoints.
Why publish a new version?
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.
- 1.1 Ensure, by providing text equivalents to auditory and graphical presentations
as necessary, that every component of a document, web page or multimedia
presentation can be rendered as text in a standard character set.
- Note: a text equivalent can take a variety of
forms. It is intended to fulfill the same function, and serve the same
purpose as the auditory or visual presentation to which it provides an
alternative. Thus, in writing a text equivalent,
it may be appropriate, in some contexts, to provide a short label or
descriptive phrase that can be substituted for the auditory or graphical
material. In other circumstances, however, a longer explanation,
description or exposition may be required. A text
equivalentmay consist of structured content or metadata, if
appropriate.
- 1.2 For any time-based multimedia
presentation (e.g., a movie or animation), synchronize the
text equivalents (e.g., captions of the
audio track or descriptions of the video track) with the presentation.
- 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).
Guideline 2. Separate content
and structure from presentation and explicitly define significant structural
or semantic distinctions in markup or in a data model.
- [Proposed - clarification] 2.1 Use markup
languages 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.
- 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.
- [Proposed - combining checkpoints] 2.3 Use markup or a data
model to provide logical structure to content.
- Providing logically structured content serves several purposes:
- The ability to navigate the content with a user agent via the
structure.
- The ability to apply style to content based on user preferences
and device capabilities.
- Search engines and other applications can process the content
[@@why is this note here? this is true of several checkpoints].
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.
- 3.1 Use a consistent style of
presentation that will facilitate comprehension of the content.
- 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 Use color,
styles, and graphics to emphasize the logical structure of the
content.
- In so doing, ensure that the structural and semantic distinctions
defined in the markup (checkpoint 2.3) are reflected in the
presentation. This will help the user
- orient himself or herself within the document,
- focus on the important elements of the document,
- differentiate between a key element and the explanatory or
supplementary material.
- 3.3 Divide large blocks of
information into more manageable groups where natural and
appropriate.
- For example,
- Divide user interface controls into logically organized
groups.
- 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.
- 3.4 Label blocks of
information to help users identify significatn 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.
- 3.5 Place
distinguishing information at the beginning of headings, paragraphs,
lists, etc.
- Examples? Explanations?
- 3.6 Use the clearest
and simplest language appropriate for a site's content.
- 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.
- 3.10 Minimize
content that will interfere with the user’s ability to focus.
- Animations and banners frequently disorient the user and interfere
with the user’s ability to focus from the main content of the page. This
can be improved by:
- Restricting these items to one section of the page to help the
user retain focus.
- For a content-filled site, providing an optional banner-free
view".
- 4.1 Provide
clear and consistent navigation mechanisms throughout a document,
application or site.
- 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 functions are 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.
- [Proposed - clarification] 4.3 Do not use
mechanisms that may interfere with navigation.
- Practices that can disorient a visitor include
- automatic refresh,
- redirection,
- opening a new browser window,
- frames that do not track history making the "back" button of most
browsers useless.
[@@Got rid of avoid, but this is way too strong]
Note: this guideline applies only where the content provides its own user
interface (for example as a form or programmatic object).
- 5.1 Associate an explicit
label with each user interface control.
- This checkpoint applies not only to individual user interface controls
but also to groups of controls.
- 5.2 Logically group
user interface controls.
- Note that there is an upper limit to the number of user interface
controls that should occur in a single group, refer to checkpoint
3.x.
- 5.3 Use
device-independent event handlers.
- Examples?
- 5.4 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.
Guideline 6.
Design content to be compatible with the features and capabilities of user
agents, including those that only support older technologies or
standards.
- [Proposed - combined with 6.4] 6.1 The site must be usable
when newer technologies are turned off or not supported.
- This may be accomplished by providing:
- metadata,
- a transformation filter,
- a style sheet,
- a mechanism to enable the content to be processed by the user,
or
- multiple versions of the same content in order to ensure backward
compatibility (refer to checkpoint 5.1).
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
technical advances.
- for significant groups of users, it may not be possible to obtain
the latest software or the hardware required to operate it.
- [Proposed - clarification] 6.2 Do not cause content to blink or
flicker unless the user can control the rate of change.
- Some user agents allow the user to suppress blinking or flickering,
but many user agents do not. Use blink and flicker carefully. [@@Too
strict??]
- [Proposed - clarification] 6.3 Do not automatically
refresh or update content. Refresh or update content per user
request.
- Note that this requirement 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. [@@Too
strict??]
Glossary
@@need definitions
- Content
- Equivalent
- Markup
- Presentation
- Semantics