Making Web Applications Accessible
Stephanie Bodoff, Amy Roh
Problem Description
The dictionary defines accessible as easily approached or
entered. For people with disabilities such as vision or hearing
impairment, web applications and the user agents (browsers) through
which the applications are invoked are often not very accessible.
They may not support the use of interaction technologies other
than the mouse, or they may contain artifacts, such as images, that
cannot be perceived by someone with a visual impairment.
To be accessible, web pages and applications must support assistive
technologies. Assistive technologies are useful for people
with disabilities. Assistive technologies provide
specialized input and output capabilities.
Examples of assistive technologies include the following:
- Screen readers, which enable vision-impaired users to navigate
through applications, determine the state of controls, and read text
using text-to-speech conversion
- Screen magnifiers, which enlarge the screen display
- Voice command and control, which enables users to control the
system by using spoken commands
- Transcripts, which are text equivalents of audio presentations
- Captions, which provide text descriptions of spoken language,
events, and scenes
U.S. government purchases of information technology are required by
federal law to satisfy certain requirements that guarantee
accessibility. Section 508 requires that Federal agencies'
electronic and information technology be accessible to people with
disabilities. In addition to the U.S. government requirements,
the World Wide Web consortium (http://w3c.org)
web
accessibility initiative has developed a series of guidelines and
technique recommendations (see http://w3c.org/TR/WCAG10-TECHS/
)
to help web developers create accessible web sites and applications.
The following sections summarize the U.S. government and WWW
consortium recommendations for web content accessibility. The
sections are organized around themes relating to content (for example,
multimedia) and HTML page structuring mechanisms (for example, frames).
A text-only page, with equivalent information or functionality,
should be provided when compliance to the recommendations described
here cannot be accomplished in any other way. The content
of the text-only page should be updated whenever the primary page
changes.
Solution
The following table summarizes web technologies and recommendations for
using them. More detailed recommendations and examples are
provided in each
section.
Web Technology |
Recommendation |
<img> tags
|
Provide alt text for everything.
Use an empty alt for spacing images.
|
Flickering elements
|
Avoid causing the screen to flicker with a frequency greater
than 2 Hz and lower than 55 Hz.
|
Color
|
Some other method of identification, such as
text labels, must be used in combination with color.
|
Style sheets
|
Make sure that the application can be navigated with
style sheets
turned off, and that this does not interfere with user-defined
style sheets.
|
Image maps |
With client-side image maps, each active region can have its
own alternative text. Client-side image maps are preferred over
server-side image maps because determining links on the server-side is
difficult for non-browser clients. Use a redundant text link to
provide access to the page with a server-side image map. |
Tables
|
Use the header and id
attributes of the <th> and <td>
tags,
or use the scope attribute of the <th>
and <td> tags.
|
Frames |
Use the title attribute, if supported, or label
frames that include text within the body of each frame with labels that
clearly identify
the
frame. |
Scripting languages |
Provide alternative text with a script that conveys an
accurate message as to what is being displayed by the script. |
Forms
|
Use the <label> tag to
describe
a form control. The description should appear adjacent to the
control.
|
Navigational links
|
Provide a jump link that enables users to skip
repetitive navigational links.
|
Timed response
|
Alert users with a prompt and give them sufficient response
time. Make sure the forms are not too large.
Increase time-out if forms cannot be shortened.
|
Referencing non-HTML content
|
Provide a link to a plug-in that complies with
accessibility requirements.
|
Content
Non-Text Information
A non-text element is an image, graphic, audio clip, or other feature
where a picture or sound alone conveys meaning. Examples include
buttons, checkboxes, pictures, and embedded or streaming audio.
To be accessible, every non-text element must have a text
equivalent.
A text equivalent means adding words to represent the purpose of a
non-text element. For example, when an
image indicates a navigational action such as “move to the next screen”
or “go back to the top of the page,” the image must be accompanied
by text that states the purpose of the image, in other words,
what the image is telling you to do. When graphics or sounds are
used to render page content, those components must have a text
description accompanying them.
The text information associated with a non-text
element should, when possible, communicate the same information
as its associated element. For example, when an image indicates
an action, the action must be described in the text. The types
of non-text elements requiring actual text descriptions are limited
to those elements that provide information required for comprehension
of content or those used to facilitate navigation. Web page
authors
often use transparent graphics for spacing. Adding a text
description to these elements would produce unnecessary clutter for
users of screen readers. For such graphics, an empty alt
attribute
is appropriate. For example:
<img src=”transparent.gif” alt=” “>
There are several ways of providing textual information so that it can
be recognized by assistive technology devices. For instance, the <img>
tag can accept an alt
attribute that enables a web
designer to include text that describes the picture directly in the <img>
tag. For example:
<img src="pictureofme.jpg" alt="this is a picture of me">
Similarly, the <applet>
tag
for Java[TM] applets also accepts an alt attribute, but it only works
for browsers that provide support for Java. Often, users
with slower Internet connections will turn support for Java applets
off. A better alternative for providing textual descriptions is
to simply include the alternative text between opening and closing
<applet>
or <object>
tags.
For instance, if a web designer wanted to include an applet
called MyCoolApplet
in a web page, along with a
description that the applet shows a stock ticker displaying the current
price of
various stocks, the following code could be included:
<applet code="MyCoolApplet.class" width="200", height="100">
This applet displays current stock prices for many popular stocks
</applet>
Finally, another way of providing a textual
description is to include it in the page in the surrounding context:
Below is a picture of me during my great vacation!<p>
<img src="pictureofme.jpg">
When a web site includes multimedia information, it should provide
alternative, accessible sources of the information. When audio
presentations are available on a web page, a
text equivalent of the audio must be provided to allow people who
are deaf or hearing-challenged to comprehend the content. If the
audio is part of a multimedia presentation that is both audio and
video, the audio portion should be captioned. When an audio
portion of a multimedia production is captioned, the captioning should
be synchronized with the audio. Synchronized captioning is
required so that someone reading the captions can watch the speaker and
associate relevant body language with the speech.
If a web site has an audio stream only, it does
not have to be captioned. However, since audio is a non-text
element, a text equivalent (that is, a transcript) must be
available. Similarly, a web slide show presentation does not need
to have an audio description accompanying it, but does require text
alternatives to be associated with any graphics.
Flickering Elements
Some individuals with photosensitive epilepsy can experience seizures
that are
triggered by displays which flicker, flash, or
blink, particularly if the flash has a high intensity and is within
certain frequency ranges. Pages should be designed to avoid
causing the screen to flicker with a frequency greater than 2 Hz and
lower than 55 Hz.
Flashing or flickering elements are usually added through technologies
such as animated GIFs, Java applets, or
third-party plug-ins or applications. Java applets and
third-party
plug-ins can be identified by the presence of <applet>
or <object>
tags. Animated GIFs are images
that download in a single file like ordinary image files, but have
content that changes over short periods of time. Like other
images,
however, they are usually incorporated through the use of the <img>
tag.
Structuring Mechanisms
Color
When colors are used as the sole method for identifying screen elements
or controls, persons who are color-blind, blind, or have low vision may
find the web
page unusable.
Using color to enhance identification of important features is allowed.
However, some other method of identification, such as text
labels, must be combined with the use of color. Beware of using
color not only to indicate emphasized text, but also to indicate
an action. For example, a web page that directs a
user to “press the green button to start” should also identify the
green
button in some other way than simply by color.
There are two simple ways to test whether a web page
meets this requirement: by either viewing the
page on a black and white monitor, or by printing it out on a black and
white printer. Both methods will quickly show if the removal of
color affects the usability of the page.
Style Sheets
Style sheets allow web site designers to make web pages with consistent
appearance that can be easily updated. For instance, without
style sheets, making headings appear in large font while not affecting
the surrounding text requires separate tags hidden in the document to
control font size and boldface. For this reason, a user with low
vision may use a style sheet that renders all text in an extra large
font with white characters on a black background. If designers
set up their pages to override user-defined style sheets, people with
disabilities may not be able to use those pages. For good access,
therefore, it is critical that designers ensure that their web pages do
not interfere with user-defined style sheets.
Image Maps
An image map is a picture on a web page that provides different
“links” to other web pages, depending on where a user clicks in the
image. There are two basic types of image maps: client-side image maps
and
server-side image maps.
With client-side image maps, each active
region in a picture can be assigned a link that specifies which web
page to retrieve when a portion of the picture is selected.
Each active region can include its own alternative text, just
like a
picture can include alternative text. When a web browser
retrieves a
specific set of instructions from a client-side image map, it also
receives all the information about what action will happen when a
region of the map is selected. For this reason, client-side image
maps, although graphical in nature, can display the links related to
the map in a text format that can be read with assistive technology.
Client-side image maps are preferred over server-side image maps
except where the regions cannot be defined with an available geometric
shape.
With a server-side image map, clicking within
a region only specifies the coordinates within the image. The
selected URL must be deciphered by the computer serving the web page.
When a web page uses a server-side image map to present the user
with a selection of
options, browsers cannot indicate to the user the URL that will be
followed when a region of the map is activated. Therefore, a
redundant text link is necessary to provide access to the page for
anyone
not able to see or accurately click within the map.
Tables
Large tables of data present tremendous problems for accessibility.
Screen readers can get disoriented inside a table because it may
be impossible to associate a particular cell that a screen reader is
reading with the corresponding column headings and row names for that
cell. For example, assume that a salary table includes the salaries for
employees by grade and step. Each row in the table might
represent
a grade scale, and each column might represent a step. Thus,
finding
the salary corresponding to a Grade 9, Step 5 might involve finding the
cell in the ninth row and the fifth column. For a salary chart of
15 grade scales and 10 steps, however, the table has at least 150
cells. A user at the 7th row and 8th column might
have some difficulty using the table.
When information needs to be arranged in a table format to be properly
comprehended, the information should be laid out using appropriate
table tags as opposed to using a preformatted table with
the <pre>
tag. Row and column headers should be
identified for data tables.
There are several ways to make HTML tables readable with assistive
technology. One way is to use the header and ID attributes of the <th>
and <td>
tags to associate a cell’s contents with
the column heading. Another way is to use the scope
attribute of the <th>
and
<td>
tags to associate columns and rows with cells
located in those columns or rows. For example:
<table border="1" summary="This table charts
...">
<caption>Cups of coffee consumed by each
senator.</caption>
<tr>
<th
scope="col">Name</th>
<th
scope="col">Cups</th>
<th scope="col">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>
</tr>
...
</table>
In JavaServer Faces applications, you would use a dataTable
tag to generate the same table:
<h:dataTable id="senators" value="#{senators}"
var="senator">
<h:column >
<f:facet
name="header">
<h:outputText
value="Name" />
</f:facet>
<h:outputText size="24"
value="#{senator.name}" >
</h:column>
<h:column>
<f:facet name="header">
<h:outputText
value="Cups"/>
</f:facet>
<h:outputText size="24"
value="#{senator.cups}" >
</h:column>
...
</h:dataTable>
Note – The renderer for the dataTable
tag automatically
generates a scope
attribute in <th>
tags.
Establishing an association between data cells and header cells is more
challenging in data tables that have two or more logical levels of row
or column headers. Table 1.1 lists travel expenses at two
locations, San Jose and Seattle, by date and category (meals, hotels,
and transport).
Table 1.1 Travel Expense Report
|
Meals
|
Hotels
|
Transport
|
Subtotals
|
San Jose
|
|
|
|
|
24-Aug-2004
|
37
|
112
|
45
|
|
25-Aug-2004
|
27
|
112
|
45
|
|
Subtotals
|
64
|
224
|
90
|
378 |
Seattle
|
|
|
|
|
26-Aug-2004
|
95
|
109
|
36
|
|
27-Aug-2004
|
35
|
109
|
36
|
|
Subtotals
|
130
|
218
|
72
|
420
|
Totals
|
195
|
442
|
162
|
798
|
In tables with multiple levels, you should use methods to provide an
association between a header and its related information. The following
example shows how to create categories within a table using the axis
attribute.
<TABLE>
<CAPTION>Travel Expense Report</CAPTION>
<TR>
<TH>
<TH id="header2" axis="expenses">Meals
<TH id="header3" axis="expenses">Hotels
<TH id="header4" axis="expenses">Transport
<TD>Subtotals</TD>
<TR>
<TH id="header6" axis="location">San Jose
<TH> <TH> <TH> <TD>
<TR>
<TD id="header7" axis="date">24-Aug-04
<TD headers="header6 header7 header2">37
<TD headers="header6 header7 header3">112
<TD headers="header6 header7 header4">45
<TD>
<TR>
<TD id="header8" axis="date">25-Aug-04
<TD headers="header6 header8 header2">27
<TD headers="header6 header8 header3">112
<TD headers="header6 header8 header4">45
<TD>
<TR>
<TD>Subtotals
<TD>64 <TD>224 <TD>90
<TD>379
<TR>
<TH id="header10" axis="location">Seattle
<TH> <TH> <TH> <TD>
<TR>
<TD id="header11" axis="date">26-Aug-04
<TD headers="header10 header11 header2">95
<TD headers="header10 header11 header3">109
<TD headers="header10 header11 header4">36
<TD>
<TR>
<TD id="header12" axis="date">27-Aug-04
<TD headers="header10 header12 header2">35
<TD headers="header10 header12 header3">109
<TD headers="header10 header12 header4">36
<TD>
<TR>
<TD>subtotals
<TD>130 <TD>218 <TD>72
<TD>421
<TR>
<TH>Totals
<TD>195 <TD>442 <TD>162
<TD>798
</TABLE>
Although highly recommended by some as a way of
summarizing the contents of a table, the summary attribute of
the <table>
tag is not sufficiently supported by
major assistive technology manufacturers to warrant recommendation.
Therefore, web developers should place summaries either adjacent
to tables or in the body of the table, using the <caption>
tag. Web developers should not use
table summaries as an alternative to making the contents of their
tables accessible.
Another problem with tables that is frequently encountered by users of
screen readers and other types of assistive technologies arises when
long text elements such as phrases or sentences are placed within a
table for formatting purposes. When the text “wraps” within a
table cell, it becomes difficult or impossible for users of some
assistive technologies to make sense of it. To avoid this problem, web
developers who want to make their pages completely accessible to
persons with disabilities should avoid using tables for
formatting text.
Frames
When a web site uses frames, often only a single frame will update with
information while the other frames remain constant. Because using
frames gives the user a consistent portion of the screen, they are
often used for navigational toolbars for web sites. They are also often
faster because only a portion of the screen is updated instead of the
entire screen. Frames can be an asset to users of screen readers and
other assistive technology if the labels on the frames are explicit.
Labels such as top, bottom, or left, provide few clues as to what is
contained in the frame. However, labels such as “navigation bar” or
“main content” are more meaningful and facilitate frame identification
and navigation.
The most obvious way to label frames is to include text within the body
of each frame that clearly identifies the frame. For instance, in the
case of the navigation bar, you could put words such as Navigation
Links at the beginning of the contents of the frame to let all users
know that the frame depicts navigational links. An additional approach
is to include a description of the frame’s function in the frame tag’s
title attribute. Although not currently supported by major
manufacturers of assistive technology, the title attribute is
part of the HTML 4.0 specification and was intended to let web
developers include a description of the frame as a quote-enclosed
string. Here is an example of a
frameset containing a table of contents and main content frames:
<frameset ... >
<frame title="Table of Contents"
src="TOC.html" name="toc" />
<frame title="Main Content"
src="Front.html" name="main" />
</frameset>
Scripting Languages
A screen reader will often read the content of a script in a
meaningless jumble of numbers and letters. Because of this, web
application developers should include text with a script that
conveys an accurate message as to what is being displayed by the script.
For instance, if a web page uses a script only to fill the contents of
an HTML form with basic default values, the web page will likely be
accessible, because the text inserted into the form by the script may
be
readable by a screen reader. However, if a web page uses a script to
create a graphic map of menu choices when the user moves the pointer
over an icon, the web site designer should include redundant text
links matching the menu choices because functional text for each
menu choice cannot be rendered to the assistive technology. Determining
whether a web page meets this requirement may require careful testing
by web site designers, particularly as both assistive technology and
the JavaScript[TM] standard continue to evolve.
Forms
HTML forms are a popular interaction mechanism on the web. Gathering
information, permitting a person to apply
for services, and making purchases are just a few of the many
applications of forms.
At present, the interaction between form controls and screen readers
can be unpredictable, depending upon the design of the page containing
these controls. Some developers place control labels and controls in
different table cells. Others place control labels in various locations
in various distances from the controls themselves, making the response
from a screen reader less than accurate many times. You should use the <label>
tag to describe a form control, and the description should appear
adjacent to the control:
<label for="username">Input User Name:
</label>
<input type="text" name="j_username"
size="16" id="username"/>
The JavaServer Faces outputLabel
tag is used to attach a
label to a specified input field. In this example, an outputLabel
tag renders the label of the userName
input field:
<h:inputText id="userName" />
<h:outputLabel for="username"
<h:outputText id="userNameLabel"
value="Input User Name: " />
</h:outputLabel>
Navigation Links
Web page developers routinely place a number of site-specific
navigational links at a standard location—often across the top, bottom,
or side of a page. When
a visitor returns to a web page or site to
view the contents of that particular page instead of selecting a
navigation link to go to another page, the visitor may simply look past
the
links and begin reading wherever the desired text is located. For
visitors that use screen readers or other types of assistive
technologies,
however, it can be tedious to wait for the assistive technology to
announce
each of the standard navigational links before getting to real content.
Therefore, web page designers should provide a mechanism, such as a
jump link, that enables users to skip repetitive navigational links.
Here is
an example of a jump link:
<a href="#skip" title="Skip navigation
links"></a>
<table width="550" summary="layout">
<tr>
<td align="left" valign="center">
<a accesskey="d"
href="download.html">Download</a>
</td>
<td align="center" valign="center">
<a accesskey="p"
href="prev.html">Previous Page</a>
<a accesskey="n"
href="next.html">Next Page</a>
</td>
<td align="right"
valign="center">
<a accesskey="s"
href="search.html">Search</a>
</td>
</tr>
</table>
<a name="skip"></a>
Timed Responses
Web pages can be designed with scripts so that the web page disappears
or expires if a response is not received within a specified amount of
time. Sometimes, this technique is used for security reasons or to
reduce the demands on the computer serving the web pages. A disability
can have a direct impact on the speed with which a person can read,
move around, or fill in a web form. For instance, someone with
extremely low vision may be a slower-than-average reader. A page may
time out before the reader is able to finish reading it. Many forms,
when they time out automatically, also delete whatever data has been
entered. The result is that someone who is slow to enter data cannot
complete the form. For this reason, when a timed response is required,
the user should be alerted through a prompt and given sufficient time
to
indicate whether additional time is needed. Making sure the forms
are not too large, and having an option to save the data for later,
with
alerting users about the remaining time, are also helpful.
Referencing Non-HTML Content
Most web pages are encoded in standard HTML. However, links embedded in
many HTML pages point to proprietary file formats such as Real Audio,
Flash, or PDF. Such formats exist for transmitting and displaying
special content, such as multimedia or very precisely defined
documents. Because these file formats are proprietary, web browsers
cannot ordinarily render them.
Add-on programs or “plug-ins” can be downloaded
and installed on the user’s computer that make it possible for
their web browsers to display or play the content of these files. All
web pages that provide such content should also provide a link to a
plug-in that complies with the recommendations described in preceding
sections.
Plug-ins can usually be detected by examining a
page’s HTML for the presence of an
<object>
tag. Some plug-in manufacturers, however, may require the use of
proprietary tags.
Like plug-ins, applets can also be identified by the presence of an <object>
tag in the HTML source for a web page. Also, an <applet>
tag might also signal the inclusion of an applet in a web page.
References
The following resources are recommended for further information on
this topic:
© Sun Microsystems 2005. All of the material in The
Java BluePrints Solutions Catalog is copyright-protected
and may not be published in
other works without express written permission from Sun Microsystems.