This document is a list of techniques that implement the
guidelines described in "Web Content Accessibility Guidelines". This
document includes primarily techniques that HTML authors may use to
implement the guidelines, but also refers to some CSS techniques as
well.

While Web Content Accessibility Guidelines strives to be a stable
document (as a W3C Recommendation), the current document will
undoubtedly evolve as technologies change and content
developers discover
more effective techniques for designing accessible pages.

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.

Please note that previous versions of this document were entitled
"Techniques for WAI Page Author Guidelines".

Each checkpoint in this document (introduced by the word "Checkpoint") is rated according to the
following system:

[Priority 1]

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

[Priority 2]

This checkpoint should be implemented by an
author, or one or more groups of users will find it difficult to
access information in the document. Implementing this checkpoint
will significantly improve access to Web documents.

[Priority 3]

This checkpoint may be implemented by an author
to make it easier for one or more groups of users to access
information in the document. Implementing this checkpoint will
improve access to Web documents.

Some checkpoints may have more than one rating. This occurs when
the importance of the checkpoint varies with the importance of the
information being presented. For instance, if an author considers a
vital chart or graph more important than a small graphic, it may be
more important to implement a given checkpoint for the former but
not the latter.

The checkpoints in this document are numbered to match their
numbering in Web Content Accessibility Guidelines.

When designing a document or series of documents, page authors
should strive to identify the desired structure for their documents
without thinking about how the documents will be presented to the
user. Distinguishing the structure of a document from how the
content is presented offers a number of advantages, including
improved accessibility, manageability, and scalability.

Identifying what is structure and what is presentation may be a
challenging task at times that authors must develop a mindset for
recognizing. For instance, many authors consider that a horizontal
rule (the HR element) communicates a structural division. This may
be true for sighted users, but to unsighted users or users without
graphical browsers, a rule has next to no meaning (One might"guess" that an HR element implies a structural division, but
without other information, there is no guarantee.) Authors should
use the HTML 4.0 header elements (H1-H6) to identify new sections.
These may be complemented by visual or other cues such as
horizontal rules, but should not be replaced by them.

The inverse holds as well: authors should not use structural
elements to achieve presentation effects. For instance, even though
the BLOCKQUOTE element may cause indented text in some browsers,
that is not its meaning, only a presentation side-effect.
BLOCKQUOTE elements used for indentation confuse users and search
robots alike, who expect the element to be used to mark up block
quotations.

The next two sections identify (by theme) precisely those
elements and attributes considered structural (and some of their
uses) and those that are considered to control presentation. The
section on style and style sheets discusses
how to use CSS to accomplish the same tasks as the HTML
presentation elements and attributes.

Elements and attributes that are
deprecated in HTML 4.0 ([HTML40])
appear in red and followed by an asterisk (*) in this document.
Most presentation elements have been deprecated in HTML 4.0.

Text is considered accessible to almost all users since it may
be handled by screen readers, non-visual browsers, braille readers,
etc. It is good practice, as you design a document containing
non-textual information (images, graphics, applets, sounds, etc.)
to think about supplementing that information with textual
equivalents wherever possible.

Alternative text represents the function of the content.
Alternative text should not describe visual appearance or how
something sounds. For example, if an image of a magnifying glass is
used for a search button, the alt-text would be "Search" rather
than "Magnifying glass".

Quicktest! A good test to
determine if alternative text is useful is to imagine reading the
document aloud over the telephone. What would you say upon
encountering this image to make the page comprehensible to the
listener?

Sometimes, a brief inline description of content (of a sound,
an abbreviation, an image) may complement alt-text. In general, a
brief description should describe visual appearance or how
something sounds.

[Checkpoint B.1.1]Title each frame so that users can keep track of frames by title (e.g., via the "title" attribute on HTML FRAME elements). [Priority 1]

[Checkpoint B.1.2]Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone. (e.g., in HTML, use "longdesc," or a d-link). [Priority 2]

