Making the Web more accessible for users with various disabilities is to a great extent a matter of using HTML the way it was intended: to encode meaning rather than appearance. As long as a page is coded for meaning, it is possible for alternative browsers to present that meaning in ways that are optimized for the abilities of individual users and thus facilitate the use of the Web by disabled users.

Before discussing the difficulties disabled users may have in accessing Web information, we should note that online information provides many benefits compared with printed information: it is easy for people with poor eyesight to increase the font size, and text-to-speech conversion for blind users works much better for online text than for print. Indeed, many disabled users are empowered by computers to perform tasks that would have been difficult for them with traditional technology. For an example, see a New York Times article about one of their blind subscribers who now reads the newspaper by going to the Website in Lynx. You can even hear how the article sounds through a screen reader - note how reading is done at very high speed (access to the Times site requires registration).

The National Institute on Disability and Rehabilitation Research's Rehabilitation Engineering Research Center for Access to Computers and Information Systems has published a comprehensive set of guidelines for accessible Web design. I refer you to these guidelines for more detail and will focus on broader issues in this column.

Visual Disabilities

The most serious accessibility problems given the current state of the Web probably relate to blind users and users with other visual disabilities since most Web pages are highly visual. For example, it is quite common to see combinations of background and foreground colors that make pages virtually unreadable for colorblind users.

Textual pages are reasonably easy to access for blind users since the text can be fed to a screen reader. Long pages are problematic since it is harder for a blind user to scan for interesting parts than it is for a sighted user. In order to facilitate scanning it is recommended to emphasize the structure of the page by proper HTML markup: use <H1> for the highest level heading, <H2> for the main parts of the information within the <H1>s, and <H3> and lower levels for even finer divisions of the information. By doing so, the blind user can get an overview of the structure of a page by having the <H1>s and <H2>s read aloud and can quickly skip an uninteresting section by instructing the screen reader to jump to the next lower-level heading.

Most people already know about the use of ALT attributes to provide alternative text for images, though there are still many Web pages without ALTs. Some accessibility specialists advocate so-called described images, where text is provided to verbalize what a seeing user would see. For example, the Web Access Symbol shown above might be described as "a glowing globe with a keyhole." In my opinion, such literal descriptions are fairly useless for Web pages unless the user is an art critic. I much prefer utility descriptions that verbalize the meaning or role of the image in the dialogue: what is the image intended to communicate and what will happen if it is clicked?

All imagemaps should be client-side and should use ALT attributes for each of the link options so that a user who cannot see the image can have descriptions of the destination read as he or she moves the cursor around. There are still some browsers that only support server-side imagemaps, but client-side imagemaps are clearly the way to go in the future. Sighted users would also benefit from having ALT attributes displayed in the appropriate parts of the picture rectangle if they didn't want to wait for the image file to download, and it is rather obvious that an ALT attribute can describe the meaning of the hyperlink destination in much more user-friendly terms than a weird URL. In general, it is often the case that design rules that may have been intended to help users with disabilities end up being of benefit to all users.

In addition to completely blind users, there are many users who can see but have reduced eyesight. These users typically need large fonts which is a standard feature of most Web browsers. To support these users, never encode information with absolute font sizes but use relative sizes instead. For example, when using Style Sheets, do not set the font-size attribute to a number of points or pixels but set it to a percentage of the default font size. By doing so, your text will grow or shrink as the user issues "text larger" or "text smaller" commands and the initial appearance of the page will match the user's preferences.

Full support of users with reduced eyesight would require pages to look equally well at all font sizes. Doing so is often not practical, and it might be acceptable to make pages look slightly worse at huge font sizes as long as the basic page layout will still work. It is recommended to test pages with the default font set to 10, 12, and 14 point to ensure that the design is optimal for these common font sizes and then to make additional checks with default fonts of 18 and 24 points to make sure that the design still works at these accessibility-enhancing sizes.

Auditory Disabilities

People who are deaf or have other auditory disabilities rarely have problems on the Web since sound effects are usually totally gratuitous. The usability of a site almost always stays the same when the sound is turned off. With the trend toward more multimedia this is not going to remain the case, though. In particular, transcripts should be made available of spoken audioclips and videos should be made available in versions with subtitles (which will also benefit users who are not native speakers of the language used in the video).

Motor Disabilities

Many users have difficulty with detailed mouse movements and may also have problems holding down multiple keyboard keys simultaneously. Most of these issues should be taken care of by improved browser design and should not concern content designers except for the advice not to design imagemaps that require extremely precise mouse positioning. Client-side imagemaps will work even for users who cannot use a mouse at all: the browser should be able to move through the links under keyboard control.

Cognitive Disabilities

By cognitive disabilities, I do not refer to below-average intelligence, though many sites will have to support such users as broader segments of the population go online. Currently, the Internet is so difficult to use that users need to be fairly intelligent to figure it out, but even these smart users sometimes have cognitive disabilities. Unfortunately, cognitive disabilities have not been the focus of as much user interface research as physical disabilities, so I only have a few examples.

People vary in their spatial reasoning skills and in their short-term memory capacity. Programmers and graphic designers tend to get uncommonly high scores on tests of spatial reasoning skills and are therefore good at visualizing the structure of a Web site. Similarly, young people (i.e., most Web designers) certainly have better memories for obscure codes (e.g., a URL) than older people. It is safe to assume that most users will have significantly greater difficulty navigating a Web site than its designers have. Simplified navigation helps all users, but is a required enabler for users at the opposite extreme of the scales. People who have difficulty visualizing the structure of an information can be helped if the site designers have produced such a visualization for them in the form of a sitemap; they would be further aided if the browser updated the display of the sitemap with the path of the navigation and the location of the current page.

Users with dyslexia may have problems reading long pages and will be helped if the design facilitates scanability by proper use of headings as noted above. Selecting words with high information content as hypertext anchors will help these users, as well as blind users, scan for interesting links (no "click here", please).

Most search user interfaces require the user to type in keywords as search terms. Users with spelling disabilities (and foreign-language users) will obviously often fail to find what they need as long as perfect spellings are required. A first suggestion is to for search engines to include a spelling checker; other ideas from advanced information retrieval like query-by-example and similarity search can also help these users (and benefit everybody else at the same time).

A final note: I realize that my own pages do not follow every last guideline. I have a very pragmatic approach to usability and may cut a corner in order to meet deadlines or satisfy other design trade-offs. There is a great difference between less-than-perfect design and completely reckless design, though.

Share this article: Twitter | LinkedIn | Google+ | Email