W3C logo Web  Accessibility Initiative (WAI) logo

Web Content Accessibility Guidelines 2.0

W3C Working Draft 28 September 2000

This version:
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20000928
Latest version:
http://www.w3.org/WAI/GL/WCAG20
Preview version:
http://www.w3.org/WAI/GL/WCAG20/wcag20-reformulation21
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 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.

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.


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


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.

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.

2.1 Use markup languages properly and in accordance with specification.
This checkpoint requires not only that document instances comply with any formal grammar or other test of validity provided for in the relevant markup language specification, but also that structural elements, attributes etc., be used to convey the meanings which have been assigned to them in the specification.
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.

2.3 Where presentation is used to communicate distinctions of meaning or structure within the content, also define these distinctions in the markup or data model so that a user agent can create alternative presentations.
The structural markup or metadata, and the presentation, may reside in separate files or logical resources. Thus, purely presentational versions of the content (e.g., in a graphical format or a page description language) may be provided, so long as there exists a version that preserves in markup the structural and semantic distinctions implicit in the "presentational" version. In such circumstances, content negotiation may be used to select the version which best meets the user's requirements.
2.4 Use presentation (e.g. color or font changes) to enhance semantic distinctions but not as the only means to understand them.
This is a corollary of the preceding checkpoint. It should not be interpreted as discouraging the use of color or other style properties to enhance the presentation of content. It can be satisfied by ensuring that the distinctions conveyed by the presentation are also reflected in the markup.
2.5 Use markup or a data model to provide logical structure to the content, together with any additional semantic distinctions that facilitate rendering of the content visually, auditorily, or tactually.
Defining the logical structure serves two purposes:
  1. Users may apply their preferred style to the content. It allows the content to be presented effectively in a variety of modalities on a range of output devices.
  2. It provides the basis for structural navigation by the user. In order for the content to be rendered in all three modalities, it is necessary to capture such distinctions as emphasis and changes in the natural language or notation in which the text is written.

Note. Following this checkpoint, implies that the appropriate information is provided to enable sophisticated analysis of the content by search engines and other processing applications.

Guideline 3. Design for ease of comprehension

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.
3.2 Use color, styles, and graphics to emphasize the structure of the document.
This will help the user
3.3 Divide large blocks of information into more manageable groups where natural and appropriate.
For example,

Yes - use groupiong - see 2.5 for how

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

Use title element - see also 1.1

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:
  1. Restricting these items to one section of the page to help the user retain focus.
  2. For a content-filled site, providing an optional banner-free view".

Provide an outline style - see SVG-Access

Guideline 4. Design for ease of browsing and navigation

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 by a web site, enable different types of searches 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.
4.3 Avoid methods that interfere with navigation.
Practices that can disorient a visitor include

Guideline 5. Design user interfaces for device independence

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.

6.1 Make sure that web sites which take advantage of newer technologies continue to be usable when such technologies are turned off or not supported.
Note: it may be desirable to provide multiple versions of the same content in order to ensure backward compatibility. In determining the extent to which older technologies should be supported, content designers should bear in mind that assistive hardware and software are often slow to adapt to technical advances occurring in other areas, such as web-related standards. Also, for significant groups of users, it may not be possible to obtain the latest software or the hardware required to operate it.
6.2 Avoid causing content to blink or flicker otherwise than under the control of the user.
Although some user agents may allow the user to suppress blinking or flickering this is not universally the case. Content designers should exercise special care in using these effects.
6.3 Avoid causing pages to be refreshed or updated automatically, otherwise than in response to a user's 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.
6.4 Where it is likely that some user agents will not support the data format or encoding in which the content is supplied, provide metadata, a transformation filter, a style sheet or other mechanism to enable the content to be processed by the user agent.
This requirement is especially relevant in circumstances where a data format or markup language which is not widely supported, by default, in user agent software is relied upon. Note also the discussion of backward compatibility in checkpoint 5.1.

Glossary

@@need definitions

Content
Equivalent
Markup
Presentation
Semantics