HTML allows authors to specify these substitutes in several
ways. Here is a summary of attributes used for alt-text and long
descriptions and the elements they apply to (by version of
HTML):

To implement alt-text, use the "alt" attribute.

In HTML 4.0, applies to: IMG, AREA, INPUT, APPLET. The
attribute is mandatory for the IMG and AREA elements. For other
elements, use the "title" attribute.

In HTML 3.2, applies to: IMG, AREA, APPLET.

In HTML 2.0, applies to: IMG.

To implement brief descriptions, use the "title" attribute

In HTML 4.0, applies to almost every element

In HTML 3.2, applies to: LINK, A

In HTML 2.0, applies to: LINK, A

To implement long descriptions, use the "longdesc"
attribute

In HTML 4.0, applies to: FRAME, IFRAME, IMG

In HTML 3.2, applies to: N/A.

In HTML 2.0, applies to: N/A.

Not every user agent supports these attributes. When required to
design documents for a version of HTML known not to support one of
these attributes, authors should implement alt-text or descriptions
in other ways. Methods include:

Inline alternative text or descriptions. For example, include a
description of the image immediately after the image.

Links to descriptions (called description
links or "d-links"). Description links should be ordinary links
(on the same page or another designed for such links) that
designate a document containing a long description. The link text
(content of the A element) should be "[D]".

Each of the HTML topics below
describes prioritized scenarios for alt-text and descriptions.

Some image formats allow internal text in the data file along
with the image information. If an image format supports such text
(e.g., PNG) authors may also supply brief descriptions
there as well.

Although authors should avoid as much as possible document
content for which there is no accessible alternative or supplement,
it may happen that all or part of a page remains inaccessible.
There are several techniques for creating accessible
alternatives:

Insert links at the top of both the main and alternative pages
to allow a user to move back and forth between them.

Once a majority of users use browsers that support the LINK
element, use it to designate alternative documents. Browsers should
then load alternative pages automatically, based on the user's
browser type.

Instead of static alternative pages, Webmasters may set up
server-side scripts that generate accessible versions of a page on
demand.

This technique may be taken even further, if Webmasters store
information in databases and then generate accessible pages in a
desired format on the fly.

If it is not possible to provide alternative pages, authors
should provide a phone number, fax number, email address, or postal
address where information is available and accessible, preferably
24 hours a day.

Otherwise provide a phone number, fax number, e-mail, or postal
address where information is available and accessible, preferably
24 hours a day

Example.

User agents that support LINK will load the alternative page for
those users whose browsers may be identified as supporting "aural","braille", or "tty" rendering.

Not every user has a graphic environment with a mouse or other
pointing device. Some users rely on keyboard or voice input to
navigate links, activate form controls, etc. Authors should always
ensure that users may interact with a page with devices other than
a pointing device. A page designed for keyboard access (in addition
to mouse access) will generally be accessible to users with other
input devices. What's more, designing a page for keyboard access
will usually improve its overall design as well.

Keyboard access to links and form controls may be specified in
two ways:

Keyboard shortcuts

Keyboard shortcuts allow users to combine keystrokes to
navigate links or form controls on a page.

Tabbing order

Tabbing order describes a (logical) order for navigating from
link to link or form control to form control (usually by pressing
the "tab" key, hence the name).

Here is a summary of attributes used for keyboard access and
tabbing order and the elements they apply to (by version of
HTML):

[Checkpoint B.2.9]Group related links, such as links used to create a navigation bar, and attach a meaningful title on the element creating the group (e.g., in HTML use "title" on FRAME, DIV, SPAN, etc. Use class="nav" on elements creating navigation groups). [Priority 3]

[Checkpoint A.14.5] If a resource is served in various formats or languages, use content negotiation to determine the format or language preferred by the user. Also allow the user to switch from one version to another. [Priority 3]

The following sections list some techniques for using HTML and
CSS to design accessible documents and some techniques for avoiding
HTML accessibility traps. The sections are organized by topic (and
mirror the organization of the HTML 4.0 specification, [HTML40]).

