Guidelines on alt texts in img elements

In HTML authoring, there are very good reasons to include an alt attribute into every img element. The purpose is to specify a textual replacement for the image, to be displayed or otherwise used in place of the image. Thus, the prime rule is: Consider what the page looks like or sounds like when images are not shown. Then, write for each image an alt text that best works as a replacement. This document also gives more specific suggestions for simple, common situations, and some uncommon too. For content-rich images, it recommends explicit links to textual alternatives.

Content:

Rules of thumb

  1. For an image that contains text in some specific font style, simply use that text as the value of the alt attribute. There are some special notes on text as images below.
  2. For a logo, opinions differ. If the logo consists of the text "FooBar" in a particular style, some people use alt="FooBar logo" whereas others prefer alt="FooBar". This issue is discussed below in the section The logo controversy.
  3. For a purely decorative image, use alt="".
  4. For a "spacer" or "punctuation" image, use an alt text which acts as spacer or punctuation in text-only mode. Typically this means a short, one-word or even one-character text, such as alt=" " for a simple spacer and alt="item:" for an image used as a list bullet. If it's punctuation between links, use e.g. alt="*", since mere whitespace is not sufficient for making links distinct (on several speech-based browsers). For a "decorative horizontal rule", see notes below.
  5. For an image used as a navigational symbol, such as an image of upwards-pointing arrow for a link to an upper level in page hierarchy, use a corresponding word. Since such an image is a link, the word should be separated from adjacent words with characters other than spaces, e.g. alt=", Next" or alt=" | Next". Avoid Ascii graphics like ==>.
  6. For an image used to present a character or symbol within text, such as a Greek letter or small icon, write an alt attribute which expresses the same thing verbally. This might mean something like
    The <img SRC="alpha.gif" ALT="alpha"> radiation...
  7. For an illustration of something that is explained in the text, alt="" is suitable. But if it is not a pure illustration but e.g. presents an example not discussed in the text, see the next item.
  8. For an image with rich content of its own, such as a photograph or a graphic presentation of some system, you should aim at writing an alt text that performs the same function as the image, e.g. explaining verbally how the system works. But often we resort to writing mere descriptions, like alt="[Graphic presentation of the ventilation system]", at least as interim solutions. There are more notes about this in the section When an image says more than a thousand words.
  9. \int_{0}^{\infty}e^{x^2}dx As a special case of an image with a message of its own, an image representing a mathematical formula or similar notation should be replaced by a textual explanation, using linearized notation and simple character repertoire. In simple cases, you might even be able to write a formula using HTML (and CSS) acceptably. For complicated formulas, you might resort to title-like descriptions (e.g. ALT="[Schroedinger's equation]"). If the image has been generated using TeX or some of its derivatives, you might consider using the TeX source code as alt text. TeX code might be (perhaps via conversion to Braille) readable to some people who cannot see the image, and it would thus be better than no useful alt text.)
  10. An image acting as a counter of visitors (or, rather, hits) is essentially based on loading images. Thus, the data in it cannot be expressed in an alt attribute. Something like alt="???" would reflect this (in a context like "You are visitor number ???"). It is a good idea to consider whether counters are actually useless.
  11. Try to write the alt attribute so that its value is at most 50 characters long. If this is not sufficient for presenting all the information needed, consider the problems of long alt attributes and different methods for dealing with content-rich images.
  12. If the image is a link, make the alt text express the destination of the link. Normally, this means that it is the name of the linked page, perhaps abridged or reformulated.
  13. If the image is used to specify a client-side image map, the img element should have an alt attribute that reflects the functionality of the image map as a whole, e.g. alt="Country selection". Moreover, write useful alt attributes for the area elements, and most importantly, provide an alternative for the map as a whole, using a set of textual links. See Tooltips and alt texts for image maps.

The fundamentals: replacement, not description

Accessibility requires textual alternatives

The alt attribute is an essential part of Web accessibility, which is discussed, for example, in Diffuse's Guide to Web Accessibility and Design for All and in the extensive Web Accessibility Initiative (WAI) material. In particular, in Web Content Accessibility Guidelines 1.0, the first guideline is: Provide equivalent alternatives to auditory and visual content, and the first checkpoint under it says: "Provide a text equivalent for every non-text element (e.g., via 'alt', 'longdesc', or in element content)." It refers to the document on techniques for WAI guidelines, checkpoint 1.1, for information on how to do this.

The simple idea: alt

The idea of alt is old. Although the very first implementations of the img tag lacked it, the alt attribute has been in HTML specifications since the first (!) one, HTML 2.0. It said: "HTML user agents may process the value of the ALT attribute as an alternative to processing the image resource indicated by the SRC attribute", and clarified this further by stating that the ALT attribute value is "text to use in place of the referenced image resource, for example due to processing constraints or user preference". And it gave a good example of alt attribute:
<IMG SRC="triangle.xbm" ALT="Warning:"> Be sure to read these instructions.

Simplicity has its price. Since the alternate is written as an attribute value, it is restricted to plain text with no HTML markup. We will get back to this issue in section Making text and image really alternative.

The great confusion: from alternative to description

However, there is quite some confusion around the very idea of alt texts. Although the attribute name is an abbreviation of "alternate", reflecting well the intended meaning and use, even in official documents like later HTML specifications and the WAI guidelines there are also state­ments about alt texts as "text descriptions" of images.

In particular, although WCAG 1.0 refers to "text equivalents" and contains a very good definition of "equivalent" in this context, and generally promotes the idea of alternative rather than descriptive texts, it still has expressions like "For simple content, a text equivalent may need only describe the function or purpose of content. For complex content (charts, graphs, etc.), the text equivalent may be longer and include descriptive information." To see how careless the formulation is, consider a spacer image. An attribute like alt="spacer" would be a description of the image, and alt="a 20 pixels wide horizontal spacer image" would be even more descriptive; yet, both texts are pointless as substitutes for the image, and the more descriptive the description is, the more disturbing it is as an alternate text.

In the working draft Web Content Accessibility Guidelines 2.0 dated 22 August 2002, the formulation is clearer. Its checkpoint 1.1 says:

For all non-text content that can be expressed in words, provide a text equivalent of the function or information the non-text content was intended to convey.

The guidelines are intended to be general, not related to HTML specifically, and the checkpoint does not refer to the alt attribute directly. Rather, different methods can be used, depending on the state of technologies, and other considerations. But the examples mention "short labels" and "longer descriptions", which might look suspiciously like generalizations of alt and longdesc. This is somewhat disquieting, as it might be read so that it is acceptable to rely on the latter, i.e. to assume that both of those attribute values are always available to the user.

In the index of attributes in the HTML 4 specification, the characterization of the alt attribute is "short description". Although the description of the alt attribute in the specification clearly defines it as providing "alternate text to serve as content when the element cannot be rendered normally", people tend to remember short slogans better than long explanations with lots of difficult words. Besides, the long explanation isn't that exact, and it's preceded by an even more confusing one: "For user agents that cannot display images, forms, or applets, this attribute specifies alternate text." (It's not only a matter of being able to display images; it could be just the user's choice, for example.) Thus, the meme of regarding alt as a description has become frustratingly common. It is easy to understand and easy to implement, without thinking about difficult things like the context and communicative purpose of the image. Luckily the slogan "alt gives an alternate text" has some properties of a successful meme too.

