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"
longesc="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!

Voice Your Support for HR 3101: Make Online Video Accessible

While you're contacting your congressperson and encouraging them to support a public health care option, please take a moment to also encourage them to support HR 3101, the "21st Century Communications and Video Accessibility Act of 2009". This bill was introduced by Massachusetts Rep Ed Markey on June 26 and is currently in committee.

If passed, HR 3101 will bring existing federal laws requiring communications and video programming accessibility up to date. As you all know, the Information Age has expanded well beyond our television sets, and we now get information and media from the Internet using our laptop or desktop computers as well as handheld mobile devices.

Back in the days when we got all our information from TV, the Deaf and Hard of Hearing had the same level of access as the Hearing, thanks to federal laws (passed in the 1990s) that required (a) video program distributors to provide closed captions with their programming, and (b) television manufacturers to produce TVs that were capable of displaying those captions.

Fast forward to 2009: You're watching the latest news from CNN on your laptop while catching up on last night's episode of America's Got Talent on your mobile device. This programming is all captioned on television, but not on the Internet, and captions may not even be supported on your mobile device. If you're a person who doesn't have good hearing and therefore needs closed captions, none of this programming is accessible to you. Your only choice for accessing video is to remain in your living room tethered to your TV set.

Worse yet, if you're blind or visually impaired you don't even have equal access to that TV set. You can generally understand most video content based on the spoken dialog and other sound cues, but most programming includes visual content that is not communicated audibly. The art of making this content accessible is called "audio description" (also "video description" and various other terms). It consists of a separate audio track in which a narrator describes key visual content. Blind users can choose to turn this track on or off. This method of providing access to visual content has been around since 1974 (according to this history of audio description), but U.S. telecommunication laws have not required it, and there is little standardization in today's technology as to how it should be delivered.

HR 3101 does for audio description what the federal laws passed in the 90's did for captions. It directs the FCC to conduct an inquiry into the best methods for delivering audio description and to report their findings to Congress within 18 months of enactment of the law. It also requires programs to be described, and requires that video-enabled devices be capable of delivering the descriptions if they're available.

In short, HR 3101 stands to finally bring U.S. accessibility laws related to communications and video programming into the 21st Century. By doing so it will remove the growing array of technological barriers that prevent individuals with disabilities from fully participating in our video-based information society.

To learn more about HR 3101 or to track its progress, one good resource is Coalition of Organizations for Accessible Technology (COAT). Their website includes a One Page Summary of the Bill as well as a Section-by-Section Summary of the Bill.