Categories
A11y

Long Descriptions of Images

Yesterday Kyle Weems, aka CSSquirrel (who incidentally I just recently learned is a fellow ‘Hamster) discussed in his blog a couple of strategies for adding long descriptions to his comics.

One of the longest-running debates in all of web accessibility is how best to provide long descriptions of images on the web to people who are unable to see them. Most images can be described with an alt attribute, which is read by screen readers whenever an image receives focus. As such, they should be short and sweet, the goal being to ensure that non-visual users have access to the same information that visual users have.

But what if an image can’t be described succinctly, such as is the case with a comic strip? In academia, we encounter images like this all the time. Our journal articles, curricula, reports and presentations, etc. are all filled with graphs, charts, diagrams, and figures that are filled with tons of information.

The longdesc attribute has been the standard solution since 1997 when it was introduced in HTML 4.0. Here’s how it works: The web author creates a separate web page (e.g., “fig1.html”) that contains the long description of the image. Then, they reference that file in the longdesc attribute of the image element:

<img src=”figure1.gif”

alt=”Figure 1: A bar graph showing accessibility results”
longdesc=”fig1.html”/>

Unfortunately the web didn’t exactly embrace this new attribute. It took many years before screen readers supported it. Freedom Scientific JAWS didn’t build in support until four years later with the release of JAWS 4.01 in November 2001. Given the lag time, the workaround that many web developers adopted was a so-called “D link”, which was simply the letter “D” in a link adjacent to the image. The D link worked just like longdesc was supposed to (i.e., it targeted a separate web page that contained the long description), but it was supported by all browsers since it was just a link. Although lots of people were aware of this convention there were far more people that were not. I used to practice this technique myself, and I can’t count the number of times people asked me “What is that D for?”

Longdesc eventually came around to being supported by the major screen readers, although even today the usability of its implementation is not especially graceful. Both JAWS and Window-Eyes announce to the user that a long description is available (if one is), and prompt the user to read it (if they so desire) by pressing Enter (JAWS) or Alt+Enter (Window-Eyes). So far so good. But if the user responds affirmatively to this prompt, the long description opens in a new window. This has much of the usability baggage that accompanies any link spawning a new window: The user now has multiple tabs or windows to manage; they temporarily lose their focus in the original document; and if they have pop-up blockers enabled the long description may not be delivered at all, even though they’ve just requested it.

Longdesc also presents a minor inconvenience to web developers, who have extra pages to maintain. Most web developers don’t use it, and many that have tried don’t use it correctly according to Mark Pilgrim’s stats.

All of these might be good reasons to come up with a better method for supporting long descriptions on images. The current draft HTML5 specification has eliminated longdesc, and the WAI CG Task Force on Alternative Text has resolved that it’s ok to obsolete longdesc as long as other better methods are in place for providing long descriptions.

That better method is the aria-describedby attribute, which is part of the Accessibility Rich Internet Applications (ARIA) recommendation. Here’s the technique for adding a long description using aria-describedby:

<img src=”figure1.gif”

alt=”Figure 1: A bar graph showing accessibility results”
aria-describedby=”fig1″/>

Then, somewhere else in the document, add a description with an id matching the one specified in the aria-describedby attribute. The description could be hidden using CSS if desired, but maybe some sighted users would benefit from the description as well.

<p id=”fig1″>The long description of Figure 1 goes here.</p>

Some long descriptions might be prohibitively long, and really would be better served on a separate page as they currently are with longdesc. For this reason, aria-describedby should support long descriptions that are stored off the page in addition to supporting those that are on the page. That could be accomplished by using aria-describedby to point to the id of a link (as in the following example) as opposed to a paragraph (as in the preceding example, like this:

<img src=”figure1.gif”
alt=”Figure 1: A bar graph showing accessibility results”
aria-describedby=”fig1″/>

<a href=”fig1.html” id=”fig1″>Description of Figure 1</a>

Currently, aria-describedby doesn’t seem to be well supported by user agents. I created a Long Description Test Page that includes several images marked up with various combinations of description-related attributes. I tested this page with NVDA 0.6p3.2, JAWS 10, and WindowEyes 7.0 (not the latest version, 7.1) in both Firefox 3.5 and Internet Explorer 8. JAWS and Window-Eyes both handled the longdesc as described earlier, but none of these screen readers announced the aria-describedby description or gave any indication that a description was present. That said, ARIA support in general is moving forward quickly, so I’m optimistic that aria-describedby will ultimately be supported by assistive technologies as well as browsers.

If you experience positive results with aria-describedby on the test page, please post a comment!

One reply on “Long Descriptions of Images”

WebAIM has just announced the results of their second screen reader user survey, and there are interesting results about complex images:

28.4% prefer descriptions
as text on the web page, immediately following the image

26.6% prefer descriptions as optional text, available on the same page but only if they request it by following a link

19.8% prefer descriptions on a separate page, available by following a link

14.2% prefer descriptions as a very long description (alt text) on the image itself

9.1% prefer descriptions on a separate page, announced by and available to their screen reader

1.9% prefer descriptions to be ignored entirely by their screen reader

Comments are closed.