Maybe the most serious official confusion appears in the so-called Section 508 guide, which gives instructions based on the accessibility legislation in the US. In that guide, the explanation of rule (a) ("A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).") partly uses adequate phrases like "communicate the same information as its associated element", partly misleading expressions like "a text description accompanying it that explains the meaning of the image". - It needs to be added here that Web accessibility rules in Section 508 as a whole are well-written and pragmatic.

To some extent this confusion relates to difficulties in writing good alt texts and using descrip­tions instead, as explored below in section When an image says more than a thousand words. But there is little hope in getting things right unless we make it clear, and keep it clear, that an alt attribute should be an alternative that stands on its own. Otherwise authors will get misled into writing descriptions even for spacer and bullet images and other images that have very good textual alternatives.

Let us end the discussion of alt texts as replacements versus descriptions by quoting a famous usability expert:

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 [...] 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 descrip­tions 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?
Source: Jakob Nielsen: Accessible Design for Users With Disabilities, alertbox for October 1996.

The phone test

Imagine that you are reading your page to someone over a phone. What would be the appropriate thing to do when you reach an image?

Would you just skip the image, or would you use words that perform the function of the image, to the extent possible? What would you do if it turns out that you can say just part of the content in words since the some essential features are inherently visual? If there is no adequate replace­ment, would it be somehow relevant to tell that there is an image with such-and-such content?

The Core Techniques for Web Content AccessibilityGuidelines 1.0 mentions a test like this (under "Quicktest!"). But it says this after having given a confusing explanation:

When a text equivalent is presented to the user, it fulfills essentially the same function (to the extent possible) as the original content. For simple content, a text equivalent may need only describe the function or purpose of content. For complex content (charts, graphs, etc.), the text equivalent may be longer and include descriptive information.

That explanation would be very good without the middle sentence. How does describing some function or purpose fit in into the idea of actually accomplishing the function or purpose? There is a difference between saying "this graph shows our organization" and actually telling what the organization is.

What about considering the alternative first?

It would be best to write alt attribute first, before an image is chosen. Such an approach could speed up Web publishing: you could publish information content without waiting for decorations and other images to be ready and processed. You would first think how to say something in words, then consider what might be a useful graphic alternative to that. Such an approach is discussed in a more general context in Augmentative authoring - a different look at "graceful degradation" in Web authoring. In particular, it can be useful to think first how the page works in auditive presentation, then consider adding visual layout and possibly alternatives.

Such an approach could help the visually oriented too. An author, after designing the page primarily for auditive presentation, would consider how it works as visible text, then move into thinking which parts might need visual alternatives or enhancements. It would not be decisive what images he has at his disposal, or what graphics wait to get embedded into the page; instead the question would be: what images does the text call for, either to be used as alternative to textual explanations that would better be presented graphically, or as illustrations that repeat or exemplify the textual content, or as eye-catchers or decorations?

Notes on different types of images

Text as images

Authors often include images for the purpose of presenting some text in a particular style. It could be a company logo, a heading, or a navigational button with text in it, for instance. Note that you might consider using just styled text instead in some cases.

It is usually trivial to write a good alt text for such an image. There are, however, some details to note:

Styled text instead of an image?

If an image contains just text in some particular appearance, it is useful to ask whether it would be better to use just text instead of an image, using a style sheet to suggest some particular presentational properties, such as font face, size, and colors. (For some properties, you could use HTML markup too, but that would be rather outdated.)

This would imply, among other things, that the characters would scale up (or down) according to the user's wishes and needs. As an example, using the CSS rule
strong { background: #ffc none; color: #060; font-weight: normal; font-family: "Comic Sans MS", Western, fantasy; }
you could make all strong elements appear in a particular style. Your current browser presents it this way:
Sample text

However, such an approach is not always adequate. In particular, if the image is a company logo, containing the company's name in a particular presentation style in which it has become a well-known symbol, then it would often be better to use the image. For most people, the image would be more informative, more easily recognizable, more accessible. In most situations where imageless browsing is used out of necessity (rather than convenience), it does not disturb the user that an img element is used instead of text, provided that the img element has an adequate alt text of course.

On the other hand, if the image is just a particularly styled version of the company's name, perhaps different from the style used last (or next) week, it would normally be better to use just text (and CSS). But where do you draw the border between the cases? Typically, a logo image cannot be satisfactorily approximated by using CSS styling features on text. It could even be somewhat alienating to arrive at a page of a widely known company with a widely known logo and not see the logo there, in a browsing situation where images are generally viewed.

In general, there are situations where the appearance of some text is part of its very meaning. For example, it is possible that a name by itself is not trademarked as a merely verbal expression but a particular visual apperance of a name is trademarked. A more common example is an abbreviation presented as particularly styled visual symbol. The visual appearance can be essential for distinguishing the symbol from other meanings of the abbreviation. If you use such an image on a Web page, you should consider whether the alt text needs to contain a little more than the name or abbreviation only, such as an expansion of the abbreviation in parentheses.

Alternate texts for links

If the image is a link, i.e. the only content in an <a href=...>...</a> element, write an alt text that corresponds to the destination of the link.

Note that e.g. HTML Techniques for Web Content Accessibility Guidelines 1.0 do not use or endorse anything like a "Link to..." prefix in such cases. (Unfortunately, the first example of text equivalent there is "Go to table of content" instead of "Table of content", but this is probably an oversight.) Browsers are expected to indicate links as links.

For example, if a company logo is a link to the company's main page, you could just put the company's name there, optionally followed by "(main page)". See also: Links Want To Be Links, which explains why images as links are often a bad idea, even if you use adequate alt texts. Consider also using an image and a text in parallel as a link.

List bullets: how do you read them?

Authors often wish to use colored or otherwise decorated bullets. Although there are ways to do this in a style sheet, using the list-style-image property for a normal ul list, people still mostly use images. This is relatively risk-free when done properly, including the user of an adequate alt, although it may cause some problems that a construct that is logically a list is not marked up as such.

There are different approaches to writing alt texts for bullet images:

First, use some character that resembles a bullet, such as "*"
Second, use a dash-like or other character that is commonly recognized as having a meaning similar to a bullet, such as "-"
Third, use a word, with adequate punctuation added, such as "item:" or, perhaps better, words that reflect the progression of the sequence, like "First,", "Second,", and so on.

The choice between such alternatives is not a big issue, and they are all superior to not using alt at all or using something pointless like alt="small green bullet" . But this case illustrates how the needs of speech presentation are sometimes different from what is optimal visual presentation without images. The characters mentioned work rather well on text-only browsers, but how will they be pronounced? In particular, the use of the letter "o" is not a good idea, despite its bullet-like appearance, since it would be treated as a one-letter word or pronounced as the name of the letter in speech synthesis; in English, this would probably mean expressing it the same way as the word "oh". Other bullet-like characters aren't optimal in speech synthesis either.

Authors sometimes use different bullets for different items in a list, so that the differences carry essential information. For example, red bullets might indicate new entries in a list, in contrast with green bullets for other entries. This would, however, violate the accessibility principle "don't rely on color only". It is useful to indicate differences with colors, though hopefully with a contrast other than green versus red (since red-green color-blindness is so common), but it should be accompanied with information that is accessible without the use of colors. At the simplest, you could append the text "(New!)" to each new item, and then the alt texts for the images could all be identical, or could reflect the order.

Similar considerations apply to punctuation images, used often between short links on one line. This is bullet-like use in a sense, but with some specific features. In text-only browsing, "|" or "*" would work rather well. Hopefully the pronunciations (presumably "vertical bar" and "asterisk") are tolerable.

Avoid Ascii graphics

Ascii graphics (or Ascii art) means a construct that presents a graphic using characters as building blocks. For example, ==> is a very simple Ascii graphic, intended to create the visual impression of a rightwards-pointing arrow. Skip larger Ascii graphic. The following example demonstrates how Ascii graphics could be used in a technical explanation:

  ---------------                     ----------------
 |  10.10.10.10  |--------L2TP-------| Assigned by A  |
 |    Host A     |   ---       ---   |    Host B      |
 |    10.1.1.1   |--|NAT|-----|NAT|--|  10.10.10.10   |
  ---------------    ---       ---    ----------------

Although this would be "accessible" in the sense that it can be viewed even on simple text terminals, it would become rather incomprehensible when read aloud line by line. Besides, in alt attributes there is no guarantee of having like breaks preserved.

The term "Ascii graphics" is somewhat a misnomer, since the characters are not always limited to the Ascii repertoire.

In a sense, even a single character could be regarded as an Ascii graphic, when it is used for its visual appearance only. Someone might even argue that the use of a | (vertical bar) character as a separator between links is to be avoided, since it relies upon visual impression only. In practice, however, we can assume that people using speech browsers will understand what "vertical bar" means; in a suitable context, even "greater than" might be understood as something like an arrow. But listening to "equals sign equals sign greater than sign" makes the presentation sound a bit odd.

Apart from simple cases like "==>", there is rarely a serious temptation to write an alt text that constitutes an Ascii graphic. One reason to this that Ascii graphics generally rely on the line structure being preserved as written fixed width (monospace) characters being used. And small icon-like Ascii graphics like ~~~ (symbolizing waves) don't cause much harm. Nevertheless, they are best avoided. It is almost always better to use words in alt texts instead. However, if there is an Ascii graphic presentation for the content of an image, it might be a good idea to provide a separate, adequately annotated link to it.

A smiley (emoticon) like :-) is basically Ascii graphic too. When images are used instead of such Ascii graphics, it is in a way natural to use the character string as alt text, e.g.
<img src="smilingface.png" alt=":-)">
However, although alt texts have a large number of uses, it seems fair to regard their use in speech synthesis as decisive. That's were imageless presentation is needed, whereas, for example, the use of Lynx is mostly just a practical choice. So the crucial question is: what would you say if you presented your document by reading it over the phone, for example? To make things clearer, you can imagine that the listener is blind. It would mostly be irrelevant, and even irritating, to tell what symbol would be seen if he could see. What you would say depends on the language and linguistic style in use, but alt=" (I'm just joking.)" might be appropriate.

