 | Making Web sites available to users with disabilities
David Mertz, Ph.D. (mertz@gnosis.cx)
Gnosis Software, Inc.
1 November 2000 Tips for making your Web pages and Web sites accessible to people with disabilities. First, how HTML markup lends itself to accessible pages. Second, find out how to avoid HTML coding "gotchas" that make your pages unnecessarily difficult to use for people with limited vision and mobility. We include an overview of free tools to use in evaluating and improving the accessibility of your site. Making your Web site friendly to -- or at least usable by -- persons with disabilities
expands your audience. In some cases doing so might be mandated by law,
and in every case, it is the right thing to do. Moreover, many of
the techniques used to make Web pages more accessible to the disabled also
wind up making Web pages that are just plain better for everyone. Think about how people access your pages
Disabled people employ a variety of tools and techniques to mediate
their access to the internet, depending on their differing abilities (as
well as their ability to pay for technologies). Blind or seriously visually
impaired people might use screen readers or Braille readers to translate
pages. People with less severe visual impairments might use screen magnifiers.
Other users might be unable to make color distinctions. People with neurological
and mobility limitations might have difficulty operating a mouse or
a keyboard; they might use special keyboards or spoken input to replace
those input devices. Those with hearing loss or deafness
can't use sounds included in pages. And yet, all of these people
are able to comprehend and use many types of information and functionality
on the Web ... and probably most of the actual information on your
Web site ... if you take the effort to allow them access. Technically, there's no reason why persons
with disabilities should not be able to read about your organization or
company, order products from you, complete forms, and launch server processes.
If your site closes these options to persons with disabilities, the only
reason is bad design on your part. Stick to the very good design of HTML
If you stick to the intention of HTML (that is, structural markup of hypertext
content, not graphic design) when you create HTML files, you are probably
90% of the way toward making your site accessible. For example, any technical
means of rendering a Web page includes some way of conveying concepts like:
"this is a paragraph," "this is a hyperlink," "this is a secondary heading."
Speech synthesizers, Braille, or three-inch tall onscreen fonts can all
render those basic structural elements of HTML. On
the other hand, if you try to make some text
look like a header by putting it in a certain font size, face, color,
and style but without actually marking it with an <h2> tag or the like,
alternate devices may not recognize and render the subhead correctly. Fortunately,
style sheets let you do both things at once: mark something as an HTML
header, but recommend that the browser render the header in a certain
way (but only if it makes sense for the browser and user). On the input side of things, HTML forms are equally well designed
for adaptation to devices for disabled users. Every entry field
identifies itself by the type of information it enters,
which means that it's possible to enter these abstract types of
information without a mouse, with special keyboards, or with voice recognition.
The only time that entry is likely to exclude disabled users is when you
go a long way out of the way to perform entry in ways that avoid the simple
HTML form methods -- such as JavaScript tricks, Java entry applications where
they are not needed, or special plug-ins (which are also likely to be platform-restricted). For example, some Web sites
have forms with a graphical "Submit" button, which can't be reached in
tab order, but only with a mouse click (it takes some extra work to program
this in the first place!). This needlessly excludes the blind and those
who cannot use a mouse -- and annoys sighted typists like the author
who prefer to keep their hands on the keyboard. Quite aside from disabled users, a wide variety of new ways of viewing
Web pages are growing in popularity. PDAs, cell phones, pagers, car-dashboard
displays, embedded devices, kiosks, and other types of unconventional Web-display
machines are likely not to support the same display, plug-in and input
assumptions you might make for conventional PCs. A lot of the issues relevant
to new devices are surprisingly similar to disability issues. And good
HTML works everywhere. Avoid common pitfalls in coding
When you aim to make your pages accessible to visually and mobility
impaired users, two key factors are how you handle images and how well
you enable keyboard access. Here are a few specific tips to help you avoid
the most common pitfalls.
Use the ALT attribute in IMG tags
The top "gotcha"
that causes inaccessible Web pages is probably the failure to use the ALT
attribute in <IMG> tags. The more important the information
conveyed by a graphic, the more important it is to have ALT text
associated with it. Help users skip unimportant images they can't see
If a graphic
is merely decorative or conveys a type of information not reducible to
verbal description, do your visually impaired users a favor so they don't
have to wade through "unknown graphic" descriptions: If the graphic is
purely decorative, use an empty string in the ALT attribute (that is, <img="pic1.png"
alt="">). If the visual information is complicated, at least let the
user know some context. A good rule of thumb for figuring out how to describe
images in ALT text: ask yourself "What would I say if I were reading
this page over a telephone?" For example, if it's a map of Cleveland,
describe it as "Map of Cleveland" -- sure, the user won't see the individual
streets, but at least the context is there. Use clear link descriptions
Poor link descriptions rank high
on the list of common pitfalls. Click this and Click Here
really don't do much to describe a link. Be considerate to all your users,
not just to the disabled ones. Use style sheets
In general, use style sheets as much as possible,
as long as they are accompanied by sensible structural markup. Most tags
give a pretty good description of what they are for; if you want to make
them look a certain way, go ahead, but just make sure to use the
right type of tag. Avoid absolute positioning
Don't rely too much on absolute
positioning of tables, frames, and so on. If your information requires having
a table exactly 420 pixels wide to make sense, it probably won't
make sense to many users, disabled or not. Make keyboard-friendly pages
Some users have difficulty
operating a mouse, and the mouse should really only exist as an alternative
to a keyboard. So make sure you can do everything in your pages from a
keyboard without reaching for a mouse. JavaScript is great for validation
of forms, but don't use special tricks that make forms hard (or impossible)
to operate without a mouse.
Test your pages
A good way to screen for accessible Web pages is to make sure that
they contain valid HTML. In many cases, popular general-purpose browsers
make allowances for improper HTML; the browser tries to render something
no matter what flaws exist in the HTML for the page. Although this forgiving
behavior probably aids most users, you can't count on special-purpose browsers
to be as sophisticated at inferring meaning from bad markup; erroneous
inference is likely to create more difficulties for disabled users than
for the average user. Many HTML authoring tools include syntax-checking
capabilities, which usually work well. Or try a free alternative to commercial
packages: Weblint, for example, does batch processing of syntax checking
(see Resources). Try these tools for testing
A couple of good tools help automate the improvement of HTML syntax
problems. Microsoft Office tools don't do a stellar job of producing good
HTML -- in terms of syntax or accessibility. The tool demoroniser (see
Resources for links to all the tools mentioned)
helps correct some of these shortcomings.
Another tool, tidy,
is generally useful in improving HTML structure. Tidy also includes
options for reducing the size of HTML files and for improving them stylistically.
Once your pages have passed syntax checks, try using it from a browser
with good support of HTML that lacks (by intention) a lot of GUI accoutrements.
The homonymous browsers Lynx and Links
are excellent places to start. These browsers render almost all "good"
HTML (including frames and form entry), but do it in text-mode, and mostly
using keyboard input. If you find your Web site hard to work with using
one of these browsers, chances are very good that disabled users will have
trouble with your site; the inverse is often true also. (If nothing else,
a screen-reader device can easily process a Lynx or Links text screen). After you do your own testing using a text-mode browser, try running
your pages through CAST's Bobby.
This free tool does a wonderful job of complaining about almost everything
that might make your pages unfriendly to disabled users. The online version
of Bobby examines a specific URL you submit, but you can download a Java
language version that checks a whole site. A lot of the advice Bobby gives
is just that: advice. You still must use your common sense in evaluating
Bobby's suggestions, and a lot of the suggestions explicitly say so. Resources About the author
David Mertz has been consumed with ressentiment since the introduction of the <blink> tag in Netscape 2.0. David may be reached at mertz@gnosis.cx; his life pored over at http://gnosis.cx/publish/. Suggestions and recommendations on these tips and on past or future columns are welcomed. |
| |
