I was presented with a mild quandary today concerning a page that required some extra help in the web content accessibility stakes, and what presented itself as the obvious option was the old longdesc attribute, along with some questions though concerning it’s usefulness.
For those that may not be familiar with the attribute, a brief explanation of it’s purpose is as follows: The longdesc attribute is intended to provide further detailed explanation of an image where the alt attribute may not be sufficient, or to quote from the W3C:
This attribute specifies a link to a long description of the image. This description should supplement the short description provided using the alt attribute. When the image has an associated image map, this attribute should provide information about the image map’s contents. This is particularly important for server-side image maps. 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.
W3C – 13 Objects, Images, and Applets: 13.2 including an image: the img element
The above quote is drawn from the W3C page on objects and images it is perhaps not the best example of the use of this attribute, to add further the alt attribute is meant to convey a short snappy description and should not be overly lengthy, remember that it will be displayed if the image fails to load and could cause a layout or body of text to seem a little odd, the long desc attribute therefore is meant for a far more detailed description that can amount to a story if you like.
It appears that this attribute is one of those that, if people have come across it, tends to get misused or simply incorrectly used. A common misuse is for people to believe that it simply acts to replace the alt attribute and use it in the same manner but writing a lot of text directly into the attribute string. The correct method of use for longdesc is to describe the path to a separate file (or section, but more on that use later) So in the attributes string would be a path reference to an html file or at least another page.
My quandary was as follows; I was required to re code a page that I had previously finished, coded and laid out, semantic and happy, a revision from the design team came through, this version was greatly improved much cleaner looking , however it relied a lot on font faces and images for that style and was reminiscent of a printed page or brochure/flyer. All in all, although not a walk in the park, it was all basically do-able the primary aims to attempt to recreate the look of the psd layout whilst retaining semantic markup. The headings were not a problem I could describe them correctly as ordered heading tags and then using a bit of extra markup I could cut the psd text and save as an image which was then placed over the top of the actual heading text by adding the image as a background of the extra element in the heading tag this was then displayed positioned absolute so that it overlaid and hid the original markup text – a straightforward and commonplace image replacement technique, should images fail to show the original text would replace it and for screen reader the markup text was still there to be read. So on that note all was well and good; my quandary and dilemma – and reason for this post – came with the next section of that page.
The page made use of a couple of pie graphs to graphically represent some comparative data, these were a fine set of graphics looking very smart and well executed, naturally as these conveyed important information they would need to be inline elements, that is, foreground ones, part of the markup rather than as backgrounds to elements. A simple job to do and they looked rather nice 🙂 however here my problem began, as images they were fine for sighted users – as long as the image was displayed!- but what about for screen readers or if images failed to load? how to present the information?
Why of course, the longdesc attribute, seldom used but this felt like the perfect justification if not necessity for it’s use. It’s not something that I can remember having actually used (well once long ago) and although I knew how to use it correctly – I hoped – I did realise that I wasn’t sure just how effective a solution it was for the problem, did anything actually pay any attention to this attribute or was it simply wasted characters?.
Alternatives at this point were few, I believe that some would advocate using the title attribute to convey extra detailed description, but this is still not really the correct approach as named the ‘title’ attr is not suitable for lengthy descriptions.
Getting back to the quandary; having entered a longdesc attr
<img src="" alt="" longdesc="my-descrip-file.html" /> and created a file to hold a detailed explanation of the graph and it’s data results, I wondered just how effective this actually was, would screen readers all work wth this attribute and read that long description file? It’s a question I couldn’t answer.
Upon some investigation it would appear that this attr is one of those that has patchy support, possibly due to no one really being sure if it is an effective tool?
Alternative approaches to the longdesc attribute
One approach that I have seen mentioned and described a few times and which originates from the W3C is that of the D-link short for Description Link this involves placing a text link next to the image using the character ‘d’ and linking that to your text file description. This is an approach that I don’t necessarily feel comfortable with, largely due to the feeling (as others express as well) that it is not a particularly familiar link to see and might simply be overlooked by users or just plain confuse them and it does navigate away from the page, also – and importantly in this instance – it is not in keeping with the design aims of the page (even though it could be argued that it was necessary and fight for it’s inclusion, it would disrupt the look of the page)
For the moment I rule out this approach, but as an alternative there is a method that Andy Clarke uses and which he briefly touches upon in a post of his titled ‘Accessible Alternatives’ which is about the subject of providing accessible alternative content for images and graphics. Andy’s approach is essentially to add text in the form of a paragraph that is then shunted of screen using text-indent and a background image applied to the paragraph, this is a technique many of us are familiar with and is a good alternative where a background image can be used (in fact it causes me to wonder whether I actually do need to use a foreground image?) screen readers will be able to still read that text description sighted users will see the background, it does fail if for some reason the background image fails to load and sadly is not a perfect solution.
Following on from Andy Clarks post above is an update post – ‘Accessibility footnotes’ where he expands on his ideas. Interestingly it starts with a quote from a discussion with Bob Easton which re-enforces the notion of bad browser support for longdesc by mentioning that certain screen readers such as Jaws will open a longdesc link in a new window, adding a helpful close link might cause problems with browsers that navigate to that new page as they upon closing that page via the link will loose the whole session – not great!
So in conclusion and borrowing heavily from Andy Clarks blog posts on this subject it would appear that there isn’t a great deal to support the use of the longdesc attribute, and some negative issues.
In his conclusion Andy Clark makes a case for abandoning the longdesc altogether, instead adding a link as was described earlier but not as a ‘d’ but with a fuller descriptive link text, much as we would normally like to see with a link this then points to an anchor element at the bottom of the page holding the full description, the link to this footnote is hidden from visual browsers using CSS as is the text decription, screen readers will be able to read it and the markup should retain semantic sense with styles disabled or text only; this I think is probably the best approach that will be found for this requirement for full descriptions but it’s sad that the longdesc doesn’t suit the purpose it was designed for.Tweet
Comments are closed.