As discussed above, authors should use structural markup
wherever possible (and use it as intended by the authors of W3C
specifications). Structural elements promote consistency in
documents and supply information to other tools (e.g., indexing
tools, search engines, programs that extract tables to databases,
navigation tools that use header elements, and automatic
translation software that translates text from one language into
another.

Some structural elements provide information about the document
itself. This is called "metadata" about the document (Metadata is
information about data). Well-crafted metadata can provide
important orientation information to users. HTML elements that
provide useful information about a document include:

TITLE: The document title. Note that the TITLE element (one
time only in a document) is different from the "title" attribute,
which applies to almost every HTML 4.0 element. This document makes
use of the "title" attribute for many occasions that require brief
descriptions of element content (e.g., "a sailboat" when an image
depicts a sailboat).

ADDRESS: Can be used to provide information about the author of
the page.

LINK: Can be used to indicate alternative documents (different
structure, different language, different target device, etc.).

The META element can be used to describe metadata about a
document. Many page authors use the META element to send users from
one page to another automatically (usually after a time delay).
This can be disorienting to some users.

Sections should be introduced with the HTML header elements
(H1-H6). Other markup may complement these elements to improve
presentation (e.g., the HR element to create a horizontal dividing
line), but visual presentation is not sufficient to identify
document sections.

[Checkpoint A.6.1]Nest headings properly (e.g., in HTML, H1 - H6). [Priority 2]
Since some users skim
through a document by navigating its headings, it is important to
nest headings correctly, i.e., to follow an H1 with an H2, not and
H3, and so on. Headings should not be used for other purposes
(such as formatting text in a larger font size) since this may
disorient users; use style sheets for text
formatting.

[Checkpoint A.7.1]Clearly identify changes in the language of text (e.g., the HTML "lang" attribute, configure your server to take advantage of content negotiation mechanisms to allow browsers to retrieve files of the preferred language automatically). [Priority 2]
If you use a
number of different languages on a page, make sure that any changes
in language are clearly identified by using the "lang"
attribute:

<P>And with a certain <SPAN lang="fr">je ne sais quoi</SPAN>,
she entered both the room, and his life, forever. <Q>My name
is Natasha,</Q> she said. <Q lang="it">Piacere,</Q>
he replied in impeccable Italian, locking the door.

As mentioned above, structural elements add information to a
page that may be used by browsers, search engines, and other
software. Authors are encouraged to use
structural elements and attributes whenever possible. Below we
discuss how to further improve accessibility by careful use of
attributes with these elements.

The proper HTML elements should be used to mark up emphasis: EM
and STRONG. The B and I elements should not be used; they are used
to create a visual presentation effect. The EM and STRONG elements
were designed to indicate structural emphasis that may be rendered
in a variety of ways (font style changes, speech inflection
changes, etc.)

[Checkpoint A.7.2]Specify the expansion of abbreviations and acronyms (e.g., with the "title" attribute of the HTML ABBR or ACRONYM elements). [Priority 2]
Mark up
abbreviations and acronyms with ABBR and ACRONYM and use "title" to
indicate the expansion:

[Checkpoint A.6.3]Mark up quotations (e.g., with the Q and BLOCKQUOTE elements in HTML). Do not use quotation markup for formatting effects such as indentation. [Priority 2]
See the language
example above for an illustration of the Q element.

[Checkpoint A.6.2]Encode list structure and list items properly (e.g., in HTML: UL, OL, DL, LI). [Priority 2]
The HTML list elements DL, UL, and OL (available in
HTML 3.2 and HTML 4.0) should only be used to create lists, not for
formatting effects such as indentation.

When possible, use
ordered (numbered) lists to help navigation. Non-visual users
often "get lost" in lists, especially those with several layers of
embedding and those that do not indicate the specific level of
indentation for each item. In addition, it is often difficult for
non-visual users to know where the list itself begins and ends and
where each list item starts. Finally, if a list entry wraps to the
next line, it may appear to be two separate items in the list.

Example.

Instead of nesting bulleted lists like this:

writing tools

pens

highlighters

red

green

blue

ball-point

green

purple

mauve

pencils

soft lead

#2 lead

erasers

which might be read by a screen reader (stripping bullets and
indentation) as:

Here is a better way to change list bullet styles (using style
sheets). To further ensure that users understand differences
between list items indicated visually, authors should provide a
label before or after the list item phrase:

[Checkpoint A.8.2] For data tables, identify headers for rows and columns (e.g., the HTML TD and TH elements). [Priority 1]
Future browsers and assistive
technologies will be able to automatically translate tables into
linear sequences if data is labeled appropriately.

[Checkpoint A.8.3] For data tables that have more than one row and/or more than one column of header cells, use markup to associate data cells and header cells (e.g., in HTML, THEAD, TFOOT, TBODY, COLGROUP, the "axis", "scope", and "headers" attributes, etc.). [Priority 1]
Identify structural
groups of rows (THEAD for repeated table headers, TFOOT for
repeated table footers, and TBODY for other groups of rows) and
groups of columns (COLGROUP and COL). Label table elements with the"scope", "headers", and "axis" attributes so that future browsers
and assistive technologies will be able to select data from a table
by filtering on categories. This markup will also help browsers
translate tables into linear sequences automatically (also called
table "serialization"). A linear sequence is usually generated by
reading a row left to right and proceeding each cell with the label
of its column.

[Checkpoint A.8.5]Provide abbreviations for header labels (e.g., in HTML, the "abbr" attribute on TH). [Priority 3]
Provide
terse substitutes for header labels with the "abbr" attribute on
TH. These will be particularly useful for future speaking
technologies that can read row and column labels for each cell.
Abbreviations cut down on repetition and reading time.

[Checkpoint A.8.1] If a table is used for layout, do not use any structural markup for the purpose of visual formatting. For example, in HTML do not use the table header (TH) element to cause the contents of a cell to be displayed centered and in bold. Other attributes of a table, such as a caption describing the layout purpose and content of columns is valuable, particularly if some cells become navbars, frames, images, imagemaps, or lists of links. [Priority 1]

Most of the above elements and attributes are only available in
HTML 4.0.

This markup will allow accessible browsers and other user agents
to restructure tables for non-visual media.

The following example shows how to associate data cells with
their corresponding headers by means of the "headers" attribute.
The "headers" attribute specifies a list of header cells (row and
column labels) associated with the current data cell. This requires
each header cell to have an "id" attribute.

Caption: Cups of coffee consumed by each senator
Summary: This table charts the number of cups of coffee
consumed by each senator, the type of coffee
(decaf or regular), and whether taken with sugar.
Name: T. Sexton, Cups: 10, Type: Espresso, Sugar: No
Name: J. Dinnen, Cups: 5, Type: Decaf, Sugar: Yes

A visual user agent might render this table as follows:

The next example associates the same header and data cells as
before, but this time uses the "scope" attribute rather than"headers." "Scope" must have one of the following values: row, col,
rowgroup or colgroup. Scope specifies the set of data cells to be
associated with the current header cell. This method is
particularly useful for simple tables. It should be noted that the
spoken rendering of this table would be identical to that of the
previous example. A choice between the "headers" and "scope"
attributes is dependent on the complexity of the table. It does not
affect the output so long as the relationships between header and
data cells are made clear in the markup.

One source of problems for screen readers that do not interpret
the source HTML is wrapped text in table cells. They read across
the page, reading sentences on the same row from different columns
as one sentence.

For example, if a table is rendered like this on the screen:

There is a 30% chance of Classes at the University of Wisconsin
rain showers this morning, but they will resume on September 3rd.
should stop before the weekend.

This might be read by a screen reader as:

There is a 30% chance of Classes at the University of Wisconsin
rain showers this morning, but they will resume on September 3rd.
should stop before the weekend.

Screen readers that read the source HTML will recognize the
structure of each cell, but for older screen readers, authors
should minimize the risk of word wrapping by limiting the amount of
text in each cell. Also, the longest chunks of text should all be
in the last column (rightmost for left-to-right tables). This way,
if they wrap, they will still be read coherently.

Authors should test tables for wrapping with a browser window
dimension of "640x480".

Quicktest! To get a better
understanding of how a screen reader would read a table, run a
piece of paper down the page and read your table line by line.

Users who are blind often jump from link to link when skimming a
page or looking for information. When they do this, only the text
of the link (the "link text") is read.

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

[Checkpoint B.2.1] Wherever possible, make link phrases as terse as possible yet as meaningful as possible when read on their own or in succession . Avoid non-meaningful phrases, such as "click here." [Priority 2]
Therefore,
it is important that link text make sense when read without
surrounding text. For example, authors should not use "click
here" as link text several times on the same page; this requires a
user browsing the page with a screen reader to step through each
link and read the surrounding text to determine the purpose of the
link. Instead, link text should carry sufficient information, as in"download this document in ASCII text," "view the full version in
HTML," or "for the text version select this link."

When an image is used as the content of a link, specify alt-text for the image that makes sense in
context.

Quicktest! To choose alt-text in
this case, think of what you would say in words rather than an
image in this context.

"Navigation bars" (sets of links that appear on every page in a
site) are usually the first thing someone encounters on a page. For speech
users, this means taking the time to read through x number of links on every
page before reaching the unique content of a page. Therefore, grouping links
will allow a user with a user agent that can navigate by elements, to jump
over the group. This is similar to how people with vision skip reading
the links when they see the same set on each page. Since this type of
mechanism is not available today, providing a link that skips over the
links, or using a tabindex at a link just before the content begins
are strategies that work today.

[Checkpoint A.14.4]Indicate what type of resource you are linking to , especially when linking to resources that are not W3C technologies, For example, to link to a PDF file from an HTML document, set the "type" attribute to "application/pdf" on the A element. [Priority 3]

[Checkpoint A.2.1] Provide a long description of all graphics, scripts, or applets that convey important information (e.g., in HTML, via "longdesc" on IMG, with a d-link (or an invisible d-link), or as content of OBJECT). [Priority 1]
When using IMG,
specify a long description of the image
with the "longdesc" attribute:

[Checkpoint A.1.6] For ASCII art , either replace it with an image and alternative text or provide a description and a means to skip over the art (e.g., a link). [Priority 1] or [Priority 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 alternative text. (See also A.2)

Avoid ascii
art (character illustrations) and use real images instead since
it is easier to supply alt-text and long descriptions for images. The priority of
this checkpoint depends on the importance of the information (e.g.,
an important chart).

However, if ascii art must be used provide a link to jump over the ASCII
art, as follows.

If the description of (important) ASCII art is long, provide a
description in addition to alt-text.

Another way to replace ascii art is to use human language
substitutes. For example, <wink> might substitute for the
emoticon <SPAN title="wink smiley">;-)</SPAN>, the word"therefore" could replace arrows consisting of dashes and greater
than signs (e.g., -->), and the word "great" for the uncommon
abbreviation "gr8".

An image map is an image that has "active regions". When the
user selects one of the regions, some action takes place -- a link
may be followed, information sent to a server, etc. To make an
image map accessible, authors must ensure that each action
associated with a visual region may be activated without a pointing
device.

Authors should either avoid server-side image maps (because they
require a specific input device - a mouse) or provide the same
functionality or information in an alternative accessible format.
One way to achieve this is to provide a textual link for each
active region so that each link is navigable with the keyboard. If you must use a server-side image map,
please consult the section on server-side
image maps

[Checkpoint A.1.3] For all image map links, provide text for each link (e.g., via the "alt" attribute of HTML AREA element or by using the MAP element with anchors defined with the A element). [Priority 1]
If AREA is used, use the"alt"
attribute:

[Checkpoint A.1.4] For all image map links, provide redundant textual links.[Priority 2] if client-side image maps are used, [Priority 1] for server-side.
In addition to
providing alt-text, provide redundant textual links. If the A
element is used instead of AREA, the author may describe the active
regions and provide redundant links at the same time:

Note that in the previous example the MAP element is the content
of the OBJECT element so that the alternative links will only be
displayed if the image map (navbar1.gif) is not.

Note also that links have been separated by brackets ([]). This
is to prevent screen readers from reading several adjacent links as
a single link.

[Checkpoint A.13.3]Include non-link, printable characters (surrounded by spaces) between links that occur consecutively. [Priority 3]
Authors should make
sure they include printable characters (such as brackets or a
vertical bar (|)) surrounded by spaces between adjacent
links.

When a server-side image map must be used, authors should
provide an alternative list of image map choices. There are three
techniques:

If an alternative list of links follows the image map, authors
should indicate the existence and location of the alternative list.
If IMG is used to insert the image, provide this information in the"alt" attribute. If OBJECT is used, provide it in the "title"
attribute.

[Checkpoint A.2.1] Provide a long description of all graphics, scripts, or applets that convey important information (e.g., in HTML, via "longdesc" on IMG, with a d-link (or an invisible d-link), or as content of OBJECT). [Priority 1]

[Checkpoint A.9.5] For applets and programmatic objects, when 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.1.2) If APPLET is used,
provide alt-text with the "alt" attribute
and content in the APPLET element. This enables them to transform
gracefully for those user agents that only support one of the two
mechanisms ("alt" or content).

