In the last two months I’ve come across more examples of the LONGDESC attribute in use, than I’ve seen in as many previous years. Due to this apparent rise in its popularity, this seems like a good time to look at when the LONGDESC can be useful, and when it’s just a waste of code.
This seems to deserve an airing because, in the eleven times I’ve encountered it this year, only one functioned as it should. The other ten either couldn’t function, or had no description to offer. With that in mind, lets look first at the purpose and correct way to add a LONGDESC to an image.
What is a LONGDESC?
It’s no more than a long description for acomplex image. When there’s so much information within an image, that the ALT attribute would be too long, the LONGDESC gives you the opportunity to provide a subtle link to a different page, where the image is fully described.
The value applied to the LONGDESC attribute needs to be the uri of the descriptive HTML or text page.
Example of workable LONGDESC
The code that would correctly apply a LONGDESC attribute could be:
<img src="whitby01.jpg" alt="Sunset over the water at Whitby" longdesc="whitby01desc.html" />
Then you’d need a very simple HTML page called "whitby01desc.html" to deliver the description, which might be:
“A deep orange sun sinks toward the seaward horizon lighting up the waves off the East coast resort of Whitby.”
How it should work
Screen readers can announce the presence of a LONGDESC applied to an image, JAWS announces the ALT attribute, followed by “Press enter for long description”. On pressing enter, the description page loads in a new browser window, (by default), so that the user doesn’t lose their place on the original page.
I’ve yet to find any evidence that people who don’t use screen readers can access the long description page at all, which is a shame, as it could be useful for screen magnification users, certainly more useful than a lengthy ALT text.
This all seems quite simple. So what goes wrong?
Incorrect applications of LONGDESC
The ten sites that had faulty applications of LONGDESC made at least one of three errors:
- Two sites used the long description as the LONGDESC value. This obviously wasn’t announced, and there was no link to follow, so that was a wasted effort.
- Three sites used “#”, or the uri of the current page as the LONGDESC value. This meant that a new window opened, but it only presented the user with the same page as the one they’d just left. Oh my!
- Seven sites used LONGDESC, either correctly or as in one of the ways above, but on linked images. This just can’t work.
The problem with the last technique is that the same keystroke, (Enter key), is used to launch both the LONGDESC page and the destination of the link. It shouldn’t happen, but it does. W3C warned about this in the HTML4 specification:
“Since an IMG element may be within the content of an A element, the user agent’s mechanism in the user interface for accessing the “longdesc” resource of the former must be different than the mechanism for accessing the href resource of the latter. “
Put simply, this means that browsers should respond to a different keystroke to open LONGDESC information than the one used to open links. This hasn’t happened, so applying a LONGDESC to a linked image is wasted effort.
LONGDESC, a fall from grace?
As the subtle way of providing a long description seems to cause confusion to web authors, I’d like to suggest an alternative. This would also solve the more important problem that a properly implemented LONGDESC isn’t accessible to people who aren’t screen reader users.
How about putting a short text link adjacent to the image, leading to the description page? In the Whitby sunset example, if the image and text were wrapped into a single link, the text could just be “Image description”. Visually the relative positions would inform users which image this refered to, and screen readers would hear both the ALT and text announced as a single link, “Sunset over the water at Whitby: Image description”.
Alternatively, the link text could be more descriptive, and leave the image out of the link.
Either of these techniques would make the long description available to everyone. Of course you’d need to decide whether or not to open the link in a new window, and how to let users know it’ll happen.
If anyone knows of a way to make the LONGDESC linked page available to all users, please pipe up. I’d be happy to support it if it can support all users, otherwise, isn’t it time we took it out of the web authors’ accessibility toolbox?
Martin Kliehm | 13/02/2008 at 15:48 | Permalink
Bim, I have used longdesc only once on a website where I published flyers for an event. I had the text of the flyer on another page anyway, so I pointed longdesc to other-page.html#text. Though on other-page.html was a smaller image of the flyer, and that also pointed to #text. That seemed reasonable. What I didn’t know then was that browsers or rather screenreaders fail to implement the mechanism to open longdescs properly, so I used it on a linked image. Thanks for sharing that.
But the whole case reminds me of the alt-attribute. We have an attribute where people don’t know how to use it properly. Also we have faulty browser implementations that lead people to misuse the attribute (as a tooltip). Is that reason enough to remove it from the specification, or shouldn’t we rather educate developers and build pressure on browser and screenreader vendors? longdesc is obscure, but in certain cases it is very useful and less pain than adding a link. I would rather tell screenreader vendors to fix that behavior according to the specs than removing a reasonable element.
Ben 'Cerbera' Millard | 14/02/2008 at 10:35 | Permalink
My response didn’t go through, so I blogged it: the Long Description.
Bim | 14/02/2008 at 12:30 | Permalink
Martin: I do so agree! It would be wonderful if we could get all user agents to implement the specifications for all elements and attributes correctly. But how soon is it going to happen? When did complaints about IE rendering of the ALT attribute begin? I believe that we should keep trying, but am suggesting what I hope are workable alternatives, “until user agents …”.
I was being deliberately controvertial in suggesting that LONGDESC is removed from the web authors accessibility toolbox, hoping for a comment like yours. We put pressure on where we can, but the web community at large has to get behind calls for adherence to standards. Many hands make light work.
Educating developers is exactly what we’re trying to do in this WACblog, along with flagging problems, and suggesting alternatives. Education is a big part of everything we do, whether we’re engaged in client commissioned audits, speaking at conferences, providing online guidance, or running training courses. We’re always looking for effective ways to reach more developers, so if you can think of any, do let us know.
The way you handled LONGDESC on the only time you used it, sounds grand, apart from it being initially in a link. In that case, if the large image linked to a download, I’d have been tempted to provide an adjacent text link, “Leaflet text: (HTML)”, assuming that the download was in a different format.
Bim | 14/02/2008 at 13:38 | Permalink
Ben: Many thanks for pointing up my errors, which I’ve now corrected. I’d typed straight quotes into WordPress, not realising that they would be converted to curly ones. Thanks also for the thought provoking blog, where you make some interesting points, my response to these is below:
John | 14/02/2008 at 13:58 | Permalink
Nice artical Bim, I’ve only come across this longdesc attribute recently and have never used it.
My only question is what is the difference between having an images long description linked to by an image inside a link and an image using longdesc?
If they both respond via enter/clicking then the only difference I can see is longdesc is a kind of short hand?
Also how does longdesc respond while images are disabled? IE textonly browsers etc.
Bim | 14/02/2008 at 14:46 | Permalink
John: the difference between having an images long description linked to by an image inside a link and an image using LONGDESC is that people who aren’t screen reader users don’t have access to the long description file. Some may want or need it.
I don’t advocate just linking from the image though. That would leave folk who don’t have easy access to the ALT text, in some doubt about why the image is linked, and where the link leads. That’s why I suggest incorporating contextual text into the link.
Yes, LONGDESC is just a kind of shorthand, but it needs to be handled in browsers in such a way that allows everyone to access the long description. Sometimes it’s used to link to a table layout of financial information presented in a chart. If the chart is too small for people with less than 20-20 vision to identify labels, or users find charts more difficult to understand than plain figures, there’s a clear need to provide an alternative that can be accessed without having to buy a screen reader. At least until the LONGDESC is available to all.
I have to confess, I don’t know how a text browser would handle LONGDESC. It’s a good point, thanks for raising it. I’ll check it out and come back to you on this one.
Ben 'Cerbera' Millard | 17/02/2008 at 14:33 | Permalink
I’ve got some ideas about how
longdesccould be handled without needing a screen reader. I’ve written them up in Further Description.Bim | 18/02/2008 at 10:23 | Permalink
Hi Ben, the only related content I could find from following your link was an expansion on what you mean by “seeing the image”:
Unfortunately, that doesn’t take account of the many people who can see, but not clearly, or only partially. They may not be screen reader users because they have enough sight to cope with text, which can be enlarged or reduced in size and follows predictable patterns. Reading is slowed, but still possible. An image doesn’t present any predictable pattern, so it’s meaning would be either pure guesswork or have to be built up by a long process of concentrating on one bit of it at a time and reconstructing it in the mind like a jigsaw.
Text presented in graphics, such as the x and y coordinates, or labels of a graph, won’t scale with text, and will never be as clear, so that type of information is likely to be lost to a lot of users, even those without serious sight conditions. Long-sighted and short-sighted people for instance, might be equally disadvantaged, but don’t need a screen reader.
Ben 'Cerbera' Millard | 19/02/2008 at 9:35 | Permalink
Interesting point about enlarged pictures of things being hard to recognise while enlarged text is fine. I thought these 2 experiences would be equivalent. Learn something new every day! :-)
When a screen magnifier or a browser zoom feature is used, images do scale with text. If the scaling applies a sensible type of smoothing, I thought text in images would remain legible?
In the comments here, you wrote:
So I thought discussing ideas about accessing
longdescwas relevant. My blog entry, “Further Description”, mentioned context menus in graphical UAs and suggested generating a link beside images in text-only UAs. What do you think of those ideas?Bim | 19/02/2008 at 10:12 | Permalink
Hi Ben,
Sorry I didn’t find your whole message when I sent my reply. I hit a bug in my screen reader that skips all content in a DIV, after it reaches an ABBR element. Had to disable abbreviation expansion and guess at the shorthand in your blog. :)
The right-click solution you suggested for Firefox users could present a problem for people who can’t use a mouse, don’t you think?
Some screen magnifiers aren’t too bad, if you have several hundred pounds to spend, but most aren’t clever at making enlarged images appear as clear as the original.
I’d be interested to try out the extension idea though, but then we get back to the whole point of this post, fewer than 10% of web authors are coding LONGDESC attributes that could work under any circumstances. Providing a text link isn’t quite the same as browser CSS hacks, is it? If a text link isn’t robust, the whole future of the web is in the balance.
Ben 'Cerbera' Millard | 19/02/2008 at 21:22 | Permalink
My reply wouldn’t go through so I’ve blogged it: Comparing
longdescto<a href>.If authors aren’t using
longdescsensibly, how would they become more successful at doing the same thing with another method? Is most usage oflongdescjust bogus additions from authoring tools which would be cleaned up by fixing those tools?Bim | 20/02/2008 at 9:06 | Permalink
Hi Ben,
If the incorrect implementations of LONGDESC I’ve seen are down to authoring tools, I’d be surprised. They only appeared on a few images. Authoring tool problems tend to be more widespread than that.
The alternative I’ve suggested can hardly be thought of as reinventing the wheel Ben, It’s a text link. It’s also one of the suggested methods in the current draft WCAG 2.0 techniques for handling providing a long description.
Most important, it would make the long description available to everyone who needed it, regardless of the technology they use.