Change Proposal for not including longdesc=""

Poll Closed 2010-06-30

Objections to longdesc documented in this poll:

http://www.w3.org/2002/09/wbs/40318/issue-30-objection-poll/

Feel free to add more to this wiki page.

Summary

The longdesc="" attribute does not improve accessibility in practice and should not be included in the language.

(This does not affect conformance criteria for implementations.)

See related: Issue 30.

Rationale

studies

Several studies have been performed. They have shown that:

• The longdesc="" attribute is extremely rarely used (on the order of 0.1% in one Google study). [1]
• When used, longdesc="" is extremely rarely used correctly (over 99% were incorrect in a study that only caught the most obvious errors [2]; the correct values were below the threshold of statistical significance on another study that examined each longdesc="" by hand [3]).
• Most users (more than 90%) don't want the interaction model that longdesc="" implies. [4]
• Users that try to use longdesc="" find it doesn't work ("Who uses this kind of thing? In my experience [...] it just didn't work. There was no description.") [5].

alternatives exist

Furthermore, there already exist a number of alternative mechanisms for providing information to users without using longdesc="", such as simply including the information inline, providing explicit links to long descriptions, and using ARIA attributes such as aria-describedby="".

accessibility expert statements

Some accessibility experts have indicated that the longdesc="" attribute has been problematic:

• IBM's Rich Schwerdtfeger: "longdesc was a disaster" [6] (no particular rationale given)
• Google's Mark Pilgrim: "We've been living with longdesc for 10 years now, and let me tell you, it's not working out" [7] (based on the data collected by Google cited above)

Even the XHTML2 working group described the longdesc="" attribute as a failure. [8]

Including the longdesc="" attribute in the language therefore seems like a poor design decision.

badly designed

The longdesc attribute is badly designed, and has been harmful to accessibility.

invisible metadata

It is one of the worst forms of invisible metadata or "dark data" which are known to rot and become inaccurate over time (see: meta keywords, RDF in comments, sidefiles, etc.).

poorly named

It is VERY poorly named - seems to imply a "long description" as whereas it is actually a URL.

causes misinformation

Because it is invisible metadata and poorly named, the longdesc attribute encourages and causes misinformation about the image. This has been well documented: http://wiki.whatwg.org/wiki/Longdesc_usage

harms accessibility

Because it has been framed/claimed as an "accessibility feature" - this damage is particularly bad.

causes lower quality AT experience

On the rare occasion that a user finds an alternative browser that reveals the longdesc attribute, they will get a noisier (lower fidelity/quality) web experience.

false comfort

The existence of the longdesc attribute caused a superficial sense of "false comfort/support" - because it existed and was alleged (falsely) to solve an accessibility problem, it can be used to reject alternative accessibility techniques or feature proposals.

Counter-arguments

• It is argued that the user quoted above later retracted his comments and agreed that longdesc="" descriptions are useful. A careful examination of the video shows that the user never retracts their initial statement (which concerned their actual experience with the attribute in the wild), and only agreed with the facilitator regarding the theoretical value of the attribute _when used correctly_. However, this value is hardly ever realised in practice, as described by the data above.

• It is argued that since some pages use longdesc="" correctly, it would be bad to make the attribute non-conforming.
  • First, it's not clear which pages this is actually referring to; none of the studies cited above actually found positively useful longdesc="" values, they only found an upper bound to the fraction of pages that might have useful values. The video cited previously shows some examples of arguably useful longdesc="" values, but the user in those videos in at least one case explained that while the descriptions might be useful in theory, they weren't especially useful to him specifically since they were describing the visual design of the diagrams and he was not able to interpret those descriptions easily. One site has since been suggested as an example of a site that uses longdesc="" usefully (namely the comics at cssquirrel.com), but it was then immediately pointed out that that recent pages on that site have longdesc="" point to 404 pages. (That site also already correctly uses ARIA for the same effect, and the case would be better handled by just putting the descriptions inline anyway.)
  • Second, this would set a very bad precedent. A large number of the features listed in the "obsolete" section of HTML5 are used by considerably more pages. Many were conforming in HTML4 Strict (e.g. presentational attributes on table elements). We have already experimented with the idea of slowly deprecating features to "sunset" them; HTML4 Transitional has shown that this simply does not work as a strategy.

• It is argued that since laws refer to this attribute, we cannot make it non-conforming. No specific laws are named, however, so this claim is hard to verify or argue against. Such vague claims should not be valid rationales for change proposals.

Details

No change to the spec.

Impact

Positive Effects

• Stops authors from spending time trying to use a feature that they don't understand and that users don't want.
• Encourages authors to include suitable information in an alternative form that is more likely to be accurate.
• Results in better overall accessibility on the long term.

Negative Effects

• May harm the reputation of people who designed longdesc="" in the first place.

Conformance Classes Changes

No change to spec.

This would not affect existing ATs and user agents, as they can continue to support longdesc="" if compatibility with some set of documents where it is used correctly is desired. In practice, removing support is likely to either not be noticed (some users don't know the feature exists) or actually improve matters (given how poorly the feature is used in practice on the Web).

ARIA provides a number of alternative mechanisms that are currently not poisoned by existing content and that fit better into the kind of interaction model desired by users (according to the survey cited above). For example, aria-describedby="" allows an image to be related to in-page descriptive content.

Risks

• If the data collected is not representative of actual Web content, then we could be removing a valuable accessibility aid.
  • The probability of this is very low given the volume of data collected.
  • The cost to fix this once discovered is minimal.

References

Links included inline.