Design & UX
By Dennis Lembree

Longdesc & Other Long Image Description Solutions — Part 1: The Issues

By Dennis Lembree

You may have heard some discussion about “longdesc” recently which spiked when much debate broke out on whether to keep it in the HTML5 specification. Unless you’re a “veteran” web professional, you may not even heard of “longdesc”. So what is it, you ask, and should you be using it? Let’s examine.

A screenshot of the markup from an xkcd comic page superimposed over the rendered page with a longdesc attribute.

What Is Longdesc?

As you probably know, the alt attribute is intended to provide a short text-based alternative description of an image on a web page. Additionally, the longdesc attribute was designed to point to a web page which provides a longer, detailed description of an image, when needed. It complements the image element’s alt attribute; when a description is longer than what feasibly works with alt, longdesc would be used. As we’ll discuss, there are other potential uses for longdesc, but the primary reason for its use is for blind and low-vision users who are using a screen reader and cannot see a content-heavy image. Many use cases exist for a long description which include describing a logo, comic, piece of artwork, graphical chart, infographics, and photograph. (Note that longdesc was specified to support the frame and iframe elements as well, but hardly anyone even knows that, never mind implements it!)

The Controversy

On the surface, the longdesc attribute seems like a great way to provide detailed text descriptions of an image. But unfortunately the technique has never achieved its full potential, to say the very least. So much so, that many believe longdesc should be entirely forgotten and in many resources is no longer a recommended technique.

A few years ago, an article was written which documents the extremely small percentage of images which have longdesc implemented correctly (approximately 1 in 100,000 images; 1 in 100 who attempt it). More recently, in defense of the attribute, many examples of proper longdesc implementations were documented (by a variety of entities such as museums, universities, personal blogs, government agencies, etcetera). However you look at it, it’s agreed that the overall process of providing an image long description is broken and something must be done.

Authors’ Issues

So why is longdesc hardly ever implemented or done incorrectly so often? One reason, like many other accessibility-related concepts and techniques, is ignorance; if web authors (designers, developers, owners) don’t understand why they should do something (provide alternative text in this case), they probably won’t do it. Another reason is lack of proper training; authors just aren’t taught how to use longdesc.

Some folks declare that the name “longdesc” itself is an issue, but I don’t necessarily agree. The argument is that the name is misleading which is why many times the text description itself would mistakenly be entered in the attribute value, rather than a URI, as defined (basically, a URL). Although this error does occur often, training is still the source of this problem considerably more than the name of the attribute.

In addition, some advocates of WAIARIA insist that the aria-describedby attribute takes care of the issue. But there are many arguments against this as a replacement, many outlined in an HTML5 Change Proposal. The top points are:

  • The aria-describedby attribute cannot point to content off the page (to a URI, as longdesc does); it can only point to in-page anchors (IDREF). A negative result of this is it cannot provide one common external description for the same image repeated over different pages.
  • Screen readers do not pause when they encounter aria-describedby; it is read aloud straight away like the alt attribute and forcing the longer description on the user whether they want it or not. (longdesc essentially inserts a pause where the user can choose to follow the link or not.)
  • The aria-describedby attribute is not backwards compatible.

Browser (Non) Support

Another reason why longdesc is hardly ever implemented is that the major browsers do a poor job of supporting longdesc. If an author’s work won’t render in the browser, he or she is much less apt to do it. Especially if there’s a deadline approaching and there’s pressure to get the job done as quickly as possible, which is too often the case. Of today’s top browsers, only Opera 10.10+ supports it. To help other browsers along, there’s a Firefox longdesc add-on by Patrick Lauke which provides access to the long description, like Opera, through the image’s context menu. There’s also an extension for Opera, TellMeMore, by Charles McCathieNevile which provides a visual cue, as does the Firefox add-on. And I heard a rumor that an extension for Chrome is in the works.

The problem of providing image long descriptions isn’t longdesc; it’s primarily the browsers’ failure to notify the user of the presence of the attribute.

