NB: This page is archived without styles. Go to our home page or read our blog.

Accessible alternatives

I've become interested in the subject of accessible, 'alternative' content for complex graphics and images. Looking at browser support and usability issues in the W3C's recommendations, I have come up with two solutions of my own.

I'm working on the early stages of my new design company web site and I have become interested in the subject of accessible, 'alternative' content for complex graphics and images, in particular portfolio images and screen captures of client sites.

Here's what the W3C recommendations have to say on the subject of text equivalents for images in the Techniques for Web Content Accessibility Guidelines.

1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. [Priority 1] . Note that these instructions refer to all non-text elements, not just images. You can add ALT and LONGDESC text to image maps, objects, and applets - any page element that needs to be described fully to a visitor who can't actually see it.

The 'alt' attribute

In my view, alternative text should always either be descriptive or should provide an alternative to the content contained 'within' the image (if that image is designed to convey any meaningful content or a task that is to be fulfilled). In the case of an image used as a button, deciding on 'alt' text should be pretty simple.

Order now

<img src="images/button.gif" 
alt="Order now" />

When not to use alt text

But when the image is purely decorative, like the bullet below, I part company with the W3C and prefer to use an empty alt string rather than a description of the image itself.

<img src="images/bullet.gif" 
alt="" />

The empty alt string seems logical, whereas <alt="bullet"> would add nothing meaningful.

But deciding on alternative text for this next example might prove to be a little trickier.

Mickey Spillane, American thriller writer, master of 'hard boiled' style and best-known for his private detective Mike Hammer. Of the thirteen Hammer novels, it is the 1950 'My Gun Is Quick that remains my favourite.

Realistically, I could use any of the following selection of alt attributes;

  1. My Gun Is Quick
  2. My Gun Is Quick by Mickey Spillane
  3. My favourite book is My Gun Is Quick by Mickey Spillane
  4. The My Gun Is Quick book cover

But here too, I part company with the W3C and I lean towards using an empty alt string. None of the above choices will enhance a non-visual user's understanding of my content and using alt text in this instance will slow down a screen-reader user's progress through my document. However the W3C does allow for this view when it says,

... any page element that needs to be described fully to a visitor who can't actually see it.

Using longer descriptions

There are often times when an image does contain content which adds to a non-visual user's understanding. In my design portfolio example I might want to provide a description of a site's layout or colour scheme, I might want to explain that the page contains pictures of hotel rooms. So two further options are available for me to use, a 'long description' and a 'description link'.

Long description attribute

Implementing a long description link usually requires an additional page which contains a text alternative of the graphical content, (be it a chart, a diagram or a map) and the use of the <longdesc> attribute within the <img> tag.

<img src="images/chart.gif" 
alt="Population chart of Wales" 
longdesc="wales-population.html" />

This solution is simple but involves creating a separate page which takes the non-visual user away from the current page and requires a further call to the server. A more elegant solution is to place the alternative content inside a 'footnotes' area at the end of the current document and hide these footnotes for sighted users with a little CSS. For example,


<img src="images/chart.gif" 
alt="Population chart of Wales" 
longdesc="#wales-population" />

<div id="content-footnotes">
<table id="wales-population">


div#content-footnotes {
position : absolute;
left : -1000em;
width : 900em;

This has the advantage of keeping all content within the context of the current document.

Sadly the longdesc attribute is invisible to those not using screen-readers and goes unsupported by some browsers. Until browser support for longdesc grows, an interim solution is recommended by the W3C, the [D] (description) link.

The D-link

The D-link solution involves placing a text link to alternative content next to the image in your mark-up.

<img src="images/chart.gif" 
alt="Population chart of Wales" 
<a href="#wales-population" 
title="The population chart of Wales">[D]</a> />

However D-link is not widely used and might be confusing to sighted people who are not familiar seeing them.

Structured mark-up and CSS

My own alternative to using longdesc and D-link is the use of structured mark-up and CSS to provide an 'inline' explanation of my client site screen captures.

First I'll mark-up my portfolio section as a definition list,

<dt>Empire Hotel</dt>
<p class="portfolio" id="portfolio-empire">
The Empire Hotel web site is designed 
in subtle tones of mauves and purples
and uses traditional patterns to 
reflect the traditional atmosphere.</p>
<li><a href="#">Case study</a></li>
<li><a href="#">Web site</a></li>

Next I'll turn the first paragraph into an image for sighted users with a little CSS. To optimise the CSS, I'll first set a class of 'portfolio' as there will be more than one portfolio item on the page in which I'll float the paragraph left and set the width and height to match that of my screen-capture.

