Longdesc is dead! Long live Longdesc!

Written by Joshue O Connor Friday, 20 August 2010

Coffin Brassplate saying @longdesc RIP 1997-2010 The future of an important mechanism allowing the creation of accessible images using HTML5 hangs in the balance after a working group decision to remove it from the specification - despite the recommendations of their own expert working group to keep it.

The longdesc attribute (@longdesc) is used as a long descriptor for images on webpages to help describe them in detail for blind and vision impaired people. The idea being that for most images, a short or terse description is all that is needed but in some cases there is need for a more verbose or longer description, this is where @longdesc steps up.

Traditionally, @longdesc has been little used and there are many cases where a short text description will suffice as an image description. However, there are use cases where a much more detailed long description is actually needed - such as for technical diagrams, complex images such as periodic tables and other scientific materials either used in industry or in education.

So how could a useful, if little used attribute get dropped from HTML5? Firstly some background. The Public HTML 5 working group list, is a busy place so in order to focus on issues relating to accessibility it was wisely decided to start a dedicated accessibility related working group.

The HTML Accessibility Task Force

The HTML Accessibility Task Force (HTML A11y TF) was formed as a partnership between the HTML 5 working group and the Protocols and Formats working group (PFWG), in the W3C. Its purpose is to “ensure that HTML 5 provides features to enable Web content to be accessible to people with disabilities”. It is where both accessibility experts from the PFWG provide input and architects from the HTML WG provide input on architectural goals and non-accessibility considerations.

A recommendation was made to the HTML5 WG that @longdesc be retained. This decision was reached after much deliberation via email and Face to face discussion, and presented as a candidate recommendation.

The recommendation was then dismissed by the WG chairs - despite the existence of an equivalent functional alternative – and @longdesc is no longer a part of HMTL 5.

Some of the main reasons for dropping @longdesc include:

The strongest argument against inclusion was the lack of use cases that clearly and directly support this specific feature of the language. The fact that @longdesc has little observable uptake amongst users reinforces this: all the evidence indicates that users don't see this feature to be compelling, and the lack of user demand has been noticed by implementers

Chicken and Egg?

To some degree, I can understand why they came to the above conclusion, because when looking at the Web in toto pretty much all accessibility related functionally can look relatively very underused. What is spurious however is to state reasoning that there is little uptake amongst users, as the end user will only interact to what designers and authors put online in the first place, and it can be argued that only over time is awareness slowly increasing about Web Standards, best practice and how to support accessibility in Web design and development work. So this argument is a little chicken-and-egg.

Misuse of @longdesc?

Also another rational for @longdesc's discontinuation is that the content of many images containing @longdesc may be bogus. For me, this is not a very solid reason to discontinue this or any other attribute. More so when it is actually useful for people with disabilities. When needed the functionality should be there, available to the developer. The developer should not be censored nor or people with disabilities penalised due to legacy misuse.

No real alternative

Contrary to what the chairs of the HTML5 WG state, there are no real functional alternatives. What is cited as a replacement for @longdesc is ‘aria-describedby’ however this is not a functional replacement as it is only an ID fragment identifier and not a fully functional replacement (this may be the case in future with ARIA 2.0 but it just isn’t at this point). Also the working group has stated a preference for native solutions (which @longdesc is). FIGURE is maybe the closest functional equivalent but its functionality is closer to @alt or the CAPTION element.

@longdesc is also mandated for those who with to comply with Section 508, the WAI guidelines and more as Laura Carlson from the University of Minnesota Duluth points out in a reply to the working group:

Longdesc is a technique recommended in both the WAI guidelines and the Section 508 standards. Standards issued by the Access Board under Section 508 of the Rehabilitation Act cover access to electronic and information technology procured by United States Federal agencies. One example: longdesc is an official part of United States Postal Service policy. It has also trickled down to States and State agencies. For instance, longdesc is a recommended solution in many University Web Standards like the University of Minnesota. Longdesc is part of Dutch Accessibility Law (section R-pd.7.3) Translation: "Do not use d-links on government websites. The use of longdesc (long description) attribute is preferred if the alternative text in the alt attribute is inadequate for understanding the information in the image.

