PoliciesStandards Best
Practices Development
F.A.Q. Glossary Accessibility
Resources
Accessibility
Architecture - Web Page Best Practices for Development
This document was developed from the W3C's
(World Wide Web Consortium) WAI (Web Access Initiative),
using their Checkpoints as its basis. Examples and
definitions were taken from other documents on their
site. This document specifies the requirements as
determined by the Web Accessibility Work Group necessary
to make web pages accessible. The work group was
comprised of web designers, technical users and non-technical
users, from both the sighted and non-sighted community.
This group believes following the standards listed
below will insure the accessibility of your web pages
to the general public, whether or not they are visually
challenged or hearing impaired.
Best Practices
The items listed below are considered best practices.
You are not required by this document to conform
to these standards; however your pages will be considerably
more accessible if you do.
Best Practice 1 (based on
Check point 1.4)
For any time-based multimedia presentation (e.g.,
a movie or animation), synchronize equivalent alternatives
(e.g., captions or auditory descriptions of the visual
track) with the presentation.
Best Practice 2 (based on
Check point 3.3)
Use style sheets to control layout and presentation.
Best Practice 3 (based on
Check point 3.5)
Use header elements to convey document structure
and use them according to specification.
Long documents are often divided into a variety
of chapters, chapters have subtopics and subtopics
are divided into various sections, sections into
paragraphs, etc. These semantic chunks of information
make up the structure of the document.Sections
should be introduced with the HTML heading 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.
Since some users skim through a document by navigating
its headings, it is important to use them appropriately
to convey document structure. Users should order
heading elements properly. For example, in HTML,
H2 elements should follow H1 elements, H3 elements
should follow H2 elements, etc. Content developers
should not "skip" levels (e.g., H1 directly to
H3). Do not use headings to create font effects;
use style sheets to change font styles, for example.
Note that in HTML, heading elements (H1 - H6)
only start sections, they don't contain them as
element content. The following HTML markup shows
how style sheets may be used to control the appearance
of a heading and the content that follows:
Example:
<HEAD>
<TITLE>Cooking techniques</TITLE>
<STYLE type="text/css">
/* Indent heading and following content */
DIV.section2 { margin-left: 5% }
</STYLE>
</HEAD>
<BODY>
<H1>Cooking techniques</H1>
... some text here ...
<DIV class="section2">
<H2>Cooking with oil</H2>
... text of the section ...
</DIV>
<DIV class="section2">
<H2>Cooking with butter</H2>
... text of the section ...
</DIV>
End Example.
Best Practice 4 (based on
Check point 3.6 )
Mark up lists and list items properly.
Content developers are encouraged to use UL for
unordered lists and OL for ordered lists (i.e.,
use markup appropriately) combined with CSS to
provide contextual clues.
The following CSS2 style sheet shows how to provide
compound numbers for nested lists created with
either UL or OL elements. Items are numbered as "1", "1.1", "1.1.1",
etc.
Begin Example:
<STYLE type="text/css">
UL, OL { counter-reset: item }
LI { display: block }
LI:before { content: counters(item, "."); counter-increment: item }
</STYLE>
End Example.
Until either CSS2 is widely supported by user
agents or user agents allow users to control rendering
of lists through other means, authors should consider
providing contextual clues in nested lists. The
following CSS1 mechanism shows how to hide the
end of a list when style sheets are turned on,
and to reveal it when style sheets are turned off,
when user style sheets override the hiding mechanism,
or when style sheets aren't supported.
Example:
<STYLE type="text/css">
.endoflist { display: none }
</STYLE>
<UL>
<LI>Paper:
<UL>
<LI>Envelopes
<LI>Notepaper
<LI>Letterhead
<LI>Poster
paper
<span
class="endoflist">(End of Paper)</span>
</UL>
<LI>Pens:
<UL>
<LI>Blue
writing pens
<LI>whiteboard
pens
<span
class="endoflist">(End of Pens)</span>
</UL>
<LI>Fasteners:
<UL>
<LI>paper
clips
<LI>staples
<LI>Big
lengths of rope.
<span
class="endoflist">(End of Fasteners)</span>
</UL>
<span class="endoflist">(End of Office
Supplies)</span>
</UL>
Note: This example does not help the case of wrapping
list items. With some more effort, the author could
put similar markup at the end of each list item.
Best Practice 5 (based on
Check point 3.7)
Mark up quotations. Do not use quotation markup
for formatting effects such as indentation. The Q
and BLOCKQUOTE elements mark up inline and block
quotations, respectively.
Begin Example:
This example marks up a longer quotation with
BLOCKQUOTE:
<BLOCKQUOTE cite="http://www.example.com/loveslabourlost">
<P>Remuneration! O! that's
the Latin word for three farthings.
--- William Shakespeare (Love's
Labor Lost).
</P>
</BLOCKQUOTE>
End Example
Best Practice 6 (based on
Check point 4.2)
Specify the expansion of each abbreviation or
acronym in a document where it first occurs. Mark
up abbreviations and acronyms with ABBR and ACRONYM
and use "title" to indicate the expansion:
Begin Example:
<P>Welcome to the <ACRONYM title="World
Wide Web">WWW</ACRONYM>!
End Example.
This also applies to shortened phrases used as
headings for table row or columns. If a heading
is already abbreviated provide the expansion in
ABBR. If a heading is long, you may wish to provide
an abbreviation, as described in Data Tables.
Example:
<TH>First name</TH>
<TH><ABBR title="Social Security Number">SS#</ABBR>
End Example.
Best Practice 7 (based on
Check point 4.3)
Identify the primary natural language of a document
by using DOCTYP in the header of each html page.
It is also good practice to identify the primary
language of a document, either with markup (as shown
below) or through HTTP headers.
Begin Example:
<HTML lang="fr">
....rest of an HTML document written in French...</HTML>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
End Example.
Best Practice 8 (based on
Check point 5.1)
For data tables identify row and column headers.
(See 15 above for more information.)
Best Practice 9 (based on Check
point 5.4)
If a table is used for layout, do not use any structural
markup for formatting. Authors should use style sheets
for layout and positioning. However, when it is necessary
to use a table for layout, the table must linearize
in a readable order. When a table is linearized,
the contents of the cells become a series of paragraphs
(e.g., down the page) one after another. Cells should
make sense when read in row order and should include
structural elements (that create paragraphs, headings,
lists, etc.) so the page makes sense after linearization.
Also, when using tables to create a layout, do not
use structural markup to create visual formatting.
For example, the TH (table header) element, is usually
displayed visually as centered, and bold. If a cell
is not actually a header for a row or column of data,
use style sheets or formatting attributes of the
element.
Best Practice 10 (based on
Check point 5.5)
Provide summaries for tables. Provide a summary
via the "summary" attribute. Summaries are especially
useful for non-visual readers. A summary of the relationships
among cells is especially important for tables with
nested headings, cells that span multiple columns
or rows, or other relationships that may not be obvious
from analyzing the structure of the table but that
may be apparent in a visual rendering of the table.
A summary may also describe how the table fits into
the context of the current document. If no caption
is provided, it is even more critical to provide
a summary.
Best Practice 11 (based on
Check point 6.4)
For scripts and applets, ensure that event handlers
are input device-independent. Provide Alternative
text.
Device independent Users must be able to interact
with a user agent (and the document it renders)
using the supported input and output devices of
their choice and according to their needs. Input
devices may include pointing devices, keyboards,
braille devices, head wands, microphones, and others.
Output devices may include monitors, speech synthesizers,
and braille devices.
Please note that "device-independent support" does
not mean that user agents must support every input
or output device. User agents should offer redundant
input and output mechanisms for those devices that
are supported. For example, if a user agent supports
keyboard and mouse input, users should be able
to interact with all features using either the
keyboard or the mouse.
Best Practice 12 (based
on Check point 7.2)
Until user agents allow users to control blinking,
avoid causing content to blink (i.e., change presentation
at a regular reate, such as turning on and off).
Best Practice 13 (based
on Check point 7.3)
Until user agents allow users to freeze moving content,
avoid movement in pages.
Best Practice 14 (based on
Check point 9.1)
Provide client-side image maps instead of server-side
image maps except where the regions cannot be defined
with an available geometric shape. When a server-side
image map must be used, content developers should
provide an alternative list of image map choices.
Begin Example
There are three techniques:
- Include the alternative links within the body
of an OBJECT element.
- If IMG is used to insert the image, provide
an alternative list of links after it and
indicate the existence and location of the
alternative list (e.g., via that "alt" attribute).
Example:
<A href="http://www.example.com/cgi-bin/imagemap/my-map">
<IMG src="welcome.gif" alt="Welcome! (Text links follow)" ismap>
</A>
<P>[<A href="reference.html">Reference</A>]
[<A href="media.html">Audio Visual Lab</A>]
If other approaches don't make the image map accessible,
create an alternative page that is accessible.
End Example
Best Practice 15 ( based
on Check point 9.3)
For scripts, specify logical event handlers rather
than device-dependent event handlers.
Some event handlers, when invoked, produce purely
decorative effects such as highlighting an image
or changing the color of an element's text. Other
event handlers produce much more substantial effects,
such as carrying out a calculation, providing important
information to the user, or submitting a form.
For event handlers that do more than just change
the presentation of an element, content developers
should do the following:
Use application-level event triggers rather than
user interaction-level triggers. In HTML 4.01,
application-level event attributes are "onfocus", "onblur" (the
opposite of "onfocus"), and "onselect".
Note that these attributes are designed to be
device-independent, but are implemented as keyboard
specific events in current browsers. Otherwise,
if you must use device-dependent attributes, provide
redundant input mechanisms (i.e., specify two handlers
for the same element):
- Use "onmousedown" with "onkeydown".
- Use "onmouseup" with "onkeyup"
- Use "onclick" with "onkeypress"
Note that there is no keyboard equivalent to double-clicking
("ondblclick") in HTML 4.01.
Do not write event handlers that rely on mouse
coordinates since this prevents device-independent
input.
Best Practice 16 (based on
Check point 10.4)
Until user agents handle empty controls correctly,
include default, place-holding characters in edit
boxes and text areas.
Begin Example
Some legacy assistive technologies require initial
text in form controls such as TEXTAREA in order to
function properly.
<FORM action="http://example.com/prog/text-read" method="post"><P>
<TEXTAREA name=yourname rows="20" cols="80">
Please enter your name here.
</TEXTAREA>
<INPUT type="submit" value="Send"><INPUT
type="reset">
</P></FORM>
Provide a text equivalent for images used as "submit" buttons:
Example
<FORM action="http://example.com/prog/text-read" method="post"><P>
<INPUT type="image" name=submit src="button.gif" alt="Submit">
</FORM>
End Example.
Best Practice 17 (based on
Check point 12.1)
Title each frame to facilitate frame identification
and navigation.
Begin Example
Use the "title" attribute to name frames.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Frameset//EN">
<HTML>
<HEAD>
<TITLE>A simple frameset document</TITLE>
</HEAD>
<FRAMESET cols="10%, 90%"
title="Our library of electronic documents">
<FRAME src="nav.html" title="Navigation bar">
<FRAME src="doc.html" title="Documents">
<NOFRAMES>
<A href="lib.html" title="Library link">
Select to go to the electronic library</A>
</NOFRAMES>
</FRAMESET>
End Example
Best Practice 18 (based
on Check point 12.3)
Divide large blocks of information into more manageable
groups where natural and appropriate.
The following HTML 4.01 mechanisms group content
and makes it easier to understand:
- Use FIELDSET to group form controls into semantic
units and describe the group with the LEGEND
element.
- Use OPTGROUP to organize long lists of
menu options into smaller groups.
- Use tables for tabular data and describe
the table with CAPTION.
- Group table rows and columns with THEAD,
TBODY, TFOOT, and COLGROUP.
- Nest lists with UL, OL, and DL.
- Use section headings (H1 - H6) to create
structured documents and break up long stretches
of text. Refer to the following section for
more information.
- Break up lines of text into paragraphs
(with the P element).
- Group related links. Refer to the section
Grouping and bypassing links
- All of these grouping mechanisms should
be used when appropriate and natural, i.e.,
when the information lends itself to logical
groups. Content developers should not create
groups randomly, as this will confuse all
users.
Best Practice 19 (based on
Check point 13.3)
Provide information about the general layout of
a site (e.g., a site map or table of contents).
A consistent style of presentation on each page
allows users to locate navigation mechanisms more
easily but also to skip navigation mechanisms more
easily to find important content. This helps people
with learning and reading disabilities but also
makes navigation easier for all users. Predictability
will increase the likelihood that people will find
information at your site, or avoid it when they
so desire.
Examples of structures that may appear at the
same place between pages:
A navigation mechanism creates a set of paths
a user may take through your site. Providing navigation
bars, site maps, and search features all increase
the likelihood that a user will reach the information
they seek at your site. If your site is highly
visual in nature, the structure might be harder
to navigate if the user can't form a mental map
of where they are going or where they have been.
To help them, content developers should describe
any navigation mechanisms. It is crucial that the
descriptions and site guides be accessible since
people who are lost at your site will rely heavily
on them.
When providing search functionality, content developers
should offer search mechanisms that satisfy varying
skill levels and preferences. Most search facilities
require the user to enter keywords for search terms.
Users with spelling disabilities and users unfamiliar
with the language of your site will have a difficult
time finding what they need if the search requires
perfect spelling. Search engines might include
a spell checker, offer "best guess" alternatives,
query-by-example searches, similarity searches,
etc.
Best Practice 20 (based
on Check point 13.4)
Use navigation mechanisms in a consistent manner.
(See above.)
Best Practice 21 (based on
Check point 13.5)
Provide navigation bars to highlight and give access
to the navigation mechanism. (See above.)
Best Practice 22 (based on
Check point 13.8)
Place distinguishing information at the beginning
of headings, paragraphs, lists, etc.
The following writing style suggestions should
help make the content of your site easier to read
for everyone, especially people with reading and/or
ognitive disabilities. Several guides (including
[HACKER]) discuss these and other writing style
issues in more detail.
Strive for clear and accurate headings and link
descriptions. This includes using link phrases
that are terse and that make sense when read out
of context or as part of a series of links (Some
users browse by jumping from link to link and listening
only to link text.) Use informative headings so
that users can scan a page quickly for information
rather than reading it in detail.
State the topic of the sentence or paragraph at
the beginning of the sentence or paragraph (this
is called "front-loading"). This will help both
people who are skimming visually, but also people
who use speech synthesizers. "Skimming" with speech
currently means that the user jumps from heading
to heading, or paragraph to paragraph and listens
to just enough words to determine whether the current
chunk of information (heading, paragraph, link,
etc.) interests them. If the main idea of the paragraph
is in the middle or at the end, speech users may
have to listen to most of the document before finding
what they want. Depending on what the user is looking
for and how much they know about the topic, search
features may also help users locate content more
quickly.
Limit each paragraph to one main idea. Avoid slang,
jargon, and specialized meanings of familiar words,
unless defined within your document. Favor words
that are commonly used. For example, use "begin" rather
than "commence" or use "try" rather than "endeavor."
Use active rather than passive verbs. Avoid complex
sentence structures.
To help determine whether your document is easy
to read, consider using the Gunning-Fog reading
measure (described in [SPOOL] with examples and
the algorithm online at [TECHHEAD]). This algorithm
generally produces a lower score when content is
easier to read. As example results, the Bible,
Shakespeare, Mark Twain, and TV Guide all have
Fog indexes of about 6. Time, Newsweek, and the
Wall St. Journal an average Fog index of about
11.
Best Practice 23 (based
on Check point 13.10)
Provide a means to skip over multi-line ASCII art.
Do not use multi-line ASCII art. Avoid ASCII art
(character illustrations) and use real images instead
since it is easier to supply a text equivalent for
images. However, if ASCII art must be used provide
a link to jump over the ASCII art, as follows.
Example
<P>
<a href="#post-art">skip over ASCII art</a>
<!-- ASCII art goes here -->
<a name="post-art">caption for ASCII art</a>
End Example.
ASCII art may also be marked up as follows [skip
over ASCII figure or consult a description of chart].
Example:
% __ __ __ __ __ __ __ __ __ __ __ __ __ __ 100
| * | 90 | * * | 80 | * * | 70 | @ * | 60 | @ * |
50 | * @ * | 40 | @ * | 30 | * @ @ @ * | 20 | | 10
| @ @ @ @ @ | 0 5 10 15 20 25 30 35 40 45 50 55 60
65 70 Flash frequency (Hz)
End Example
Another option for smaller ascii art is to use an
ABBR element with "title".
Example
<P><ABBR title="smiley in ASCII art">:-)</ABBR>
End Example
If the ASCII art is complex, ensure that the text
equivalent adequately describes it. Another way to
replace ASCII art is to use human language substitutes.
For example, <wink> might substitute for a
winking smiley: ;-). Or, the word "therefore" can
replace arrows consisting of dashes and greater than
signs (e.g., -->), and the word "great" for the
uncommon abbreviation "gr8".
Best Practice 24 (based on
Check point 14.3)
Create a style of presentation that is consistent
across pages. Use a minimal number of style sheets
for your site.
Use linked style sheets rather than embedded styles,
and avoid inline style sheets. If you have more than
one, use the same "class" name for the same concept
in all of the style sheets.
Accessibility
Architecture Resources
|
