Use of ALT texts in IMGs

Introduction

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 provide alternative or substitute text, primarily for use when the image is not being displayed. The most common mistake (apart from not using it 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 should be composed as a suitable textual alternative to the image: sometimes that might turn out to be a description of the image, but in practice that choice seems to be wrong more often than it's right.

Some readers say they prefer to see my collection of howlers first.

Principles

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 a document about HTML or about the WWW - that just confuses the issue.

Reference to the mechanics of the World Wide Web or of a particular browser is generally an unwelcome 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, is very likely to confuse them if they are using a different browser/version/platform. I recommend authors, as a general rule, to assume that users are already familiar with the operation of their browsers, or have appropriate ways of finding out (Help files etc.), and are hungry for your information about the "topic of discourse". [1]

This note is about the kind of WWW document that is primarily textual, whose images, where used, are an adjunct to the textual information. In other words, the document is inherently accessible to text-only readers, and it's the author's job to make sure that such readers 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, genuinely dependent on images.

This article was written at a time when ALT was the only available attribute for communicating IMG information to text-only readers, and the conclusions involve some compromises as a result. With HTML4.0 we have three or four different attributes available, and so, some of the compromises implicit on this article can be relaxed, at least when suitable browsers are widely enough deployed. That could be a topic for a later update of this article.

This note is 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 different reader has at their disposal. That is the big difference between the concept of the WWW and most of the earlier concepts for making information available on the 'net.

Caveat: The advice in here (although aiming at a wide range of browsing situations) may occasionally be incompatible with strict accessibility guidelines. Please visit the Web Accessibility Initiative pages at W3C. If you are mandated to produce fully accessible documents, then obviously your accessibility guide takes precedence.

Tabular summary, for those with too little time.

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

In section 13.2 there is a very sloppy remark saying that "you need to provide a description with ALT": we will see in this discussion that a mere description of the image is often not appropriate to use as the alternative text.

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 forms part of a heading, be sure to enclose it between the Hn.../Hn tags. It's been clear since the HTML2.0 spec that the alt text is intended to support the &entityname; and &#number; mechanisms for representing displayable characters, and nowadays browsers get that right (some early versions didn't). This does not mean that you can get line breaks displayed in ALT texts by using the control codes  and/or  - there isn't any defined way for an author to call for a line-break at a specific point of an ALT text. 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 it seems to get worse with every release of the mass-market browsers, but there isn't much that you can do about that as a document author (recent issues of MSIE4 have an option on the "Advanced" menu, curiously not set by default, to display the whole ALT text when images are turned off).

Hint: avoid putting line breaks in your source HTML within your ALT texts, as some browsers display badly (either displaying a rectangular block at that point, or leaving no gap at all). If necessary, start on a fresh input line before the ALT= attribute, and end the input line after the closing quotation mark, but don't break the input line anywhere between.

HTML4.0 introduces the LONGDESC attribute, for linking to a document offering a long description, but we can't expect much support from browsers for that yet: there is a well-established convention for unobtrusively offering such a link using existing mechanisms, which would be useful to blind readers [4] if you'd like to offer this.

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] on this topic.

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, at the same time, 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

Henry Churchyard's small page quotes some earlier usenet discussions about 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 human being is unable to make use of a conventional user-interface (such as the degree of control needed to operate a typical imagemap).

When you use an inline image, the ALT text is your tool - not a very precise tool, but a serviceable tool neverthless - 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, then there is nothing that an alt text can usefully add to the topic of discourse, and there is little likelihood that a normal reader who is running in text mode will want to view or download such a decoration. So, code ALT="" in most cases. In the event that 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". Cautionary or interrogatory icons might be replaced by something like "[!]" or "[?]", and bullets with ALT="*" etc.

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 an otherwise unimportant identifying mark on the page, or as a significant element that should be brought to the attention of non-image readers. (If you are a vendor of logos, exhibiting specimens of your wares, 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 accepted conventions of offering a separate description.

b) "Navigation Icons"

These are, of course, links to other documents. The text equivalent is usually simple enough, being a short description of the target ("Adventure", "Science Fiction") or function ("ToC", "Next Chapter", "Previous", "Foo Corporation Home Page"). Please bear in mind that browsers already have their own meaning for terms such as "Back", "Home" and maybe "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 xxx" links that are so irritating to someone who went directly to your page, and has never visited xxx before. I prefer just "xxx", but you can put "Go to xxx" if you feel that you must. (Each browser has its way of showing the reader that a text is a link - often showing it underlined or boxed, and/or in a distinctive colour, and/or flashing up a URL in a status area, so the "Go to" is redundant IMHO.)

By all means help your readers to understand your site layout by using terms such as "Previous", "Up", "Next", or texts such as the examples in the previous paragraph, but I still say avoid that irritating little word "Return".

A reader comments to me that some early graphical browsers do not display the ALT text when image loading is off, and they prefer to offer separate text-mode links in addition. Seems a fair enough decision, though I don't make that choice myself (based on my perception of current browser usage, including some fairly elderly versions). At least, if you do include text-mode links, you may as well code ALT="" for the corresponding IMGs.

