Solving the longdesc problem

The Image Description extension re-introduces the longdesc attribute to HTML. Although most people recognise that longdesc is flawed, finding a viable alternative has proved surprisingly difficult. For now longdesc is the best solution we have, but in the interests of finding a better option perhaps it’s helpful to take a step back and look at the problem we’re trying to solve.

Problem 1: Availability

The first problem we need to solve: It must be possible to provide a detailed description for complex images.

A complex image might be something like the blueprint for a building, a UML diagram, a renaissance oil painting or a movie poster. A person who is unable to see the image would use a detailed description to understand and enjoy its content. A person who struggles to understand the image would use the detailed description to interpret and appreciate the image.

Problem 2: Discoverability

The second problem we need to solve: It must be possible to discover and access the detailed description.

Complex images might be used to educate, inform or entertain. Whatever the circumstances, there must be a way for people to find out that a detailed description is available, and a way for them to access it. This means the call to action must be visible (for sighted people), and programmatic (for non-sighted people).

Problem 3: Structure

The third problem we need to solve: It must be possible for a detailed description to include structured content.

A detailed description of a product in an online store might only need text. A detailed description for something like a graph or chart is likely to need more structure, so a detailed description must be able to include headings, lists, data tables and so forth.

In short we need a mechanism for providing detailed descriptions for complex images. The detailed description must be discoverable by anyone, and have content that is appropriate to the image it corresponds to.

The pros and cons of longdesc have been discussed ad nauseam (let’s not do it all again). For the moment a flawed solution is better than no solution at all, but now seems like a good time to re-energise the search for a better solution. Look at it this way: If longdesc had never existed, how would we solve these problems today?

4 comments on “Solving the longdesc problem”

Skip to Post a comment
  1. Comment by Stomme poes

    For better or for worse, most would solve it with ARIA. This won’t fit demand #2, because currently ARIA is hidden from many users, but that seems to be the go-to place to look for solutions, even to problems where better markup would be the better answer.

    And for the rest, a link is what many of us have been using: I had a time where all longdescs (mostly for web comics) were all on one page, and anywhere else on my site linked to the appropriate chunk of the page using the hash#. That must have been painful for webkit users though with that nasty focus bug.

    The problem any solution has with getting anything implemented is the extra time it takes someone (likely someone paid) to translation the complex image into something else. Sometimes graphs or charts can be created programmatically or the complex image was already derived from charts or chart data, but otherwise, it can be quite a large undertaking, and working web devs are going to wonder how they will charge for an “extra service” the client didn’t ask for.

    Reading comments on web dev forums and article sites, this is the prevailing feeling, and I suspect it’s the biggest barrier to longesc-y things, not the standards/browser implementation method. Maybe that’s the problem to solve.

  2. Comment by Laura

    I strongly disagree with using an ARIA solution to provide a HTML long description. ARIA is designed to provide accessibility at a technical level – what is known as ‘programmatically determinable accessibility’ – where it doesn’t already exist. Longdesc exists.

    WAI-ARIA is a bridging technology. Bridging technologies are not intended to replace native HTML semantic features. Detouring accessibility technical requirements into an “Accessible Rich Internet Applications” bridging specification is backward. The “Introduction to ARIA” document clearly states, “WAI-ARIA is intended to be used as a supplement for native language semantics, not a replacement. When the host language provides a feature that provides equivalent accessibility to the WAI-ARIA feature, use the host language feature.”

    WAI-ARIA should only be used as a last resort when content can’t be made accessible using the host language. Longdesc exists in the host language.

    The first rule of ARIA use is: “If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.”

    The Protocols and Formats Working Group is the group that authors WAI-ARIA. Their charter states: “Note that WAI-ARIA is intended to be a bridging technology. It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with WAI-ARIA.”

    A significant goal of WAI-ARIA is to: “help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature.”

    Comparede to longdesc any ARIA technique is a retrograde, makeshift substitute that does not directly provide the valuable native semantics and critical backwards compatibility that longdesc does.

    All that needs to be furthered is longdesc browser support and author education.

  3. Comment by Catherine Roy

    No offense Léonie but I wonder what the point of this post is. Looking at your criteria, the longdesc attribute already meets them naturally except for #2 that has a few problems but I think that is more an issue of user agent implementation (ex. JAWS and NVDA support it and some mainstream browsers partially support through plugins but there is still work to do in that area).

    I have to agree with Stromme poes. The biggest obstacle to longdesc is the effort of producing the descriptions. And generally speaking, unless it is part of the culture (i.e. embedded in content development practices) or an obligation (i.e. required by some sort of enforceable rule), no amount of rebranding or reinventing will change that. Of course, if people want to spend more time trying to replace something that already works, that is certainly their right. But personally, I think we should be focusing on outreach and development of tools for facilitating the production of descriptions.

Comment on this post

Will not be published