Making websites more accessible to persons with disabilities (part II)
David Mertz, Ph.D.
Tips on making your web pages and web sites disabled- accessible. Part I gives a general introduction to disability issues, and discusses the structural markup at the heart of HTML. Part II discusses specific HTML coding "gotchas" that make your pages unnecessarily difficult for vision and mobility limited people to use; part II also provides an overview of free tools to use in evaluating and improving the accessibility of your site.
In the first part of these tips we made some general remarks on the abilities of disabled web users, and about the special technical means used to present web pages to such users. Also in the first part, we introduced the idea that focussing on structural rather than visual markup alleviates many accessibility problems. In this second installment we go on to discuss specific coding "gotchas" and present some tools that help in ensuring accessibility for web pages.
Specific Coding Techniques
The top "gotcha" in making 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. Even if
the graphic is merely decorative or conveys a type of
information not reducible to verbal description, it is
unnecessarily cumbersome for visually impaired users to wade
through "unknown graphic" descriptions. If the graphic is
purely decorative, use an empty string in the ALT attribute,
<img="pic1.png" alt="">. If the visual information is
complicated, at least let the user know some context. A good
guideline is to ask yourself "what would I say if I were
reading this page over a telephone?" For example, if it is a
map of Cleveland, describe it as "Map of Cleveland"--sure the
user won't see the individual streets, but at least the context
Another "gotcha" is poor link descriptions. "This" and "Click Here" really do not do much to describe a link. Be considerate to all your users, not just to the disabled ones.
In general, you are best off using 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 the are the right type of tag.
Another good guideline is to avoid relying too much on absolute positioning of tables, frames, etc. If your information requires having a table exactly 420 pixels wide to make sense, it is probably going to fail to make sense to a lot of users, disabled or not.
Testing Your Pages
A good "pre-screen" of a web page is making sure that it
contains valid HTML. In many cases, popular general-purpose
browsers will make allowances for improper HTML, and try to
render something no matter what. Although this is probably
reasonable behavior for these browsers, special-purpose
browsers are likely to be less sophisticated in inferring
meaning from bad markup, and erronous inference is likely to
create more difficulties for disabled users. Many HTML
authoring tools include syntax checking capabilities, which are
usually of good quality. A free alternative to commercial
packages is to use
Weblint for batch processing of syntax
There are a couple good tools to help automate the improvement
of HTML syntax problems. Microsoft Office tools have a habit
of producing particularly bad HTML--in terms of both
syntax and accessibility. The tool
demoroniser helps correct
some of MS' mistakes. The tool
tidy is generally useful in
improving the well-formedness of HTML;
tidy also includes
options for reducing the size of HTML files and for
improving them stylistically.
Once your pages have passed syntax checks, a good first
practical test of your web site is to try using it on a browser
with good support of HTML, but that lacks (by intention) a lot
of GUI accouterments. The homonymous browsers
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; and the inverse is mostly true also (if
nothing else, a screen reader can easily process a
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 disabled-unfriendly. Their online version will examine a specific URL, but you can download a Java version that will check a whole site. A lot of the advice Bobby gives is just that: advice. It is still necessary to use your common sense in evaluating suggestions, and even a lot of Bobby's suggestions explicitly say as much.
An excellent starting point for many accessibility issues is The Disability Rights Activist. This site provides links to laws, guidelines, and downloadable software:
The W3C Web Accessibility Initiative provides links to a helpful collection of (generally free) tools for evaluating web-sites:
The Bobby tool is discussed in the main text, and is the premier tool in evaluating accessiblity:
Weblint syntax and style checker:
"Diversity Compliance in Web Design" is Tom Christiansen's site
demoroniser and other tools for web page
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 email@example.com; his life pored over at http://gnosis.cx/publish/. Suggestions and recommendations on this, past, or future, columns are welcomed.