From HTML WG Wiki
< ChangeProposals
Revision as of 07:19, 25 June 2011 by Jsicking (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Keep the longdesc attribute for the img element deprecated


There is a change proposal to re-instate the @longdesc attribute as a valid attribute in HTML5. This change proposal proposes to keep it deprecated, but instead suggest to authors to use the aria-describedby attribute instead. In order to ensure that aria-describedby is as good a replacement as it can be, this change proposal includes a change to the @hidden attribute in order to let authors use it together with aria-describedby in order to accomplish the page behavior they want.

This proposal also includes a proposal to add text to the HTML5 specification that encourages implementations to follow the recommendations in the WAI-ARIA specification for how a implementation of the aria-describedby attribute should work. The purpose of this reminder reaches far beyond the use cases that are intended to be solved by the @longdesc attribute and should be to benefit of users of AT in multiple situations.

This Change Proposal is for ISSUE-30.


Rationale for suggesting aria-describedby as alternative for longdesc

The aria-describedby attribute designed by WAI has several advantages over the longdesc attribute. The first one is that it is much more generic than longdesc. Longdesc is only available on <img> and the various frame elements. Aria-describedby on the other hand is allowed to be used on any HTML element, SVG element and Mathml element. This means that authors only need to learn one mechanism for supplying descriptions. And developers of tools producing HTML can use the same mechanism for adding descriptions no matter what element is being described.

aria-describedby also has the advantage that it encourages authors to create pages where the description is available to both AT users and non-AT users alike. This is generally preferrable since it allows both groups of people to collaborate better, for example if a blind and a seeing person sit at the same computer and look at the same document, both have the description available and can discuss its contents.

The longdesc attribute on the other hand is generally not available visually directly in the page which means that a person who inspects a page visually will not have the same experience as a person who uses a screen reader. While technically browsers could display the contents of the longdesc attribute visually, browsers have traditionally been very reluctant to change the default rendering for fear of creating visually unpleasing results. It is likely technically possible for browsers to have a separate "mode" where contents of metadata attributes such as longdesc, however almost a decade and a half after HTML4 was published as a recommendation, no browser has implemented or even expressed interest in implementing such a mode. In fact, Firefox removed the closest thing there was to such a feature since it was deemed that the amount of code complexity wasn't warranted by how little the feature was used.

Opera (and possibly other browsers) do make the longdesc attribute available through a context menu when clicking a element which has longdesc set. However there is no hint indicating that the longdesc attribute is available until the user right-clicks the element which means that it's still not very discoverable. In fact, the first piece of feedback to the addon which gives firefox the same context menu is complaining about the lack of discoverability.

Another problem that longdesc suffers is that a lot of people seem to misunderstand how the attribute works. In a large number of cases discovered on the web people put the actual description in the attribute rather than a URI pointing to the description. This leads to the fact that even in cases where authors have made the extra effort in order to improve page accessibility for AT users, which appears to be hard to get authors to do given the small number of sites that do it, the page will be no more accessible than if they hadn't provided a longdesc attribute.

Finally, longdesc suffers the problem that it encourages people to make the description available in a separate document rather than in the the same document. While possible to make the URI in the longdesc attribute simply be a fragment identifier such as longdesc="#description", this doesn't seem to be how people intuitively use it. Additionally it doesn't work if the page uses a <base href="..."> element. For example one of the cases commonly brought up as an example of longdesc usage, the CSSquirrel comic, puts the description in a separate page, rather than in the same document. This despite putting other information related to the image in the same document, such as title and blogpost related to the comic.

Note that both aria-describedby and longdesc support putting the description in either the same document or in an external document. Likewise, both aria-describedby and longdesc support displaying the description (or a link to it) to both AT and non-AT users or hiding it for non-AT users if visual requirements for that. However the different structure of the features leads aria-describedby to encourage the better behavior in both these cases.

Reasons for deprecating longdesc

While deprecating longdesc will mean that the pages that use it today will no longer be valid, it also has several advantages.

First off, deprecating longdesc in favor of aria-describedby encourages implementations and tool vendors to focus their efforts on aria-describedby. All browser vendors and tool vendors operate with resource constraints which means that if more time is spent on one feature, that means that less time is spent on another. And in most organizations it's the same team of people which would implement longdesc that would implement, or improve the implementation of aria-describedby. As demonstrated above, the better long term feature to improve accessibility is aria-describedby. Hence we'll help accessibility more by making vendors focus on making the aria-describedby implementation all it can be.

Also note that the HTML5 specification already has the same requirements on HTML5 implementations for longdesc as HTML4 does. Hence there is no reason for vendors to reduce the amount of support for longdesc.

Given the advantages listed above that aria-describedby has over longdesc we should encourage authors to choose aria-describedby over longdesc. The most gentle tool we have for doing so is to deprecate longdesc. Simply deprecating it will not break any existing pages, they will continue to work as they always have.

If both longdesc and aria-describedby are valid, this requires much more complicated tutorials and descriptions for how to make pages accessible. Basically we'll end up telling authors:

If you want to provide a description, use aria-describedby which contains the ids of the elements with the description. Unless the what you want to describe is an image or a frame. Then you should use longdesc. Which doesn't contain ids but rather a URI. But remember that the URI can be just a fragment identifier if you want to point to a description in the page, unless you have a <base href> in the page. Then you can still point within the same document, but you'll need to use more than a fragment identifier, possibly a full absolute URI.

This is a much more complicated message than simply:

If you want to provide a description, use the aria-describedby attribute which contains a list of IDs of the elements with that description.

One downside that has been mentioned with regards to deprecating longdesc is that it might make it harder for people working under contract which requires them to create pages that validate as valid HTML. However this will always be true for any feature which is removed so if we followed that argument we'd never be able to remove any features from HTML, no matter how poorly they turned out to work out. HTML5 is supposed to pave the way forward. We should create HTML5 for how we want things to develop, not simply describe the best recommendations for the tools available today. The tools and UAs should move forward to support the feature set defined in the specification. The specification shouldn't limit itself to the tool and UA support that exists today.

Additionally it hasn't been shown that people that are required to produce valid markup are required to produce valid HTML5 markup. Given the fact that HTML5 is far from a W3C Recommendation, it seems unlikely that people are already writing contracts that require them to follow that specification. By the time that HTML5 becomes a recommendation, aria-describedby support is likely to be better than it is today. Especially if HTML5 encourages that as the one way to provide descriptions.

Reasons for allowing aria attributes to point inside hidden elements

One use case that has been brought up is the ability to provide a description to AT users, while still not affecting the design for non-AT users. This is because page designers often have quite strict requirements on the visual appearance of the page and it would likely negatively impact the level of accessibility support if contents specifically for for example screen readers had to be provided within those requirements.

One simple way for page authors to provide such AT-specific content is to put it inside an element and add a hidden attribute to that element. As the specification is written today that is required to work and so authors are likely to do this even though the specification says it is invalid use of HTML. It is however unclear if HTML validators are expected to warn about such invalid markup. But even if they did, few people validate their markup and simply do what works. Hence it's likely that we'll see such markup used.

There doesn't seem to be any harm in such markup. It doesn't for example negatively impact the usability or searchability of the page. And since it both is intuitive for authors and provides value to them it would be a net win to allow this pattern.

As a side note, I think we should further explicitly allow other IDREFs in HTML documents, such as the pattern attribute in svg elements and the form attribute in input elements, to point to elements which are themselves hidden or are inside hidden elements. This for the same reasons as enumerated above. However since this change doesn't fall in the scope of ISSUE 30, I'm not suggesting such a change here.


I suggest the following changes to the specification

Changes to the section "The hidden attribute"

Change the following paragraph

Elements that are not hidden should not link to or refer to elements that are hidden.


Elements that are not hidden should not link to or refer to elements that are hidden. However, ARIA attributes are exempted from this rule and are allowed to point to contents inside hidden elements

or some other text to the same effect.

Changes to the WAI-ARIA section

After the first paragraph, add the following note (using the green text layout as used for notes elsewhere):

Note: Implementations are encouraged to follow the recommendation in ARIA specification and expose the full semantics of any HTML elements linked to by aria attributes. For example if an aria-describedby attribute points to a <a> element or a <table> element, then it is recommended that implementations expose the full semantics of those elements rather than for example just their textual contents. This applies even if those elements aren't rendered, for example due to CSS


Positive Effects

  • Makes the HTML5 specification have a simpler and more consistent message for how to deliver descriptions for elements. I.e. use aria-describedby everywhere.
  • Makes it possible to write simpler tutorials for how to make HTML5 contents accessible.
  • Allows tools to be simpler since they can use a single mechanism for providing descriptions for elements.
  • Allows browsers and other HTML 5 implementations to focus their continued efforts on making aria-describedby great, rather than dividing their time between longdesc and aria-describedby.
  • Encourages authors to put their description in the same document as the rest of the context about the image, thus making it less likely to get out of date.
  • Encourages authors to make the description available both to AT and non-AT users, making collaboration easier.
  • Ties in better with the rest of HTML. If you want your description to not be visible by default, put a hidden attribute on it, just like other contents that you don't want to be visible by default. If you want your description to be in a separate page, create a <a> link to it, just like other contents that you want to link to.
  • Makes the harmless and likely common usage pattern of putting AT specific content inside a hidden element valid.
  • Keeps existing documents that use longdesc working the way they always have since HTML5 has the same UA requirements for longdesc as HTML4 has.
  • Less duplication of functionality.

Negative Effects

  • People that are obligated under contract to provide documents that are valid HTML5 will not be able to use longdesc and thus will have a harder time targetting browser versions which doesn't support aria-describedby to the extent needed. It hasn't however been shown that such contracts are already getting written.

Conformance Classes Changes

No change.


If aria-describedby is rejected by implementations, we could be left with no good way of providing descriptions. However so far implementations have not given any indication that they are unwilling to implement aria-describedby. On the contrary aria has seen a vastly faster adoption in implementations than longdesc did.


References are linked inline.