A Case for longdesc

If browsers made longdesc more “discoverable” data rather than “hidden”, the attribute could be much more beneficial, particularly including sighted users. Like the alt attribute, providing long description to sighted users can be helpful when an image becomes unavailable such as in the instance of a broken image link, or in the case of low-band Internet connection (including mobile devices, let’s not forget about developing countries where mobile may be the only means of surfing the web).

And there are other uses besides visual backups. A long description can assist in comprehension of information, especially for those with cognitive impairments. Also, like audio transcripts and video captions, long textual descriptions of an image can be a means for internationalization as the text can be translated to a different language by services such as Google Translate (as opposed to text within an image which cannot be translated (not feasibly, at least not yet).

The fact of the matter is that there are many use cases for longdesc and that there is a consensus that a mechanism to provide an image long description is needed. For now, there is no fully “functional replacement” for longdesc. It currently works well when implemented as it’s supported by many assistive technologies including popular screen readers like JAWS and Window-Eyes.

In addition, there is a history with longdesc; there’s something to be said about backwards-compatibility. There are many guidelines, laws, policies, and standards citing longdesc as a solution. These appear within organizations such as IBM, the United States Postal Service, and the University of California. The longdesc attribute has a critical support base that has taken a dozen years to build and would most likely take as much time to rebuild it with a new attribute/method for long description. Also note that longdesc is a part of the ISO HTML (see IMG under Annex B).


The longdesc image attribute is a good way to provide detailed descriptions for images that need it. But since most web authors haven’t learned about it and most browsers don’t support it, the technique is very unpopular. Other methods such as ARIA exist to achieve a similar goal but may not be fully supported either and is not a true replacement. Until browser vendors do their part, and until longdesc is rejuvenated in the web community, there will continue to be only partially supported solutions of providing a long description of an image.

Oh, and in case you’re wondering about its fate, as it currently stands, longdesc is currently defined as “obsolete” in HTML5.

Check out Part 2, where we’ll discuss how to implement longdesc and examine a variety of other solutions and ideas.

  • Hi Dennis,
    While the *current* Draft of HTML5 shows longdesc being obsoleted, it is also worth noting that the Issue has been re-opened by the 3-person Chairs of the HTML5 Working Group to re-examine the current situation.

    As for an alternative means of making longdesc discoverable, one of the accessibility engineers at Yahoo! – Dirk Ginader – created a cool jQuery extension which provides some very cool functionality to longdesc that authors might be interested in looking at. See the extension here:

    …and a demo here:

    It also makes use of some slick AJAX (XMLhttpRequest) to render the textual description in the same bounding box that contains the image. Check it out!

    • Thanks for the update on the spec, John. As far as Dirk’s example goes, it’s already in the draft for Part 2!

  • The problem I have is some ADA and Section 508 validators require the use of longdesc and the Federal Govt. requires the validation for organizations to keep their federal funding. I’m doing consulting work on a large project and this is a major concern. Needless to say, your article is an eye opener for me. Thanks.

  • Hi Dennis,

    As you know, I am a supporter of longdesc. I do not believe longdesc is “broken”. Also, I do not believe ARIA is the answer and I do not think trying to modify ARIA at the last minute in this sort of a context is a productive use of anyone’s time.

    In addition to the reasons you stated with regards to why longdesc has been poorly implemented (and indeed, training is a big one), I think one of the problems is that writing long descriptions should not, in most cases, be relegated to developers but to content authors. I think there is something broken in the production chain. I am not talking about ma and pa set ups where one person does everything. But, for example, Statistics Canada has many images (complex graphs and stuff) that need longdesc. But I do not think it is the developer’s job to write them. It is the content authors job to provide long descriptions. And I think that is where things break down. Content authors need to be made aware of these problems and trained accordingly.

    Anyway, nice summary of the issue. Looking forward to part 2 :)

  • Ed Brandon

    It seems to me another great reason for the lack of longdesc is the lack of support in WYSIWYG editors used with common CMSes and other applications. If it isn’t that easy to code, it isn’t going anywhere. Too bad. I too believe it should be used.

    – Ed Brandon

  • mattur

    > “examples of proper longdesc implementations were documented”

    Note even some of these “proper” examples include longdesc links that don’t work in JfW, links to pages that are not long descriptions, tiny white text on white backgrounds, links on invisible spacer gifs and other horrendous techniques from the dark ages of web design.

    > “There are many guidelines, laws, policies, and standards citing longdesc as a solution”

    Perhaps I’m missing something here, but ISTM what matters is WHETHER IT ACTUALLY WORKS.

    Is it ok to use a technique that we know locks out VoiceOver, ORCA, NVDA, IE, Firefox, Safari and Chrome users just because policy guidelines mention that technique? Or is actually being accessible to people with disabilities more important?

    @Jim Watson if you’re using longdesc for accessibility you’re doing it wrong.

    > “Other methods such as ARIA exist to achieve a similar goal but may not be fully supported either and is not a true replacement.”

    ARIA is new and not fully supported yet. longdesc is 14 years old and not fully supported yet.

    Since some see longdesc functionality as fundamentally flawed, duplicating that flawed functionality with a “true replacement” would be sub-optimal, so new techniques take a different approach to achieving the same thing.

    >”it’s primarily the browsers’ failure to notify the user of the presence of the attribute.”

    I don’t think that’s true at all. The fundamental flaw with longdesc, apart from it being hidden, is that it requires an alternative mechanism to “clicking” – longdesc might be on an image inside a link, so just clicking it when for example a special cursor is displayed won’t work. Any new activation mechanism would require re-training every single user who needs to access the long description.

    To be successful longdesc needs to have an activation mechanism as easy and intuitive to use as a normal link, which is probably impossible. If it is not as easy and intuitive to use as a normal link, it means that using this “accessibility” technique results in a net *decrease* in accessibility. IMHO this is primarily why longdesc has failed to take off: it’s fundamentally flawed.

    So, the alternative point of view is that a normal link should be used, with a programmatic association where required (eg aria-describedby or rel=longdesc), since this works for everyone now, degrades gracefully without locking out users and does not require software upgrades or user re-training.

    > “Also note that longdesc is a part of the ISO HTML (see IMG under Annex B).”

    Also note that ISO HTML is completely impractical and entirely irrelevant to the real world, because it doesn’t allow authors to use inside ‘s. Perhaps that’s why it includes longdesc :)

  • Saying that something is flawed due to a lack of proper or inclusive implementation is fundamentally a misdirection of responsibility.
    I agree that browser vendors have failed to implement longdesc in an inclusive fashion but this does not negate the utility value that the attribute can provide.
    I think of the phrase “Don’t throw the baby out with the bath water.”
    Don’t throw the baby out because you’re too lazy to turn on the tap.

  • Another point.
    Some AT don’t support some elements of a specification, FACT.
    Is the specification wrong or are the AT vendors failing to serve their target audience?
    For too long we have developed “guidelines” and “best practices ” to accommodate failings of some AT.
    Historically, AT vendors have done an admirable job of accommodating non-conforming code. This has had the negative effect of essentially codifying the implementation of bad code
    Any accessibility requirements are only achieved when all essential components work together. Otherwise we are reduced to providing “work arounds” and “hacks” that have no measurable value.

  • Bill Shackleton

    Thank you Dennis for shining a floodlight onto this heated issue. Although there are times when focusing lasers to drill into specific details is helpful, without overall contextual illumination of the landscape they can all too often result in generating more heat than light.

    For whatever value (or not) that I may contribute, I would suggest that an essential flaw in the key reasoning, as I understand it, to remove longdesc is in assuming that because its past effectiveness has been limited, it is doing more harm than good. That is to say, that because of poor implementation – by user agents, by content authors, etc. – it should therefore be removed.

    I respectfully disagree. Much accessibility work takes time and yes, some of that time includes the need for awareness and training.

    In my experience, progress in accessibility has rarely been consistent or even linear… And it is definitely not binary. It progresses in fits and starts and even, unfortunately, backslides. That’s why it’s important, in this case as in others, to wedge in a backstop to preserve hard-won progress. Fortunately it is fundamental W3C policy that everyone be included (regardless of disability). This means that the burden of proof does not lay with the accessibility community to make the case for maintaining longdesc in the next version of HTML, but with those who wish to remove it.

    I personally have not yet seen it (pushing Google-driven ‘research’ doesn’t do it, neither does any ‘analysis’ based on comparing numbers of disabled verses non-disabled).

    And despite some comments to the contrary, this isn’t a technical issue, it’s a policy one. Unfortunately too often, policy gets decided by default as techies innocently (or, depending on vendor incentive or political competition, sometimes maliciously) hardwire their decisions into systems un-transparently. I believe that at the very least this issue should be escalated into a larger, more policy-oriented forum.

    As to any argument that suggests that a standard isn’t any good if vendors don’t wish to implement, I would argue that as number zero in the Fortune 500, the purchasing power of a US government intent on substantive accessibility can be quite persuasive indeed!

    My 2 cents worth.

  • mattur

    > “Fortunately it is fundamental W3C policy that everyone be included (regardless of disability). This means that the burden of proof does not lay with the accessibility community to make the case for maintaining longdesc in the next version of HTML, but with those who wish to remove it. ”

    It’s important to remember the HTML-A11y-TF found they do “NOT want longdesc to continue indefinitely although there are some objections”, and that they “do want aria-describedby to replace longdesc.”

    The W3C WAI-CG also accepted “it is acceptable to obsolete longdesc in HTML5” if aria-describedby was specified so it could point to a link.

    Recent discussions amongst some W3C WAI PFWG members suggest they also want to obsolete longdesc – but in HTML6.

    AFAICT most people involved in accessibility at W3C agrees that longdesc has failed and should be replaced by aria-describedby, the only debate is over timing.

    So this is not an accessibility community vs HTML5 thing; there are a range of opinions, and many folks are involved in both communities anyway.

    • @mattur,

      You can continue to truck out ancient emails from 2009 and 2010 from W3C, RNIB, WebAIM and your neighbors cat, but it is abundantly clear that today, May of 2011, the general consensus of the W3C Protocols and Formats Working Group (WAI) as well as the HTML WG Accessibility Task Force, who’s members have continued to discuss this issue at great length, they are now unequivocally in favor of retaining longdesc in html5:
      * HTML WG A11yTF:
      * PFWG:,

      In fact, the Director of WAI – Judy Brewer – along with the Chair of the PFWG – Janina Sajka – are both actively working on a formal Change Proposal for this now, as well as looking to have this issue (as well as the @summary issue and the total mishandling of the @alt decision) addressed as quickly as possible, ( via an appeal to the Director for expedited review *prior* to the Last Call Working Draft if so required.

      For someone who has never participated in a single W3C accessibility conference call, never contributed a single email to the Accessibility Task Force, and who’s sole contribution to the @longdesc issue is to spread half truths and mis-information wherever you can, your continued bleating on various blogs fools no-one. I suspect that one reason why you choose not to involve yourself inside the W3C process is that your personal perspective would be quickly dismissed as out of date, out of touch, and out of sync with those who have worked hard on this issue for a very long time.

      Feel free to continue to resorting to calling me names if you want (, but even then, be sure you get your facts straight:

      But once again, I’m sure you won’t let recent facts get in the way of your continued campaign to spread your particular brand of FUD.

      • mattur

        Can you point to the part on any of those links where the HTML-A11Y-TF polled and reached resolutions? Or where the WAI-CG changed it’s previous findings?

        Can you point to a reference that shows the PFWG wants to keep longdesc indefinitely?

        If PFWG are planning to obsolete it in HTML6, it’s pointless to include it HTML5. If it’s going to be obsoleted, the work required to implement UA support, re-train authors and re-train users would be a complete waste of time, since it’s just going to be obsoleted anyway.

        BTW: you’re projecting. It’s quite funny.

      • If you ever get around to it, your comments on the 2nd article would be very much appreciated:


  • Stomme poes

    Warning: this contains some FUUUUUU and some rage. All of it completely uninformed and stupid. But I’m bored and drank tastey whiskies.

    Aria-describedby sucks for longdescs (what, am I like the only developer in the entire freaking world who’s been commanded to hide the a11y stuff from the sighted IE users (bosses)???? aria-describedby links to stuff sitting in PLAIN VIEW on THAT page), and frankly, so does longdesc. Like most *normal* developers, I have to just use a link. A plain old ordinary works-in-freakin-Lynx anchor. That’s the only thing that works for everyone, all the time. It’s also way easier to get away with setting a link out in plain view than a whole longdesc, mostly because we can weasel our way around teh clientses and teh bosses by saying “it’s good for the googles” (this works very well when trying to implement a11y stuff bosses and clients don’t understand or care about on web sites; try it. That magic “SEO” word works wonders).

    The vendors *could* fix this, but no, they’re too busy implementing Annoyance—er, I mean, CSS transitions and other cutesy nonesense. Stuff I still haven’t figured out how to block in my browser without disabled all the CSS. I may have to stick to keeping a copy of Firefox 2 around just to surf the web.

    This whole debate reeks of hair loss. Longdesc *could* work, but adding a few plugins (hello, plugins?????) is too little too late. Substituting aria-* attributes (let’s lock out the sighted-who-don’t-load-images, yes, what a wonderful idea, so accessible, just like longdesc!) is… I dunno what it is. Drinking some weird “I hate users” K00l-aid. Or did I miss something and I am supposed to be getting that aria stuff in my browser when I block MB-sized images so a web site doesn’t take a day and a half to load because someone thought it would be l33t to have these ginormous images all over the site.

    So let’s do this: let’s announce something *completely brand new* which does absolutely NOTHING except gives descriptions of complex images, that ALL browsers and ALL AT agree to support, and that ALL USERS can use, right now. I don’t care if it’s an attribute or a tag or an Illuminati fluoridated water conspiracy, whatever. Just check Yes. Just sign on the dotted line. Now that everyone agrees to make this ONE THING that works for EVERYONE, we can leave all this squabbling behind and get something done. Not half-done. Not done-but-only-for-certain-privileged-users. (and definitely not done-but-doesn’t-work-in-the-most-popular-browser-on-the-planet) Just, done. So long as certain people can point to broken browsers and broken AT and use that to say “see? totally useless, let’s drop it before it kills someone” and certain other people can point to a page written by someone who gives a rat’s and say “see? non-geniuses with a copy of Notepad can use it just fine”, this isn’t going anywhere. So fine: let’s make something completely new. HTML5 (oh wait “HTML the living standard so nobody knows what’s valid and not anymore”) is good at that. Inventing random stuff. So let’s invent some stuff that does something USEFULL to real human beings.

    And let’s call it something cool. Maybe it could have the word “ninja” in it.

    (or everyone could just implement longdesc + make it obvious to everyone else that there’s a longdesc of some image… but that would just be too easy)

    Some jack-booted thugs would help in this endeavour: we all remember how many things one company signed up to and then never bothered to implement.

    (This may not be the place for tipsy rants, but there you go. Better here than in certain other places.)

    • mattur

      > “So let’s do this: let’s announce something *completely brand new* which does absolutely NOTHING except gives descriptions of complex images, that ALL browsers and ALL AT agree to support, and that ALL USERS can use, right now.”

      We’ve already done that. It’s called aria-describedby.

        • Anonymous

          I don’t think that worrying about whether something being introduced in HTML5 is backwards-compatible is really the issue. Many other features being introduced aren’t backwards-compatible either … if they were, the language wouldn’t be evolving.

          If people are writing pages in HTML5, they should be doing that aware that any features new since HTML4 won’t work for people using older browsers. That goes for elements and the like, it goes for and , the lot. Why should this be any different?

        • Stomme poes

          Yeah, I kinda mostly have the problem with “the description is somewhere visible on the page”, esp with the kinds of bosses/clients I have… most developers! Yeah, the way newspapers have these whole descriptions of charts, graphs, and political cartoons on their pages… oh wait, they don’t, because they assume sighted (and in-the-know) readers and these graphics are compressing information. The whole purpose of the graphic is to convey information in a compressed and/or visual manner. Or make you squint in confusion.

          I suppose Browsers and AT fixing longdesc gets rid of the backwards compatibility issue, but I’m still pushing for a ninja tag. Developers seem totally fine with setting up those cute little badges on their newer sites with adorable messages like “Best Viewed In Apple’s Latest Wunderbrowser” or whatever.

          The longdesc (or ninja-text or whatever) is a leftover for those who, for whichever reason, don’t get the graphic, or don’t understand it. So yeah, should be available to EVERYONE (and due to vendor problems, ISN’T), but NOT simply spewed out on the same page or area as the graphic itself. The closest I can get to is footnotes. Those could have aria-describedby, why not? The footnote itself is within the same resource, but maybe far away from the reference.

          I’m talking about something for graphic on one resource, description at another. Aria-describedby is NOT making an annoying blinking thingie in my browser alerting me that this current XKCD comic has a description somewhere else and that I could click something to get to it (but that would be awesome… so, is anyone seriously changing aria-stuff from “for screen readers” to “for everyone”? Fine by me. The whisky is flowing tonight. The world is okay).

        • Stomme poes

          “* aria-describedby kills off links: ARIA 1.0 specifies that anything that aria-describedby points to is presented to the user as if it occurred inside an attribute. Hence, if aria-describedby points to an element which is – or contains – a link, the link will be completely dead – the AT won’t even inform the user about the link presence”

          Wut? But I’ve been using it to have skip links in my forms, and it’s being read out in my readers. So far, they work (well, not in webkit but webkit is retarded in that way)

          • mattur

            > “* aria-describedby kills off links: ARIA 1.0 specifies that anything that aria-describedby points to is presented to the user as if it occurred inside an attribute. Hence, if aria-describedby points to an element which is – or contains – a link, the link will be completely dead – the AT won’t even inform the user about the link presence”

            See for recent discussion IN THE HTMLWG!!!

            From the aria implementation guide:

            “Note that aria-describedby may reference structured or interactive
            information where users would want to be able to navigate to different
            sections of content. User agents MAY provide a way for the user to
            navigate to structured information referenced by aria-describedby and
            assistive technology SHOULD provide such a method.”

          • Stomme poes

            Me Jargonese not so good… does that mean it should work? The 3 readers (but only one browser) I tested in read out a text link (which worked) which was linked to a fieldset using aria-describedby… so, it seemed to work, which is why John’s comment confuzled me. Still does.

          • mattur

            Yes. aria-describedy should support referencing interactive content (eg links) and structured content (eg unordered lists) for AT users.

      • Stomme poes

        Psh, aria-describedby is MONTHS old. I’m not talking baby-new. I mean gleam-in-someones-eye new.

  • vmtech

    I use longdesc on images that have a lot of text, such as a logo with address and phone contact. Not all images need this level of detail, which is why I think it doesn’t get used as often as other attributes.

    Getting it off of obsolete status on HTML5 would be a start to keeping it around, but my experience says its usefulness depends on knowledge and the need for it.

  • Hernan Beati

    And why not to use figure and figcaption, linking a portion of text into the figcaption towards an external page which describe the figure?

Get the latest in Design, once a week, for free.