- From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
- Date: Sat, 9 Sep 2000 11:50:16 +1100 (EST)
- To: Web Content Accessibility Guidelines <w3c-wai-gl@w3.org>
Several weeks ago, I accepted an action item which involved an undertaking
to rewrite the guidelines (not including the technology-specific checks)
to clarify the concepts and reflect some of the recent discussions which
have taken place within the working group. The results of this effort are
included below. It should be emphasized that what follows is not an
"official" working group draft. All members of the group are, therefore
welcome to propose alternatives, At this stage, I have not incorporated
William's proposed introduction, pending further discussion. Wendy's list
of characteristics of accessible web content could also be integrated into
an introductory overview.
Draft text, for your consideration, follows:
Draft Reformulation of Web Content Accessibility Guidelines
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. For the sake of
consistency with recent working group drafts, the terms principle and
guideline have been retained, notwithstanding the proposal advanced by
several members of the group that the words guideline and checkpoint
respectively, be substituted. This decision should not be regarded as
an endorsement of the present terminology.
Principles and Guidelines
Principle 1: Design content which can be presented visually, auditorily
or tactually,
according to the needs and preferences of the user.
Guidelines
1.1 Ensure, by providing textual 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 textual 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 textual 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 textual 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 textual equivalents (e.g., captions
of the audio track or descriptions of the video track) with the
presentation.
This guideline applies to multimedia presentations which have
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 textual equivalent, for example a description which
can be retrieved by the user in place of the multimedia
presentation, is still required (see guideline 1.1).
Principle 2: Separate content and structure from presentation, and ensure
that significant structural or semantic distinctions are captured explicitly
in markup, or in a data model.
Guidelines
2.1 Use markup languages properly and in accordance with
specification.
This guideline 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 secification.
2.3 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.
Style languages permit a high degree of separation to be
maintained between content and presentation, by allowing the
rules which control the rendering of the content to be
separated from the markup codes that denote its structural
features. 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
documents.
2.3 Where presentation is used to communicate distinctions of meaning
or structure within the content, ensure, if possible, that
these distinctions are captured in equivalent data or markup
which can be obtained and accessed by a user agent.
It should be noted that, in accordance with the above
requirement, the structural markup or metadata, and the
presentation, respectively, need not reside in the same file or
logical resource. 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
which can be retrieved by user agents and contains markup which
preserves the same structural and semantic distinctions that
are implicit in the "presentational" version. In such
circumstances, techniques of content negotiation may be used to
select the version which best meets the user's requirements.
2.4 Do not rely on presentation alone (E.G. colour or font changes) to
express semantic distinctions.
This is a corollary of the preceding guideline. It should not
be interpreted as discouraging the use of colour 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 Ensure that the logical structure of the content is preserved in
the markup or data model, together with any additional semantic
distinctions that facilitate rendering of the content in the
visual, auditory and tactile modalities.
The logical structure of the content needs to be explicitly
preserved for two purposes. First, it allows style rules (other
than those provided by the author) to be applied, thus enabling
the content to be presented effectively and appropriately in
different modalities, with a range of output devices. Secondly,
it provides the basis for structural navigation by the user. In
order for the content to be rendered in all three modalities,
it is also necessary to capture such distinctions as emphasis
and changes in the natural language or notation in which the
text is written. Note also that if this guideline is followed,
it will enable more sophisticated analysis of the content by
search engines and other document processing applications.
Principle 3: Design for ease of comprehension, browsing and navigation
Note: this principle is applicable only in circumstances in which the
web content consists of a document or user interface which 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 principle.
Guidelines
3.1 Use a consistent style of presentation in which the structural and
semantic distinctions expressed in the markup, are associated
with appropriate formatting conventions that enhance the
readability and intelligibility of the content.
The purpose of presentation is to communicate the meaning of
the content, as effectively as possible. Thus, to aid
understanding, it is vital that the structure and semantics of
the content be readily apparent from the presentational
conventions chosen by the author.
3.2 Provide clear and consistent navigation mechanisms throughout a
document or web site.
Such navigational mechanisms may include logically organized
groups of hypertext links, an overview or table of contents, a
site map (with an appropriate textual equivalent; see guideline
1.1), an index, etc. They should be easy to locate within the
over-all structure of the content and consistent across web
pages or related documents.
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. Use headings, paragraphs, lists etc.,
appropriately to communicate relationships among items, topics
or ideas.
3.4 If search functions are provided by a web site, enable different
types of searches for different skill levels and preferences.
Examples needed here.
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 guideline is intended 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. Authors should
however strive for clarity and simplicity in their writing, and
review the text with these considerations in mind prior to
publication on the web.
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 the textual content is written. Note that
material provided in auditory or visual forms must also be
available as text (see guideline 1.1).
3.8 Use headings, labels and titles appropriately to identify
structurally significant divisions within the content.
For example, use headings to identify important topics or
subdivisions within a document. Label table headers, user
interface controls and other complex structures within the
content. Note that in addition to full, descriptive labels, it
may also be appropriate, in designing complex structures such
as tables and forms, to provide abbreviated labels which can be
used when the content is rendered on small displays or via
speech output.
3.9 Provide an overview or summary of highly structured materials,
such as tables and groups of user interface controls.
A discussion of which types of structures should be considered
complex, and the circumstances in which this guideline applies,
should be added here.
3.10 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.
Principle 4: Design user interfaces for device independence
Note: this principle applies only where the content provides its own
user interface (for example as a form or programmatic object).
Guidelines
4.1 Associate an explicit label with each user interface control.
This guideline applies not only to individual user interface
controls, but also to groups of such controls, which should
likewise be provided with descriptive labels.
4.2 Ensure that user interface controls are grouped logically.
Note that there is an upper limit to the number of user
interface controls that should occur in a single group; see
guideline 3.3.
4.3 Ensure that event handlers are device-independent.
Examples?
4.4Design user interfaces to be compatible with assistive
technologies.
Use standard software conventions to control the behaviour and
activation of user interface components. Note that
platform-specific guidance may be available for your operating
system or application environment.
Principle 5: Design content to be compatible with the features and
capabilities of user agents, including those which only support older
technologies or standards.
Guidelines
5.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.
5.2 Avoid causing content to blink or flicker otherwise than under the
control of the user.
Note that although some user agents may permit blinking or
flickering to be suppressed, this is not universally the case.
Content designers should therefore exercise special care in
avoiding such presentational effects.
5.2 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.
5.3 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 guideline 5.1.
Draft prepared by Jason White.
Please direct comments to the working group mailing list at
w3c-wai-gl@w3.org.
Received on Friday, 8 September 2000 20:52:20 UTC