[Checkpoint A.11.1] Where possible, make programmatic elements, such as scripts and applets, directly accessible. (See also A.9). [Priority 1] if information or functionality is important, and not presented elsewhere, otherwise [Priority 2].
If an applet requires user interaction
(e.g., the ability to manipulate a physics experiment) that cannot be
duplicated in an alternative format, make the applet directly
accessible.

Audio and video should be accompanied by text
transcripts, textual descriptions or equivalents of auditory
or visual events. When these transcripts are presented
synchronously with a video presentation they are called "captions"
and are used by people who cannot hear the audio track of the video
material. Full audio transcripts include spoken dialogue as well as
any other significant sounds including on-screen and off-screen
sounds, music, laughter, applause, etc. The following two examples
show captions, a text transcript, and auditory descriptions.

Example.

Captions for a scene from "E.T." The phone rings three times,
then is answered.

Some media formats, such as QuickTime 3.0, allow captions and
video descriptions to be added to the multimedia clip.

Until the format you are using supports alternative tracks, two
versions of the movie could be made available, one with captions
and descriptive video, and one without. Future technologies, on the
other hand, will allow separate audio/visual files to be combined
with text files via a synchronization file to create captioned
audio and movies. It will also allow the user to choose from
multiple sets of captions to match their reading skills. For more
information see the SMIL 1.0 ([SMIL])
specification.