p.portfolio {
float : left;
width : 180px;
height : 150px;

I'll set a right margin to give the image breathing space, and then hide the text from view by moving it off screen by 3000px.

p.portfolio {
float : left;
width : 180px;
height : 150px;
margin-right : 10px;
text-indent : -3000px;

Now I'll add the screen-capture image for this unique item using the background property.

#portfolio-empire {
background : url(portfolio-empire.jpg) no-repeat center center;

Now, sighted users see the screen-capture image as intended and non-visual users are treated to an inline description in place of the image. Whilst this method fails in the rare 'images-off/css-on' scenario, it does have the advantage of reduced server calls and keeps the visitor within the context of the document, rather than linking to an external file or a footnote.

The objectives of the WAI guidelines are still satisfied while getting round the issues of browser support for longdesc and the annoyances of D-link.

Let me know what you think.


I have expanded on some of these ideas in Accessibility footnotes.


  1. #1 On September 11, 2004 03:08 AM retrogrrl said:

    re empty alt tags - I believe it is actually more correct to have no space between the quotes "" which therefore avoids the IE empty tooltip

  2. #2 On September 11, 2004 03:50 AM Chris Owens said:

    I *think* the reason for the spacing is to fool accessibility validators into thinking there is actual content within the alt attribute.

  3. #3 On September 11, 2004 05:29 AM stylo~ said:

    So, please a "validator" and annoy your visitors? Priorities are badly wrong there.

  4. #4 On September 11, 2004 09:55 AM Rimantas said:

    Validators are happy to have alt="" (no space). At least ones by W3C and WDG.

  5. #5 On September 11, 2004 11:30 AM Laura said:

    Some alt references that may be useful:


  6. #6 On September 11, 2004 03:59 PM Keith Bell said:

    I think you have the best solution to the problem, Andy. It's bad that so long after introduction of the longdesc attribute it's still so poorly supported -- but even if support were better, I've always felt that taking the user to another page was a clumsy method. The D link is just a kludge; few sites use it and those that do find it necessary to explain what it's all about, e.g. https://www.pbs.org/wgbh/aso/access.html#dlinks

    Ultimately, pragmatism rules. I suspect the number of users affected by the 'images-off/css-on' situation is less than those whose browsers don't support longdesc, or who don't know what D links are all about. And if they're smart enough to figure out how to set their browsers to 'images-off/css-on', they're probably smart enough to realise that sometimes they may be missing something.

  7. #7 On September 11, 2004 04:17 PM Fernando Dunn II said:

    Andy, I like your reasoning here.

    Sometimes with the bullet, I would rather use an asterisk instead of an empty alt attribute.

    I think titles and alt tags for images are many times useless. If I cannot see a non-textual image on a page, I would not want to see what the image is called, nor what it is about. I would want to see the page as if the images never existed.

  8. #8 On September 12, 2004 02:12 AM seth said:

    Great ideas, Andy.

    I've often considered image-replacement as an alternative to longdesc - in certain cases.

    I think a distinction needs to be made between images that are essential to the document, and those that aren't. I decent test for this is viewing the document with css turned off, and seeing if things get confusing.

    If an image is directly referenced or even implied, I would argue that the image itself should be in the (x)html rather than in the css.

    I suppose one could argue either way in the portfolio example, but I would personally opt to put the screen shot in the (x)html. My opinion is that the screen shot is truly part of the content, and should be therefore be in the "content" document.

    I think an even clearer example would be a biography with an image of the subject's portrait. I would want that image to be available as part of the (x)html document, and made available to whatever agent was consuming it (whether or not it has css support).

  9. #9 On September 12, 2004 02:32 AM Malarkey said:

    @ Everyone: A big "Hello" to all those people that I haven't seen commenting here before. And a big thanks for the links.

  10. #10 On September 13, 2004 12:38 PM Lachlan Hunt said:

    Why don't you just use object? That way, you don't need to write extra CSS every time you add an image, the alternate content can be whatever you want, and users with descent browsers will see the image. Users of IE (I believe) and other users that can't see the image,, will get the alternate content.

    Also, you might want to take a look at what Hixie has to say on the subject too.

  11. #11 On September 13, 2004 01:43 PM Phunky said:

    I also use the blank alt="" if there is nothing worthwhile within the image to describe.

    I've never had any problems with any validators with me not adding the extra blank space inbetween the comments either.

    Another sly way of getting around it would be to place ur none discriptive graphical elements as background-images instead of inline images, this then gets around you using alt's and any snubbing from a vaildator...

  12. #12 On September 13, 2004 01:47 PM Malarkey said:

    @ Phunky: Hello Mr. Harwood, using background images and image/text replacement is what I am proposing to do. See 'Structured mark-up and CSS' above.

  13. #13 On September 13, 2004 02:16 PM Derek Featherstone said:

    @Malarkey: An interesting solution, and certainly its use would be dependent upon the context.

    With this technique, your descriptive paragraph ("The Empire Hotel web site is designed
    in subtle tones of mauves and purples and uses traditional patterns to reflect the traditional atmosphere.") is now only available to nonvisual users. I'd bet that it may be of benefit/interest to visual users as well.

    When we are making appropriate decisions about alt text, we question whether or not the image would have any value to a non visual user. Perhaps we also need to question whether or not the descriptive paragraph would have any value to a visual user. In many cases, the answer might be yes, and if so, perhaps we shouldn't hide it, and make it available to everyone?

  14. #14 On September 13, 2004 02:37 PM Malarkey said:

    @ Feather: Hi matey, where *have* you been?

    I take your point about the descriptive paragraph being of use to more than non-visual users. But I think that I might not have been clear enough in the code snippet.

    I intend to have multiple paragraphs in the case study for each client, but only the first one (class="portfolio") will contain a description of how the site looks.

    With CSS/images on, this paragraph will appear as an image (no text), solving the need for longdesc, d-link or alt text.

  15. #15 On September 13, 2004 03:05 PM feather said:

    @Malarkey: I've been around, but it was a tough week last week, and I wasn't online much at all...

    re: "I intend to have multiple paragraphs in the case study for each client, but only the first one (class="portfolio") will contain a description of how the site looks."

    Ahhhh, I see. Thanks for clarifying...

    I still wonder, though, if the paragraph describing how the site looks might still be of use to others. Is there any reason to hide it (other than the assumption we are making that someone who can see the picture doesn't want the description)?

    I suspect (like most things) that it depends on context, and different strategies might be appropriate for your portfolio than elsewhere.

  16. #16 On September 13, 2004 03:57 PM Adrian Lee said:

    Nice idea, I think it falls into the same issues as FIR generally in cases. One being the SEO problem of people using the same kind of techniques to spam the Search Engines. Matters little at the moment, but ya never know when it might....

    I also wonder about blank alt text. With the reasoning for leaving the book cover alt text blank, it could confuse people. If a screen reader spits out alt blank or whatever, they are left wondering what the hell that image was. Was it something meaningless like a spacer gif? Was it a bullet point? (ok they may have a bit more idea if its a bullet point) or is it something relating to the context of the surrounding text, but doesn't mean a great deal if explained?

    Almost makes me wonder if ALL alt text should have SOMETHING in, though that has its downsides as well..... Dunno, not sure on that one.

  17. #17 On September 13, 2004 05:23 PM Chris said:

    On my new site (still in very early development stages) I have a unique picture of me for each section of content. I initially was going to take the alt="" approach, since it doesn't convey information per se. But then I found myself thinking the following: since the picture is meant to provide an emotional setting to a sighted user (in a way not dissimilar to Malarkey's picture at the top of a post), perhaps it makes sense to use flowery or poetic alt text that attempts to provide a similar emotional setting.

    For example, the blog section has a shadowy picture of me making a weird face. The alt text I went with was "out of the shadows, a dubious genius." That seemed to me the closest I could get to representing the experience of the visual to a non-sighted user. When I saw this discussion, I wondered what people thought of that. Certainly it's not wrong to take the alt="" approach. But is it wrong to do something like this? Would it be better to do it in a longdesc?

    Thanks in advance for any thoughts, and to Malarkey for another interesting post.

  18. #18 On September 13, 2004 08:26 PM Malarkey said:

    @ Adrian Lee: Personally I don't worry about the SEO issues of this technique. Generally, search-engines ignore or penalise keyword-stuffing or similar techniques, and this content is 'real' and meaningful. Where you say, "Almost makes me wonder if ALL alt text should have SOMETHING in", I tend to lean in the other direction and would suggest that we should use alt text *only* where we are explaining the content of an image, not what the image is.

    @ Chris: In your case I wonder how "out of the shadows, a dubious genius." would sound through a screen-reader in the context of your text. I would be tempted to insert the image through CSS and not in the HTML.

  19. #19 On September 14, 2004 12:40 PM Phunky said:

    Mr.Harwood hey :D making me feel all special inside :D

    ohh wait, that sounds kinda bad !


  20. #20 On September 14, 2004 01:21 PM Chris Hunt said:

    "it could confuse people. If a screen reader spits out alt blank or whatever"

    My understanding is that if a screen reader finds an img element without any alt attribute, it says "image" (or something similar). If it finds an img with some alt text specified, it reads out the alt text. If it finds an alt="", it doesn't say anything at all. So giving alt="" to purely eye-candy images is (usually) the right thing to do.

    Be aware also, that screen readers do not explicitly identify text drawn from an alt attribute from ordinary text - the two are run together, leading to potential howlers like:

    Small red bullet Response to Terrorism

    Oldtown University arms Physics Department

    Photo of a bull in the water canoeing

    Much more on alt text (and more howlers) at https://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html

  21. #21 On September 15, 2004 05:00 PM kartooner said:

    My preference, when it comes to "eye-candy" graphics is to not provide alternate text. I take into account that if a screenreader were used it would break up the flow of the text.

    If I had an image of a movie poster, for instance and then had written an article on said movie, it would be confusing (as someone stated on here) for the screenreader to read the article and then pause to read "Star Wars poster [1977]".

  22. #22 On September 16, 2004 01:24 PM Richard Rutter said:

    re. the Mickey Spillane image: "I lean towards using an empty alt string. None of the above choices will enhance a non-visual user's understanding of my content and using alt text in this instance will slow down a screen-reader user's progress through my document."

    I think you're on slightly dodgy ground here, Andy. *You* are deciding what's important to your reader, and perhaps as the author you're best placed to do so, but my understanding is that visually impaired users would still rather know what is in the image that they're missing. Sure if the image is pure eye candy (a stripe or background fade or something) then provide alt="" but in the above case I would use your latter example: alt="The My Gun Is Quick book cover." in order to complete the picture, as it were.

    And if images are being used as bullets, I would use alt="*" to indicate such (Fernando Dunn II mentioned this). That said, this situation might be redundant if the bullets are part of a list because you'd being marking it up using LI anyway and probably showing the bullet using CSS.

    As for using image replacement to provide full descriptive text for an image: it seems just as valid as using the technique for headings etc. That said I agree with Seth that a screenshot image can certainly be considered page content and feels like it deserves its own IMG element rather than being relegated to a background image, but ultimately is there that much of a difference? Perhasp - it seems wrong to ignore LONGDESC but at least your technique actually works in reality.

    Is there a list anywhere of which browsers and assistive software support LONGDESC?

    And finally, you might need an overflow:hidden in your portfolio class just in case.

  23. #23 On September 17, 2004 10:15 AM patrick h. lauke said:

    i know i already wrote about it elsewhere, but for completeness' sake: on the question of which browsers support longdesc, we need to clarify what we need by "support".
    a lot of browsers (even IE5, I seem to recall) "support" longdesc in that they make it available programmatically. but if "support" is meant to signify "make it easily accessible and available to the user" then the answer, as far as i can tell, is "none of the mainstream ones".

    anyway, prompted by malarkey's question on this subject over at accessify's forum https://www.accessifyforum.com/viewtopic.php?t=1807 i created a very simple firefox longdesc extension, which adds "View Image Longdesc: ..." to the browser's image context menu.


    tested in firefox 1.0PR and mozilla 1.7.3, but should also work in older builds.

    (and sorry for link whoring again)

  24. #24 On September 17, 2004 10:23 AM Malarkey said:

    @ Redux: Keep delivering the goods like that and I'll let you off! ;)

  25. #25 On September 17, 2004 04:33 PM brothercake said:

    Beautiful solution, as always mate :) But I can't relax on this images off / css situation - I surf like that sometimes - and I don't imagine it's as rare as we're allowing ourselves to believe.

    Using a browser like Opera that makes image-toggling easy, and being on dial-up, I appreciates the bandwidth saving of surfing like this. Sites using this technique are often completely or partially blank ... not helpful.

    I may not have any serious disabilities, but I still have accessibility requirements ;)

  26. #26 On September 19, 2004 11:00 AM Bruce Boughton said:

    Correct me if I'm wrong, but I always thought putting a space as an ALT description was better than nothing because screen-readers read it better then. Don't ask me to explain this, it's just something I have stored at the back of my head, and it may be entirely incorrect!

    As Malarkey suggests, all non-content images *should* be CSS (i.e. presentation layer) and not in your (X)HTML. That I thought was one of the main principles of CSS/(X)HTML and abstracting the presentation from the content!

  27. #27 On September 19, 2004 07:04 PM Bob Easton said:

    Yet another reason to avoid LONGDESC ...

    There is variance in the way assistive technology handles LONGDESC pages. Some screen readers, Jaws in particular, launch the LONGDESC page as new window. The Jaws user has to know this and be ready to close those extra windows.

    Now, if you're thoughtful and add a "close window" link to the LONGDESC page, you run afowl the other screen readers that navigate to the LONGDESC page rahter than open it as a new window. If they hit that convenient close window link you adder, "poof," goodbye session!

    The foot note alternative turns out to be far better behaved.

  28. #28 On September 26, 2004 09:27 PM patrick h. lauke said:

    just to flag up: updated the extension https://www.splintered.co.uk/experiments/55/ - version 2.0 now handles longdesc in local files (with a file:// url) as well, thanks to a rewrite that now leverages firefox's native functions rather than my homebrew javascript attempts...