Use of ALT texts in IMGs



On the WWW, I see a lot of confusion about the appropriate use of ALT texts in HTML. Although the finer points could be argued, I believe the general principles are more or less as I have set them out in this note. At least, I commend them to you, and look forward to reasoned discussion if you disagree.

The ALT text is meant to be alternative text, primarily for use when the image is not being displayed. The most common mistake (if used at all!) is to provide a description of the image, without considering what job the image was doing on the page, leading to results that can range from the incongruous to the absurd. The ALT text is intended to be a suitable textual alternative to the purpose of the image: sometimes that might turn out to be a description of the image, but in practice that choice seems to be wrong far more often than it's right.

Some readers prefer to see my collection of howlers first.


The first principle of HTML authoring, it seems to me, is to convey information to the reader about some "topic of discourse". That's a high-falutin' way of saying that one is writing a story, advertising a product, offering scientific results, giving a tutorial on basket-weaving, recipes for cooking wild mushrooms, or whatever the "topic of discourse" happens to be. (I'm not considering the special case of writing about HTML or about the WWW - that just confuses the issue.)

Reference to mechanics of the World Wide Web or a particular browser is generally a distraction. There are differences between browsers and platforms, and trying to tell the user how to use the browser with which you, the author, are familiar, can just confuse users of a different browser/version/platform. I recommend authors, as a general rule, to presume that users already know how to operate their browsers, or can find out (Help files etc.), and are hungry for your information about the "topic of discourse". [1]

This note is about web pages that have substantial text content, whose images are an adjunct rather than being the whole purpose of the page. In other words, the content is inherently accessible to text-only readers, and it's the author's job to facilitate such readers to get the best that they can out of the document, in spite of the absence of images. I don't try to cover the kind of WWW document whose information is, for whatever reason, primarily dependent on images, such as say a photo gallery, although some of the points made here can be usefully applied there too.

This note is emphatically not asking you to "dumb-down" your documents in order to make them work on text-mode browsers. What it is doing is asking you to give thought to how your documents will come across in a wide range of browsing situations, and to follow an authoring style that will make best use of whatever combination of resources each reader has at their disposal. That is the big difference between the concept of the WWW, and most other ways of publishing information.

Caveat: If you are mandated to produce fully-accessible documents, then obviously your accessibility guide takes precedence. Please also visit the Web Accessibility Initiative pages at W3C.

Tabular summary.

ALT is no longer the only attribute for conveying text-mode information. With HTML4 we have three or four attributes available, reducing the need for compromise in the way that each is used: the title attribute on the image itself, the title attribute on any link which encloses the image, and the longdesc link to a page with a long description of the image. Advice on how to exploit these features (aimed at disability situations, and broadly helpful in general text-mode browsing too), can be found at the W3C WAI: I encourage authors to phase-in the use of these features in ways that would be helpful to those whose browsers support them.

Look on the ALT text as an opportunity to reinforce your message, as discussed in this item in the W3C WAI email archives, which I thoroughly recommend pondering over: it's a win-win option, which does no harm to those who are already getting your point, but rates to help those readers who would be less-effectively reached without it. See also Ian Hickson's ALT text miniFAQ, his idea of a specification for client agent behaviour, and the Images tests in his Eviltests repertoire.

HTML mechanisms for offering images

In HTML, you can offer an inline IMG, or a regular link (anchor) that points to an image. You may decide to use one or other, or both, of these. If you are offering a link to an image, then your options are to include, within the scope of that link anchor, either an IMG or some normal text, or both. So there is a wide choice of combinations, each of which could be appropriate in particular circumstances. [2]

The ALT attribute of the IMG is intended to be used as alternative text for situations where the IMG is not being displayed. The idea is expressed well in the HTML4 recommendation (section 13.8):

"Several non-textual elements (IMG, AREA, APPLET, and INPUT) require authors to specify alternate text to serve as content when the element cannot be rendered normally."

Note that key phrase: " serve as content...". In section 13.2 there is a very sloppy remark quoted from the comments in the DTD, saying that "you need to provide a description with ALT": we will see in this discussion that a description of the image is often a poor choice as the alternative text, precisely because it does not "serve as content" in the particular context. An insightful tip that I learned from WAI discussions was, instead of thinking of the ALT text as a substitute for the image representation, think of the text and the image as alternative representations for content.

The corollary is that when someone asks "what's the right alt text for this image?", the appropriate first response is "what job is that image meant to be doing on the page: what content does it represent?". Once the answer to that has been given, then choosing the right alt text should follow naturally. Omitting to ask that question, and just composing an alt text by rote without attention to context, produces absurdities of the kind we see in the howlers.

The ALT text itself is not allowed to be marked up by including HTML tags within the text; on the other hand the IMG (and thus its ALT text) is governed by any tags that enclose it, so, for example, if your IMG is a heading, or part of a heading, be sure to enclose it between the n>...n> tags. The use of &entityname; and number; mechanisms is legal, and supported by any reasonable browser now. Text-mode browsers will typically flow the actual text string onto two or more displayed lines if needed, so this is not a problem. Graphical browsers, I am afraid, don't do a particularly good job with ALT texts, and for years it seemed to get worse with each edition of the 'popular' browsers, but there isn't much that you can do about that as a document author. Opera and, now, Mozilla-based browsers, commendably reverse that trend.

Hint: avoid putting line breaks in your source HTML within your ALT texts, as some browsers display badly. If necessary, start on a fresh source line before the ALT= attribute, and end the source line after the closing quotation mark, but don't break the source line anywhere between.

Some people have tried the plausible trick of including number; references for carriage-return and/or line-feed in their ALT text in hope of getting line-breaks in its display, but I'm afraid this isn't part of the specification and doesn't really work.

HTML4 introduces the LONGDESC attribute, for linking to a document offering a long description, which may be supported by specialised browsers, at least: there was a well-established convention for unobtrusively offering such a link using existing mechanisms [4].

Why should authors bother with ALT texts?

Well, from the fact that you're reading this article, I hope you already think it's a good idea, but I have written some notes [3].

Some of the biggest "casualties" on the information dirt-track are documents whose authors didn't take the indexing robots seriously. Every step that you take towards text-mode accessibility is also a step towards being friendly to those indexing robots, so (whether or not you care about minority audiences such as the blind or users of text mode terminals) I'd say it's in your own interest to keep text-mode accessibility in mind.

Appropriate choice of ALT texts

Callie at Writepage commented:

Many authors haven't figured out exactly what they are trying to present; they don't know what it is about the image that's important to the page's intended audience. The reason you can't figure out why their alt [texts] aren't working is that they don't know why the images are there. Every graphic has a reason for being on that page: because it either enhances the theme/ mood/ atmosphere or it is critical to what the page is trying to explain. Knowing what the image is for?... makes the labels easier to write.

When you write predominantly-textual material in HTML, you address three different kinds of user:

I. Those with image loading enabled.
Example: any graphical browser
II. Those browsing in text mode, but having image display available if they so choose.
Examples: graphical browser with auto image loading off; Lynx with a graphical viewer available as helper application
III. Those who have text mode only, and cannot display images at all.
Examples: character mode terminal; readers who use a speaking machine. Indexing robots!

The speaking machine isn't only for blind[4] readers, although why people would want to put additional difficulties in the way of blind people accessing their textual material I can't imagine; a sighted reader might use a speaking machine while resting their eyes or otherwise occupied. Motor-impairment can also mean that an otherwise well-adjusted person cannot use a conventional user-interface (such as the precision needed for a typical imagemap).

When you use an inline image, the ALT text is your tool - not very precise, but a serviceable tool nevertheless - to get your message over to readers of types II and III. There are several different reasons why you might be making images available to your reader, so, not surprisingly, there are several different approaches to choosing an alt text. I found it helpful to categorise four main types of image. These are not meant to be in any order of priority: each use has its proper field of applicability.

a) "Page decorations"

