This document is a list of guidelines that Web content developers should follow in
order to make their pages more accessible to people with disabilities.
Following these guidelines will also make pages more useful to people
using a broad range of devices (desktop browsers, voice browsers,
mobile phones, automobile-based PC's, etc.) and to search engines.
Tools that create Web content (HTML
editors, document conversion tools, tools
that generate Web content from databases) should generate content that
is consistent with these guidelines.

The guidelines in this document explain to authors, including those
providing multimedia content, how to ensure that the content and
functions they provide are available to all users. These guidelines do
not discourage authors from using images, video, etc. Rather, they
encourage authors to make them accessible to the widest possible
audience.

This is a W3C Working Draft for review by W3C members and other
interested parties. With the publication of this draft, the Web
Content Accessibility Guidelines enters "last call." The last call period
will end on March 19, 1999. Please note that only the current document
(not the accompanying Techniques
Document.) is entering last call. Comments about that document are
still encouraged.

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". 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.

For those unfamiliar with accessibility issues pertaining to
Web page design, consider that many users may be using
documents in contexts very different from your own:

They may not be able to see, hear, move, or understand
easily or at all.

They may be in a situation where their eyes, ears, or
hands are busy or interfered with (e.g., driving to work,
working in a loud environment, etc.)

They may have difficulty reading or comprehending text.

They may not have or be able to use a keyboard or mouse.

They may have an early version of a browser, a different
browser entirely, a voice browser, or a
different operating system.

They may have a slow connection, a small screen,
a text-only screen, etc.

They may not speak or understand fluently
the language in which the document is written.

Authoring accessible Web pages means being aware of all these
different environments, and accounting for them in design choices.
Fortunately, accessible design does not generally mean extra work
(or page duplication) and it usually benefits the Web community at
large. Following the guidelines will generally shorten page
download times and make sites easier to manage (e.g., by sharing
style sheets).

Consider what happens when an image is inserted into an HTML
document with the IMG element. Some users may not be able to see
images, others may have support for images turned off (e.g., due to a
slow Internet connection) or their browsers may not support images at
all. Accessible authoring does not mean avoiding images or video.
Multimedia should be used where appropriate (which we explain later
on) but also accompanied by accessible alternatives to the visual
information. In the case of the IMG, this means providing a short
description of the image's function via the "alt" attribute. There
are additional ways to make images accessible described in this
document and the accompanying Techniques Document. Making images
more accessible will benefit a number of "content consumers":

Users with blindness will understand the function of the image.
This is particularly helpful when the image is
part of a hyperlink since the link has no other text
to suggest the nature of its target.

User agents can render "alt" text as a tool tip, thus
providing additional information to the general populace.

Search engines will find more information about a page or site.

These guidelines describe how to use the features of HTML, SMIL,
CSS, and other languages that promote accessibility. Reading these
guidelines will help authors understand:

What accessibility issues to be aware of.

Why certain pages are inaccessible.

How to improve the design of a page or site without
heavy additional cost.

Once you've reviewed the guidelines, we encourage you to seek out
and correct any accessibility barriers on your Web sites by borrowing
solutions from the very detailed Techniques Document.

A guideline is a general principle of accessible design.
A guideline addresses the question "What should I keep
in mind while authoring?"

Checkpoint

A checkpoint is a specific way of satisfying one or
more guidelines. While checkpoints describe verifiable
actions that may be carried out by the author, implementation
details are described elsewhere. A checkpoint answers
the question "What steps can I take to improve accessibility?"

Technique

A technique is an implementation of one or more checkpoints in a
given language (e.g., HTML, CSS, MathML, etc.). A technique
answers the question "How do I do that in HTML or CSS or MathML?"

This document lists guidelines and the checkpoints that satisfy
them. It is accompanied by a
List of Checkpoints so that authors can evaluate their documents
and Web sites.

The Techniques Document
provides in-depth descriptions of the same checkpoints and examples of
how to implement the checkpoints using HTML, CSS, and more.
Please note that the Techniques Document will be updated more
regularly than the current document in order to keep up
with changes in technology.

Note. The current document and the Techniques Document refer to some
technologies (e.g., features of HTML,
CSS, or
SMIL) that may not be
supported yet in some browsers, multimedia tools, etc. Browser support
for language features is discussed in the Techniques Document.

Some checkpoints are more important to accessibility than others and
so each one has been assigned a priority level. Some checkpoints
specify a priority level that may change under some (indicated)
conditions.

This checkpoint must be satisfied by an author,
or one or more groups of users will find it impossible to access
information in the document. Satisfying this checkpoint is a basic
requirement for some groups to be able to use Web documents.

This checkpoint should be satisfied by an
author, or one or more groups of users will find it difficult to
access information in the document. Satisfying this checkpoint
will remove significant barriers to accessing Web documents.

By following these guidelines, authors can create pages that transform gracefully.
Pages that transform gracefully remain accessible despite any of the
constraints described in the introduction,
including physical, sensory, and cognitive disabilities, work
constraints, and technological barriers. Here are some keys to
designing pages that transform gracefully:

Separate content (what is said) from
structure (how it is organized) from
presentation (how it appears on the screen,
when spoken, when rendered by a braille device, etc.).

Use text or provide a text equivalent.
Textual information is generally available to all
users and browsing devices.

Don't create documents that only work if the user
can see and/or hear. For content that is
sensory-specific (e.g., audio, video,
applets that present visual information),
provide equivalent information in forms suited to other
senses as well. This does not mean creating an
entire auditory version of
a site. Screen readers will be able to speak all
information on a page as long as it is available in text.

Don't create documents that rely on one type of hardware.
Pages should be usable by people
without mice, with small screens, low resolution screens,
black and white screens, no screens, with only voice or text
output, etc.

Authors should also consider in
their design how users will navigate and understand each page and
the relation between pages. Providing navigation tools and
orientation information in pages will maximize usability. Remember,
not all users can make use of visual clues such as image maps,
proportional scroll bars, side-by-side frames, or icons that guide
sighted users of graphical desktop browsers. Users also lose
contextual information when they can only view a portion of a page,
either because they are accessing the page one word at a time (speech
synthesis or braille display), or one
section at a time (small display, or a magnified display). Very large
tables, lists, menus, etc. without orientation information may be very
disorienting to users.

Guidelines 14 to 16
discuss ways to add context and orientation to documents, for
example by grouping form controls, providing navigation bars, offering
a site map, and numbering lists and sections.

A text
equivalent describes the purpose or function of an image, applet,
image map, or other visual information. For example, the text
equivalent for a company logo image in a link might be "Return to home
page".

If text equivalents are not provided for visual information, people
who are blind, have low vision, or
any user who cannot or has chosen not to view
graphics will not know the purpose of the visual components
on the page.

1.6Replace ASCII art with an image or describe the ASCII art and offer a means (e.g., a link) to skip over it. [Priority 1 or Priority 2 depending on the importance of the information (e.g., an important chart).]

Note. When replacing
ASCII art with an image, specify
a text equivalent for
the image

Note. If the description of
(important) ASCII art is long, provide a description in addition to
a text equivalent. See also guideline 2.

Provide descriptions of important
information in graphics, scripts, applets, videos, or animations if it is not
fully described through
text equivalents or in the document's content.

A long
description, unlike a
text equivalent, describes the visual information presented by an image,
script, or applet. Long descriptions make information presented
graphically (charts, billboards, diagrams) perceivable to people with
blindness, some people with low
vision, and to people who have chosen not to view
graphics, scripts, or applets or whose browser does
not support scripts or applets.

In movies or visual presentations, some visual action, body
language, or other visual cues may not be accompanied by enough audio
information to understanding what's going on without the video. Unless
verbal descriptions of this visual information are provided,
people who cannot see (or look at) the visual content
will not be able to perceive it.

If a visual presentation has an associated auditory presentation
(e.g., a movie), the audio version of the descriptions should be
synchronized with the existing auditory presentation,
and a text
version of the descriptions should be collated with the text transcripts
(captions) of the primary audio track. The collated
information will make the presentation available to people
who are deaf-blind and to people who cannot play or
choose not to play movies, animations, etc..

When a transcript is synchronized with a video presentation it is
called a "caption". Captions are used by people who cannot hear the
audio track of the video material. Without transcripts and captions,
people who are deaf, or hard of
hearing, or any user who cannot or has chosen not to
hear sound cannot perceive the information presented through
speech, sound effects, music, etc.

If color alone is used to convey information, people 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
deficits.

Using markup improperly -- not according to specification --
hinders accessibility. Misusing markup for a presentation effect
(e.g., using a table for layout or a header to change the font size)
makes it difficult for users with specialized
software to understand the structure of the page or to
navigate through it. Furthermore, presentation effects used alone to
convey structure (e.g., constructing what looks like a table of data
with an HTML PRE element) make it difficult to render a page
intelligibly to other devices. For more information, see
the Techniques Document discussion
of structure versus
presentation.

Changes between multiple languages on the same page and
abbreviations can both be indecipherable when spoken
or brailled unless they are identified. Authors
should identify the predominant (natural) language of a document's text
and indicate when language changes occur. They should also provide
expansions of abbreviations and acronyms. This supplemental
information also helps search engines find key words and identify
documents in a desired language. The information also improves
readability for the general populace, including those with reading and
language disabilities.

For example, in HTML
use the "lang" attribute. Server operators should
configure their server to
take advantage of HTTP content negotiation mechanisms so
that clients can automatically retrieve
documents of the preferred language.

Tables should be used to structure truly tabular data
("data tables"). They should
not be used to lay out pages ("layout tables").
Tables for any use also present special
problems to users of screen
readers.

Many user agents restructure tables to present them and if not
marked up properly, the tables will not make sense when
rendered. See also guideline 5.

The following checkpoints will directly benefit people who
access a table through auditory means (e.g., through
an Automobile PC that operates by speech input and output) or who
view only a portion of the page at a time (e.g.,
users with blindness or low vision using speech or a braille display, or other users of devices
with small displays, etc.).

For example, in HTML do not use the TH element to
cause the contents of a (non-table header)
cell to be displayed centered and in bold.
Authors should use attributes or table captions to explain
that the table is a layout table.

For example, in HTML, use THEAD, TFOOT, and TBODY to group
rows, COL and COLGROUP to group columns, and
the "axis", "scope", and "headers" attributes, to describe
more complex relationships among data.

Although authors should be encouraged to use new technologies that
solve problems raised by existing technologies, they should know how
to make their pages still work with older browsers
and people who choose to turn off features.

This makes it more likely that the document will be
understood even when styles are turned off or overridden by the user.
For applets and programmatic objects,
at a minimum, follow the techniques for
text equivalents and
long descriptions, where
needed.

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 flashes per second (Hertz) range
with a peak sensitivity at 20 flashes per second as well as quick
changes from dark to light (like strobe lights).

9.4 Avoid movement in pages, but if it must be used, provide a mechanism to allow users to freeze motion or updates in applets and scripts or use style sheets and scripting to create movement. [Priority 2]

When an embedded object has its "own interface", the interface --
like the interface to the browser itself -- must be accessible. If the
interface of the embedded object cannot be made accessible, an
alternative accessible solution must be provided.

10.1 Where possible, make programmatic elements, such as scripts and applets, directly accessible or compatible with assistive technologies [Priority 1 if information or functionality is important and not presented elsewhere, otherwise Priority 2.]

Not everyone uses a mouse. Interaction with a document should not
depend on a particular input device. If, for example, a form control
can only be activated with a mouse or other pointing device, someone
who is using the page without sight, with voice input, or with
a keyboard or who is using an input device other than a mouse
(e.g., a braille display) will not be
able to use the form.

Note. Providing text equivalents for image maps or
images used as links makes it possible for users to interact with them
without a pointing device. See also guideline 1.

Generally, pages that allow keyboard interaction are
also accessible through speech input or a command line interface.

For example, older browsers do not allow users to
navigate to empty edit boxes. Older screen readers read lists of
consecutive links as one link. These activate elements are therefore
difficult or impossible to access. Also, changing the current window
or popping up new windows can be very disorienting to users
who have available, but aren't using, the graphical features of the
desktop environment.

Note. The following checkpoints apply until most
users are able to secure newer technologies that address these
issues.

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 which often create pages that cannot be
viewed or navigated using standard Web access or screen reading tools.
Also, W3C technologies may be used in ways that do not transform
gracefully (e.g., the visual components are too complex, assistive
technologies or browsers lack a specific feature, etc.). Avoiding
non-standard features (elements, attributes, properties, etc. only
supported by a specific browser type) and ensuring that all
technologies transform gracefully will make pages more accessible to
more people using a wider variety of hardware and software.

Note. Converting documents (from PDF, PostScript,
RTF, etc.) to W3C markup languages (HTML,
XML) does not always create
an accessible document. Therefore, test each page for
readability after the translation process. If a page does not readily
translate, either revise the page until its original
representation converts appropriately or provide an HTML or plain text
equivalent.

For example, to link to a PDF file
from an HTML document, set the "type" attribute to
"application/pdf" on the A element.

13.4For servers. If a resource is served in various formats or languages, use content negotiation to determine the format or language preferred by the user. [Priority 3]

Also allow the user to
switch from one version of a document to another.

13.5 If, after best efforts, you can not avoid using a non-W3C technology or any W3C technology in an accessible way, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information, and is updated as often as the inaccessible (original) page. [Priority 1]

Note. Alternative
pages should be used sparingly since authors tend to neglect updating
the alternative page as often as the original page. An out-of-date
page may be as frustrating as one that is inaccessible since, in both
cases, the information presented on the original page is not
available. Automatically generating alternative pages may lead to
more frequent updates, but authors must still be careful to ensure
that generated pages always make sense and that users are able to
navigate a site by following links on primary pages, alternative
pages, or both. Before resorting to an alternative page,
reconsider the design of the original page; simplifying it
is likely to make it more effective for all users.

Grouping and providing contextual information about the
relationships between elements can be useful for all
users. Complex relationships between elements on a page may
be difficult for people with cognitive disabilities
and people with visual disabilities to interpret.

Navigation structures benefit people with cognitive
disabilities. Furthermore, everyone who visits
the site will appreciate them.

To make it easier for people 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 with serial
presentation techniques such as speech.

For example, in HTML use the LINK element. Or
create an archive of the different pages
(e.g., with zip, gzip, stuffit, etc.).

15.10Group related links, identify the group (for user agents), and provide a mechanism to bypass the group (until user agents provide this mechanism). [Priority 3]

For example, when creating a navigation bar composed
of links in HTML use "title" on FRAME, DIV, SPAN, etc. Use class="nav"
to identify the group. Use "tabindex=1" on an anchor after
the group so users may quickly navigate to it.

Consistent page layout, recognizable icons, and easy to understand
language benefit all who visit a site. In particular, they help
people with cognitive disabilities or who
have difficulty reading. However, ensure that images
have text equivalents for people who are blind, have
low vision, or for any user who cannot or has
chosen not to view graphics. See also guideline 1.

Using direct, simple language is an integral part of effective
communication. Conditions ranging from dyslexia to deafness can make
access to written information difficult to impossible for some
users. This consideration also applies to the many people
whose first language differs from your own.

Validate pages and assess the accessibility with
automated tools, manual tests, and other services.

It is important to test a site with various types of
browsers, older versions of browsers, and services that
emulate browsers. Testing a site with a variety of browsers and
other services will provide firsthand experience of some
of the issues people deal with. Design adjustments based on
the results of tests will increase the likelihood that a site
will be usable by a wide range of people and technologies.

Braille uses six raised dots in different patterns to represent
letters and numbers to be read by people who are blind with their
fingertips. The word "Accessible" in braille follows:

A Braille display, commonly referred
to as a "dynamic braille display," raises or lowers dot patterns on
command from an electronic device, usually a computer. The result is a
line of braille that can change from moment to moment. Dynamic braille
displays range in size from one cell (six or eight dots) to an eighty
cell line. Displays with twelve to twenty cells per line are the most
common.

When referring to
transcripts, collating means combining
the text version of the descriptions and the text
transcript (captions) of the primary audio track into
a single document to read like a script of the movie. In other
words, the two documents are not combined but flow as a single
document.

The interaction of HTML, style
sheets, the Document Object Model [DOM1] and
scripting is commonly referred to as "Dynamic HTML" or DHTML.
However, there is no W3C specification that formally defines DHTML. Most guidelines may be applicable
to DHTML-type of applications, however the following guidelines focus
on issues related to scripting, and style sheets:
1, 2, 8, and
9.

An image that has been divided into regions with associated
actions. Clicking on an active region causes an action to occur.

When a user clicks on an active region of a client-side image map,
the user agent calculates in which region the click occurred and
follows the link associated with that region. Clicking on an active
region of a server-side image map causes the coordinates of the click
to be sent to a server, which then performs some action.

Authors can make client-side image maps accessible by providing
device-independent access to the same links associated with the image
map's regions. Client-side image maps allow the user agent to provide
immediate feedback as to whether or not the user's pointer is over an
active region.

A PDA is a class
of small, portable computing devices. usually used for tracking
personal data such as calendars, contacts, and electronic
mail. It is generally a handheld
device with a small screen that allows input from various
sources.

A software program that reads the contents of the screen aloud
to a user. Used primarily by individuals who are blind, screen
readers can usually only read text that is printed, not painted, to
the screen.

The original draft of this document is based on "The Unified Web
Site Accessibility Guidelines" ([UWSAG])
compiled by the Trace R & D Center at the University of Wisconsin.
That document includes a list of additional contributors.

"The Unified Web Site Accessibility Guidelines", G.
Vanderheiden, W. Chisholm, eds.
The Unified Web Site Guidelines were compiled by the
Trace R
& D Center at the University of Wisconsin under funding from the
National Institute on Disability and Rehabilitation Research
(NIDRR), U.S. Dept. of Education. This document is
available at:
http://www.tracecenter.org/docs/html_guidelines/version8.htm