If the icons are in fact thumbnails for "navigating" to a fullsize image of the same thing, then see later discussion 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 engine 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 ALTs can do the job in an effective manner, that adapts better to changes of window size.

I offer a separate 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 site being inaccessible 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.
i) 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
<a href="...">Frigate, circa 1800, 160kB PNG</a>
ii) 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 (either the same image, or a larger, more detailed version of it). In this case, 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 kind of alt texts that I am criticising in this article.

If you feel that the IMG needs some additional alt text, provide it; if not, then put ALT="" as usual. 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 yourself 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 there 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 (Callie's, for instance) this situation rarely arises. In others (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. If you have a mixture of optional graphics with a few mandatory ones, maybe you could consider using the ALT text of the mandatory graphics to inform the user that they need to load this particular image for proper understanding; most browsers support selective loading of a few desired inline graphics, even where the reader is unwilling to load a heap of decoration over a slow network.

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 of the image, then you could use that as the ALT text. If your audience is accustomed to reading mathematical equations in L^AT_EX notation, you could use that as alt text for the image of the equation. If you are dealing with heraldry, then for a picture of a shield you might use the appropriate heraldic description or "blazon", Three Seaxes Argent in pale on a field Vert. 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 subject 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. That seems a good idea, so an example might be:
ALT="[The Pines Hotel, a fine old stone building...]".

As I 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: indicate to them what information it contains that's relevant to the "topic of discourse", and leave them to take whatever action they consider appropriate.

As for pure decorations, your readers don't want to see [IMAGE] sprinkled around! So be sure to code an explicit ALT="" for your decorative images, and provide something suitable for bullets and rules. Please, do not use character code points that are undefined in the spec for the level of HTML you are using, but that just happen to produce a bullet on your particular platform: these may produce anything, or nothing, on other platforms.

"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, so I'm not going to suggest a better way of doing it. If you're a page counter fan, I'm sure you'll work something out with a bit of Server Side Includery or CGI.

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 remedying the loss by displaying the ALT texts as "tooltips" when the mouse pointer was on the image location. Perhaps that wasn't such a bad idea in itself, but plenty of authors seem to have reacted by using the ALT text to specify their desired tooltip text, regardless of the fact that it was an entirely inappropriate text for use as the "alternative text" described in the HTML specifications.

Well, HTML4.0 has an answer to this: the TITLE attribute. The HTML4.0 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 element to title the image, in a way that would be appropriate for a tooltip. MSIE4 already supports this, for one example, and can be configured (via a checkbox on the Advanced Preferences menu) to display the whole ALT text on the page when images aren't loaded.

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. You might try:

<P ALIGN=CENTER><IMG SRC="rule.gif" ALT=". o O o ."></P>

choosing your own decorative string ad lib ("-----" or "- - -" or whatever); but be aware that this may produce strange results on a speaking browser, or on a "tooltip" popup.

Style sheets also offer a possibility, by 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:

<IMG SRC=univ.gif ALT="The University"><IMG SRC=town.gif ALT="The Town">...

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

The UniversityThe Town...

Various solutions may be considered:

• If the ALT texts themselves are single words, then it may be sufficient to include space(s) in the ALT texts, e.g this sequence of ALT texts for some navigation buttons:

  "Left ", "Right ", "Index ", "Config" etc.

  so that the text mode page will look like this

  Left Right Index Config

  But note that the HTML4.0 recommendation warns against using leading/trailing "white space" on attribute values.

• Vertical bars are a popular alternative: to get e.g:

  |Left|Right|Index|Config|

  the ALT texts might be respectively: "|Left|", "Right|", "Index|", "Config|"
• Brackets balance well and they reflect the typical text-browser convention of [LINK]. ALT texts such as "[The University]", "[The Town]", "[Main Index]", etc., producing the obvious result:

  [The University][The Town][Main Index]

Although the above ideas are serviceable in quite a range of browsing situations, and would be entirely acceptable if the relevant IMGs were not in the scope of anchor links, there's one point on which they fail. We deal with that next.

Navigation to be text-friendly and accessible

Accessibility guidelines recommend having something more than space(s) between adjacent link texts, at least with the current crop of browsers/ screen-readers that sight-impaired users might be using. But most users of graphical browsers don't need or want such separators. One approach to that is as follows. 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 " | " or " - " to act as text mode separators. Here's a modified navigation bar to demonstrate the idea:

 

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 and, as far as I could see, they conformed with the accessibility guidelines (not forgetting to put the TITLE attributes to proper use, of course; but that is a topic for a later discussion).

OK, this is just one suggested solution: maybe other authors will find a better compromise, and in the longer term it may be hoped that suitable browsers would be available where this kind of author-supplied workaround isn't necessary.

The colour of ALT text

The colour of ALT text is discussed separately.

HEIGHT and WIDTH?

There has 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 (and this is true of e.g recent Netscape versions) will display the ALT text only partially, or not at all, if the specified rectangle is too small. 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 the h/w attributes.

INPUT TYPE=IMAGE

(There's now a separate page about INPUT TYPE=IMAGE.)

A reader comment

A correspondent suggests that many of the misuses described here are being caused by the "authoring tools" which authors are using to create their WWW documents. That isn't much of an excuse, is it? HTML markup is simple enough already: certainly it makes sense to use an appropriate software tool if it genuinely saves drudgery. But when the tool prevents you from producing documents that conform to good authoring style, then you should be questioning your original decision to rely on that tool.

A few howlers

All of these examples represent things I have seen on the WWW.

Reality check - typical scenarios in text mode:

                Click on your choice now:
                        [LINK]
                        [LINK]

    Grateful thanks to our Sponsors, [LINK] and [LINK]

or this, as seen on a unix system for which their 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 advertising (spelling as in original):

        Another fine Web sight from [Company Logo]

or, to quote from an information site of a major corporation:

                spacer image

                [INLINE]

                spacer image

You wouldn't do that to your readers, would you? (;-)

"This site is [LINK]etscape [INLINE]"

I spent a few minutes browsing the results of a www search for the string "etscape", and found some HTML sources varying from the slightly silly to the sheer demented!

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

(Yes, I have genuinely seen this kind of thing on the WWW, I am not making this up. What were these authors thinking of?)

ALT="This image is mapped, please download it"

For Lynx users, this does not help. I've already made some more-appropriate suggestions above. See my accompanying document 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"

¿Qué?

"Oldtown University arms Physics Department"

Gosh, has it come to that? Ah, this is the Physics Department's web page, decorated at the left with the University's coat-of-arms (name changed to protect the guilty...).

[THUMBNAIL] [THUMBNAIL] [THUMBNAIL] [THUMBNAIL] [THUMBNAIL]

A heroically misguided attempt to comply with the authoring advice to "be sure to provide an ALT attribute on every IMG" - by putting ALT="[THUMBNAIL]" on every one!! Sorry.

"Photo of a bull in the water canoeing"

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

<IMG SRC="bull.jpg" ALT="Photo of a bull in the water">
<IMG SRC="canoe.jpg" ALT="canoeing">

The original site, with two perfectly reasonable pictures, might still be found via AltaVista search: 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, if you want); and choose distinctive text markers to use for the ALT texts, e.g.:

Academic departments are indicated
by: <IMG SRC="mortarboard.gif" 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. A careful Web author will separate their content clearly from details of its presentation.

"Click on the green text"

The author had turned a few words of text into an image, which, as it happened, was green. They had remembered to supply the same text in the ALT attribute, but had apparently forgotten (1) that "click on the text" needlessly assumes a specific kind of browser, and (2) the author can have no assurance of what colour the text will be in a particular display situation. Apart from those two points, and the fact that readers who are on slow networks do not find it any particular benefit that a dozen bytes of text has been turned into several kilobytes of image, the author had done a fine job! Another case of "leakage", I'd say, on top of the highly infectious "click here" disease.

"[INLINE] understands the important relationship of graphic intensive pages versus rapid user access time."

It's difficult to believe that they really do understand that, isn't it?

ALT="Loading... Please Wait"

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

J.K also told me about a site where the body of the text had been translated into Swedish, but the ALT texts left in the original Finnish.

An email correspondent called my attention to a site with a series of links buttons with ALT texts as below (company name altered). I don't know whether to classify this as a howler, or as a deliberate attempt to hoodwink the indexers - but it sure looked clumsy on any text-mode browser:

Acme Computer Graphics Company home button
Acme computer Graphics company info button
Acme Computer graphics Company tools button
...etc...

MIT/LCSINRIAKeioDARPACEC

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, with ALT texts that didn't include any punctuation nor even spaces.

My favourite howler went something like this

<CENTER>
<FONT SIZE=6>Our Classrooms and Staff</FONT>
<IMG SRC="rule.gif" ALT="fancy horizontal rule">
</CENTER>

Instead of using <H1> for this first level header, they had simply marked it up with a font size. So, there was no linebreak implied between the text and the image. Now, when displayed 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 Lynx this whole thing was quaintly rendered as

Our Classrooms and Staff fancy horizontal rule

Certainly they should have used H1 markup for the header. See above for suggestions on how to handle a decorative horizontal rule.

(Comment: you may be able to find some of the above howlers with search engines such as AltaVista; others have been adapted by simplifying the original, or taking two or more similar examples and composing one that represents them all.)

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 those 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 browsing situations that the mass of WWW authors seem to be aiming for.

To sum up:

• Think what information will be presented to each of the three types of user
• Consider how that information illuminates the "topic of discourse"
• And then all should be clear.

A final thought. When your paperback edition is published, does it include an ALT text that tells the reader what a cheapskate they are, and how they should have bought the hardback edition with the eight extra illustrations, and the handsome dustcover? I think not. Please don't address your text-mode readers [3] as if they were second class citizens, either.

---

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

---

The contents of this article were originally published at http://ppewww.ph.gla.ac.uk/%7Eflavell/alt/alt-text.html.

Original materials © Copyright 1994 - 1999 A.J.Flavell & Glasgow University

---