The idea of equivalent alternatives is fundamental to Web accessibility for people with disabilities. We might think of this as a kind of "principled redundancy" providing multiple paths to key ideas and information to ensure that all roads do in fact lead to Rome.
The most common type of equivalent alternative is ALT text , which should be associated with images and selectable regions of image maps. ALT text is a short phrase that succinctly identifies the image and makes its function clear to a person who cannot see the image. For image maps, ALT text is associated with each selectable area to allow people using screen readers, talking browsers, and refreshable Braille displays to access the links and understand where they go.
Technically speaking, the term ALT refers to a specific HTML attribute that can be attached to a number of HTML elements. The most important of these elements are images (<img> elements) and selectable areas of client-side image maps (<area> elements), and we concentrate on these in this chapter. 
 Other HTML elements require other means for providing alternative content. WCAG 1.0 recommends synchronized audio descriptions and captions for multimedia; Section 508 requires them. Also, scripts, applets, plug-ins, and other embedded or ancillary materials must be accessible as well. When these elements and their functions cannot be made directly accessible to people with disabilities, the site should provide alternative ways to access the same information or interactions through equivalent functionality. See Chapter 13 to learn about alternatives for multimedia objects such as video, audio, and animation. See Chapter 14 for discussion of alternatives for the <script> and <applet> elements.
The ALT text is generally a phrase or short sentence that forms the content of the alt attribute. This apparently simple idea has great power. Missing or inadequate ALT text can make your Web site completely unusable for people with disabilities such as blindness, low vision, and cognitive disabilities caused by traumatic brain injury or learning disabilities. By the same token, writing effective ALT text can provide a significantly better experience not only for people with these disabilities but also for just about everyone who visits your site. This is because the process of writing ALT text will lead you to clarify both the purpose of each element on each page and the organization of the elements in relation to one another.
Sample HTML for ALT Text
The HTML code for associating ALT text with an image looks like this:
<img src="/books/3/135/1/html/2/http://www.somewhere.edu/images/imagefile.jpg" height="340" width="160" alt="Photo of Slatin's head">
img is the HTML image element.
src is the HTML attribute identifying the name and location of the image file to be displayed.
height is the height of the image, measured in pixels.
width is the width of the image, measured in pixels.
alt is the HTML attribute that contains the text to be associated with the image. This text is read aloud by screen readers and talking browsers, displayed by text-only browsers, and converted to Braille characters by Braille displays. In some browsers, it also appears briefly as a "tool tip" when the mouse passes across an element that has an alt attribute (and no title attribute, which takes precedence).
Characteristics of Effective ALT Text
In order to be effective, ALT text should
Be short: 150 characters or fewer, including spaces and punctuation.
Make sense out of context, for example, when read aloud by itself or as an item in a list of links spoken by a screen reader or talking browser, or when rendered as Braille. (Examples of links presented in the JAWS Links List appear in Chapters 2, 5, and 8.)
Make sense in context, for example, when read aloud as part of a larger page that contains other text.
Contribute to the intelligibility of the page as an auditory experience.
We'll discuss these issues as we go along. First, though, let's look at the issue of equivalence itself.
When is an alternative an equivalent alternative? Suppose the visual design of your page calls for a red arrow that serves as a graphical link to the next page in a sequence. The ALT text for this image should not be "right arrow" or "red arrow": it should say "Next page." It isn't appropriate to use phrases like "Link to next page" or "Go to next page," either, and certainly not "Click here to go to the next page" (we've seen all of these in various places). Why? There are several reasons.
First, it's redundant. Assistive technology devices generally inform their users when they encounter links. The JAWS screen reader, for example, inserts the word "link"; IBM's Home Page Reader speaks link text (including ALT text for graphical links) in a different voice than it uses for other content; Braille displays insert additional Braille characters, such as "lnk". So it's redundant to use such phrases in the ALT text for graphical links. People who use screen readers, talking browsers, and refreshable Braille displays already have to spend more time on typical Web tasks than people who can point and click; redundant phrases just make it take even longer because users have to listen to each one (or scan it with their fingers).
Second, beginning the ALT text for every graphical link with a phrase like "Go to . . ." may interfere with an important navigation aid. JAWS, for example, includes a Links List feature (as seen in several of the user experience chapters in the first section of this book). Users can navigate this scrollable list of links alphabetically that is, pressing a letter takes you directly to the next link that begins with that letter. In our current example, pressing the n key would let us jump directly to the "Next page" link. If all the links begin with the same letter ( g, for example), this convenience is lost.
Finally, "Click here" doesn't work for two reasons. First, it's device-dependent, assuming the use of a mouse. You may think that this is silly: surely everyone can translate the word "Click" into the action that's appropriate for whatever input device they're using. But that apparently simple act of translation may be beyond the cognitive grasp of some users people with traumatic brain injury, for instance, might have trouble; even if they're able to do the translating, the effort required may be tiring. Second, spatial references like the word "here" or the phrase "on the left" might pose similar problems, both for people with cognitive impairments and for people who can't see the screen: where is "here" when you're listening to the page? Where's "left"?
Length and Intelligibility
ALT text should be short, but it still has to contribute to the intelligibility of the page. So how short is too short? It's not unusual to encounter ALT text containing just one or two words. This may not be enough, however, to provide the information people really need. Jared Spool and his colleagues at User Interface Engineering  found, for example, that a link's value for users depends on how well those users are able to predict where the link will take them and on how easy it is to recognize differences among the links on the page. Predictability, in turn, depended heavily on the descriptiveness of the link text; longer phrases containing 5-12 words yielded higher predictability than shorter ones.
These findings by Spool et al. have important implications for the length of ALT text, too, especially when it's used as link text or as an important identifier for an entire page or site. The ALT text for the first image on the General Motors site, for example, consists of just two letters: "GM."  It's easy to think that this should be fine after all, there can't be many people in the Web-using world who don't know what GM is! But remember that people using screen readers and talking browsers are listening to the Web, not scanning visually for familiar signs and logos. The ALT text for the General Motors logo is extremely short and goes past the ear very quickly; people using screen readers and talking browsers may not be entirely certain of what they've heard. The Fujitsu site says only the single word "Fujitsu,"  risking similar disorientation especially if the user got to the Fujitsu site by following a link from another site that didn't clearly indicate the destination. The Sprint site, only marginally better, announces itself as "Sprint dot com."  Even on the site for Jared Spool's firm, User Interface Engineering, the ALT text for the logo is just "U I E logo."  This is fine if you already know where you are, but unintelligible if you don't.
 Accessed July 15, 2001, at http://www.gm.com.
 Accessed July 15, 2001, at http://www.fujitsu.com.
 Accessed July 15, 2001, at http://www.sprint.com.
 Accessed July 15, 2001, at http://world.std.com/~uieWeb/index.html.