So where next? There is currently an appeal to the Director of the W3C as well as couple of potential Formal Objections (which are both extreme measures but illustrate how serious the issue is). If the appeal is successful then @longdesc may be reinstated, either that or the engineers come up with a better solution, that is backwards compatible, that fits into the expectations of users and follows an establish user interaction pattern and so on. Actually @longdesc already does that, so why not just re-instate it?

Comments (17)

Hi Josh,

"So where next?", you ask.

Use longdesc. For instance as an addition to this week's bug report [1] to the HTML5 accessibility task force, I made a page with some charts and tables. The first chart has a longdesc [2].

Can NCBI help improve the "little observable uptake" of longdesc? Anyone else?

[1] http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0155.html
[2] http://www.d.umn.edu/~lcarlson/html5bugchart/20100821/

While @longdesc is little used and seldom needed, it seems much more needed than it is used. E.g. such a banal thing as tables presented to the readers in the form of an image, is not at all uncommon in many online publications ... @longdesc could offer a ‘quick fix’ for those examples.

Use longdesc.

The main effect of using longdesc at the current time is you will block people from being able to access the content, including some, possibly most, AT users. That's the opposite of what accessibility is supposed to be about.

The first chart has a longdesc

If you had used a normal link on that image, or put the content in-page, like the RNIB and WebAim recommend, you would have made the long description accessible to everyone. Instead you deliberately chose a technique that makes the long description inaccessible to nearly everyone. This is not accessibility, it's accessibility theatre.

A longdesc provides a solution for describing visualizations of content like charts and graphs to the blind when that content is visually apparent and redundant to a sighted person. Adding longdesc text or a link to a page would only add visual clutter for the sighted as a longdesc aim is to be a substitute for the non-text content.

However, user agents should (as Opera currently does) natively possess the option to reveal the presence of longdesc to all users. This provides a practical method for developers who want a tool to check longdesc and keep it up to date. It also gives everyone access to longdesc content if they actually are curious.

Obsoleting longdesc and telling authors to use visible text links or the full text description in page (neither of which is of use to people who see images) isn't the answer here. So I'll continue using HTML 4 whenever I need longdesc, as HTML5 currently doesn't provide that functionality in a valid feature.

So, here's a "double-negative use case" (in the wild)!

"Double-negative" because longdesc is not being used here — but I would have liked to use it, and its use would have been absolutely appropriate! It's just that weak user-agent support meant that using it would potentially have left the long description actually unavailable to people who might benefit from it. So instead, I decided to compromise (somewhat) the experience of people who already could perceive the graphical image perfectly well, and exposed the long description for all users (even though it is redundant for the majority). This decision then, logically, had the further effect of requiring an explanation — for those majority users — of what a long description is and why — which explanation, in turn, is redundant for those users who would normally actually benefit from a long description!

I humbly suggest that such a convoluted (nay, "traumatic"!) design decision — genuinely existing "in the wild" — should count as legitimate evidence of the use-case-need for longdesc!?

Hi everyone,

Thanks for your thoughtful replies.

@Laura: Many thanks for the useful @longdesc example. I will try to gather more examples of @longdesc in the wild - that would be useful.

@Leif: Thanks for your comment.

@Mattur:@longdesc is not perfect, but it has potential to be modified, its implementation in AT improved etc but we do need to provide use cases etc. It is preferable to some other solutions as it is native to the HTML markup language. As Laura C, then goes to point out via the implementation Opera have - it doesn't have to be an inelegant solution. The point is (for me) that a long descriptor that can reference a URI is needed - how it is implemented is a user agent issue that needs work.

Hi Barry,

