Chapter 6. Accessibility

In general, to make web content accessible to everyone, there is a greater reliance on text and document structure. That is not to say that sites need to be text-only and media-free in order to be accessible to everyone. The goal is to create sites that (as the WAI puts it) "transform gracefully" when accessed via alternative methods. Some simple examples include providing alternative text for images that can be read if the image can't be viewed, or providing a text transcript of an audio track if it can't be heard. It also requires the proper use of HTML markup for document structure and Cascading Style Sheets for presentation.

Web Content Accessibility Guidelines 1.0 is a thorough and highly detailed document. What follows here is a summary of the guidelines to point you in the right direction. For the details, read the original document online at http://www.w3.org/TR/WAI-WEBCONTENT/.

Guideline 1: Provide equivalent alternatives to auditory and visual content.

When providing text alternatives to images, video, and audio, be sure that the text has the same function and purpose as the media it is replacing. For example, if there is a graphic of an arrow that is used as a link to the top of the page, the alternative text should read "go to the top of the page," not "arrow." In addition, consider providing an auditory track (like a narrative explanation) for video media whose meaning is lost if it can't be seen.

Guideline 2: Don't rely on color alone.

Make sure your site is usable in black and white and colors contrast sufficiently.

Guideline 3: Use markup and style sheets and do so properly.

Great strides have been made in HTML and CSS technology to aid in accessibility, but they are only successful if they are used consistently to separate style from content.

Guideline 4: Clarify natural language usage.

Identify the language of the document and mark up exceptions such as foreign words, abbreviations, and acronyms. This makes it easier for speech devices and other assistive technologies to interpret the content.

Guideline 5: Create tables that transform gracefully.

The WAI recommends that tables be used for tabular data only. In addition, taking advantage of the more descriptive HTML 4 table markup can help users with disabilities navigate through complex tables. It is also useful to provide a summary of the table's contents in the <table> tag.

Guideline 6: Ensure that pages featuring new technologies transform gracefully.

Make sure that your page still works and makes sense without style sheets, JavaScript, applets, or other objects added to the page.

Guideline 7: Ensure user control of time-sensitive changes.

Any scrolling, blinking, or otherwise moving object should be able to be paused or stopped. Audio should be able to be paused or turned off as well.

Guideline 8: Ensure direct accessibility of embedded user interfaces.

This means that if you create your own site interface using a Java applet or Flash, the interface should follow basic accessibility guidelines.

Guideline 9: Design for device-independence.

Keep in mind that users may be using a variety of input devices, such as a mouse, keyboard, voice, head wand, or other device. Take advantage of technologies that allow shortcuts to links and elements on the page.

Guideline 10: Use interim solutions.

The W3C is developing technologies that will be useful just while older browsers are catching up to the current HTML 4.0/CSS2 way of doing things. These interim solutions ensure that older browsers operate correctly.

Guideline 11: Use W3C technologies and guidelines.

This one seems like a given, but be sure to use the current technologies since they have been developed and reviewed thoughtfully to support accessibility.

Guideline 12: Provide context and orientation information.

Provide clear labels for frames, sections of the page, and any complex page structure that requires extra explanation. Keep in mind what it would be like to use your site if you couldn't see it.

Guideline 13: Provide clear navigation mechanisms.

Take measures to ensure your site is easy to navigate, including clearly identified links, a site map or index, and consistent navigation.

Guideline 14: Ensure documents are clear and simple.

Everyone benefits from web pages that are laid out clearly and use simple language.

WAI has also compiled a list of very practical applications of each of these principles in a document called Techniques for Web Content Accessibility Guidelines 1.0. It provides specific techniques that address each of the checkpoints outlined in the general guidelines document. It also acts as a gateway to a number of other resources that describe the specifics on how HTML, CSS, and other core technologies address accessibility.

• Avoid using images for text and information.

• Provide alternative text for all images (via the <img> tag's alt or longdesc attribute). Make the alternative text rich and meaningful. Adding alt text should be standard procedure for all web page creation; in fact, in the new HTML 4.0 specification, the alt attribute is now a required part of the <img> tag. (See Chapter 9, "Structural HTML Tags" for more information.)

• Add periods at the end of alt text so a speech device can locate the logical end of the phrase.

• When linking a graphic, provide a caption under it that also serves as a text link.

• Always provide text link alternatives for imagemaps.

• Offer a text-only version of the whole site from the home page.

• Provide transcripts or descriptions of audio clips to make that content accessible to those with hearing impairments.

• Provide alternative mechanisms for online forms, such as a text-based order form or a phone number for personal assistance.

• Avoid the <blink> tag, which is said to wreak havoc with Braille and speech displays.

• Be aware that misuse of HTML structural tags for presentation purposes (such as using the <blockquote> tag purely to achieve indents) hinders clear communication via a speech or Braille device.

• Avoid using pop-up windows as they can be disorienting to sight-impaired users.

If you would like to check how accessible your web page is, try running it through a validator, such as Bobby (http://www.cast.org/bobby/), that will scan your page and point out accessibility issues.