WD-WAI-PAGEAUTH-19980825
WAI Accessibility
Guidelines: Page Authoring
W3C Working Draft -25
August 1998
- This version:
- http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-19980825
- Latest version:
- http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH
- Previous versions:
- http://www.w3.org/WAI/GL/19980806.htm
- http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-0414.html
- http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-0203.html
- Editors:
- Gregg Vanderheiden <po@trace.wisc.edu>
Wendy Chisholm <chisholm@trace.wisc.edu>
Ian Jacobs <ij@w3.org>
Abstract
This document is a list of guidelines that
page authors should follow in order to make
their pages more accessible for people with
disabilities as well as more useful to other
users, new page viewing technologies (mobile
and voice), and electronic agents such as
indexing robots. Tools that generate
documents in HTML (authoring tools, file
conversion packages, or other products)
should produce documents that follow these
guidelines. This document is part of a
series of accessibility documents published
by the Web
Accessibility Initiative.
Status of this document
This is a W3C Working Draft for review by
W3C members and other interested parties. It
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". This is work in progress and
does not imply endorsement by, or the
consensus of, either W3C or members of the
WAI GL Working Group.
This document has been produced as part of
the W3C WAI
Activity, and is intended as a draft
of a Proposed Recommendation for authoring
accessible Web pages. The goal of the
WAI-GL
working group is discussed in our
charter.
Comments
Please send detailed comments on this
document to
w3c-wai-gl@w3.org.
Public comments about the WAI author
guidelines can also be sent to this
mailing list.
Rating and
Classification
- A. Make sure pages
transform gracefully across users,
techniques, and situations
- A.1. Provide
alternative text for images,
applets, and image maps
- A.2. Provide
descriptions
- A.3. Provide textual
equivalents for audio information
- A.4. Provide
descriptions of moving visual
information in both auditory and
text form
- A.5. Design
documents in a way that allows
alternative presentations to be
provided
- A.6. Ensure that
text and graphics are perceivable
and understandable when viewed
without color
- A.7. Indicate
structure with structural elements,
and control presentation with
presentation elements and style
sheets
- A.8. Ensure that
moving, blinking, scrolling, or
auto-updating objects or pages may
be paused or frozen
- A.9. Provide
supplemental information needed to
pronounce or interpret abbreviated
or foreign text.
- A.10. Ensure that
pages using newer W3C features
(technologies) will transform
gracefully into an accessible form
- A.11. Elements that
contain their own user interface
should have accessibility built in
- A.12. Use features
that enable activation of page
elements via input devices other
than a pointing device (e.g., via
keyboard, voice, etc.).
- A.13. Design
documents that use interim
accessibility solutions so that
assistive technologies and older
browsers will operate correctly.
- A.14. If, after all
of your best efforts, any page is
still not accessible then you MUST
provide a link to an alternative
page
- B. Provide context and
orientation information for complex pages
or elements
-
- C. Maximize usability by
following good design practices
-
- Appendix:
Definitions
- [PRIORITY 1]
- This guideline must
be followed by an author, or one or more
groups of users will find it impossible to
access information in the document.
Implementing this guideline is a basic
requirement for some groups to be able to
use WWW documents.
- [PRIORITY 2]
- This guideline should
be followed by an author, or one or more
groups of users will find it difficult to
access information in the document.
Implementing this guideline will
significantly improve access to WWW
documents.
- [PRIORITY 3]
- This guideline should
be followed by an author to make it easier
for one or more groups of users to access
information in the document. Implementing
this guideline will improve access to WWW
documents.
Each Guideline and each
Technique has a priority listed. For the
guidelines, the priority refers to the
importance of addressing the issue
identified by the guideline. For Techniques,
the priority refers to which technique best
improves accessibility with respect to this
guideline. For example, a Priority 1
Guideline may have a Priority 1 Technique,
which must be done to
provide accessibility, and a Priority 3
Technique, which may also
be done to help address the issue.
A. Make sure pages
transform gracefully across users, techniques,
and situations
To "transform gracefully" means
that a page remains usable despite user,
technological, or situational constraints.
In order to use the page at all, some users
may need to "turn off" features
specified by the author (font size, color
combinations, etc.). For example, a person
with low vision might need to display all
text in 36-point font, so any formatting
based on an author-determined font size will
fall apart.
To create documents that transform
gracefully, authors should:
- Ensure that all the information on the
page may be perceived entirely visually or
entirely through auditory means, or that
all information is also represented
textually.
- Ensure that pages will be operable on
various types of hardware including
devices without mice, with small or low
resolution screens, with only voice or
text output, without screens, etc.
- Always separate the content on your
site (what you say), and the way you
choose to structure that content (how you
organize it), from the way the content and
structure are presented (how you want
people to "see" it).
1. Provide
alternative text for all images, applets,
and image maps. This includes
images used as submit buttons and all of the
links within an image map. [Priority 1]
Note. Alternative text does not describe
the visual appearance of an image, applet, or
image map. Rather, it is used to represent the
function the image, applet, or image map
performs.
Rationale:
Otherwise, users who are blind,
have low vision, or have
chosen not to view graphics
will not know the purpose of the visual
components on the page.
Since "bare"
ASCII art
(characters that form images) does not allow
alt-text, it must be marked up specially for
this purpose.
Techniques:
- For all
images
(IMG) provide alt-text (via the "alt"
attribute). [Priority 1]
- For all
applets
(APPLET) provide alt-text (via the "alt"
attribute) and content. [Priority 1]
- For all
image
map links (AREA)
- Provide alt-text (via the "alt"
attribute). [Priority 1]
- Also provide redundant links.
[Priority 2]
- Don't use
server-side
image maps unless the same
functionality or information is available
in an alternative accessible format.
[Priority 1]
- For all
graphical
buttons (INPUT type="image")
provide alt-text (via the "alt"
attribute) [Priority 1]
- Replace
ASCII art with an image and
alt-text. [Priority 1 or 2 depending on
the importance of the information (e.g.,
an important chart)] Note. If the
description of (important) ASCII art is
long, provide a description
in addition to alt-text.
- If OBJECT is used to incorporate an
image, applet, or script into a page, use
any of the
many
ways to convey that information in
cases where the OBJECT cannot be
perceived. [Priority 1]
2. Provide
descriptions for graphics,
scripts, or applets that convey important
information unless they are
already fully described (through alt-text
or in the document's content). [Priority1]
Rationale:
Otherwise, important information presented
graphically (charts, billboards, diagrams)
will not be perceivable to people with
blindness, some people
with low vision, and users
who have chosen not to view
graphics, scripts, or applets or
whose browser does not support
scripts or applets.
Techniques:
- Provide a long description of all
graphics that convey important
information. To do so:
- Use
"longdesc".
[Priority 1]
- Until most browsers support "longdesc",
also use
d-links
(or invisible d-links). [Priority 1]
- If OBJECT is used to incorporate an
image, applet, or script into a page, and
it presents important information, use any
of the
many
ways to convey that information in
cases where the OBJECT cannot be
perceived. [Priority 1]
Rationale:
Otherwise, users who are deaf,
or hard of hearing, or who
have sound turned off
cannot perceive the information presented
through speech, sound effects, music, etc.
Techniques:
- For
stand-alone
audio files provide a textual
transcript of all words spoken or sung as
well as all significant sounds. [Priority 1]
- For
audio
associated with video, provide a
textual transcript (of dialog and sounds)
synchronized
with the video (e.g., captions). [Priority 1]
- Where sounds are played automatically,
provide
visual notification and transcripts.
[Priority 1 or 2 depending on the
importance of the sound]
4. Provide verbal
descriptions of moving visual information in
both auditory and text form (for
movies, animations, etc.). If the visual
presentation is associated with an auditory
presentation (e.g., for a movie), synchronize
the audio version of the descriptions with the
existing auditory presentation and
collate the text version of the
descriptions with the text transcript
(captions) of the primary audio track.
[Priority 1]
Rationale:
Otherwise, if actions, body language, or
other visual cues present information that
is not expressed through auditory means as
well (through dialogue, sound effects,
etc.), users who cannot see
(or look at) the page will not be able to
perceive it. The collated text version
allows access to the information by
devices that do not play movies and
by people who are deaf-blind.
Techniques:
- For short animations such as animated "gif"
images, provide alt-text
(see A.1)and a short
description (see A.2) if needed.
[Priority 1]
- For movies, provide
auditory
descriptions that are synchronized
with the original audio. [Priority 1]
- Provide a
text
version of the auditory description
that is collated with the text transcript
(captions) of the primary audio track.
[Priority 2]
Rationale:
The easier it is to provide alternate
presentations, the more likely it is authors
will do so. Both good design and accessible
authoring tools will facilitate this.
For example, if you specify an image as the
source of a frame (via the "src"
attribute), then there is no simple way to
attach alt-text (see A.1)
to that image.
Techniques:
- Ensure
that the source of each frame is an HTML
file. [Priority 1]
Rationale:
Otherwise, if color is used to convey
information, users who cannot
differentiate between certain colors
(and users with devices that have
non-color or non-visual displays)
will not receive the information.
When
foreground and background colors are too
close to the same hue, they may not provide
sufficient contrast when viewed using
monochrome displays or by
people with different types of
color blindness.
Techniques:
- Don't
use color to convey information
unless the information is also clear from
the markup and/or text. [Priority 1]
- Use foreground and background
color
combinations that provide sufficient
contrast when viewed by someone with
color blindness or when viewed on a black
and white screen. [Priority 1]
Rationale:
When structural elements and attributes
are used to create presentation effects,
user agents that allow users to
navigate through the structure will
be unable to do so properly. Such practices
also make it difficult to render the page on
other media and devices. For instance, don't
use H1 to create large, bold face text
unless that text is actually a top-level
heading.
Techniques:
- Nest
headings properly (H1 - H6).
[Priority 2]
- Encode
list structure and list items properly
(UL, OL, DL, LI). [Priority 2]
- Do not use an image map to create a set
of buttons in a form. Instead,
use
separate buttons or images
(accompanied by alt-text).
[Priority 2]
- Use
style
sheets to control layout and
presentation wherever possible as soon as
a majority of browsers in use support them
(see A.10). Until
then,
tables
(to control layout) and
bitmap
text with alt-text (for special text
effects) may be used, with
alternative
pages used as necessary to ensure
that the information on the page is
accessible. [Priority 2]
- Use
relative
sizing and positioning (e.g.,
percent) rather than absolute (e.g.,
pixels or point). [Priority 2]
Rationale:
Note. This does not
apply to instant
redirection.
Some people with cognitive
limitations or visual
disabilities are unable to read
moving text quickly enough or at all.
Movement can also cause such a distraction
that the rest of the page becomes unreadable
for people with cognitive
disabilities. Screen readers are
unable to read moving text. People with
physical disabilities
might not be able to move quickly or
accurately enough to interact with moving
objects. People with photosensitive
epilepsy can have seizures triggered by
flickering or flashing in the 4 to 59 Hertz
range with a peak sensitivity at 20 Hertz.
Techniques:
- Avoid
using movement where possible.
[Priority 3]
- Provide a mechanism to allow users to
freeze
motion or updates in applets and
scripts or use
style
sheets and scripting to create
movement. (see also A.10)
[Priority 2]
- For auto-refreshing or timed response
pages, provide a second copy of the page
where refresh
only
happens after a link has been selected
(until user agents provide this ability
themselves). [Priority 1]
- Avoid
any blinking or updating of the screen
that causes flicker between 4 and 59
Hertz. [Priority 1]
Note. BLINK
and MARQUEE are not defined in any W3C
HTML specification and should not be used.
See C.1
Rationale:
Unless changes between multiple languages
on the same page are identified, and
expansions for abbreviations and acronyms
are provided, they may be indecipherable
when spoken or brailled.
Techniques:
- Use the "lang" attribute to
clearly
identify
changes in the language of text.
[Priority 2]
- For
abbreviations use ABBR with the "title"
attribute to specify the expansion.
[Priority 2]
- For
acronyms use ACRONYM with the "title"
attribute to specify the expansion.
[Priority 2]
Rationale:
Each release of HTML has included new
language features. For example, HTML 4.0
added the ability to attach style sheets to
a page and to embed scripts and applets into
a page. Older browsers
ignore new features and some users
configure their browser not to make use of
new features. These users often see
nothing more than a blank page or an
unusable page when new features do not
transform gracefully.
Techniques:
- Provide
a
fallback page for pages that contain
frames (e.g., by using NOFRAME).
[Priority 1]
- For scripts that present critical
information or functions,
provide
an alternative, equivalent presentation
or mechanism (e.g., by using
NOSCRIPT). [Priority 1]
- For pages that use style sheets, ensure
that the contents of each page are
ordered
and structured so that they read
appropriately without the style sheet.
[Priority 1]
- Applets: (embedded using OBJECT or
APPLET)
- At a minimum:
- If possible, provide
an
alternative function or presentation
in a format other than an applet. For
example, a canned "mpeg"
movie of a physics simulation (written
in Java) or a single frame of the
animation saved as a "gif"
image. [Priority 2]
See also A.14
Rationale:
The accessibility of objects with their
own interface is independent of the
accessibility of the user agent.
Accessibility must therefore be built into
the objects or an alternative must be
provided (see A.12.4).
Techniques:
- Where possible
make
applets directly accessible (see
also A.10.4). [Priority 1 if
information or functionality is important,
and not presented elsewhere,otherwise
Priority 2]
Rationale:
Someone who is using the page without
sight, with voice input, or with a keyboard
(or input device other than a
mouse) will have a difficult time navigating
a page if operation requires a pointing
device. If a page is usable via a keyboard,
it is more likely that it should also be
operable via speech input, or a command line
interface. Access to image
maps is impossible for these users if
alternatives are not provided.
Techniques:
- For
image
maps, provide alternative text for
links. [Priority 1] see
alto A.1
- If possible, ensure that
all elements that
have their own interface are keyboard operable (see
also A.11). [Priority 2]
- Create a
logical
tab order through links, form
controls, and objects (via the "tabindex"
attribute or through logical page design).
[Priority 3]
- Provide
keyboard
shortcuts (via the "accesskey"
attribute) to links (including those in
client-side image maps), form controls,
and groups of form controls). [Priority 3]
Rationale:
Older browsers are
unable to "Tab" to edit boxes,
text areas and lists of consecutive links,
making it difficult to impossible for users
to access them.
Users not
operating in a graphical environment
are disoriented by being transferred to a
new window without warning.
Until most users are able to secure newer
technologies that address these issues:
Techniques:
- Include
default,
place-holding characters in edit
boxes and text areas. [Priority 3]
- Include
non-link,
printable characters (surrounded by
spaces) between links that occur
consecutively. [Priority 3]
- Do
not use pop-up windows, new windows,
or change active window unless the user is
aware that this is happening. [Priority 2]
- For all form controls with labels,
ensure that the label that is either:
Rationale:
- is accessible,
- has equivalent information,
- is updated as often as the
inaccessible page.
[Priority 1]
Some pages will be unable to transform
gracefully at this time either because the
visual components are too complex, or
because assistive technologies or user
agents (browsers) are lacking a specific
feature. For example a complex table (e.g.,
of text and numbers) must be converted into
a linear version.
Techniques:
- Until user agents and screen readers
are able to handle text presented
side-by-side, all tables that
lay out text in parallel, word-wrapped
columns require
a
linear text alternative (on the
current page or some other). [Priority 1]
- If you can not make a page accessible
then do one of the following [Priority 1]:
B. Provide context and
orientation information for complex pages or
elements.
To provide context and orientation
information means that additional
information is provided to help users gain
an understanding of the "big picture"
presented by a page, table, frame, or form.
Oftentimes users are limited to viewing only
a portion of a page, either because they are
accessing the page one word at a time
(speech synthesis), or one section at a time
(small display, or a magnified display).
To create documents that provide context
and orientation information, authors should:
- Structure and group information.
- Clearly label the structure and groups.
Rationale:
Users with blindness and
low vision often access
the screen with "tunnel vision"
and are unable to get an overview
understanding of the page. Complex
relationships between frames may also be
difficult for people with cognitive
disabilities to use.
Techniques:
- Provide
titles
for frames (via the "title"
attribute on FRAME) so that users can keep
track of frames by name. [Priority 1]
- Use
"longdesc"
(where needed) to associate a more
complete description (than is provided by
the title) directly with the frame. Until
"longdesc" is widely supported,
also used-links
or
invisible
d-links. [Priority 2]
Rationale:
This provides contextual information about
the relationship between controls, which is
useful for all users.
Techniques:
- Group
form controls (using the FIELDSET
and LEGEND elements). [Priority 2 for
radio buttons and checkboxes, Priority 3
for other controls.]
- Associate
labels to their controls (using
LABEL and its "for" attribute).
[Priority 2]
- Create
a hierarchy of long lists of choices
(with OPTGROUP). [Priority 2]
Rationale:
Many user agents restructure tables to
present them. Without appropriate markup,
the tables will not make sense when
restructured. Tables also present special
problems to users of screen readers.
These guidelines benefit users that are
accessing the table through
auditory means or viewing
only a portion of the page at a time (e.g.,
users with blindness or low vision, users
with an auto-pc or using devices with small
displays, etc.).
Techniques:
- Provide
summaries
for tables (via the "summary"
attribute on TABLE). [Priority 3]
- Identify
headers for rows and columns (TD and
TH). [Priority 2]
- Where tables have
structural
divisions beyond those implicit in the
rows and columns, use appropriate
markup to identify those divisions (THEAD,
TFOOT, TBODY, COLGROUP, the "axis"
and "scope" attributes, etc.).
[Priority 2]
- Provide
abbreviations
for header labels (via the "abbr"
attribute on TH). [Priority 3]
Rationale:
- do not repeat on a page,
- are meaningful when read out
of context,
- are terse
[Priority 2]
"Auditory users," people who are
blind, have
difficulty seeing, or who are
using devices with small or no
displays are unable to scan the
page quickly with their eyes and often use a
list of links to get an overview of a page
or to quickly find a link. When links are
not descriptive enough, do not make sense
when read out of context, or are not unique,
the auditory user must stop to read the text
surrounding each link to identify it.
Wherever possible:
Techniques:
- If more than one link shares the same
textual phrase,
all
those links should point to the same
resource. [Priority 2]
- Avoid
phrases that are not meaningful on their
own such as "click here."
[Priority 2]
- Avoid creating link phrases that
contain
full
sentences. [Priority 2]
C. Maximize usability by
following good design practices.
Good design is accessible design and
vice-versa. For instance, many of the
practices that lead to more accessible pages
also make them accessible to indexing
engines as well as more usable by
all users. Good design practices include
consistency, generality, simplicity, reuse,
and validation.
Rationale:
Many non-HTML technologies (e.g., PDF,
Shockwave, and other non-W3C data formats)
used to encode information require either
plug-ins or stand-alone applications that
often create pages that cannot be viewed or
navigated using standard Web access tools.
By avoiding non-standard features (elements,
attributes, properties, etc. only supported
by a specific browser type), your pages will
be accessible to more people using a wider
variety of hardware and software.
Note. Not all PDF pages are accessible
or readable after being run through a PDF
translator. Indivdually test each page for
readability after the translation process.
If a page does not automatically translate,
either re-layout the page in PDF or manually
generate an HTML or text equivalent.
Techniques:
- If a non-W3C technology must be used to
display information for some reason,
provide one of the following [Priority 1]:
- Use the latest
specifications whenever possible.
- Avoid
deprecated elements whenever
possible. [Priority 2]
Rationale:
Consistent page layouts between pages and
a clear navigation structure will not only
benefit people with cognitive
disabilities, but everyone
that visits your site.
To decrease the amount of sifting readers
perform to find important information, place
distinguishing information at the beginning
of headings, paragraphs, lists, etc. This is
commonly referred to as "front-loading"
and is especially helpful for people
accessing information serially.
Techniques:
- Create
a
consistent style of presentation
between pages. [Priority 3]
- Use a
clear,
consistent navigation structure.
[Priority 3]
- Offer
navigation
bars for easy access to the
navigation structure. [Priority 3]
- Provide
a description of the general layout
of the site, the access features used, and
how to use them. [Priority 3]
- Offer a
site
map. [Priority 3]
- Offer
different
types of searches for different
skill levels and preferences. [Priority 3]
- Place
distinguishing
information at the beginning of
headings, paragraphs, lists, etc.
[Priority 3]
Rationale:
This helps people reading
documents off-line. Currently, an
archival or compression program is needed to
create the single file. In the near future,
user agents will be able to collate separate
pages based on meta information.
Techniques:
- Indicate
which is the first page of the document
and which page follows the current one.
(e.g., by using LINK). [Priority 3]
- Create
a bundled version of all pages that
compose the document. [Priority 3]
Rationale:
Testing your site with a variety of
browsers and other services will allow you
to gain first-hand experience of some of the
issues people deal with. Adjustments to your
design based on the results of tests will
increase the likelihood that your site will
be usable by a wide range of people and
technologies.
Techniques:
- Use Bobby, an automated accessibility,
browser and HTML validation tool,
available at
http://www.cast.org/bobby/
[Priority 3]
- Use the W3C HTML Validation Service,
available at
http://validator.w3.org/
[Priority 3]
- Use the W3C CSS Validation Service,
available at
http://jigsaw.w3.org/css-validator/
[Priority 3]
- Test
the site with at least:
- a text-only browser (e.g., Lynx or
a Lynx emulator such as
Lynx
Viewer or
Lynx-me)
[Priority 3]
- multiple graphic browsers,
[Priority 3] with:
- sounds and graphics loaded,
- graphics not loaded,
- sounds not loaded,
- no mouse
- It may also be helpful to test a site
with a
self-voicing browser (such as
PWWebspeak). [Priority 3]
- ASCII art
- ASCII art refers to text characters and
symbols that are combined to create an
image. For example ";-)"
is the smiley emoticon and the following
drawing represents a cow.
(__)
(oo)
/-------\/
/ | ||
* ||----||
^^ ^^
- Instant
redirection
- A page is loaded but immediately
replaced by another due to meta
information in the transient document.
- Backwards
compatible
- Something that has been designed to
work with earlier versions of a language,
program, etc.