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:

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 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 .

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:

utility descrip­tions that 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 preferthat 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.

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.

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?

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:

You cannot use HTML tags within an alt attribute, just plain text. However, entities can be used, e.g. é for the character é. See notes on character set later.

within an attribute, just plain text. However, entities can be used, e.g. for the character é. See notes on character set later. On the other hand, an img element may appear inside other markup . It is allowed wherever text-level elements are allowed, e.g. within a H1 element (indicating first-level heading). Thus, you could write

<H1><img SRC="logo.gif" ALT="FooBar Company"></H1>

and you probably should do so, if the image actually plays the role of an overall page heading (e.g., on FooBar's main page). The use of H1 markup would have no effect on the image itself, when the img element is shown as an image. It may have an effect on the text appearance when the alt text is displayed instead; unfortunately just a few browsers do the logical thing, showing the alt text in such a context in the presentation style used for headings. In addition, heading markup often causes some top and bottom margins, i.e. extra vertical spacing. You might wish to use CSS to suppress or reduce the spacing (even down to using h1 {margin:0;} ).

element may appear . It is allowed wherever text-level elements are allowed, e.g. within a element (indicating first-level heading). Thus, you could write and you probably should do so, if the image actually plays the role of an overall page heading (e.g., on FooBar's main page). The use of markup would have no effect on the image itself, when the element is shown as an image. It may have an effect on the text appearance when the text is displayed instead; unfortunately just a few browsers do the logical thing, showing the text in such a context in the presentation style used for headings. In addition, heading markup often causes some top and bottom margins, i.e. extra vertical spacing. You might wish to use CSS to suppress or reduce the spacing (even down to using ). An advertisement text might be reformulated so that it becomes obvious that it is an advertisement. The visual appearance and positioning usually makes this evident, but in non-visual presentation the situation is different. A simple indication might be suitable: alt="Ad: New mudgets available..." .

text might be reformulated so that it becomes obvious that it is an advertisement. The visual appearance and positioning usually makes this evident, but in non-visual presentation the situation is different. A simple indication might be suitable: . For an animated GIF image that contains first some text, then something else, the alt text should contain all the textual information.

GIF image that contains first some text, then something else, the text should contain all the textual information. If the text in the image contains characters that cannot be represented reliably in the character set available in normal text – which is often the reason for using an image instead of text – ;you need to find a way to present the same information otherwise. For example, a transliteration might be used, as in an old version of the main page of the European Union. It it contained greetings in different languages, but due to character set problems, the Greek text was there as an image, with an alt text presenting the Greek word as transliterated into Latin alphabet: ( alt=" Kalosorisate " ). This made the Greek version look exceptional, deviating. A later versíon had all the texts as images, with English text alt="The European Union On-Line(Greek)" for the Greek text image. Though illogical, such an approach might have been preferable for practical reasons, since the Greek letters would not have worked well. (A transliteration might not be understandable enough to Greek-speaking people, and would confuse others especially since there are different transliteration and transcription schemes in use.) Nowadays, the EU page is Unicode encoded (UTF-8 encoded), with all languages treated equally and with all links as text. (The two-letter codes for languages are images, though, for no apparent reason – they could be presented as styled text.)

If the text in the image contains reliably in the character set available in normal text – which is often the reason for using an image instead of text – ;you need to find a way to present the same information otherwise. For example, a transliteration might be used, as in an old version of the main page of the European Union. It it contained greetings in different languages, but due to character set problems, the Greek text was there as an image, with an text presenting the Greek word as transliterated into Latin alphabet: ( ). This made the Greek version look exceptional, deviating. A later versíon had all the texts as images, with English text for the Greek text image. Though illogical, such an approach might have been preferable for practical reasons, since the Greek letters would not have worked well. (A transliteration might not be understandable enough to Greek-speaking people, and would confuse others especially since there are different transliteration and transcription schemes in use.) Nowadays, the EU page is Unicode encoded (UTF-8 encoded), with all languages treated equally and with all links as text. (The two-letter codes for languages are images, though, for no apparent reason – they could be presented as styled text.) If the image is a link and the text in it is an instruction like "Click here" or "Mail me", then the best approach is to remove or change the image or its use. Links express relations; verbs express actions; hence a link should rarely contain an imperative verb. Vague words like "Mail" or "Home", on the other hand, are often inadequate too; they don't tell what the link really leads to. But even if the text in an image is kept as poorly selected, the alternate text could be better. In particular, it should not refer to clicking but identify the resource that the link points to. An image of a mailbox, with or without words like "Mail me" in it, as a symbol for E-mail is questionable for several reasons. If used as a so-called mailto link (the common case), it should preferably have an alt text that specifies the address itself, since people who need alt attributes may well need to use a special E-mail program rather than an E-mail facility built into the browser. So a reasonable way would be something like the following:

<a href="mailto:jkorpela@cs.tut.ti"><img src="mailbox.gif" alt="E-mail to author: jukkakk@gmail.com" border="0"></a>

like "Click here" or "Mail me", then the best approach is to remove or change the image or its use. Links express relations; verbs express actions; hence a link should rarely contain an imperative verb. like "Mail" or "Home", on the other hand, are often inadequate too; they don't tell what the link really leads to. But even if the text in an image is kept as poorly selected, the alternate text could be better. In particular, it should not refer to clicking but identify the resource that the link points to. An image of a mailbox, with or without words like "Mail me" in it, as a symbol for E-mail is questionable for several reasons. If used as a so-called link (the common case), it should preferably have an text that specifies the address itself, since people who need attributes may well need to use a special E-mail program rather than an E-mail facility built into the browser. So a reasonable way would be something like the following: The alternate text need not be identical with the text in the image. Sometimes the communicative purpose even requires some modifications. For example, in a list of entries, an image with the word "New" in front of each new entry might work well; it would be evident from the appearance that the image is a special symbol. In speech or text-only presentation, things could be different: if alt="New" were used, the word "New" might be misunderstood as part of the entry text. Thus, alt="(new)" or even alt="New entry:" might work better.

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.

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.

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:

use some character that resembles a bullet, such as "*" use some character that resembles a bullet, such as use a dash-like or other character that is commonly recognized as having a meaning similar to a bullet, such as "-" use a dash-like or other character that is commonly recognized as having a meaning similar to a bullet, such as 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. use a word, with adequate punctuation added, such asor, perhaps better, words that reflect the progression of the sequence, like, 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.

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. 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.

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!

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.

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."

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.

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.

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

text that just describes the image; text that communicates verbally the same thing as the image; 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."

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)].

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,