If your reader doesn't display these, there is nothing that an alt text can usefully add to the topic of discourse, and a reader running in text mode is unlikely to want to view or download the decoration. So, code ALT="" in most cases. If you are using one as a link anchor, be sure to include some text in the scope of the anchor too (it is good authoring style to make the significant text be the link, rather than some insignificant bullet or, so help me, "click here"). Spacer images (until this unpleasant crutch has been phased out) should have an ALT attribute which also serves as a spacer (maybe ?).

For cautionary, interrogatory etc. icons the natural choice for text-mode browsers would be something like "[!]" or "[?]", and for bullets ALT="*" etc.; however, in general ASCII-art may produce intrusive results on a speaking browser. Something like this may be worth considering:


As far as company logos are concerned, well, if the name of the company is already on the page in clear text, as is often the case, then the logo can be treated as decoration, and ALT="" is appropriate; if the logo were being used instead of the company name, "Foo Corporation", then I recommend ALT="Foo?Corporation" as the right choice; in fairness I should note that there are differing opinions held on this topic, and only the author can truly know whether they intended the logo to be a visual branding mark on the page, such that no textual replacement would be meaningful, or as a significant element that should be brought to the attention of non-image readers. (But if you sell logos, and are exhibiting specimens of your work, then your logos are your content!)

