HTML Unleashed PRE. Creating Widely Accessible Web Pages: Graphics

alt Texts

The value of the alt attribute of the IMG tag is a string of characters defined as CDATA in the HTML DTD (see Chapter 4, "The HTML Document Type Definition").  This means it may contain both mnemonic (e.g. &nbsp;) and numeric (e.g. &#160;) character entities, but cannot contain any markup tags.  For example, you cannot control linebreaks within an alt text because any <BR> will be displayed verbatim instead of having the desired effect.

However, you can (and are even recommended to) surround the entire image with the necessary logical descriptive tags (e.g. H1 if the image is meant to be the main heading on the page).  In this way, the alt text of the image will be displayed or read aloud using the corresponding formatting (centering and highlighting in text mode, tone of voice in speech, and so on).  This convention, however, is not followed by visual browsers (for more on the peculiarities of displaying alt texts in visual browsers, see "Real World Character Set Problems" in Chapter 41, "Internationalizing Your HTML").

alt Writer's Guidelines

So what is the most important principle of writing alt texts?  According to Alan Flavell who has written an in-depth article on the topic, you should remember in the first place that alt text is supposed to communicate the information contained in the image, not some meta-information about the image itself.

In the simplest case, when an image displays some text string (for example, a heading or a button on a navigation panel), its alt text should contain the very same text and nothing more.  There's no need to write something like "Big red button," "Click here to go to...," or, God forbid, quote the size of the image in bytes or pixels.  All this would present some meta-information about the image or its role on the page, and since this information is absent in the image itself, it is just as redundant in this image's alt text.  For an example of a good alt text (although incorrectly formatted), refer back to the C|Net screenshot in the "Other Layout Tools" section earlier in the chapter; writing something like alt="pull-out quote" would be an obvious mistake in this case.

Of course it's not always as simple as that.  For a company logo, for instance, it is not so easy to decide what it is that the image tells us.  Are we always aware that it's a logo, or do we more often perceive it as just a fancy way of displaying the company name?  I think that in most cases logos are used on web pages simply as headings, so it is better to say alt="Foo Inc." than alt="Logo of Foo Inc."  However, sometimes we need to emphasize the fact that the image represents a logo (for example, in an online logo design portfolio), so the second variant of the alt text may also have its uses.

In the following list, I've summarized the rules-of-thumb for choosing alt texts for various kinds of images:

• Spacers and decorations.  For images with little or no importance to the page's meaning, always specify an empty alt text (alt="").

  You might think this is the default value anyway, but that's not the case.  The HTML 4.0 specification lists a number of sources that a browser should use to make up an alt text for an image without alt attribute, and the most probable outcome of the algorithm is the file name of the image (minus the extension).  The most common text-mode browser, Lynx, uses [IMAGE] as a substitute for altless images.  So, alt="" is a must if you don't want to drive your readers crazy with this sort of junk.

• List bullets.  Images of this kind may be considered decorative but actually they're not, serving a very practical purpose of separating items in a list.  Therefore, the alt string should present what's conventionally used as bullets in text only documents---most often the "*" character.

  Considering what has been said about lists (see "Lists" earlier in the chapter), it is a good idea to put consecutive numbers or letters as alt texts for a row of graphic bullets.  This way, you don't distract users of visual browsers with the redundant numeration while providing a useful navigation aid for the disabled users.

• Dividing rules.  Again, an almost decorative element that nevertheless performs a useful function; various plain ASCII substitutes for graphic rules may include "=====", "-----", "*****", and so on.  Note, however, that this recommendation clashes with the warning against using unusual punctuation (see the Note in the "Text Markup and Formatting" section, earlier in the chapter); imagine that you have to listen to the endless "hyphen hyphen hyphen..." mumbled by a speech browser in place of a graphic rule.  Nevertheless, in the "Unified Accessibility Guidelines" document, graphic rules are preferred over HR elements precisely because they allow you to set alt values.

Simply put, an ideal alt text should be such that users of text-mode or speech browsers can't even guess that it is a substitute for an image, but perceive it as an integral part of the page text.

Presentation of alt Texts

As we've seen from the C|Net example in the "Other Layout Tools" section, non-graphic browsers do not treat alt texts any differently than they treat the usual text of the page; no separators are added, and an alt text is simply displayed in place of the image.  For example, if two images are positioned immediately next to each other, their alt texts won't be separated by even a space.  This is likely to seriously damage a navigation bar made of a row of adjacent images (for more on this, see "Just Say No to Image Maps" later in the chapter).

Therefore, in most cases it's advisable to provide some means of separation in the alt text itself.  You could add a space at the end of the alt text, as shown here:

alt="text "

This solution may work but is not particularly elegant. The safest way is to surround the text by a pair of brackets:

 alt="[text]" 

You can also add a | character, as follows (this variation can be used to separate the alt texts of several images in a row):

alt=" text |"

Visual browsers pose another problem.  If you've specified height and width values for an image (and you should because this measure drastically improves the speed of downloading and displaying the page), its alt text may not fit into the allocated space.  For users who have turned auto-loading images off, therefore, these alt texts might become unreadable.  As a compromise, you can remove height and width attributes for those images that do not significantly affect the speed of page downloading; this will prompt the browser to allocate for each image a rectangle big enough to contain the alt text.

Alternatives to alt Texts

The use of the alt attribute with the IMG tag is widespread and universally supported, but has some serious limitations.  The fact that alt texts cannot contain HTML markup and (for fear of breaking the display in some browsers) cannot exceed some reasonable length may become an obstacle when an image (e.g. a scientific diagram) contains a lot of data, most of which could be communicated in text form to those users who cannot view graphics.

In such cases, the readily available solution is to provide a separate subpage for each image containing the necessary annotation.  However, the remaining problem is how to link this page to the main page in a way that's obvious for non-graphic users and not distracting for graphic users.  One suggested method is using a small capital "D" (standing for "Description") for the link, located near the image's upper right corner.

A more elegant solution is to use a small transparent image for the link, invisible in graphic browsers, positioned adjacent to the image being annotated, and given an alt text that makes its purpose obvious for non-graphic users.

In the future, other options of annotating images may become available.  The new graphic format called PNG (Portable Network Graphics), intended to eventually replace GIF, has provisions for storing arbitrary text strings right in the image file.  HTML 4.0 specification suggests that with time, the IMG tag should be displaced by the OBJECT element whose content serves as an analog of alt text:

  <OBJECT data="TheEarth.gif">
   The <STRONG>Earth</STRONG>
           as seen from space.
  </OBJECT>

Here, the string between <OBJECT> and </OBJECT> will be rendered only by those user agents that cannot display the image.  In this way, any amount of text with any markup can be used as an alternative presentation for an image.

Just Say No to Image Maps

Image maps once were popularized as a significant improvement over the original HTML's one-link-per-element scheme.  The capability to assign URLs to arbitrary areas of an image was indeed exciting in the era when images were still perceived as alien beings dispersed on graphic-poor Mosaic pages.  Since those times, however, layout tools (or tricks?) have improved considerably, and for most design-conscious pages, images have become the foundation of the page composition.

Modern graphic browsers are able to position images with up-to-the-pixel precision (even without style sheets, this is achievable using tables and spacer images).  In fact, this feature makes image maps unnecessary: You can nearly always break your navigation panel into separate buttons with no more than one link per image and seamlessly arrange them on the canvas.  However, you may feel reluctant to engage in this sort of handiwork without sufficient reasons.  What are, at any rate, the disadvantages to image maps?

As you might guess, their most important disadvantage is poor accessibility to non-graphic user agents.  This is especially true for server-side image maps that require a pair of coordinates to be sent to the server.  Text-mode or speech browsers have no way to figure out any meaningful coordinate values other than to attempt the "0,0" pair (that's why it is recommended to link this origin point to an alternative text-only page).

Client-side image maps that use MAP and AREA elements are much more disabilities-friendly because in this case, the HTML file itself contains all the information about the image map links and their URLs.  An alt text for each of the links is now the only thing that is missing for a non-graphic browser to be able to build a working alternative for the image map.  It is enough to display (or read out) the row of alt texts as links, and the user will never even suspect that they were extracted from an image map.

This is not a deficiency in the standard: The alt attribute is indeed provided for the AREA element and, what's more, is its only obligatory attribute.  For example:

<IMG src="navbar.gif" USEMAP="#navmap">
<MAP NAME="navmap">
  <AREA coords="0,0,50,50"
        href="page1.html" ALT="Previous Page">
  <AREA coords="51,0,100,50"
        href="/"          ALT="Home">
  <AREA coords="101,0,150,50"
        href="page3.html" ALT="Next Page">
</MAP>

However, the support for such gracefully degrading image maps is far from universal.  Even those web authors who are well aware of the necessity to set alt texts for images, often forget to include alt texts in image maps' AREAs.  Worse yet, far from all non-graphic browsers are smart enough to recognize the alt texts in AREAs and to present them as links.  The same is true about the common graphic browsers with auto-loading images turned off.

Thus, the main incentive to abandon image maps is accessibility: When each link is tied to its own IMG element with its own alt text, this link is guaranteed to work with any existing user agent or access technique.  However, there are more reasons for preferring the one-link-per-image approach:

• If other pages of the site use similar but not identical navigation panels, you could reuse the buttons stored in separate graphic files, thereby reducing the total download time of the site.

• With GIF files that are limited to a maximum of 256 colors, breaking a navigation bar into pieces allows for each button to have a separate palette of its own, thus improving the color rendering on high color or true color systems (i.e. those that do not dither all images to one fixed palette).