The logo controversy

There are two main opinions about alt texts for logots. Some people think that for a logo of FooBar, alt="FooBar logo" is pointless and alt="FooBar" (corresponding to the the actual text in the logo) should be used when needed. And it would be needed only if the image is a link or if it is used in a heading-like manner or otherwise as identifying the content or context of the page. Otherwise you could use alt="".

Others think that the "logo" concept is more or less universally understood in verbal presentation too and that alt="Foobar logo" is OK: it is taken as roughly meaning 'this page belongs to Foobar, it has a Foobar stamp on it'. Thus, it would have a message of its own to convey.

As a special (though common) case, if all pages of a site contain a logo, which is a link to the main page, then it's probably best to use either alt="FooBar" or alt="FooBar main page" for the logo image. Even if you would otherwise use "FooBar logo", the context would make the text too misleading. If you hear "link to FooBar logo", wouldn't it be natural to expect that it points to information about the logo, not FooBar main page? Note that on the main page itself, the logo should not be a link; links that point to the page itself tend to cause confusion.

There was an interesting discussion, with the title Is "this-or-that logo" adequate in an ALT text?, on the WebAIM mailing list, raised by my question there. I still think the word "logo" should almost never appear in alt texts, even though people presented very good arguments in favor of the opposite view too. It is not natural speech or writing to say "FooBar logo" when not discussing the logo itself; the natural way would be something different, like "This is a FooBar page" or "This is a web page by FooBar."

Besides, each page should have a descriptive <title> element, with content that is understandable in a global context, so it should often include something that identifies the page as being part of a specific site, such as "New products of FooBar" rather than just "New products". User agents typically present the content of the <title> element in some way that users are accustomed to, e.g. by reading it first. Quite often the <title> text is more less similar to the content of the main heading. This typically implies some reduncancy in speech synthesis, but it's probably tolerable. But why would we add more redundancy by including a text like "FooBar logo"?

When discussing a logo or other visual symbol, it would be adequate to include the logo image with an alt text that explains the appearance of the symbol, such as "The logo of the University of Maine contains the head of a black bear." Compare this with item 1 in Creating Accessible Websites by that university; it uses a noun phrase "The University of Maine Black Bear.", apparently suggesting that such a text would be adequate for common logo usage!

When an image says more than a thousand words

There are images with messages of their own, like photographs, paintings, and graphs, which really say more than a thousand words. For such images, the best practical approach is usually to write an alternative textual presentation of the information into a separate document, or into a separate part of a document, and link to it. You might then use the alt attribute to specify a condensed textual alternative, or just refer to the fact that separate text is available. There will be an example in the section Making text and image really alternative.

If the purpose is decoration, say no more

If an image is used for decoration only, alt="" is adequate, no matter how beautiful or artistic the decoration is. There's no point in explaining it in words.

Redundant images call for empty alt

Empty alternate text is usually adequate for redundant images too, i.e. for a visual illustration of something that is fully explained in the text, even if the image by itself is content-rich. Being redundant doesn't mean being useless. Such an image can be very useful to many people, but people who do not see the image have no use for an alternative text when the alternative text has already been given! The only reason for using a non-empty alt text in such a case would be to help some people decide whether to download the image for viewing, or to switch to a browser that can show the image. I would suggest that if you do so, use a verbal expression that clearly identifies the image as optional illustration, e.g. alt="[Illustration of the above: The main components of the widget"] distinguishing it from the case where the image is essential.

For an essential image, say something

When an image is essential for communicating what the page tries to communicate, and not just decoration or a visualization of something already explained in the text, you should in principle always try to write an alt text that conveys verbally at least the most essential message of the image. This would often take a lot of work, and long alt texts cause some problems. So you might, as a compromise, write an alt text that tells what the picture is about, instead of acting as a replacement for it. It might be useful to put it into brackets to indicate this. Examples: alt="[my photo], alt="[a graphic presentation of the main components of the system]. Such texts are of little value in text-only browsing, but at least they can help people using graphic browsers with image autoload off, and such information could be used to decide whether e.g. a blind person should ask his friend look at the image and explain its content.