The often-seen variations on ALT="Company Logo", ALT="Logo of Foo Corporation", or even ALT="Medium size GIF of logo" (!) are incomprehensible: the author is supposed to be providing the reader with information, not with meta-information (descriptions of information). A text description of the logo is generally felt to be inappropriate as ALT text: for those readers who wanted it [4] there are LONGDESC etc.

With the increased emphasis on separation of Content (marked up in HTML) from Presentation (proposed by CSS), it's been persuasively argued that "decorative images" should be treated as "presentational", and so should be taken out of the HTML, and proposed (for appropriate media types) from the stylesheet. This makes sense where you would otherwise compose alt="".

b) "Navigation Icons"

Here, the text equivalent is usually simple enough, being a short statement of the target ("Adventure", "Science Fiction") or function ("Contents", "Next Chapter", "Previous", "Foo Corporation Home Page"). Please bear in mind that browsers already have their own meaning for terms such as "Back", "Home", "Forward", so it is best to avoid the potential confusion that results when the author makes these terms mean something else. Please avoid those "Return to (xyz)" links, that are so irritating to someone who went directly to your page, and has never visited (xyz) before.

By all means help your readers to understand your site layout by using terms such as "Previous", "Up", "Next", or texts which state the destination explicitly ("About Quarks"); but I still say avoid the confusion of the terms "Return" or "Back".

Some authors prefer to offer alternative text-mode links separately from their graphical links, in which case ALT="" would seem plausible; but I prefer to avoid the confusion of two sets of navigation links pointing to the same targets. Also, accessibility checkers rightly complain when they find an image used alone as a link and given ALT="", and some browsers will detect this situation and overrule the ALT="" in the interests of accessibility.

Thumbnails, for "navigating" to a fullsize image of the same thing, are discussed under (c).

Imagemaps are a special case of this category. In some situations, imagemaps play a role that cannot directly be substituted by anything else (geographical maps, for example), but some alternative means of navigation such as an A-Z index or a search can be useful to all kinds of users, you should not devalue it as an extra chore that's only for text-mode readers. Often, though, on the WWW, one sees imagemaps used instead of simple links, presumably on the grounds that it's more complex and so demonstrates the author's prowess. This is a pity, if the author doesn't also have the prowess to make their page usable for all text-mode readers.

Client-side imagemaps, for which browser support is now widespread, are more adaptable for use by text-mode users than the older server-side maps were, so long as you provide them with ALT texts on their AREA tags. Still, as a navigation tool, a row of simple IMG with ALT texts can do the job in an effective manner, that adapts better to changes of window size.

I offer a page about text-friendly imagemaps. Did I say you should provide separate graphical and text-only pages? - I did not: in general I don't believe you need to, and those people who keep yelling "I can't afford the time to make separate text mode versions of my pages" are just looking for some excuse for their own inability to make a web page that is both visually attractive on a graphical browser, and accessible to text mode users.

c) "Supplemental or Interesting"