This can be provided in the form of a text phrase on the page
that links to a text transcript or description of the sound file.
The link to the transcript should appear in a highly visible
location such as at the top of the page. However, if a script is
automatically loading a sound, it should also be able to
automatically load a visual indication that the sound is currently
being played and provide a description or transcript of the
sound.

Note. Some controversy surrounds this technique
because the browser should load the visual form of the information
instead of the auditory form if the user preferences are set to do
so. However, strategies must also work with today's browsers.

Video descriptions are used primarily by people who are blind to
follow the action and other non-auditory information in video
material. The description provides narration of the key visual
elements without interfering with the audio or dialogue of a movie.
Key visual elements include actions, settings, body language,
graphics, and displayed text.

[Checkpoint A.4.2] For movies, provide auditory descriptions that are synchronized with the original audio. [Priority 1]
For movies,
provide auditory descriptions that are synchronized with the original
audio. See the section on audio
information for more information about multimedia formats.

[Checkpoint A.4.3]Provide text version of the auditory description that is collated with the text transcript (captions) of the primary audio track. [Priority 2]
This text transcript, in conjunction
with the full audio transcript described above, allows access by
people with both visual and hearing disabilities. This also provides
everyone with the ability to index and search for information
contained in audio/visual materials.

[Checkpoint A.4.1] For short animations such as animated "gifs" images, provide alternative text(See also A.1) and a long description (See also A.2) if needed. [Priority 1]
Depending on the context, either a brief description or a long description should
be provided for visual information that is necessary to understanding
the page. For example for an ad that displays text like a marquee, the
text should be provided in the alternative text, unless there is a lot
of text. For a looping image of cloud cover over the United States, if
the image is in the context of a weather status report, where the
information is presented in text, a less verbose description of the
image is necessary. However, if the image appears on in a pedagogical
setting, elaborating on cloud formations in relation to land mass,
ought to be described.