As regards to photos of people, they contain a lot of information but they are typically non-essential for most purposes, but it might still be relevant to know that a photo is available, for the purpose of recognizing a person, or for getting an idea (often a wrong idea, but anyway) of what a person is like. And something like alt="[my photo] shouldn't normally be disturbing. As the example of photos shows, the distinction between "essential" and "non-essential" information in images is not always clear-cut. - If a photo is used as the only information that refers to a person, e.g. when people who belong to a group are identified by their photos only, then the name of a person would normally be an adequate alt attribute value. But such situations are rare, or should be; normally the photo should be accompanied with text (name etc.), and then alt="" would usually be suitable, since the image is basically redundant.

There are images that have real content but cannot be expressed verbally in any satisfactory way, such as works of art when they are part of the subject matter, rather than decorations. Quite often any attempt to write a textual alternative, or even a description, is just someone's subjective view. It often belongs to the the essence of visual art that it can be experienced and interpreted in different ways Could you imagine writing a textual alternative to Mona Lisa? I mean a real alternative that conveys the same message, not a description of the theme, style, colors, etc.

We should be honest about material that is inherently graphic, just as we shouldn't think that any text could really be an alternative to a symphony, or that you could paint a visual equivalent of a poem. As part of such honesty, a page that is of fundamentally graphic nature should say that at the very start of a page. Quite often it might be sufficient to use descriptive title and h1 elements (with a text like "Photos from our trip to...").

Thus, the approach of using description-like alt texts is usually the only feasible solution for most collections of graphics, or any graphic presented as content, such as a painting. Typically, those texts would be similar to image captions but shorter. Even if the images have captions e.g. below each image, as they normally should, alt should be included; they may help e.g. people who need access the page using a text-only browser that is capable of launching an external application to show images, upon request for a specific image.

The function of an image is decisive

Sometimes it is difficult to draw a border between decorative images and essentially graphic content. The image itself is not decisive but its intended function. On a page about Louvre, you might use Mona Lisa as illustration. It would be a visual example rather than an arbitrary decoration, but I think alt="" would still be appropriate. On the other hand, if the image is a link to page that tells about the painting, then alt="Mona Lisa" would be suitable; you would simply use the text that you would use as link text if the image were not available to you. If a page is about Mona Lisa itself, and especially if your text refers to features and details of the painting, then the image is essential and you should use e.g. alt="[Mona Lisa, the painting]". Then the message, to people who do not see the image, is that there is some essential graphic content that they miss, and the message also briefly names the content. This may help people to decide what to do, if they have a chance. Some of them may have an opportunity to view the image later, or they might ask someone describe the image for them. Some essentially graphic information could even be accessed using a haptic mouse or in some other non-visual way.

Using brackets to distinguish descriptions from replacements

I have proposed that an alt text be enclosed in square brackets, as above, if the text is descriptive of the image rather than an adequately replacement for it. This is intended to convey the message that there is something special about the text, something that deviates from normal flow of text. Whether this really works, and whether it may cause some confusion, is debatable. But it seems to me that there are no strong opinions against the practice.

For example, if an image contains a pie chart, the alt text could say
"[Pie chart of our sales in 2002]"
or something like that. Such a text is not a replacement for the image; it does not communicate in words what the image communicates graphically. Hence, the use of brackets might be useful for distinguishing such texts from genuine alt texts like
"Our sales in 2002 were dominantly (65 %) Widgets and just 35 % Gadgets."

Turning a pie chart into text

The following simple example, from a hypothetical business document, illustrates a genuine text alternative to an image. In a non-visual presentation, the user might not even know that the text is an alternative text and not normal content. In a visual presentation, the user probably doesn't even see that there is a textual alternative.

Sales in 2002: Widgets 65 %, Gadgets 33 %, Mudgets 1 %, Other 1 %

It is often obvious from the alt text itself whether it is a real replacement, a description, or something pointless. But some convention could help in getting a quick clue.

If you start with an alt text that is a description, later write a replacement text, you could keep the description text too, making it (without the brackets) the value of a title attribute. Example:
<img src="pie.png" alt= "Sales in 2002: Widgets 65 %, Gadgets 33 %, Mudgets 1 %, Other 1 %" title="Pie chart of our sales in 2002">

Images that say more than a thousand words would usually not be links, except in contexts like a photo gallery where they might be thumbnails. If there would be some need to make the pie chart image a link, it's probably better to use a separate textual link instead. The link might appear as a caption for the image. In such a case, if the link points to a page containing the content of the chart in text format (perhaps in a table), you could use alt="" for the image, since a textual replacement would be unnecessary and even undesirable.

What about saying part of the message in alt text?

We can distinguish three types of relationships between the information content of an image and an alt text:

  1. text that just describes the image;
  2. text that communicates verbally the same thing as the image;
  3. alt text that partially communicates the same thing as the image, hopefully the most important information.

For example, it might not be feasible and useful for a pie chart alt text to present all the information, down to the items with fractions of percentage. Wouldn't it be better to say part of the information in the alternate text, instead of resorting to a mere description like [Our sales in 2002 (pie chart)]?

This is a difficult question. Consider the following idea:

If the picture illustrates a concept, describe the concept, such as "College students in the 1980's wore their backpacks over one shoulder."
Source: The Rules of alt in the Idocs Guide to HTML.

The example apparently relates to an assumed photo of college students in the 1980's. If the only purpose for including the photo is to convey the message about that particular feature of behavior, then the text would indeed be a suitable alt text. The question then arises whether that text should always appear on the page, as image caption, since otherwise the message might easily be missed.

I would say that normally you should either write alternate text that carries the entire message of the image or write a mere description, hopefully adding some way to access some text that presents the entire message. Intermediate solutions have the problem of giving wrong information. Some of the omitted details might really matter.

But the alternate text should carry the message that the image is supposed to carry, not all the details that are irrelevant to the message itself. Some people have even taken the trouble of explaining the colors used in a pie chart, in addition to (or maybe instead of!) the information content of the chart. Of course, an alternate text should not describe such features of visual presentation that could be modified without affecting the message.

As regards to omitting information, I'd give the following rule of thumb: Omit things that you would edit away from the image too if you had time for that. Do not omit things just because they are less important, if they are still important enough that you wouldn't want to remove them from the image.

In some cases, you might decide to write an alt that contains part of the information content, and ends with a hint like "..." at its end, when the element is accompanied with some reference (preferably, an explicit link) to more information. Alternatively, you could use a description text and add remark that expresses some of the content, such as [Our sales my month in 2002 (showing small increases)].

Captions as a problem

(A photo of J. Korpela)
J. Korpela

Special problems arise when there is a caption below an image or, less commonly, above it or on either side of it. A caption is a piece of text, typically less than a line, that names an image, identifies it (e.g., "Picture 42"), describes its content, or comments on it, or performs several of these functions.

There is no specific HTML markup for associating an image with its caption, and several markup and styling techniques are used for captions so that they appear visually associated with images. See Image captions on Web pages - HTML and CSS techniques.

In particular, if the image has the empty string as its alt text, a user who does not see the image at all (and might not even know about the existence of an image) would still observe the caption text.

