On the WWW, I see a lot of confusion about the appropriate
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.
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.
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.
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". 
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.
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
ALT attribute of the
IMG is intended
to be used as alternative text for situations where the
IMG is not
The idea is expressed well in the HTML4.0 recommendation
"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.
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
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
It's been clear since the HTML2.0 spec that the alt text is
intended to support the
&#number; mechanisms for representing displayable
characters, and nowadays browsers get that right (some early versions
This does not mean that you can get line breaks
displayed in ALT texts by using the control codes
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
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
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
 if you'd like to offer this.
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  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.
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:
The speaking machine isn't only for blind 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 for example while driving along, and there is at least one product, the "Web-on-Call(TM) Voice Browser", for reading out textual WWW pages over the telephone. Users with motor disabilities may also be unable to cope with the user interface of a normal graphical browser.
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.
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
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
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
(If you are a vendor of logos, exhibiting specimens of your wares,
then your logos are your content!)
The often-seen variations on
ALT="Logo of Foo Corporation",
ALT="Medium size GIF of logo" (!)
are incomprehensible: the author is supposed to be providing
the reader with information, not with meta-information (descriptions
A text description of the logo is generally felt to be
inappropriate as ALT text:
for those readers who wanted it 
there are accepted conventions of offering a separate description.
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
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
Still, as a navigation tool,
a row of simple
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.
<a href="...">Frigate, circa 1800, 160kB PNG</a>
IMG, with an
ALTtext 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
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.)
ALTtext. If you have a mixture of optional graphics with a few mandatory ones, maybe you could consider using the
ALTtext 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.
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
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
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
"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
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
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).
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
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.
Authors ask, reasonably enough, to use
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 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
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..
Consider some images crammed together, for example as navigation buttons:
When viewed on a text-mode browser, this is going to read:
ALT="The University"><IMG SRC=town.gif
The UniversityThe Town...Various solutions may be considered:
ALTtexts themselves are single words, then it may be sufficient to include space(s) in the
ALTtexts, e.g this sequence of
ALTtexts for some navigation buttons:
so that the text mode page will look like this
"Left ", "Right ", "Index ", "Config"
Left Right Index Config
But note that the HTML4.0 recommendation warns against using leading/trailing "white space" on attribute values.
the ALT texts might be respectively:
"|Left|", "Right|", "Index|", "Config|"
[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
IMGs were not in the scope of anchor links,
there's one point on which they fail.
We deal with that next.
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 is discussed separately.
There has been a long-running debate on c.i.w.a.html
about the wisdom
of providing correct HEIGHT and WIDTH attributes on
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
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.
(There's now a separate page about INPUT TYPE=IMAGE.)
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.
All of these examples represent things I have seen on the WWW.
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? (;-)
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?
An image of some "self-explanatory" text,
ALT="Put your alt text here"
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...).
A heroically misguided attempt to comply with the authoring
advice to "be sure to provide an
ALT attribute on
ALT="[THUMBNAIL]" on every one!! Sorry.
<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!.
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
Academic departments are indicated
by: <IMG SRC="mortarboard.gif"
(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.
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
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.
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.
Acme Computer Graphics Company home button Acme computer Graphics company info button Acme Computer graphics Company tools button ...etc...
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.
<CENTER> <FONT SIZE=6>Our Classrooms and Staff</FONT> <IMG SRC="rule.gif"
ALT="fancy horizontal rule"> </CENTER>
Instead of using
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 ruleCertainly they should have used
H1markup 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
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:
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
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, where they are currently maintained.
Original materials © Copyright 1994 - 1999 A.J.Flavell & Glasgow University