[Checkpoint A.6.4]Use style sheets to control layout and presentation wherever possible as soon as a majority of browsers in use support them well (See also A.9). Until then, simple 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 (See also A.14). [Priority 2]
CSS1 ([[CSS1]) and CSS2 ([[CSS2]) allow authors to duplicate almost
every HTML 4.0 presentation feature and offer more power with less
cost. However, until most users have browsers that support style
sheets, not every presentation idiom may be expressed
satisfactorily with style sheets. In the following sections, we
show how style sheets may be used to create accessible pages. We
also provide examples of how to use HTML 4.0 features (e.g.,
tables, bitmap text) more accessibly when they must be used.

Authors should use style sheets for text formatting rather than
converting text to images. For example, stylized text on a colored
background can be created with style sheets instead of as an image.
This provides flexibility for people to view the text in a form
that is most readable to them including magnified, in a particular
color combination such as white on black, or in a particular
font.

However, if you must use a bitmap to create a text effect
(special font, transformation, shadows, etc.) it must be
accessible.

[Checkpoint A.10.2]Avoid any blinking or updating of the screen that causes flicker. [Priority 1]
Blinking
may cause seizures in some users and is annoying to many other
users. They should also provide a mechanism for freezing motion. If
style sheets are used to create an effect (e.g., 'text-decoration:
blink'), users may cancel the effect through style sheets as well.

Note. Do not use the BLINK and MARQUEE
elements. These elements are not part of any W3C specification for
HTML (i.e., they are non-standard elements).

Indentation: Use the CSS 'text-indent' property to indent text.
Do not use the BLOCKQUOTE or any other structural element to indent
text.

Spacing: Authors should achieve spacing effects with the CSS
'word-spacing' and 'white-space' properties rather than by putting
actual spaces between letters and using the PRE element.

Instead of using deprecated presentation
elements and attributes, use the many CSS properties to control
font characteristics: 'font-family', 'font-size',
'font-size-adjust', 'font-stretch', 'font-style', 'font-variant',
and 'font-weight'.

[Checkpoint A.5.1]Don't use color to convey information unless the information is also clear from the markup and/or text. [Priority 1]
For example, in this document, examples appear
in a different color than the rest of the text. However, that is
not enough to identify them as examples, so we precede each one
with the word "Example." or "Deprecated example."

Quicktest! To text whether your
page passes the text, examine it with a monochrome monitor or
colors turned off.

Quicktest! To test whether color
contrast is sufficient to be read by people with color deficiencies
or by those with low resolution monitors, print pages on a black
and white printer (with backgrounds and colors appearing in
grayscale).

For more information about colors and contrasts, please consult
The Lighthouse
and

Layout, positioning, and alignment should be done through style
sheets (notably by using CSS floats and absolute positioning).

When laying out tabular information, authors should use tables
that are designed for accessibility (see the section on tables. Do not use PRE to create a tabular layout of
text.

[Checkpoint A.13.5] 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 2]
However, 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). See also the section on tables for additional information on table
accessibility.

If authors cannot use style sheets and must use invisible or
transparent images to lay out images on the page, they must supply"null" (alt=) or "white space" (alt=" ") alt-text, whichever
the context requires.

Deprecated example.

In this example, an image is used to create a carefully defined
space between words or graphics. "White space" alt-text is used to
prevent the words from running together when the image is not
loaded:

When using graphics (e.g., horizontal rules) as section
separators, authors should provide a brief
description of what the graphic represents to the visually
enabled user via the "title" attribute. Hence, in the previous
example, we specified title="navigation-bar".

Example.

In this example, a red line is used to separate Chapter 7 from
Chapter 8:

For visually enabled users, frames may organize a page into
different zones. For non-visual users, relationships between the
content in frames (e.g., one frame has a table of contents, another
the contents themselves). must be conveyed through other means.

frameset-desc.html might say something like:
#Navbar - this frame provides links to the major sections of the site: World News, National News, Local News, Technological News,
and Entertainment News.
#Story - this frame displays the currently selected story.
#Index - this frame provides links to the day's headline stories within this section.

End example.

Note that if the a frame's contents change, the long
descriptions will no longer apply. Also, links to a frame's
longdesc ("d-links") ought to be provided with other alternative contents
in the NOFRAMES element of a FRAMESET.

[Checkpoint A.9.1]Provide a fallback page for pages with dynamic content (HTML examples: NOFRAMES at the end of each frameset, NOSCRIPT for every script, server-side scripts instead of client-side). [Priority 2]

Authors must provide descriptions of frames so that their
contents and the relationships between frames make sense. Note that
as the contents of a frame change, so must change any description.
This is not possible if an IMG is inserted directly into a frame,
as in this deprecated example:

[Checkpoint A.13.1]Do not use pop-up windows, new windows, or change active window unless the user is aware that this is happening. [Priority 2]
For example, authors
should avoid specifying a new window as the target of a frame with
target="_blank".

[Checkpoint A.12.3]Create a logical tab order through links, form controls, and objects (e.g., in HTML, via the "tabindex" attribute or through logical page design). [Priority 3]

[Checkpoint A.12.4]Provide keyboard shortcuts to links, including those in client-side image maps, form controls, and groups of form controls (e.g., in HTML, via the "accesskey" attribute). [Priority 3]
See the section on keyboard access for more information.

[Checkpoint A.13.4] For all form controls with implicitly associated labels, ensure that the label is properly positioned. The label must immediately precede its control on the same line (allowing more than one control/label per line) or be on the line before the control (with only one label and one control per line). [Priority 2]

[Checkpoint B.1.5]Divide long lists of choices into groups (e.g., with the HTML OPTGROUP element). [Priority 2]
For long
lists of selections (which are hard to remember), authors should
group items into a hierarchy using the OPTGROUP element (available
in HTML 4.0).

[Checkpoint A.9.3] For scripts that present critical information or functions, provide an alternative, equivalent presentation or mechanism (e.g., by using NOSCRIPT in HTML, or a server-side script). [Priority 1]
One way to accomplish this is with the
NOSCRIPT element (available in HTML 4.0). The content of this
element is rendered with scripts are not enabled.

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. This document is
available at
http://www.tracecenter.org/docs/html_guidelines/version8.htm
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 index lists all elements in HTML 4.0 and whether they are
defined in earlier versions of HTML. Elements and attributes that
are
deprecated in HTML 4.0 ([HTML40]) are
followed by an asterisk (*). Elements that are obsolete in HTML 4.0
or don't exist in any version of HTML (2.0, 3.2, 4.0) do not appear
in this table. An entry of "N/A" means that an element is not
discussed in this document.

Attributes that are
deprecated in HTML 4.0 ([HTML40]) are
marked up in this document and followed by an asterisk (*).
Attributes that are obsolete in HTML 4.0 or don't exist in any
version of HTML (2.0, 3.2) do not appear in this table. An entry of "N/A" means this attribute is not discussed in this document.