For example, the sample image above is a photo with the person's name below it. Quite often, it would be appropriate to use alt="" for the photo if it had no caption. It would be just an illustration, such as the photo of the author of the document. Usually there is no point in trying to write a text that expresses the essential content of the image. You either see the image, or you don't and you have to proceed without the information in it.

The caption changes this. A user who suddenly hears or sees a person's name inside some flow of text may wonder what is going on. If the caption text is something more elaborated, like a caption for a news photo, it may or may not work well without the image and without any indication of an image. Sometimes the caption even explicitly refers to something in the image. Thus, you may need to write some concise alt text that tries to remove the mystery caused by a caption appearing "out of the blue".

For an image with caption,

In the second or third case, you might also consider using alt="" if you make the caption text start with a "text identifier". By this we mean an expression like "Picture 1:" or "Figure 42." We might expect that it that makes it clear that the text that follows is a caption for some image. However, this might look odd e.g. when used for photos on a news page. It might be quite suitable for an article or essay.

Making text and image really alternative

The alt attribute is in many ways a primitive tool. It is limited to plain text, it cannot be very long for practical reasons, and it prescribes that the textual alternative is a secondary option. Note that even the object element, which is intended to be a more flexible generalization of the img element but is currently poorly supported for such purposes, still effectively makes the image primary and the text secondary alternative. A more balanced approach is to treat graphic and text as parallel alternatives, when their information content is the same. It could then be the user's business to decide whether he finds, in a particular case, one or the other more suitable, or whether he wants to "consume" both of them for understanding the message.

For content-rich images that need long textual alternatives, the simple and robust approach is to write that alternative somewhere in HTML and link to it. Use a normal link near the image so that it is reasonably clear what the link refers to.

This also lets you use structuring markup, like paragraph division, lists, and even tables. As a side effect, a user who can access the image could still use the text too. If you can write a good textual alternative to a content-rich image, why wouldn't you make it available even when the image is seen? Some people are verbally oriented, or would otherwise like to read the text as well, thereby perhaps better understanding the image.

There is no HTML element for saying "this text and this image say the same thing". But you can still express the idea in simple way. Simplest of all, in a sense, you could have just two annotated links, one pointing to a text document, one pointing to an image. Or even simpler in a sense, you could embed both, e.g. an image (with alt="") and a textual alternative side by side; but then you should make a reasonable effort of making it clear that they have the same information, since this is often far from obvious in visual presentation. Alternatively, you could embed one of them and link to the other, thereby giving preference to the embedded one. Usually this means including the image and using a link for the textual alternative. It's really a matter of judgement and being innovative in finding a way to do this smoothly.

As an example, the previous pie chart example could be modified so that the chart caption is not part of the image (which is a good idea anyway) and made to a link to an HTML document containing the information as a table. Naturally, it could be plain text or non-tabular HTML as well. You could then use alt="" for the image or, if desired, you could keep the plain text explanation in the alt attribute, as follows:

Our sales in 2002
Sales in 2002: Widgets 65 %, Gadgets 33 %, Mudgets 1 %, Other 1 %

In this case, it is actually easy to write an alt attribute that contains exactly the same information as the image, though presented in a very different format. In the general case, a graph or other image might contain more details than one can (or need) to put into an alt attribute.

The example uses a two-cell table, with the first cell containing the caption (title) of the image. You might alternatively use a single-cell table, putting the caption into a caption element. Or you might decide not to make the caption a link but include a link to the textual alternative into the text preceding the image, e.g. "The following chart shows our sales in 2002". In that case, the image should have a description-like alt attribute, since the reference to the image in the text could cause confusion if you use alt="".

The approach is suitable for org charts, too, though they often need restructuring to avoid excessive amount of information in one chart. There is more information on this on the page Accessible org charts on web pages.

What about longdesc attributes and [D] links?

The approach suggested above, using an explicit link to a textual alternative, avoids the problems with longdesc attributes and so-called [D] links.

The longdesc attribute is supported to a very limited extent in browsers. Even people using browsers that support it might not be aware of this feature, or of the availability of a "long description" for a particular image.

Note that the name of longdesc is misleading too: it suggests a description of image, not an alternative. If an image really needs a description, short or long, this should be considered as something rather separate from the question of providing a textual alternative. A description proper would be most useful to people who actually see the image, or at least could see later. Thus, for example, if you think that the logo of your company needs to be explained verbally, you should simply add the description into a suitable place on your Web site, such as an "About us" section.

There is even confusion about the need for an alt attribute when a longdesc attribute is used. The formulation of the WAI guidelines themself have part of the guilt. The wording "(e.g., via 'alt', 'longdesc', or in element content)" actually seems to suggest that alt and longdesc are alternative ways of satisfying the requirement!

The [D] link construct has often been proposed in various discussions and tutorials. It has however been deprecated in the WAI guidelines, though not in a very convincing way: "in favor of the longdesc attribute". A better argument is that you can use normal links instead. Besides, in addition to being visually somewhat disturbing, a string like [D] has no intuitively obvious meaning, and it violates the important rule of using different link texts for different destinations.

Naturally you can use longdesc in addition to the method I have proposed here. Thatt would be just a matter of adding an attribute referring to a long textual alternative, in addition to an explicit link to it.

Using an image and a text in parallel as a link

Some types of links often work best if the link text is accompanied with an image. Instead of using two links pointing to the same destination, it is best to make them one link, using markup like the following:

<a href="address"><img src="imagefile" alt=""> linktext</a>

An important reason for using a single link instead of two links is that when the user tabs from one link to another, redundant links make the use less convenient. Moreover, if there are two links, the question easily arises whether they really point to the same resources.

Note that the alt attribute should have an empty value, since the image is "redundant". You might wish to tune the visual appearance of the construct using presentational HTML attributes, or CSS, or both. For example, the following link has the attributes align="middle" border="0" in the img tag to make the image and the text appear "in line" and to suppress a border (which most browsers use around an image link by default):

Finland

You might alternatively put the image outside the <a> element, i.e. not part of the link. But some people have the habit of clicking on images in the hope that they might be links, and why should we disappoint them?

Decorative dividers (horizontal rules)

If an image is intended to act as a divider between major parts of a document, as a decorative counterpart of the hr element, then a visually adequate alt text could be a sequence of hyphens (-), underline characters (_) or macrons (¯), or perhaps some other characters like asterisks (*). Example:
<p align="center"><img src="hr.gif" alt="------------"></p>

But in speech presentation, the result could be rather bad (such as "hyphen hyphen hyphen..."). A descriptive text like alt="horizontal rule" isn't much better. If we consider what we would say in speech, then alt="Change of topic." might be natural. Or you might make it more specific, indicating which part ends or which part will follow, or both. Examples: alt="End of introduction.", alt="End of page content proper. Contact information follows.". But if headings are used properly to indicate document structure, we might regard divider rules as an additional visual hint only, and use alt="".

For a different approach to "decorative horizontal rules", see CSS1 and the Decorative HR by Alan Flavell. The method discussed there does not use an img element at all but an hr element together with a style sheet which suggests a presentation style using an author-supplied image. Thus it naturally uses a normal horizontal rule (the default rendering of hr on a browser) as a fallback when the browser does not apply the author's style sheet. (When the style sheet is applied but images are not displayed, there might be some problems, though.)