The point here is that for people listening to a screen reader or talking browser, ALT text is an experience in time, not in space. The ALT text shouldn't take up more time than necessary, but it also shouldn't go by so quickly that the user misses it or has to have it re-peated. (An analogy: Talking wristwatches like the one I [John] use play a little chime and the word "It's" before announcing the time, giving the user a better chance to get ready to hear the time when the watch speaks it.)
When ALT Text Should Be "Silent"
The fact that ALT text must contribute to the intelligibility of the page as an auditory or tactile reading experience suggests that there are times when ALT text might actually get in the way. For example, many Web developers use transparent "images" in order to achieve specific layouts. People who use screen readers, talking browsers, Braille displays, or other text-only devices will not be helped if they have to hear every such image identified! Similarly, when the page already contains a detailed description of an image (such as a chart, graph, or painting), ALT text may be unnecessary. In such cases, however, the image element (<img>) must still have an alt attribute because when there's no alt attribute present at all, screen readers and talking browsers read the contents of the src attribute (the name and location of the image file) instead.
The appropriate technique in these cases is to include an "empty" alt attribute. In Web developers' jargon this is called "setting the alt attribute to null." Setting the alt attribute to null forces screen readers and talking browsers to behave as if the ALT text isn't there.
The HTML for setting a null alt attribute looks like this:
<img src="/books/3/135/1/html/2/http://www.somewhere.edu/images/spacer.gif" alt="">
Note: As we saw in Chapter 7, setting the alt attribute to null isn't always a straightforward affair. Nonetheless, we strongly encourage you to use this technique when it's appropriate for the image to be "silent." This is a judgment call and, as with any other judgment call, you should test it against the responses of actual users.
Designers sometimes "slice" large, complex images into several smaller images in order to speed up the time it takes for the complete page to appear on the screen. This technique has some important advantages, but there are potential disadvantages from an accessibility standpoint. That's because there's a difference between what users see on their screens and what screen readers, talking browsers, and Braille displays "see" when they process the HTML source code.
What users see on their screens looks like a single image. But screen readers and talking browsers "see" a succession of individual (<img>) elements. Each of these <img> elements has to have its own ALT attribute if it doesn't, people using assistive technologies will hear the filename for each of the "slices." What the designer intended as a beautifully coherent visual impression breaks up into a multitude of incoherent auditory fragments. Associating the same alt text with each "slice" isn't the solution either. People listening to the page would hear the same phrase repeated over and over again for no apparent reason.
The solution is to write the ALT text for the first slice the first <img> element in the composition as if you were writing the ALT text for the whole large image. Then, set the alt attribute to null (alt="") for each of the remaining slices. In this way, someone using a screen reader, talking browser, or refreshable Braille display will hear or read the ALT text that identifies the entire image, and their assistive technologies will ignore the other slices. In other words, these users will experience the page as if it contained just the one image, just as people who look at the page see it.
Sliced Images That Act Like Image Maps
The exception to the procedure we've just described comes when the sliced image is actually intended to serve as an image map. In this case, some of the individual slices will actually become graphical links, while others don't. The ALT text for each of these graphical links should identify the link destination, just as it would for any other graphical link. The remaining slices, the ones that don't act as links, should have empty alt attributes so that screen readers and talking browsers will ignore them.
Considerations of Reading Order
The confusion we encountered at the Web site of the Metropolitan Museum of Art in Chapter 7 illustrated that reading order matters: it can make the difference between an informative and successful visit to a Web site and a very frustrating one. We mention this here because the order in which people using screen readers, talking browsers, refreshable Braille devices, and text-only displays encounter ALT text, whether on its own or in relation to other text on the screen, can make a huge difference in the users' ability to use the site effectively and thus in the quality of their experience.
Screen readers, talking browsers, refreshable Braille devices, and text-only displays all work from left to right and top to bottom, just the way most speakers of English and European languages learned to read in school. But whereas part of our development as literate citizens involved learning that we don't always have to read in such a linear way (and that sometimes we shouldn't), the technologies we're discussing here aren't smart enough to know that. So they just plow ahead like the robots they are, stupidly reading whatever's in their path "in the order it was received," as the voicemail robots put it so eloquently.
The placement of images and text on a page determines the reading order, so it's up to Web site developers to control the reading order. It's pretty simple, from a purely technical standpoint just a matter of placing elements on the page in such a way that the reading order makes sense. But this is harder than it sounds: since the ALT text is programmatically tied to the image (that is, alt is an attribute of the <img> element), the positions of the images on the page determine the order in which assistive technology devices read the ALT text. This may mean rethinking the way you place those images. (See Chapter 11 for further discussion of reading order in layout tables. See Chapter 15 for ideas about how to use Cascading Style Sheets to control the relationship between the order in which elements are displayed visually and the order in which they're read by screen readers, talking browsers, and Braille displays.) It may also mean thinking much harder about crafting the individual phrases of ALT text so that they make sense both when they're read on their own out of context (for example, by someone using the JAWS Links List) and when they're read as part of a whole page or a section of it. This becomes especially important if you've used visual proximity to create groups of related links or other elements because the relationships may get lost in the translation from visual to auditory mode. You've designed those visual relationships to be recognizable in a split-second glance but people using screen readers, talking browsers, and refreshable Braille displays hear (or manually scan) the items one at a time; this can sometimes take a very long time, too.
Since your pages probably contain both text and graphics, you will also have to take into account the interplay of offscreen text stored in alt attributes with onscreen text, like the text links and captions and extended descriptions on the Metropolitan Museum site discussed in Chapter 7. As we discussed there, tools like The WAVE can be invaluable resources for meeting this challenge. As we said in Chapter 7: reading order matters!