Alertbox
Oct. 1996 Disabled access
|
useit.com
Alertbox
Oct. 1996 Disabled access
|
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.
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.
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.
See also: List of other Alertbox columns, including comments on the Web Consortium's official accessibility guidelines