WD-WAI-PAGEAUTH-0203
WAI Accessibility Guidelines:
Page Authoring
W3C Working Draft 03-Feb-1998
- This version:
- http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-0203
- Latest version:
- http://www.w3.org/TR/WD-WAI-PAGEAUTH
- Previous versions:
- http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-0202
- Editors:
- Gregg Vanderheiden, Trace Research and
Development
Wendy Chisholm, Trace Research and
Development
Ian Jacobs, W3C
-
- Please see the Acknowledgements section of the Appendix for
a full listing of contributors.
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 how to make Web
pages accessible. The goal of the WAI-GL working group is discussed in our charter.
Abstract
This document is a list of markup guidelines that HTML authors should follow in order
to make their pages more accessible. Following the list of guidelines is a checklist that
authors and Web masters should use to verify page accessibility. 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.
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.
This document recommends guidelines that HTML authors should follow in order to improve
the accessibility of their pages. Some of the guidelines take advantage of the features of
HTML 4.0, but many of them apply to earlier
versions of HTML as well.
Measures to improve accessibility fall roughly into the following categories:
- Structure
- HTML documents that contain a lot of markup used for presentation and not enough markup
to convey structure pose accessibility problems for non-visual users. Authors should use
HTML structural markup to convey meaning and style sheets to format and layout pages.
- Navigation
- Authors should enable keyboard-only navigation (access to hyperlinks, navigation
among links, navigation among form fields, navigation within and between pages) and design
pages that promote easy orientation (numbered lists, titles, etc.).
- Alternative format
- Authors should always provide alternative ways to access information presented via
images, sounds, applets, and scripts. Authors may supply several types of alternative
format:
- Brief alternative text (the "alt" attribute)
- Short descriptions (the "title" attribute) and long descriptions (the
"longdesc" attribute or links to paragraphs) of content.
- Transcripts (for audio and video)
- Alternative versions of documents.
The following sections offer specific guidelines that HTML authors should use to
improve the accessibility of their pages.
Each guideline is accompanied by a rating that describes its importance:
- [Required]
- Required, otherwise it will be impossible for one or
more groups of users to understand the page.
- [Recommended]
- Makes page easier to understand and use.
Each guideline may be implemented by one or more "strategies" in HTML (and
possibly a style sheet language). Each strategy may be classified according to the
immediacy of its application:
- [Interim]
- This strategy is necessary to make pages accessible for today's browsers and assistive
technologies
- [New]
- This strategy takes advantage of features being incorporated into tomorrow's browsers
and assistive technologies (that incorporate Web Access Initiative recommendations).
Strategies with no classification work for versions of HTML prior to HTML 4.0, and old
or new browsers.
[New] Style sheets are supported as of HTML 4.0.
- [Required]
Ensure that pages are readable and usable without style sheets for
browsers that do not support them or users who deactivate them. Since style sheets are a
new phenomenon, older browsers will not support them and it will take a while for new
browsers to support them in a standard way.
- [Required]
Use style sheets, instead of HTML markup, to
control colors, fonts, and the position of text, images, and objects.
Authors should use style sheets instead of elements (such as I
, B
,
FONT
, etc.) and attributes (such as "align
") that
control visual presentation. Authors are encouraged to use elements (such as STRONG
,
EM
, H1
, H2
, ABBR
, etc.) that add structure
to documents. [Note: Current (January 1998) browsers do not yet support
use of style sheets for some types of positioning, such as absolute.]Use style
sheets rather than:
- converting text to images (e.g., an image that just displays text on a colored
background) or alternative text file formats (such as PDF)
- using tables or
PRE
elements to layout pages
- using proprietary extensions
- using "invisible" images to lay out pages
- writing a program to accomplish something that is possible with style sheets or plain
HTML
Use style sheets to:
- position text and graphics
- create drop caps, subscripts, and superscripts
- avoid uncommon typographic characters or constructions (such as ASCII art, etc.)
- enable page rendering to different target media. Whether or not an author anticipates
that a page will be viewed on alternative media, such as a PDA, a speech-based browser or
paper (printed), it is a good idea to promote accessibility by designing style sheets for
these media. Example media types are screen, tty, tv, projection, handheld, print,
braille, and aural.
- highlight sections of a document with font size, formatting, or color.
For more information:
- Style Sheets - Chapter 14 in the Central
Reference Document
- Style Sheets - the HTML 4.0
specification
- Cascading Style Sheets, level 2 -- Working
Draft from the World Wide Web Consortium
Please also consult the section on links.
- [Required]
Provide alternative text for all images and image maps.
Each image should have alternative text that describes the function of the graphic.
Examples of possible alt-text are, "Section Title: Banana Products," "Graph
of population versus age," or "Search Button." Possible strategies
include:
- The "
alt
" attribute is mandatory for the AREA
and IMG
elements. It should also be used for APPLET
, and INPUT
. For
example: <IMG src="logo.gif" alt="XYZ
Logo">
.
- [New] If
OBJECT
is used, text can be provided in the body of the OBJECT
element. For example:
<OBJECT data="logo.gif">XYZ Logo</OBJECT>
- Include internal text in image data file when the image data file format supports it,
e.g. PNG.
- [Required]
Provide a link to a longer description for graphics that present important information
(especially charts, tables, and diagrams).
Alternative text descriptions (strategy 2.1) are usually short and define the basic
purpose of graphic elements. To describe the graphic itself in more detail, supply a link
to a longer description with one of the following mechanisms:
- [Interim] Provide a description-link (D-link) next to the graphic that
links to a page or a phrase at the bottom of the page with a longer description of the
graphic. For example:
<IMG src="97sales.gif" alt="Sales for
1997">
<A href="sales.html">D</A>
- [New] Use the "
longdesc
" attribute of the IMG
element. For example:
<IMG src="97sales.gif" alt="Sales for 1997"
longdesc="sales.html">
- [New] Provide text within the body of the
OBJECT
element:
<OBJECT data="sales.gif">
Sales in 1997 were down subsequent to ...
</OBJECT>
- [Required]
Use client-side (instead of server-side) image maps.
Client-side image maps allow browsers that are not displaying graphics to use "alt
"
or "title
" attribute values to construct a list of links in
place of the image map graphic.When a server-side image map must be used, authors
should provide an alternate list of image map choices. For example, authors may put the
alternate links on the same page in the body of an OBJECT
element (similar to
strategy 2.4.2), or create an alternative page that is accessible.
To avoid confusion, if an alternative list of links follows the image map, authors should
indicate with the "alt" attribute of the MAP
element that there is
an alternate list and its location.
- [Required]
Provide a description for each link in an image map.
Depending on the image map, there are several possibilities:
- If the
MAP
element has been used with AREA
, set the "alt
"
attribute of the AREA
element. For example, with the IMG
element:
<IMG src="welcome.gif" alt="Image map of areas in the library"
usemap="#map1">
<MAP name="map1">
<AREA shape="rect" coords="0,0,30,30" href="reference.html"
alt="Reference">
<AREA shape="rect" coords="34,34,100,100" href="media.html"
alt="Audio Visual lab">
</MAP>
[New] The same idea, this time with the OBJECT
element:
<OBJECT data="welcome.gif" usemap="#map1">
alt="Image map of areas in the library"
</OBJECT>
<MAP name="map1">
<AREA shape="rect" coords="0,0,30,30"
href="ref.html" alt="Reference">
<AREA shape="rect" coords="34,34,100,100"
href="media.html" alt="Audio Visual Lab">
</MAP>
- [New] If the
MAP
element is used with A
elements that
specify active region geometries, set the "title
" attribute of each
A
element.
<OBJECT data="navbar1.gif" type="image/gif" usemap="#map1">
<MAP name="map1">
<P>Navigate the site:
<A title="Access Guide"href="guide.html"
shape="rect" coords="0,0,118,28">Access Guide</a> |
<A title="Go" href="shortcut.html"
shape="rect" coords="118,0,184,28">Go</A> |
<A title="Search" href="search.html"
shape="circle" coords="184,200,60">Search</A> |
<A title="Top 10" href="top10.html"
shape="poly" coords="276,0,373,28,50,50,276,0">Top Ten</A>
</MAP>
</OBJECT>
Note in this example that the MAP
element is the content of the OBJECT
element so that the alternate links will only be displayed if the image map (navbar1.gif)
is not.
- [Recommended]
Provide descriptive titles for all images used as links.
Use the "title"
attribute of the A
element to provide
more information about the function of images used as links. For example:
<A href="home.html" title="XYZ company home page">
<IMG src="logo.gif" alt="XYZ logo">
</A>
- [Recommended]
Avoid ASCII art. Replace it with an image and alternative text.
Common typographic characters or constructions to be avoided are emoticons, arrows
consisting of dashes and greater than signs (e.g., -->), etc.
For more information:
- From the Central Reference Document
- 13.1 Introduction to the issues
- 13.2 General recommendations
- 13.3 Viewing and interacting with static images and
image maps
- Objects, Images and Applets
- the HTML 4.0 specification
- [Required]
Provide alternative text for each script.
[New] The NOSCRIPT
element allows authors to supply alternative
content for scripts. For example:
<SCRIPT type="text/tcl">
...some Tcl script to show a billboard of sports scores...
</SCRIPT>
<NOSCRIPT>
<P>To access today's scores,
<A href="scores.html">visit our text-only version.</A>
</NOSCRIPT>
- [Required]
Provide alternative text for each applet.
- [Interim] Use the
"alt"
attribute of the APPLET
element, as in:
<APPLET code="Press.class" width="500" height="500"
alt="Java applet: how temperature affects pressure.">
As temperature increases the molecules in the balloon...
</APPLET>
Note. The APPLET
element is deprecated in HTML 4.0.
- [New] When using the
OBJECT
element, specify alternative content:
<OBJECT classid="Press.class" width="500" height="500"
title="Java applet: how temperature affects pressure.">
As temperature increases the molecules in the balloon...
</OBJECT>
A more complex version takes advantage of the fact the OBJECT
elements may
be embedded to provide for alternative representations of information:
<!-- First, try the pressure applet -->
<OBJECT title="How temperature affects pressure"
classid="Press.class" width="500" height="500">
<!-- Else, try the MPEG video -->
<OBJECT data="pressure.mpeg" type="application/mpeg">
<!-- Else, try the GIF image -->
<OBJECT data="Pressure.gif">
<!-- Else render the description and an alternative -->
As temperature increases the molecules in the balloon...
</OBJECT></OBJECT></OBJECT>
- [Required]
Provide descriptions of applets that present
important information.
- [Interim] Supply a description as content of the
APPLET
element
(see the example in 3.2.1).
- [New] Supply a description as content of the
OBJECT
element (see
the example in 3.2.2).
- [Required]
If an applet gathers information, provide an alternative mechanism for gathering the
information.
Alternative information gathering mechanisms such as a user-input form, e-mail address,
phone or fax number should be provided within the alternative text of either the APPLET
or OBJECT
elements.
- [Required]
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.
More information is available through the Java Accessibility page at the Trace
Center.
- [Required]
Provide a mechanism for the user to freeze any
moving or blinking objects, particularly those that contain text.
In the following example created by Mark Novak, if the user presses the escape key while
the Java marquee has focus, the text will be displayed statically.
- [Recommended]
Make scripts and applets keyboard-operable
(using standard conventions).
Note. More exploration is needed in this area. Please stay tuned.
For more information:
- From the Central Reference Document
- 13.1 Introduction to the issues
- 13.2 General recommendations
- 13.4 Applets
- 18 Scripts
- Objects, Images and Applets
- the HTML 4.0 specification
- Scripts - the HTML 4.0
specification
- [Required]
Provide a text transcript of all audio information.
Full audio transcripts include spoken dialogue as well as any other significant sounds
including on-screen and off-screen sounds, music, laughter, applause etc. 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.
- [Required]
Provide descriptions of all video information in an
auditory form, synchronized with the audio track.
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.
- [Required]
Provide descriptions of all video information in a
text format.
A text transcript of the video descriptions provides the same information as in
recommendation 4.2, but in a text format. This text
transcript, in conjunction with the full audio transcript (4.1), 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.
- [Required]
Synchronize text and video description information
with audio/video information, either directly or via a synchronization file.
Some media formats such as QuickTime (for Macintosh) movies provide alternative tracks
that can be used to add captioning and video descriptions.
- [Interim] Until the format in question supports alternative tracks, two
versions of the movie could be made available, one with captions and descriptive video,
and one without.
- [New] Future technologies 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
specification.
- [Recommended]
Provide visual notification of sounds that are
played automatically.
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. The controversy surrounding this recommendation is that 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.
- [Recommended]
Use the "title
" attribute to provide a brief description of
a very short sound.
For example: <A href="mittens.wav"
title="meow"></A>
For more information:
- From the Central Reference Document
- 13.1 Introduction to the issues
- 13.2 General recommendations
- 13.5 Audio and video
- Objects, Images and Applets
- the HTML 4.0 specification
- Examples
from NCAM
Please refer to the section on style sheets for more
information about formatting and positioning text and graphics.
- [Required]
Use elements and attributes that convey structure
rather than presentation.
Structural elements include: ABBR, ACRONYM, CITE, CODE, DFN, EM, H1, H2, KBD, SAMP,
STRONG, VAR,
etc.
Presentation elements include: size="14", B, I, TT, FONT, BASEFONT,
CENTER.
Documents that do not include presentation elements and attribute and use style sheets for
presentation allow users to adjust the look of the document (e.g., larger print, color
contrast, etc.) through personal style sheets or browser settings. Although authors should
avoid presentation elements, they should use structural elements, which enforce
consistency in documents and supply information to other tools (e.g., indexing tools,
search engines, programs that extract tables to databases, browsers that use header
elements ( H1, H2
, etc.) to generate navigation tools, etc.).
- [Required]
Do not misuse structural elements and attributes
for purposes of layout.
For example, do not use the BLOCKQUOTE
element or the "cite
"
attribute to indent a paragraph (use style sheets). Do not use PRE
to create
a tabular layout of text (use tables).
- [Required]
Do not misuse presentation elements for purposes of
structure.
For example, while a horizontal rule (HR
) might convey a structural change to
some users, it may not to all users. Instead, specify structure with DIV
and SPAN
.
For example:
<DIV class="navigation-bar">
<HR title="Rule introducing navigation bar">
[ <A rel="Next" href="next.html">Next page alt="Next page"</A> |
<A rel="Previous" href="previous.html">Previous page alt="Previous page"</A> |
<A rel="First" href="first.html">First page alt="First page"</A>
]
</DIV>
- [Required]
Avoid blinking or scrolling text.
[Interim] Authors should avoid the BLINK
and MARQUEE
elements. First of all, these elements are not part of HTML 4.0 (they are proprietary
extensions and should be avoided). Second, blinking and moving text is either read
incorrectly or not at all by screen readers, can adversely affect people with cognitive
disabilities, and is often annoying to people in general (see Jared Spool's book,
"Web Site Usability"). Authors should use style sheets to draw attention to text
in other ways, such different fonts, sizes, or colors.
- [Required]
Nest headings properly.
[New] Proper nesting of heading is important for document navigation. Headings
used for other purposes (e.g., for formatting text in a larger font size) may disorient
users; use style sheets for formatting.
- [Recommended]
Provide titles for horizontal rules, acronyms, and abbreviations.
For example:
<HR title="new section">
<ABBR>title="World Wide Web">WWW</ABBR>
Tips and Tricks
- To test if the text and background contrast is sufficient enough to be read by people
with color deficiencies or on low resolution monitors, view the pages with a monochrome
monitor.
- To get a better understanding of what a screen reader would present to a user, do not
load the images on a page when viewing with a graphical browser or use a text-based
browser such as Lynx.
For more information:
- Text - Chapter 9 in the Central Reference Document
- Text - the HTML 4.0
specification
- [Required]
Encode list structure and list items properly.
The HTML list elements (DL, UL, OL, LI
) should be used to create lists, not
for presentation (e.g., indentation). [New] Use style sheets rather than HTML
attributes to control item spacing.
Tips and Tricks
- Using a numbered (ordered) list makes it easier for people accessing the page aurally to
keep track of where they are within a list.
For more information:
- Lists and Outlining - Chapter 10 in the
Central Reference Document
- Lists - the HTML 4.0
specification
- [Required]
Associate table cells with row and column labels explicitly.
Future browsers and assistive technologies will be able to automatically translate tables
into linear sequences if tables are labeled appropriately. [New] One way of
labeling cells is with the "headers
" and "scope
"
attributes. Please refer to the first two tables examples in the appendix.
- [Required]
Avoid using tables to arrange text documents in
columns.
- [Recommended]
For tables of text and numbers, provide an alternative page that presents the table information in a linear
fashion.
- [Recommended]
Avoid using tables to layout a page.
[New] Authors should use style sheets to position graphics and text.
- [Recommended]
Provide abbreviations for lengthy row or column labels.
[New] Row and column header abbreviations (the "abbr
"
attribute) should be short but meaningful. This will be particularly useful for
future speaking technologies that will read row and column labels for each cell.
Abbreviations cut down on repetition and reading time. Please refer to the examples
in the appendix.
- [Recommended]
Provide summaries of tables.
[New] Summaries of table structure and purpose (the "summary
"
attribute of the TABLE element) are especially useful for non-visual users. Please
refer to the examples in the appendix.
- [Recommended]
For more complex tables, group information into categories.
[New] Future browsers will allow users to select data from a table by filtering
on categories. Please refer to the third example (the "axis
"
attribute) in the appendix.
- [Recommended]
Ensure that alternative text does not wrap within
tables used to position graphics.
[Interim] Test for wrapping using the equivalent window size as that which can
maximally fit on a 15-inch monitor using a common resolution such as 800x600 pixels.
- [Recommended]
Provide a phone number, fax number or e-mail
address if tables cannot be made accessible.
Tips and Tricks
- To predict how one of today's screen readers might read the table, hold a piece of paper
up to your monitor. As you slide the paper down the monitor, read the words
above the line the paper creates as a sentence. Ask another person to listen as you
read the page out loud without pausing for column gaps. Can he or she make sense out
of what you have read?
- Another method, to predict how a screen reader will interpret a page, is to save it as a
text-only file then open it with a word processing program. This function is
available in the "File" menu in most browsers.
For more information:
- Tables - Chapter 11 in the Central
Reference Document
- Tables - the HTML 4.0
specification
Please also consult the section on image maps.
- [Recommended]
Create link phrases that make sense when read out
of context, but that are not too verbose.
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 ("link text") is read.
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 click here."
- [Recommended]
Place non-link, printable characters
(surrounded by spaces) between links that occur consecutively to keep
separate links from being read as one by screen readers (e.g., " | ").
[Interim] Please consult the example provided in guideline 5.3.
- [Recommended]
Provide keyboard shortcuts for links.
The "accesskey
" attribute of the LABEL, A, CAPTION and LEGEND
elements allows an author to associate a keyboard shortcut with the phrase. For example,
when associated with a link, it takes the user to the associated document. <A
accesskey="C" href="doc.html">Press C to go to XYZ page</A>
For more information:
- Links - Chapter 12 in the Central Reference
Document
- Links - the HTML 4.0
specification
- [Required]
Ensure that pages are readable and usable without
frames.
[New] Authors should include a NOFRAMES
element at the end of each FRAMESET
.
Please refer to the example in the Central Reference
Document.
- [Required]
Do not include an image directly in a frame -- put it in a separate document.
[New] Otherwise, if the frame contents change, the frame title -- the only
alternative text available in this case -- will no longer make sense. Including the image
in its own file allows authors to specify alt-text with the IMG
or OBJECT
elements.
- [Required]
Give each frame a title.
[New] People accessing the page aurally will more easily keep track of how many
frames exist and which is the current one. For example:
<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>
- [Recommended]
Describe the layout and purpose of frames and how multiple frames relate to each
other.
[New] Use the "longdesc
" attribute on the FRAME
and IFRAME
elements to designate a long description.
For more information:
- Frames - Chapter 16 in the Central
Reference Document
- Frames - the HTML 4.0
specification
- [Required]
Do not use image maps to create graphical
"submit" buttons.
Instead, use the BUTTON
or INPUT
elements with alternative text.
- [Required]
Associate labels with their controls explicitly.
[New] The "for
" attribute of the LABEL
element allows explicit association. For example:
<FORM action="http://somesite.com/adduser" method="post"
<FIELDSET>
<LEGEND>Personal information</LEGEND>
<LABEL for="firstname">First name:</LABEL>
<INPUT type="text" id="firstname" tabindex="1">
<LABEL for="lastname">Last name:</LABEL>
<INPUT type="text" id="lastname" tabindex="2">
...more personal information...
</FIELDSET>
<FIELDSET>
<LEGEND>Medical History</LEGEND>
...medical history information...
</FIELDSET>
</FORM>
- [Required]
Provide alternative text for images used as
"submit" buttons.
For example: <INPUT type="image"
name="submit" src="button.gif" alt="Submit">
- [Recommended]
Specify a logical tab order among form controls.
[New] The "tabindex
" attribute specifies the tabbing
navigation order among form controls. For example:
<INPUT tabindex="1" type="text" name="field1">
<INPUT tabindex="2" type="text" name="field2">
<INPUT tabindex="3" type="submit" name="submit">
- [Recommended]
Group related controls semantically and label each
group.
[New] The new FIELDSET
element groups form controls while the LEGEND
element labels each group. Please see the example in guideline 10.2.
- [Recommended]
For long lists of selections, group items into a hierarchy.
[New] In the near future, browsers will display grouped lists with expanding and
collapsing levels of detail. To group items, use the OPTGROUP
element (with the SELECT
element). For example:
<FORM action="http://somesite.com/prog/someprog"
method="post">
<P><SELECT name="ComOS">
<OPTGROUP label="Comm Servers">
<OPTGROUP label="PortMaster 3">
<OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 with ComOS
3.7.1
<OPTION label="3.7" value="pm3_3.7">PortMaster 3 with ComOS 3.7
<OPTION label="3.5" value="pm3_3.5">PortMaster 3 with ComOS 3.5
</OPTGROUP>
<OPTGROUP label="PortMaster 2">
<OPTION label="3.7" value="pm2_3.7">PortMaster 2 with ComOS 3.7
<OPTION label="3.5" value="pm2_3.5">PortMaster 2 with ComOS 3.5
</OPTGROUP>
</OPTGROUP>
<OPTGROUP label="Routers">
<OPTGROUP label="IRX">
<OPTION label="3.7R" value="IRX_3.7R">IRX with ComOS 3.7R
<OPTION label="3.5R" value="IRX_3.5R">IRX with ComOS 3.5R
</OPTGROUP>
</OPTGROUP>
</SELECT>
</FORM>
- [Recommended]
Include default, place-holding characters in edit
boxes and text areas. [Interim]
- Recommended]
Include a phone number, fax number, e-mail address,
or postal address as alternate an way to submit information. [Interim]
- [Recommended]
Furnish keyboard shortcuts for form elements.
[New] Keyboard shortcuts are assigned with the "accesskey
"
attribute. This example assigns "U" as the access key. Typing "U"
gives focus to the label which gives focus to the control then the user can input text.
<P>
<FORM action="submit" method="post">
<LABEL for="user" accesskey="U">user name</label>
<INPUT type="text" name="user">
</FORM>
For more information:
- Forms - Chapter 17 in the Central
Reference Document
- Forms - the HTML 4.0
specification
If, after best efforts, any page is still not accessible, provide a link to an
alternative page which is accessible, has equivalent information, and is maintained with
the same frequency as the inaccessible page. This is a last resort since it
increases site maintenance.
- Methods for linking to alternative pages:
- [Interim] Provide a visible link at the top of each page to allow a user to
move back and forth between the graphic and alternative versions of the page.
- [New] Provide the appropriate information in the header of the principal page
(with the
LINK
element) so that the browser loads it automatically. If the
user has set their default media type to "aural," "braille," or
"tty" the user agent should load the alternative page automatically.
For example:
<HEAD>
<TITLE>Welcome to the Virtual Mall!</TITLE>
<LINK title="Text-only version"
rel="alternate" href="text_only.html"
media="aural, braille, tty">
</HEAD>
Following the general site design guidelines will further improve
accessibility.
- Create a consistent style for pages.
- Use a clear, consistent navigation structure.
- Offer navigation bars for easy access to the navigation structure.
- Provide a description of the general layout of the site, the access features used, and
how to use them.
- Offer a site map.
- Offer different types of searches for different skill levels and preferences.
- Ensure that nothing within the site prevents keyboard operation.
- Do not use elements outside of the HTML 4.0/3.2/2.0 specification (such as
<BLINK>
and <MARQUEE
>).
- Use a design tool that supports access features (and does not remove access when you
close, or reopen your page using the tool).
- Place distinguishing information at the beginning of headings, paragraphs, lists, etc.,
to decrease the amount of sifting readers perform to find important information.
This is commonly referred to as "front-loading" and is especially helpful for
people accessing information serially.
- Create a single downloadable file for documents that exist as a series of separate
pages. 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 information in page
headers. The following example shows how to indicate where the first page of the
reference manual exists as well as which page follows the current one.
<HEAD><TITLE>Reference manual -- Chapter 1</TITLE>
<LINK rel="Start" title="The first page of the manual"
type="text/html"
href="http://someplace.com/manual/start.html">
<LINK rel="Next" title="Chapter 2"
type="text/html"
href="http://someplace.com/manual/ch2.html">
</HEAD>
- Test the site with at least:
- a text-only browser (e.g., Lynx or a Lynx emulator such as Lynx Viewer or Lynx-me)
- multiple graphic browsers, 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)
- Validate pages with tools such as:
For more information:
Good Web Site Design Practices - Chapter 25 in the
Central Reference Document
Table examples
- "
headers
" - The following example shows how to
associate header information with 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
".
<TABLE border="border" 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.">
<CAPTION>Cups of coffee consumed by each senator</CAPTION>
<TR>
<TH id="t1">Name</TH>
<TH id="t2">Cups</TH>
<TH id="t3" abbr="Type">Type of Coffee</TH>
<TH id="t4">Sugar?</TH>
<TR>
<TD headers="t1">T. Sexton</TD>
<TD headers="t2">10</TD>
<TD headers="t3">Espresso</TD>
<TD headers="t4">No</TD>
<TR>
<TD headers="t1">J. Dinnen</TD>
<TD headers="t2">5</TD>
<TD headers="t3">Decaf</TD>
<TD headers="t4">Yes</TD>
</TABLE>
A speech synthesizer might render by speaking the following:
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
- "
scope
" - The following example associates the
same header and data information as the previous example, but 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. This example might be rendered by a speech
synthesizer as the previous example.
<TABLE border="border"
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.">
<CAPTION>Cups of coffee consumed by each senator</CAPTION>
<TR>
<TH scope="col">Name</TH>
<TH scope="col">Cups</TH>
<TH scope="col" abbr="Type">Type of Coffee</TH>
<TH scope="col">Sugar?</TH>
<TR>
<TD>T. Sexton</TD>
<TD>10</TD>
<TD>Espresso</TD>
<TD>No</TD>
<TR>
<TD>J. Dinnen</TD>
<TD>5</TD>
<TD>Decaf</TD>
<TD>Yes</TD>
</TABLE>
"axis"
- The following example shows how to
create categories within a table.
<TABLE border="border">
<CAPTION> Travel Expense Report </CAPTION>
<TR>
<TH></TH>
<TH id="a2" axis="expenses">Meals</TH>
<TH id="a3" axis="expenses">Hotels</TH>
<TH id="a4"
axis="expenses">Transport</TH><TD>subtotals</ TD>
</TR>
<TR>
<TH id="a6" axis="location">San Jose</TH>
<TH></TH><TH></TH><TH></TH><TD> </TD>
</TR>
<TR>
<TD id="a7" axis="date">25-Aug-97</TD>
<TD headers="a6 a7 a2">37.74</TD>
<TD headers="a6 a7 a3">112.00</TD>
<TD headers="a6 a7 a4">45.00</TD><TD></TD>
</TR>
<TR>
<TD id="a8" axis="date">26-Aug-97</TD>
<TD headers="a6 a8 a2">27.28</TD>
<TD headers="a6 a8 a3">112.00</TD>
<TD headers="a6 a8 a4">45.00</TD><TD></TD>
</TR>
<TR>
<TD>subtotals</TD><TD>65.02</TD><TD>224.00&
</TD><TD>90.00</TD><TD>379.02</TD>
</TR>
<TR>
<TH id="a10" axis="location">Seattle</TH>
<TH></TH><TH></TH><TH></TH><TD> </TD>
</TR>
<TR>
<TD id="a11" axis="date">27-Aug-97</TD>
<TD headers="a10 a11 a2">96.25</TD>
<TD headers="a10 a11 a3">109.00</TD>
<TD headers="a10 a11 a4">36.00</TD><TD></TD>
</TR>
<TR>
<TD id="a12" axis="date">28-Aug-97</TD>
<TD headers="a10 a12 a2">35.00</TD>
<TD headers="a10 a12 a3">109.00</TD>
<TD headers="a10 a12 a4">36.00</TD><TD></TD>
</TR>
<TR>
<TD>subtotals</TD><TD>131.25</TD><TD>218.00
</TD><TD>72.00</TD><TD>421.25</TD>
</TR>
<TR>
<TH>Totals</TH><TD>196.27</TD><TD>442.00<
</TD><TD>162.00</TD><TD>800.27</TD>
</TR>
</TABLE>
Rating System
Each guideline may be accompanied by a rating that describes its importance:
- [Required]
- Required, otherwise it will be impossible for some groups of users to understand the
page.
- [Recommended]
- Makes page easier to understand and use.
Style Sheets
Images and Image maps
Applets and Scripts
Audio and Video
Text, Symbols, Punctuation, Phrases, and Paragraphs
Lists and Outlining
Tables
Links
Frames
User-Input Forms
If All Else Fails...
If after best efforts, a page is still not accessible, provide a link to an alternative
page that is accessible, has equivalent information, and is maintained with the same
frequency as the inaccessible page.
Good Web Site Design Practices
- WAI Markup Guidelines Working Group Co-Chairs:
- Chuck Letourneau, Starling Access Services
Gregg Vanderheiden, Trace Research and Development
- Staff contacts:
- Judy Brewer and Daniel Dardailler
-
- Special thanks to the following people who have made major contributions to shaping the
content of this working draft.
- Harvey Bingham, Daniel Dardailler, Al Gilman, Jason White
-
- In addition we would like to thank the following people who have contributed through
review and comment.
- Judy Brewer, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Larry Goldberg, Jon
Gunderson, Phill Jenkins, Leonard Kasday, George Kerscher, Josh Krieger, Scott Luebking,
William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston
Enterprises), Masafumi Nakane, Charles Opperman, Mike Paciello, David Pawson, Michael
Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta
Treviranus, Steve Tyler, Jaap van Lelieveld
The original draft of this W3C working document is based on The Unified Web Site
Accessibility Guidelines compiled by the Trace R & D Center, University of Wisconsin
under funding from the National Institute on Disability and Rehabilitation Research
(NIDRR), U.S. Dept. of Education.
For a full list of Contributors to the Unified Guidelines is available at http://trace.wisc.edu/docs/html_guidelines/version7.htm
.
We would also like to thank the people listed in the References section below whose
works were used in the compilation of the unified guidelines on which this document is
based.
HTML 4.0 Recommendations.
Designing Accessible HTML Pages -- guidelines and overview documents
- Accessible Design for Users with
Disabilities. -- Sun Microsystems
- The Accessible
Web: Web Access Through Adaptive Technology -- Kevin Nguyen, University of Toronto
- All Things Web
- ALT text recommendations, and notes
on viewing situation -- A.J. Flavell, University of Glasgow
- Alternative Access to
the World Wide Web -- University of Toronto
- Any Browser Table Format --
Department of Missions, Abilene Christian University
- Best Viewed With Any Browser
-- Accessible Site Design
- Compatibility & Accessibility --
Towards the creation of an accessible, truly World-wide Web -- All Things Web
- Composing Good HTML -- James
"Eric" Tilton.
- Design Considerations: Readers
with Visual Impairments -- Arthur R. Murphy
- Designing Access to WWW Pages -
Alliance for Technology Access.
- Designing HTML Tables
to Work with HTML 2.0 Browsers -- Stanton McCandlish
- DO-IT HTML Guidelines
-- University of Washington
- Experiences Implementing Web
Accessibility Guidelines in IBM -- Phill Jenkins
- For Web Page Designers --
Microsoft
- GSA HTML Accessibility Guidelines --
Paul Fontaine
- Guide to Writing Accessible HTML
-- University of Toronto
- Hints for designing accessible
Websites -- Royal National Institute for the Blind
- IBM Web Design
Guidelines -- IBM Human Computer Interaction (HCI)
- Increasing Access
to World Wide Web Sites for Blind and Visually Impaired Computer Users -- Dena
Shumila, Jan Richards
- InfoUse Web Accessibility
Guidelines -- Jane Berliss, Lewis Kraus, Susan Stoddard
- LEVELLING THE ROAD AHEAD:
GUIDELINES FOR THE CREATION OF WWW PAGES ACCESSIBLE TO BLIND AND VISUALLY HANDICAPPED
USERS, Judith M. Dixon, Ph.D., Consumer Relations Officer, National Library Service for
the Blind and Physically Handicapped
- The Lynx Manifesto -- Dehanced
for Lynx
- Making Your Site Speech
Friendly -- Cathy Anne Murtha, Web Design and Access Specialist, Magical Mist
Creations
- NCSA Mosaic Access Page
- Nimble Document
Navigation Using Alternative Access Tools -- Jutta Treviranus, University of Toronto
- Starling Access Services Accessible Web Page
Design -- Chuck Letourneau
- Tables on non-table browsers
-- A.J. Flavell, Glasgow University
- Unified HTML Accessibility
Guidelines -- Previous version of this document
- Universal Accessibility
-- Government of Canada Internet Guide
- Universal Design of
WWW Pages -- a DO-IT (University of Washington) Brochure
- Universal Information Access on the
WWW (COCA)
- "Universal Specifications"
Accessibility Standards for Web Design -- New South Wales Attorney General's
Department
- Usability of Information and the
WWW -- UCLA Disabilities and Computing Program
- IBM Web Accessibility Guidelines
-- IBM Special Needs Systems
- World Wide Web
Access: Disability Discrimination Act Advisory Notes -- Australia
Copyright © 1998 W3C
(MIT,
INRIA,
Keio ), All Rights Reserved. W3C
liability,
trademark,
document
use and
software
licensing rules apply.