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.

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?

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.

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?

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

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.

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.

• 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 speach 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.

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.