Many thanks for that example! If it is ok with you I will forward that to the working group, with your rational. This is interested as technically aria-describedby could be used to reference the textual description but as this is just so verbose the description would appear twice in the AT users view (as such) so this would be much better, off page as a URI, IMO and referenced by longdesc.

Good stuff :-)

Josh

Barry McMullin would be well advised to use a normal link on his image, thereby avoiding making the long description "actually unavailable to people who might benefit from it".

This is not a use case.

Laura can eliminate her "visual clutter" links with the following CSS rule:

img{border:0}

@mattur said:Barry McMullin would be well advised to use a normal link on his image, thereby avoiding making the long description "actually unavailable to people who might benefit from it".

I think you may be missing the point here.

@mattur said: This is not a use case.

Yes, it is. Zero is also a value. And whats more this is in an /interesting/ case that highlights issues with:
1) The need for a capable long descriptor.
2) What some content may be like without one
3) The need for better AT vendor implementation of spec content.

@mattur said: Laura can eliminate her "visual clutter" links with the following CSS rule: img{border:0}

Something tells me Laura may already be aware of that :-)

Something tells me Laura may not be aware of that; her recent email to the HTML-WG omits any mention of using a normal link on the image:

> "Obsoleting longdesc and telling authors and designers to use visible text links *OR* the full text description in page isn't the answer here."

http://lists.w3.org/Archives/Public/public-html/2010Aug/0239.html

An unintentional oversight, perhaps :-)

@longdesc should not be removed from HTML5 until a real alternative has been provided. aria-describedby does not fully replace @longdesc because it does not support URLs, as many others have pointed out. Wrapping an image in an anchor that links to a long description is not fully satisfactory either because that technique is a cowpath (that sacred cow of HTML5!) to other things, such as an enlarged version of a thumbnail, or a normal link where the link text happens to be the content of img/@alt. The content at the target of img/@longdesc is much more similar to the content of table/@summary than to any content for sighted users.
With regard to support, John Foliot pointed out on CSSquirrel that @longdesc is supported by JAWs, WindowEyes, SuperNova/Hal and other AT, has been available in Firefox since version 1.5 (admittedly with poor UI) and is supported by Opera. Rejecting the inclusion of @longdesc in HTML5 forces the accessibility community to find workarounds for browser and AT failures.

When claiming that "The main effect of using longdesc at the current time is you will block people from being able to access the content, including some, possibly most, AT users," one should prove that aria-describedby is at least as good (browser UI and AT support) and that web developers would prefer inserting the long description inside the same page. I bet that web developers will want more choice (Kyle Weems apparently does) and that they won't like circuitous workarounds such as the one suggested by Jonas Sicking today.

Also, isn't it ironic that some people prefer aria-describedby over @longdesc when

the "invisibility" of the attribute is used as an argument against @longdesc but not against aria-describedby (or other WAI-ARIA stuff),

WAI-ARIA is a bridging solution and recommends native solutions - which would include @longdesc - if they are available?

P.S. Thank you Joshue for completing the alt text for my coffin plate ;-)

I would redesign complex images like Barry McMullin's example as follows:

I would remove the text “A model of reflection for children's palliative care”;
redesign the rest of the image so text is at a readable size;
create a caption with the previously removed text below the image: “Figure x: ...”;
turn the caption into a link to the long description;
but still add a longdesc attribute with the same URL because the relationship with the long description should be programmatically determinable.

In other words, for images that can use a caption I would still use the same approach as in a report that I wrote six years ago. This is basically because of the poor browser UI for @longdesc.

So we should think about a better rendering of longdesc content in user agents. Gregory Rosmaita has pointed out that the need to navigate away from the “current” page to the “longdesc page” is a problem with current browser implementations; an in-document rendering would be preferable, possibly per user settings. We should look into two pieces of UI:

How does the browser expose the presence of longdesc (not just to screen reader users)?
How should the description be rendered to the user?

