The rise and fall of the LONGDESC

On this page:

Post details
Comments
Add a new comment

Post details

By Bim

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?

Comments (13)

Tag: Too much accessibility

Posted at: 12/02/2008 6:13 PM by Dave Wailing

Comments

Using LONGDESC

Martin Kliehm said:

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.

Posted at: 16/7/2010 12:01 PM by Dave Wailing

Context menus and authoring tools

Ben 'Cerbera' Millard said:

Context menus can be opened from the keyboard in Windows. Either by the Properties key, located next to the right-hand Ctrl, or by Shift+F10. This is a native feature.

If the issue is longdesc being used wrongly most of the time, that's true of HTML generally.

The solution, I think, is to stop authoring tools from generating specialist markup without the author knowing about it. Automated accessibility checks which pat authors on the back for the mere presence of longdesc, without checking if it's a link to a different document which would actually work, are probably another area to improve.

Abandoning longdesc and using text links is similar to CSS hacks, to my mind. It means abandoning the purpose-built feature designed specifically to provide this, then putting something similar together using features which weren't designed for it.

Dropping longdesc and using visible text links (which will be of no use to most people who see them) doesn't seem a great option, to me. I'd rather we fix the situation with longdesc if it is useful to people.

Posted at: 16/7/2010 12:10 PM by Dave Wailing

Further thoughts on LONGDESC

Bim said:

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.

Posted at: 16/7/2010 12:11 PM by Dave Wailing

Even more thoughts on LONGDESC

Bim said:

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:

• The description links suggested in WCAG 1.0, didn't catch on, as you quite rightly say. But those simply used the letter "D". Users didn't know what they were for, that's why I suggest a clear text link, making purpose clear.

• It's not quite true that if you can see the link then you can see the image, screen readers can follow the link, but not interpret the image, people with colour blindness or poor vision would be able to see and follow the link, but may be unable to see the image clearly enough to understand it's meaning and information.

• If design constraints prevent users understanding content, that's not an accessible design. But I've more faith in the creativity and ingenuity of developers than that, especially those who are strong on accessibility.

• You're right about the confusion that could be caused by just giving in image an HREF to the text description, it could be handled by the ALT attribute, but that would only be available to screen reader and IE users.

• I agree that text to speech applications may be able to separate an HREF from a LONGDESC, and present them as different links, but that won't help users with low vision who don't need screen readers but do need the image described.

• You're right, in many cases, the correct place for complex image interpretation is in the content of the page, but there may be cases where this isn't appropriate, which is where the plain text link idea comes back in.

Posted at: 16/7/2010 12:14 PM by Dave Wailing

Images and LONGDESC

John said:

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.

Posted at: 16/7/2010 12:16 PM by Dave Wailing

Respond to images and LONGDESC

Bim said:

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.

Posted at: 16/7/2010 12:16 PM by Dave Wailing

Screen readers

Bim said:

Hi Ben, the only related content I could find from following your link was an expansion on what you mean by "seeing the image":

"By "see the link" I meant "see" in the literal sense. A user who can view the image directly has no need for a link taking them to a description of what they just saw".

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.

Posted at: 16/7/2010 12:19 PM by Dave Wailing

Scaled images

Ben 'Cerbera' Millard said:

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:

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

So I thought discussing ideas about accessing longdesc was 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?

Posted at: 16/7/2010 12:20 PM by Dave Wailing

Further thoughts on images

Bim said:

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.

Posted at: 16/7/2010 12:21 PM by Dave Wailing

Usage of LONGDESC

Ben 'Cerbera' Millard:

If authors aren't using longdesc sensibly, how would they become more successful at doing the same thing with another method? Is most usage of longdesc just bogus additions from authoring tools which would be cleaned up by fixing those tools?

Posted at: 16/7/2010 12:22 PM by Dave Wailing

Incorrect implementations of LONGDESC

Bim said:

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.

Posted at: 16/7/2010 12:23 PM by Dave Wailing

Semantic reference to a long image description

Hi Bim,

Thanks for your blog posting.

I think we all agree that the main problem with LONGDESC was the poor implementation of browsers and screen readers.

I personally think there is a high value to be able to reference semantically to a longer image description or to a bigger high-resolution image for screen magnifiers.

I don't agree that a semantically unrelated link to a long description is helpful. How would you offer to open the LONGDESC if you use the list of images (in JAWS with INS+CTRL+G)?

I fully agree that we need a better user experience. I would favour a way to expand/collapse the LONGDESC inside of the page as user interaction - similar to a tree widget. Programmatically it could be included similar to an iframe.

I think another misperception of the usage of LONGDESC is to only measure the public pages. On a lot of Intranets it's used for technical diagrams.

Posted at: 14/12/2010 12:18 PM by Artur Ortega

Browser support for longdesc

Bim,
Opera 11.10 and iCab browsers support longdesc and make them visible to sighted users when they right-click an image. Look at the examples in Laura Carlson's research on longdesc use at http://www.d.umn.edu/~lcarlson/research/ld.html.

One of the examples is at http://cssquirrel.com/comic/?comic=52, a page with comics on web design.
Right-click the image in Opera and a context menu will pop up that reads "Long Description". Select that to see the longdesc in a new browser tab.

Right-click an image in iCab and a context menu will show that reads "Show long description of image". Select that, and the longdesc will open in a new window.

Posted at: 20/5/2011 11:11 PM by Monika Trebo

Add a comment

If you would like to add a comment, you need to login first.