These are graphics that the user may find helps their appreciation of the text, but are not mandatory to it. I suggest that there are two ways of going about this.

  1. Provide only links to them; show the reader what's on offer with a brief description. Now, the principle says not to fuss about details of the WWW, but in this case, what with limited bandwidth and the possibility of not all image formats being accepted by all browsers, we can make an exception and warn the reader what it is that we are offering here. So an example could be
    Frigate, circa 1800, 560kB PNG

  2. Provide an inline IMG, with an ALT text that summarises the major feature that you wanted to bring to the reader's attention, e.g
    ALT="Warships at that time usually had two rows of cannon"

You should be able to word the body of your text so that it doesn't pre-suppose the reader is also viewing the image alongside. As long as readers of "type II" are aware that an image is available, they can make their own decision whether to load it. Giving readers of "type III" the impression that you are commanding them to load an image will only frustrate and annoy.

Of course, you could combine an inline IMG, with its ALT text, together with a link to an out of line image (typically a larger, more detailed version of it). Then, take care to put the information in its proper place, whether as clear text to be seen by all readers, or in the ALT text aimed chiefly at those who are not loading images. But these are minor details, compared with the major abuse that we see out on the WWW.

If you feel that the IMG needs additional alt text, provide it; if not, then put ALT="". This alt text could typically supply the chief piece of information for which you had provided the picture, e.g following the above example, you might describe the major relevant feature of the vessel illustrated by the picture. The test of appropriateness, as ever, is to imagine the HTML document viewed without the picture?- or imagine reading the document to someone over the telephone?- and ask yourself whether the ALT text supplies useful information about the field of discourse. (Technical information about the missing images is, as I say, tolerated if it's for good reason, but in an article on historic ships, the reader primarily wants information about ships, not technical woffle about the WWW.)

d) Critical for understanding the page

In some fields, this situation rarely arises. In others (e.g science and engineering, and mathematics so long as we have to put equations in as inline images), it's quite a common occurrence. In this case, provided you have somehow made the reader aware that the document will unfortunately be meaningless without them loading the inline images, there may be nothing useful you can do with the ALT text alone (but use of LONGDESC goes beyond the scope of the present page).

'Information is browser independent. Fluff is not' - norm@andrew

Further discussion and thoughts

I don't think cases (a) and (b) really need a great deal of discussion. (c) and (d) are trickier, and it's not always obvious which of the two we're dealing with. One reader's essential illustrations are another reader's optional extras, and in the more borderline cases it's possible to make an image seem to be either essential or supplemental depending on just how you word the text (as Toby Speight pointed out).

In a situation where there is some agreed scheme for a textual representation, then you could use that as the ALT text. If your audience is accustomed to reading mathematical equations in LATEX notation, you could use that as alt text for the image of the equation. If you are dealing with heraldry, then you might use the appropriate heraldic description or "blazon", Three Seaxes Argent in pale on a field Vert. Similarly if the image represents musical notation, needlework, or anything else for which there is also an accepted textual notation. In fairness, there are cases where a graphic is absolutely essential to the meaning, and no reasonable amount of text can possibly replace it. But this is no excuse for providing useless alt texts in those situations where a useful one could be provided.

We had an example a little while back in which someone had suggested (in the context of holiday offers) an alt text that said ALT="Picture of Hotel". I say this is inappropriate because it tells us nothing about the topic of discourse - instead, it tells us chiefly about the mechanics of the WWW. What the reader, particularly a reader of "type III", wants to know is - what does the picture show that's relevant to the topic of discourse? The picture might show, for example: ALT="The Pines Hotel, a fine old stone building in extensive grounds". This is suggested as an alt text, rather than as a caption, because those readers who can see the picture will already be able to see it for themselves. If you want to also offer them a link to the picture, then do so, in one of the ways mentioned above. (Even a blind reader might want to download the picture, to show it to a friend later.)