I can't think of many ways to expose the presence of longdesc. How about making an img with @longdesc keyboard focusable, putting it in the tab order? @longdesc contains a link, so that doesn't seem very artificial. It would also be nice to expose the presence of @longdesc to sighted users who might benefit from a long description. A widget that appears onhover would help to some extent, but I don't think you can assume that sighted users hover over every complex image.
The second part of the problem is fetching and rendering the long description itself. If the long description is on another page, the browser could fetch that page and render it. But for in-document rendering, you probably want just the description itself and nothing else, so the browser needs to know where the description begins and ends. This is easiest when the longdesc page contains only the description and when there is only one longdesc page per image. If there is other content on that page, a browser would need to be able to reliably extract it, but producing code that results in an unambiguous DOM seems too much to ask for many tools and developers.
Finally, there is the rendering issue. If we assume that the long description can benefit users without AT, a non-visible rendering (i.e. just passing the description to a screen reader) is not sufficient. So what are the UI options? Some kind of overlay? A non-modal dialogue? (A modal dialogue?) Rendering in a side bar?
To be continued... (Time to get some dinner and go to bed.)

Incidentally, Barry McMullin does have an excellent RW long description example linked from his homepage. The image "Graph: Trends in Atmospheric Carbon Dioxide - Global" links to this page with long descriptions of the graphs in page content:

http://www.esrl.noaa.gov/gmd/ccgg/trends/index.html#global

With @longdesc the relationship between an image and its long description can be programmatically determined. I think this is one of the best arguments in favour of this attribute. This is because the tendency in HTML has been towards higher degrees of semantics and programmatically determinable relationships, for example:

before HTML 4, form fields could not be associated with labels because HTML had no label element; HTML 4 introduced the label element and a mechanism to associate labels with form fields in a way that can be programmatically determined;
before HTML 4, table data cells were not explicitly associated with header cells; HTML 4 added @id and @headers to TD and TH elements to enable explicit association;
before XForms and HTML5, there was no way to mark form fields as required, so developers resorted to JavaScript behaviours to work around this;
before XForms and HTML5, there was no way to define data types for form fields, so developers resorted to JavaScript behaviours to work around this.

The list can probably be expanded, but the point should be clear: not adding @longdesc to HTML 5 is a step backwards because it goes against the tendency to more semantics and programmatically determined relationships.

In response to:

Also, isn't it ironic that some people prefer aria-describedby over @longdesc when
the "invisibility" of the attribute is used as an argument against @longdesc but not against aria-describedby (or other WAI-ARIA stuff)...

When supported both by the browser and the screen reader, the text contained in the elements specified in the aria-describedby attribute is automatically read by the screen reader. This is not the case with the longdesc attribute.

We work with university students who are pretty adept at using the screen reader and many of them don't realize how to access the longdesc content (even though in JAWS it is as easy as pressing Enter).

Until user agents (browsers) support access of the longdesc attribute for all users (not just users of adaptive technology), we don't recommend the longdesc attribute as the sole solution for providing alternate descriptions for complex content. Students with cognitive disabilities, ESL students, etc. all can benefit from a well written alternate description. We follow what WebAIM recommends and suggest adding a visible link with text like "An alternate description of Figure 3.2".

For instance, a dyslexic student using Kurzweil 3000 to read the web can benefit from a text description since the extended literary description may make more sense than listening to Kurzweil try to read numbers and other information off of a chart or table.

Many thanks to you /all/ for the support, excellent comments, solutions, engineering ideas, improvements to programmatic determination and vendor implementation ideas :-)

Josh

Hello! the main reason to longdisc death is lack of browser support.
the main purpose of longdisc in accessibility point of view is to describe more about a complex image.you can get the same effect by adding description below the image and hide it in accessible manner. this will
suffice as native alternative, but not accurate one.

yvComment v.1.22.0

Home