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.
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.
- Use a
desc
and title
element for all
g
elements
- 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).
- For animations, use multiple symbols, with relevant desc for
each, and animate the reference via a use element - see
SVG-Access
- Use CSS-based effects, and provide stylesheets in multiple media
modes
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.
- Yes. CSS should be used, best to do it by classes - see
SVG-Access.
- 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.
- Define the structure of the image in SVG, and use CSS to provide
visual styling (colour, and so on). @@
- 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.
- This seems redundant with 2.3 - at least for SVG
- 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:
- 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.
- 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.
- Structure images from components, grouping the components in a
meaningful hierarchy. Use RDF to describe more complex
relationships between components of an image - see SVG-ACCESS and
SVGX browser work.
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.
- This is generally a requirement to have good graphic
communication.
- 3.2 Use color, styles, and graphics to emphasize the structure of the
document.
- 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.
Yes - use groupiong - see 2.5 for how
- 3.4 Label blocks of information to help users identify structurally
significant 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.
Use title element - see also 1.1
- 3.5 Place distinguishing information at the beginning of headings,
paragraphs, lists, etc.
- Examples? Explanations?
- Only really relevant for document-type presentations (but still
possible in SVG). Providing good structure and using that to make
the tree of alterntive equivalents have the most important things
at the top of the tree, with more detail further down
- 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.
- Only really relevant for document-type presentations (but still
possible in SVG) Note that this also applies to tiles and desc
elements
- 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).
- Provide audio using SMIL via namespaces for descriptions /
titles. See SVG-Access
- 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.
- This should happen automatically as a result of 3.5, 2.5, etc
(good structure) and good 1.1
- 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.
- Use namespaces to mark up text elements
- Use RDF metadata to provide the information
- Reflect this in the text itself
- 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".
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.
- Use consistent presentation for identifying links. !!! (although
it can also be donme by user stylesheet
- group blocks of links in a g element
- 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
- automatic refresh,
- redirection,
- opening a new browser window,
- frames that do not track history making the "back" button of most
browsers useless.
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.
- Do this - @@CMN example code
- 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?
- See SVG-access example!! (and more code 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.
- See User agent guidelines, and use standard declarative SVG
rather than procedural script wherever possible
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.
- @@ review base level implementations (there are no older
technologies for SVG yet except for generic XML+CSS processing -
need to think about that one). THis feeds to our requirement for
establishing baseline capabilities we expect...
- 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.
- Use animations - @@requirement for user agents to identify and
suppress them.
- 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.
- This is tricky - animations, ... We think it is a User Agent
requirement
- 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.
- Provide style sheets for generic XML+CSS (e.g. does text get
presented, or desc, or what? @@CMN Can we write a single default
one that is normally useful)
- Provide an XSLT to convert the text / desc into XHTML @@CMN
- Seems redundant with 6.1 (we prefer the 6.4 version)
Glossary
@@need definitions
- Content
- Equivalent
- Markup
- Presentation
- Semantics