Readers of "type II" already have browser facilities that allow them to retrieve the image if they so choose (Lynx puts the inlines only a keystroke "*" away); there is nothing extra that the author really needs to do about it - and after several discussions of what the author could do, nobody seems to have come up with anything that really provides worthwhile additional help to the text-only user without needlessly distracting the graphics-based user. (As so often on the WWW, the important thing is to mark up the information honestly for what it is, rather than trying to out-guess the browser designer; if there are limitations in the facilities that one or other browser offers, then the place to remedy them is in the browser design, not in the author's HTML source.) When I mentioned in a usenet discussion my dissatisfaction with the above text, "Picture of Hotel", someone helpfully suggested "Download picture of Hotel". I hope that by now I've made it clear why, far from being an improvement, this seems to me to be even worse: it concentrates yet again on the mechanics of the WWW rather than on the "topic of discourse".

One suggestion was to capitalise on the typical text-mode browsers' [IMAGE] notation by putting the ALT text within square brackets, so that text-mode users would associate this with an image: ALT="[The Pines Hotel, a fine old stone building...]". This seems a good idea for sighted users, but again the extra punctuation might be intrusive for voice browsers.

As said before: if the image is mandatory to your presentation, then say so plainly. If not, then don't pester the reader to load it: tell them what information it contains relevant to the "topic of discourse", and leave them to take action as they consider appropriate.

"This page has been visited [Counter Image] times"
"Accessed [a bitmapped number] times since 12/1/95"
(and several variations on this theme).

Well, this has nothing to do with the "topic of discourse". I don't think any of the variations could be claimed to be good style (not forgetting that 12/1/95 means something different to European readers than what it means to USAns). But I can't work up any enthusiasm for page counters, nor can Jeff Goldberg.

ALT text as "tooltips"?

Version by version, popular graphical browsers got worse and worse in their display of ALT texts when auto image loading was off. Then they seem to have hit upon the idea of displaying the ALT texts as "tooltips" when the mouse pointer was on the image location. Plenty of authors seem to have reacted by using the ALT text to specify their desired tooltip text, regardless of the text being entirely inappropriate for use as the "alternative text" described in the HTML specifications.

Well, HTML4 has an answer to this: the TITLE attribute. The HTML4 spec says explicitly that it would be appropriate for the TITLE attribute to be displayed as a "tooltip", so it all falls into place. Use the ALT text for the purpose of providing alternative text, for example along the lines discussed in this article, and use the TITLE attribute to title the image, in a way that would be appropriate for a tooltip. Support for the TITLE attribute was introduced in MSIE4, and in Opera and other browsers: the major problem was Netscape 4.* releases, but Netscape 6 finally supports it.

More about this in ALT text as popups: a critical response.

The Decorative Horizontal Rule

Authors ask, reasonably enough, to use an IMG of a decorative rule in the graphical display, that falls back to some kind of separator in a text mode display: several ways of doing that have been suggested, but none are without shortcomings.

Style sheets are the least harmful way: current levels of browser support make this relatively easy, compared to the contortions which I found necessary in my earlier report about using styles with an HR.

In theory, inserting your decorative image with OBJECT, and supplying HR as the fallback, would be another solution entirely within the philosophy of HTML, but sadly not well implemented by even the latest crop of browsers.

Discussion of the various solutions on usenet brought a number of strongly-held but mutually incompatible views, so if none of these solutions appeal to you, it might be advisable to re-cast the design so that the problem doesn't need to be solved..

Spacing between alt texts

Consider some images crammed together, for example as navigation buttons:

ALT="The University">...

When viewed on a text-mode browser, this is going to read:

The UniversityThe Town...

Various solutions may be considered:

The above ideas are serviceable in quite a range of browsing situations, though I have to admit that some speaking browsers are less than ideal, for example it's no fun listening to left square bracket, right square bracket while the links are being read out (example from an earlier version of IBM Home Page Reader).

Navigation to be text-friendly and accessible

Some accessibility guidelines recommend having more than just space(s) separating adjacent link texts. But most users of graphical browsers don't need or want such separators. Here's a suggestion: as ALT texts for the images within the scope of the links, use the appropriate texts without additional separators. Then, between those images, outside of the scope of the links, place one-pixel transparent GIFs with their alt text set to "|" to act as text mode separators. See the navigation bar at the foot of this page where this is used in practice. (At least, it is so used until I take the opportunity to follow my own advice, and re-design the links as a CSS-styled list.)

Note that the buttons do not have their height and width specified, whereas the separator pixels have their height and width (=1) specified. I've played around with this on a range of browsers, and it seems to me to be a nice compromise. When image loading is enabled, graphical browsers produce a result that is practically indistinguishable from the earlier constructs. On graphical browser/versions with image loading disabled, some gave good results while others were visually rather poor, but all were at least serviceable. The results on text browsers (Lynx and emacs-w3) were entirely acceptable. (I used to suggest alt="?|?", with white space either side of the bar, but I now know that this produces undesirable effects in IBM Home Page Reader, for example.)

OK, this is just one suggested solution: maybe other authors will find a better compromise; and, as specialised browsers are developed further, the need for some of these workarounds may fade away. Again one might consider whether it was better to offer a simple text menu in the HTML, that would be serviceable from any browsing situation, optionally modified from the stylesheet to give visual styling for appropriate media types.


There had been a long-running debate on c.i.w.a.html about the wisdom of providing correct HEIGHT and WIDTH attributes on IMG tags. The idea is that the browser can reserve space for the image before the image is retrieved, and in consequence can present the normal text properly formatted on the page as soon as the text is available, simply slotting the images into place later as they arrive.

Browser versions differ in how they support this when image loading is turned off. Some (e.g Netscape 4.* versions) will display the ALT text only partially, or not at all, if the specified rectangle is too small. MSIE can display the whole ALT text, but it is not the default (Tools/ Internet Options/ Advanced/ Accessibility/ "Always expand ALT text for images"). The behaviour while waiting for image loading to be completed (some browsers display the ALT text during this interval) may or may not be the same as the behaviour when image loading is turned off. Too many variations of behaviour have been seen, between browsers and between versions, to be able to give an account of them here. On balance I think the only advice I can offer is to normally include correct HEIGHT and WIDTH information; but if these are likely to be too small for the text, then you might decide to deliberately omit those attributes.

Related topics

The colour of ALT text is discussed separately.

There's also a separate page about INPUT TYPE=IMAGE.

Reader comments and questions

A few howlers

Reality check - some typical scenarios in a text mode browser:

The online edition of a prestigious US newspaper was seen promoting its partners thus

   P A R T N E R S :

This was seen on a unix system for which the recommended browser is not in fact available:

    Our site is best experienced with: [LINK]Click to Get It!

Then, there was this great piece of self-advertising (spelling as in original):

        Another fine Web sight from [Company Logo]
An English Borough Council making its mark:
   Welcome to...
   Borough Crest
   The Borough of

   Having problems accessing our site? [Click Here]
An anonymised extract from the front page of a German web site service provider:
   [LINK]-visual fubarGmbH direct rubriken

   [space.gif] [space.gif] [space.gif] [space.gif] [space.gif]
   [space.gif] [space.gif]
   [space.gif] [space.gif] Privat [space.gif] [space.gif] [space.gif]
   [space.gif] [space.gif] [space.gif] [space.gif] [space.gif]
   [space.gif] Aktuell [space.gif] [space.gif] [space.gif] [space.gif]

(My informant tells me they were immediately taken out of consideration for the contract.)

Artistic licence(?):
   getquicktime.jpg getflash.jpg plugintester.jpg

This artist had used a whole job-lot of images (almost exclusively images of text), each solemnly furnished with an ALT text which repeated the image's file name, like so:

   img src="site_requirements_images/inorderto.jpg" alt="inorderto.jpg"
"This site is [LINK]etscape [INLINE]"

Way back, I browsed the results of a web search for the string "etscape", and found some HTML sources varying from the slightly silly to the sheer demented! Interestingly, when I reviewed this in 2002, it looks as if most of the "etscape-enhanced" sites are from 1997 or earlier. How fashions fade!

ALT="Large Yellow Bullet"

So we get to read (or blind readers get to hear):

    Large Yellow Bullet Introduction
    Large Yellow Bullet The Problem
          Small Red Bullet Historical Analysis
          Small Red Bullet Current Situation
    Large Yellow Bullet The Solution

The web site of the US Embassy Belgrade had this prizewinning example:

    Small red bullet Response to Terrorism
ALT="This image is mapped, please download it"

For text-mode browsers, this does not help. I've already made some more-appropriate suggestions above. See my accompanying imagemap page for more detail and references.

ALT="Turn on image loading, damnit!"

One wonders just how many potential visitors have given that site a miss because it "welcomed" the indexing robot in such a brusque and uninformative fashion.

ALT="Imagemap of various flags"

What would a text-only user want with an image of some unspecified flags? This is supposed to be a navigation tool, not a guessing game!

Alt="(Sorry, Not Available With Your Web Client)"

Nonsense! I was using Netscape with image loading turned off. Even if I had been using Lynx, who are you to say that I can't fire up a helper application to see this image?

[LINK]-- Self explanatory

An image of some "self-explanatory" text, with no ALT attribute.

ALT="Put your alt text here"


"Oldtown University arms Physics Department"

Gosh, could they be Weapons of Mass Distraction?... Ah: this is their Physics Department's web page, decorated at the left with the University's coat-of-arms (not ours: but name changed to protect the guilty...).

"Photo of a bull in the water canoeing"

I beg your pardon? Ah, here's what went wrong:

The original site, which featured a scenic Canadian river, showed two perfectly reasonable, but unrelated, pictures: later, a reader of this article, "Michael T.", sent me a fine illustration of this howler!.

"Academic departments are indicated by pink bullets".

Unusable in text mode, or on a monochrome display. Choose a graphic icon that can carry the message by its shape - in this case it could be a little mortarboard (no harm in making it coloured too); and choose distinctive text markers to use for the ALT texts, e.g.:

Academic departments are indicated
by: ALT

(making the corresponding adjustment to the list itself, of course).

This was "leakage", where the author had made the mistake of referring from the text to some aspect ("pink bullets") of the presentation that would only be perceived by a subset of readers. The WWW, by its very nature, will separate content from presentation in this way: a careful author can choose a style of authoring that does not fall into this kind of trap.

ALT="Loading... Please Wait"

Nice try! But who guarantees that the browser is, in fact, loading images at this time? As Jukka K says, 'Should I wait until I get some mental disorder that makes me click on the "show images" button?'

ALT="Plot of fish population against date"

This is a more subtle problem, but the poor text-mode reader is left wondering what the heck is that graph-plot supposed to be telling me?. A more helpful text might be "Graph: fish population fell dramatically through 1980's until fishing moratorium imposed", or whatever the graph actually illustrates.


Oh dear! Is nothing sacred??- this came from (an earlier version of) the welcome page of the W3C themselves! Several images had been displayed together, without any provision for spacing or punctuating their ALT texts.

My favourite howler went something like this
Our Classrooms and Staff ALT="fancy horizontal rule">

Instead of using

for this first level header, they had simply marked it up with a font size: there was no linebreak implied between the text and the image. With image loading on, this was not a problem: the "fancy horizontal rule" was so big that it automatically went onto a new line. However, with text-mode browsers this whole thing was quaintly rendered as

Our Classrooms and Staff fancy horizontal rule

Certainly they should have used H1 markup for the header. One way to handle a decorative horizontal rule is mentioned above.

(Comment: you may be able to find some of the examples with search engines which include alt text; others have been adapted, or some examples taken and a composite "howler" made. Search engines which index ALT texts still have no problem finding plenty of pages containing "small red bullet" or similar, and they aren't all web authoring tutorials advising you not to do it, unfortunately.)

I don't believe that any particular familiarity with a text browser, nor indeed with a speaking machine, was required in order to select a useful ALT text for most examples. If the document had been marked up by giving appropriate thought to the content that is to be communicated to the reader, rather than getting side-tracked by the mechanics of the WWW, then it could have "worked" on every browser - and searcher and indexer. And without in any way degrading its visual appearance in the common graphical browsing situations.

To sum up:

Related pages:

My thanks and best regards to all who have contributed to the discussions on earlier drafts of this note.

"Plagiarism is the sincerest form of flattery"? Apart from a version of this article which was featured at the WDG site with my agreement and full co-operation, and extracts which have been used with my permission in a couple of other places, web search engines have found several different sites that had "lifted" substantial parts of this article without asking permission or acknowledging their source, including one that had applied their own copyright notice onto my material. I suppose I should be pleased that the ideas are finding such an echo, but...