In the special case where you have used an image just to get a colored horizontal rule, you might consider yet another approach: Use a style sheet to suggest a bottom border (of the desired color) for a block-level construct preceding the point where the rule is to appear (or a top border for a construct after it). For example, to use such rules between major sections of a document, use markup like
<div class="section"> the section, typically starting with its heading <hr title="New section"></div>
for each of the sections except the last one (unless you want a rule after it too), and a style sheet like the following: 

div.section {
  border: solid 0 #090; width:100%;
  border-bottom-width: 0.2em;
  padding-bottom: 0.5em; margin-bottom: 0.5em; }
div.section hr { display: none; }

Note that when the style sheet is not applied, this degrades to a presentation with a default appearance of an <hr> element. When the style is applied, a dark green rule which is 0.2 em units (a fifth of the font size) thick appears instead. The style sheet is a bit tricky, especially to circumvent some Netscape 4 bugs, cf. to similar tricks for using borders around individual cells in tables.

Technical notes

Character repertoire: mostly the same as elsewhere in the document

When writing in a language that has various accented letters (as in École), write them correctly, not omitting the accent.

Unfortunately authors often write alt texts using incorrect spelling, e.g. substituting "a" for "ä". There is probably some superstition that says that accented letters should not be used in alt attributes, or attributes in general. There are many problems with using characters in HTML, but they mostly do not particularly relate to attributes. If you can use a character in the normal text of a page, you can use it in attribute values as well. And, in particular, the ISO Latin 1 (ISO-8859-1) repertoire works very well in HTML. Thus, you can use e.g. the letter É (either entering it as such, or using the entity reference &Eacute;) in attribute values as well as elsewhere.