If the image is decorative or would for other reasons have alt="" if it had no caption, make it so if the caption text makes sense if read as an independent piece of text. For example, "Ministers X and Y met in Syldavia."

if it had no caption, make it so if the caption text makes sense if read as an independent piece of text. For example, "Ministers X and Y met in Syldavia." Otherwise for an image that would have alt="" as standalone, write a short alt text that indicates the presence of an image. Example: alt="(photo of meeting)" when the caption text is "Ministers X (on the left) and Y met in Syldavia".

as standalone, write a short text that indicates the presence of an image. Example: when the caption text is "Ministers X (on the left) and Y met in Syldavia". If the image is essential and needs a lengthy textual alternative, use such an indicative alt and consider making the caption a link to the explanation, as explained in the next section.

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.

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:

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 .

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.

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):

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?

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.

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 É ) 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 (").

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.

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:

The dimensions of the image have been specified in HTML attributes or in CSS.

The alt text fits on one line within those dimensions.

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.

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.

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):





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 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 may cause the rest of the text to be ignored!

Browser behavior varies:

If the alt text does not contain linebreaks , then most browsers (e.g. Netscape 4 and IE 5) present it as one line. This is not incorrect but often very annoying if the text is long, since the user has to scroll horizontally to read the whole text, or (depending on browser) the text line spans across the screen, and if it is very long, the tail is totally inaccessible. Opera behaves much better: it presents the text in a box which adapts to the available horizontal space with word wrapping. That is, it acts as it normally does when displaying document content - it divides the text into words, separated by spaces or, equivalently, newlines, and formats the text to fit the screen area allocated. As a peculiarity, Opera centers each line horizontally. Lynx effectively handles an img element as if it were replaced by the value of the alt attribute, so it too formats the text normally, with line wrapping. Mozilla seems to have reached the same functionality.

text , then most browsers (e.g. Netscape 4 and IE 5) present it as one line. This is not incorrect but often very annoying if the text is long, since the user has to scroll horizontally to read the whole text, or (depending on browser) the text line spans across the screen, and if it is very long, the tail is totally inaccessible. Opera behaves much better: it presents the text in a box which adapts to the available horizontal space with word wrapping. That is, it acts as it normally does when displaying document content - it divides the text into words, separated by spaces or, equivalently, newlines, and formats the text to fit the screen area allocated. As a peculiarity, Opera centers each line horizontally. Lynx effectively handles an element as if it were replaced by the value of the attribute, so it too formats the text normally, with line wrapping. Mozilla seems to have reached the same functionality. If the alt text contains linebreaks , e.g.

alt="This is one line

and this is another one."

then Netscape 4 incorrectly ignores the linebreaks, treating our example similarly to alt="This is one lineand this is another one." We can overcome this problem by putting a space at the end of a line if the attribute value continues on the next line. Unfortunately Mozilla 1.0 seems to mistreat linebreaks even more badly, introducing some spurious characters into the display. IE incorrectly (but somewhat conveniently) breaks a line in the display of the alt text when there is a newline in HTML source. (This is incorrect because it violates the above-mentioned requirement about newlines being equivalent to spaces.) Opera correctly treats linebreak as equivalent to space.

text , e.g. then

In principle, XML rules (which apply to XHTML) change the way that character references such as 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 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.

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=" " , 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.

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 .

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 "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 "A M " 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.

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.

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