There is one important exception though. On Windows 95 and Windows 98, IE fails to show the so-called Windows special characters like dashes and “smart” quotes properly when used in alt attributes, or when used in an attribute that will be displayed as a tooltip. Instead, the browser displays a thick vertical bar in place of those characters. It is usually easy to avoid them in attribute values, by using various surrogates like Ascii hyphens (-) and Ascii quotation marks (").

The language(s) in alt texts

You should write alt texts with the same care as normal text, or preferably with more care, since spelling errors cause more problems in speech synthesis than in reading on screen. This includes the correct use of characters as described above.

It is best to use normal prose in alt texts, instead of "telegram style". Thus, our original pie chart example was a bit questionable. The text "Sales in 2002: Widgets 65 %, Gadgets 33 %, Mudgets 1 %, Other 1 %" doesn't look very good, and doesn't sound very good. If you would present the information in words only, you would probably write a short paragraph like the following: "In 2000, our sales consisted mainly of widgets, 65 %, and gadgets, 33 %. Mudgets made only 1 % of the total. The rest, 1 %, were divided between miscellaneous products." But practical limitations on the length of alt texts often make compact, somewhat unnatural language the lesser of evils.

Since use in speech synthesis is one of the key reasons to using alt texts, they should be written so that work in auditive presentation. In particular, abbreviations should be avoided, unless they are supposed to be read letter by letter. Similarly, sentences should end with a full stop (period), since this can help the user by causing significant pauses where needed. Even isolated words and phrases may work better with pauses after them.

In particular, you should expand abbreviations if they would be best read aloud as expanded. For example, the abbreviation "WWW" is seldom pronounced as an abbreviation. Hence, your alt text should contain "the World Wide Web" rather than "WWW". In this case, the full form is actually shorter than the abbreviation in speech. But even if the full form is considerably longer, it should be used if it is actually better to speak it out. This does not mean that verbosity is a virtue. As in all use of words, the rule is: as short as possible, but not shorter.

In speech synthesis, it is important whether the textual context makes it sufficiently clear what words mean. Quite often a word is very understandable when you look at it in its context, but only because you're looking at the context, which gives you a picture of the page as a who.e In auditive presentation, the context is primarily the textual content before the word, with main emphasis on what was right before it.

In all use of words, but especially in short isolated expressions (as in a set of navigational links), there's the problem of homonyms in pronunciation: that words spelled differently can get pronounced the same (or almost the same), for example "I" and "eye". This is rather common in English, and it implies that spoken words are often more ambiguous than written words. "Home" is relatively safe (but its equivalents in other languages might not), but think about e.g. the word "sellers" in isolation. When someone hears it, how does he know whether it is "sellers" or "cellars"? If there are "buyers" and "sellers" in succession, the context probably removes the ambiguity. But quite often we see lists of navigational buttons with texts that have no obvious connection with each other and that might be understood only by looking at the page as a whole.

According to WAI guidelines, an author should indicate the language of each element on the page. This can be done using the HTML attribute lang, or the XML attribute xml:lang, or both. It suffices to set such an attribute for the document as a whole, in the <html> tag, and, when needed, for each element that is in a language different from the main language or, more exactly, different from the language of its enclosing element. Thus, if your document is in one language only, then you have an easy task.

Such an attribute sets the language of all attributes too. For example, if your document is in English but you have some reason for using another language in an alt attribute, you can do something like the following:
<img src="dinlogo.png" lang="de" alt="Deutsches Institut für Normung (DIN)">
This would indicate that the language of the alt text is German, and this information can be used by a speech generator to pronounce it correctly, and by other software. For example, a browser might tell the user, upon request, the language of each page element, when language markup has been used by the author.

There is no useful way to indicate language changes within an alt attribute, or any attribute, since attribute values are plain text. You cannot use any markup inside them. Thus, there is no good solution if you would like to use a bilingual attribute like
alt="Deutsches Institut für Normung (DIN) - German Institute for Standardization".

However, you might use a trick of using an additional dummy image and specify the second part of the alternate text as the alt attribute for that image:
<img src="dinlogo.png" lang="de" alt="Deutsches Institut für Normung (DIN)"><img src="transp.gif" lang="en" alt= "- German Institute for Standardization">
where transp.gif refers to a single-pixel transparent GIF image, which has effectively no impact on visual appearance. Make sure that there is no space or line break between the img elements, to avoid undesired visual effects.

In theory, Unicode has "language tag" characters that can be used in plain text. Their use is however strongly discouraged by Unicode except in special cases. More importantly in practice, they hardly have any support in any browser, for accessibility purposes or otherwise.

Using WIDTH and HEIGHT attributes

Especially for small images, such as navigational icons and spacers, it is best to omit the WIDTH and HEIGHT attributes. The reason is that many graphic browsers reserve space according to them even when images are off; and this implies that the alt texts often don't fit but are brutally truncated, or even don't appear at all, if the dimensions are small. To make things worse, browsers may include an icon of a broken image, such as a red × symbol, into the area, so that there's even less room for the text.

On Internet Explorer, there is a browser configuration setting "Always expand ALT text for images" (Tools > Internet options > Advanced). This oddly named option makes the browser ignore WIDTH and HEIGHT attributes when the browser has been configured not to display images, so that alt texts will not be truncated. Users should check that this option has been selected, but authors shouldn't rely on such things. Besides, the setting does not affect situations where the image is not displayed (and the alt text is used instead) for any other reason than the browser configuration setting of not displaying images. Thus, for example, if the browser does not get the image due to network congestion, the text is forced into the dimensions given.

On the other hand, the WIDTH and HEIGHT attributes speed up the rendering of a page, since a browser can allocate space for the image before getting the actual image data. So if the alt text is short as compared with the size of the image, use those attributes (and make sure they present the true size of the image in pixels).

Problems in WebKit-based browsers

Browsers based on WebKit, such as Chrome and Safari, have a longstanding bug that often suppresses alt texts. They show the text only if both of the following conditions are met:

This is usually not a problem if the text is short as compared with the width of the image. In that case, it suffices to specify the width and height attributes. In other cases, there is no good solution; this is a browser bug that authors just cannot deal with.

Validators and checkers are your friends

Notice that according to the HTML 4.0 specification, the alt attribute is required for every img element. Consequently, a validator (like the WDG validator) will report an error if some img element lacks an alt attribute if you validate against an HTML 4.0 doctype. This is useful for checking whether you have accidentally omitted such an attribute.

A validator however can only check the presence of an alt attribute, not its meaningfulness. It is thus incorrect to claim conformance to the accessibility guideline on text equivalents just because you have alt attribute for each image; the guideline is about text equivalents, not just any association with some text.

We cannot automatically check the adequacy of alternative texts, but some programs might try to detect potentially problematic cases. For example, there are some types of alt texts, like "bloop.gif (347 bytes)", that are often generated by various programs and don't do the job that alt texts should. Some checkers might recognize them and warn about them. It depends on their logic, and on the type of checking attempted, how often you get false alarms.

Various accessibility checkers, such as Bobby and A-Prompt, verify that all img elements have alt attributes, but they may also warn about things that the authors of those programs regarded as potential problems. For example, they might warn about alt texts that exceed some length limit, in characters or in words. As we will discuss shortly, long texts could indeed be a problem, but checkers may report the problems and suggest solutions in a misleading way. For more information, refer to Notes on some tools for checking and improving Web page accessibility.

There is also an easy to use online service, Wave, that checks a page and flags, in addition to missing alt attributes, blank and "suspicious" alt attributes. As we have noted, a blank alt text is often quite adequate. Admittedly it could also be unintentional or based on a misunderstanding.

On the length of alt texts

Various specifications and guides sometimes refer to alt texts as "short alternatives" (or even "short descriptions"). Although there are serious practical reasons to keep them short, an alt text could be very long, in principle, when the adequate textual alternative needs to be an entire paragraph or more. There is no prohibition against browsers splitting the display of an alt text over several lines when needed, and no requirement on them doing that either. And there's no way to force or to prevent line breaks in the presentation of alt texts. The practical conclusion is an alt texts should be 50 characters or shorter, if feasible.

By HTML specifications, a newline is equivalent to a space in HTML source. Thus, e.g.
alt="Just an
example"
is by the specifications equivalent to
alt="Just an example"
Your browser presents them as follows (these are a img elements with those alt attributes and with a src attribute that does not refer to anything):
Just an example
Just an example
Remember that if the presentations are different, it is an error.

No HTML markup is recognized within an attribute value, so you cannot include a line break into alt text using the <br> tag. Entity references and numeric character references like &#10; are recognized there, but that won't help in this issue - a newline is a newline, no matter how it is presented, and still equivalent to a space. In fact such references just cause extra problems as compared with normal linebreaks. For example, on Opera &#10; may cause the rest of the text to be ignored!

Browser behavior varies:

In principle, XML rules (which apply to XHTML) change the way that character references such as &#10; should be handled. Section Attribute-Value Normalization in the XML specification says:

Note that if the unnormalized attribute value contains a character reference to a white space character other than space (#x20), the normalized value contains the referenced character itself (#xD, #xA or #x9). This contrasts with the case where the unnormalized value contains a white space character (not a reference), which is replaced with a space character (#x20) in the normalized value - -

Thus, in principle, in XHTML alt="hello&#10;world" should be taken so that the alt attribute value contains an actual newline character. The number 10 corresponds to the Ascii control code line feed (LF). But browser support corresponding to that specification is probably very limited, if not nonexistent.

If the text is very long, so that it would it occupies vertical space more than (roughly) the height of the browser window, it flashes annoyingly (appears and disappears with a frequency shorter than a second), so that it is virtually impossible to read, on some browsers.

The practical conclusion is that you should try to make the alt text short so that it does not matter too much if it is presented as a single line. If it really needs to be long, use newlines in the attribute value, since that somewhat increases the odds of getting a tolerable presentation, but put a space before each newline to circumvent the Netscape bug. See below for notes on dividing the text into lines.

If the adequate textual replacement for an image would consists of several paragraphs of text, it is usually best to put it into a separate file and include a link to it near the image. See section When an image says more than a thousand words above.

What about empty alt texts? Should I use alt="" or alt=" "

Some guides and checkers say that empty alt texts should not be used. However, empty alt texts are perfectly valid and correct when the appropriate textual alternative to an image is an empty string. As the so-called Section 508 rules say about "Text Tags":

Web page authors often utilize transparent graphics for spacing. Adding a text description to these elements will produce unnecessary clutter for users of screen readers. For such graphics, an empty ALT attribute is useful.
Example of source code: <IMG src="transparent.gif" alt="">

Note: What Section 508 rules say about using alt texts is otherwise not quite correct. In fact, they are rather confusing. But this part is correct.

In principle, alt="" and alt=" " say different things, since an empty string (consisting of no characters) is not the same as a string consisting of one space character. In practice, they mostly have the same effect. Some browsers (and some checkers) have problems with either of them, and therefore some people have favored the one about which they have not heard bad information (or rumors). The constructive approach is to use the logical alternative, which is almost always the empty string alt="", since you normally want the browser act as if the img element were entirely absent (in situations where the image is not displayed).

For a spacer image, however, alt=" " is sometimes preferable. If a transparent image is used between words to create some fixed-width spacing, then alt=" " causes some space to appear when the image is not displayed. You might even use a sequence of no-break spaces, e.g. alt="&nbsp;&nbsp;", in an attempt to create more than a normal inter-word space. On the other hand, spacer images themselves are deprecated. If you intend to use them to create some tabular look, use real HTML tables instead. If you just wish to save some spacing for esthetic reasons, e.g. to present modern poetry, style sheets should be used.

Sliced images

Sometimes an author divides an image into parts, or slices, and then tries to put it together again:
<img ...><img ...>...<img ...>

I will assume that such elements constitute something that is logically one image. The considerations below won’t apply of the parts are used as invididual images, e.g. by making them links; in that case, each should have an alt attribute that corresponds to the purpose and use of that particular image.

Slicing is usually a bad idea. But if an image has been sliced, then it is normally best to write its textual equivalent into the alt attribute of the first img element and use alt="" for the rest:
<img ... alt="text"><img ... alt="">...<img ... alt="">

The key point is that one alt attribute contains the alternate text and others have empty value. Putting the text into the first attribute is just the the most obvious way.

It is futile to try to divide the text into different alt attributes even if the slicing somehow corresponds to parts of the image. Speech browsers have best odds in reading the text well if it is in one attribute.

As an exception, if the parts of the image contain texts in different languages, then you should divide the alternate text between different img elements. This is discussed in section The language(s) in alt texts.

The "tooltip" effect and the title attribute

[An arbitrary image for demonstration purposes] There is a peculiar behavior in some popular browsers which is sometimes presented as an argument against using the alt attribute: Browsers like Netscape 4 and IE 5 show the value of an alt attribute as a "tooltip" when the cursor is moved over an image. (You can probably see such a behavior by moving the cursor over the image on the right.) Some people regard this as annoying. Another view on it is that it gives users the option of seeing the textual alternative even if they are looking at the image itself. The image might be obscure, or its message might be hard to understand, it might contain some text in a font size that is unreadable to the user, etc. In section Making text and image really alternative we discussed one approach to such problems.

Well, the tooltip effect can be annoying, if you have adopted the habit of moving the cursor around, to see which images are actually links. Such habits have been created by authors who have taken some extra effort to prevent image links from looking like links, i.e. to prevent browsers from drawing a colored rectangle around image links. (Admittedly such rectangles can be somewhat unesthetic, but they are the way that popular browsers use as the only way of visually indicating an image as a link.) And some authors have taken the tooltip effect as the "real meaning" of the alt attribute, and they might then use even attributes like alt="Click me!", which are very irritating to people who see only the alt text (and might lack any device to click with, for that matter). So in this area, we have cumulative, cascading, escalating cluelessness by many browser vendors and by many authors.

Anyway, the strong arguments for using alt attributes (explained below) more than outweigh the minor unesthetic effect of the "tooltips".

The rose beetle has large brown areas on bright yellow background. Those areas almost cover the front and middle part, but in the back part, they are smaller ovals. The "tooltip" effect per se can be useful. In particular, people using graphic browsers without image autoload could greatly benefit from seeing a description of an image in addition to seeing its textual replacement. But it's not the alt attribute that should be used for it. It's the title attribute which is designed to be used as an "advisory title". Luckily, IE 4 and newer already use it that way. This means that for an img element, IE uses title as the "tooltip", though it still uses alt that way, if there is no title attribute. If you are using IE 4 or newer, you can probably see how the image on the right is treated; it has alt and title attributes which are quite different from each other.

In "Standards" mode as opposite to Quirks mode, IE 8 does not use the alt attribute for tooltip effects at all, even in the absence of a title attribute. The same applies to Firefox irrespectively of mode.

Consequently, you can use the title attribute in an img tag in addition to the alt attribute, if you think that the alt value does not work nicely as a "tooltip". The text should be relatively short, since browsers typically display it for a few seconds only. You can write title="" to suggest suppression of any tooltip behavior.

If the image is a link, then consider the extra problem created by IE 4+: an alt or a title attribute for the img element is used as a "tooltip" even if the surrounding A HREF element has a title attribute! Since omitting alt would be unexcusable, the best workaround is to write the title attribute for the img element so that it works as an advisory title for the link too. In modern browsers, the problem still exists in the sense that the title attribute for the inner img has precedence over the title attribute for the outer A HREF, but that's a different issue.

In the presentation of tooltips, there are problems with long texts which are partly similar to problems in presenting alt texts in their basic purpose, i.e. as replacements for images. There is an important practical distinction however: IE displays the tooltip text as divided into lines, with a maximal line length of 50 characters (on IE 4.0 on WinNT at least). It also breaks a line when there is a linebreak in the HTML source. This happens on IE irrespectively of where it takes the tooltip text from (title attribute or alt attribute).

Thus, if the length of the title text or, in the absence of that attribute, the length of the alt text exceeds 50 characters, divide the value into lines of at most 50 characters, counting the trailing space too.

The ampersand (&) character causes problems on some browsers on some platforms when it occurs in an alt text and a browser displays that text as a "tooltip". Some browsers running on Windows systems use display routines in which the ampersand has a special control effect. This means that an alt text containing, say, "A&M" gets displayed as "AM" with the M underlined. It's a browser bug, limited to some browsers on some platforms, in a browser function that shouldn't exist, but it occurs frequently enough to justify the rule: Avoid using the ampersand character in alt attributes. If you can reasonably replace the ampersand by the word "and" or the character "+" or something like that, do so. But if the ampersand really needs to be there, e.g. because it is part of a trademark-like expression, you have a tough decision.

A different look: "alt attributes considered harmful to accessibility"

Tentatively, I posted the following message to the Usenet discussion group comp.infosystems.www.authoring.html:

Subject: ALT attributes considered harmful to accessibility

OK, now that I have your attention, I can tell that it's not the ALT attributes themselves that are harmful but the recommendations to use them. And naturally everyone has to use an ALT attribute for every img element, every area element, and every input type="image". But my point is that this is of no use, or is of worse than no use, if the attribute value is not adequate. And in reality, most ALT attributes on Web pages are useless, or worse than useless. I'm afraid that e.g. the howlers discussed in Alan Flavell's Use of ALT texts in IMGs are rather typical of the actual use, not just shocking examples.

(Maybe not quite so if you count only those actually written by human beings. But attributes like alt="mksdy.gif (5379 bytes)" are a reality too, and they fully satisfy the "validation" criteria of many accessibility checkers.)

An element's ALT attribute should not be decided by considering the element in isolation. (But such considerations are what people actually make, if they react to recommendations to use ALT for all elements.)

Rather, an author should think how he would write the page if images (or a particular image) are not available. In fact it is best if he actually does just that, writes the page first without images! (With existing pages, the situation is different of course - it has to be a thought experiment.) Then the addition of images is to be considered so that the page keeps working in no images mode too. Sometimes an image replaces some text. Here's where we get to using ALT: if the text is quite short and contains no markup, just turn it into an ALT attribute value. Otherwise e.g. move the text to a separate page and try and find a nice way to refer to it with a link near the image, e.g. in an image's caption text - and aim at being able to use ALT="" without preventing access to any information. Naturally, ALT="" is to be used to purely decorative images. And finally, there are images that have content that cannot be described in words, such as a picture of Mona Lisa; then say that, and name the image in the ALT text so that it becomes obvious that the ALT text is not meant to be taken as such but as a reference to essentially visual information.

Of course, this is ultimately what many people (including me) have kept saying. My mild provocation was meant to ask whether we should say things this way, rather than starting from "use ALT for every image...". After all, all communication fails, except by accident, and when it accidentally fails to fail, the part that gets through is probably the first main point that you make. That is, people will learn just the formal rule, and start misapplying it.

Message-ID: Xns9334946CA1F5Cjkorpelacstutfi@193.229.0.31. Date: 2003-03-04.
(The Subject line was an allusion to the famous "GOTO considered harmful" statement.)

Despite the interesting discussion that it raised, I still don't know what to think about this. I would hate to admit that this document of mine is based on wrong grounds, especially because then I would be morally obliged to rewrite it.

Other treatises on alt texts

The following list refers to some other documents discussing alt texts. Some of them contain views and examples that I cannot agree with, on the basis of arguments presented here.

Related information in other languages

Some basic reasons to always include an alt attribute into an img element

Date of last revision: 2002-08-30. Last update: 2012-01-27. Originally written probably 1998-09, with the title Simple guidelines on using ALT texts in IMG elements.
This page belongs to section Web authoring and surfing of the free information site IT and communication by Jukka "Yucca" Korpela.