Longdesc Conforming With Warning

Summary

Make the longdesc attribute on img elements conforming, but with a required validator warning. (Open issue: should longdesc be considered "obsolete but conforming" or just conforming to a warning? I'm willing to go with whatever the WG most prefers, the best option may be to ultimately make it consistent with the summary attribute.)

Rationale

Longdesc shows many signs of being problematic in practice

There is considerable evidence that longdesc is problematic as actually used. Even though the intent of the feature is to improve accessibility, it seems likely it is often creating a bad accessibility experience.

• Studies appear to show that longdesc is very rarely used; it seems to be present on less than 1% of images. See Ian Hickson's longdesc counter-proposal for more details. Some of these studies were not based on public data sets, but studies with publicly available data sets produced similar results. While these studies may be flawed, I think they should be tentatively accorded some evidential value until a specific flaw is identified.

• Studies appear to show that when longdesc is present, the value is bad at least 99% of the time. See Ian Hickson's longdesc counter-proposal for more details. See above for comments on validity. Surveys of random sites using longdesc seem to show a very low rate of correct usage even after pruning out obviously bad values with automated checks. This seems to indicate that the current pool of longdesc content is highly poisoned with bad data.

• At least one blind user, when interviewed during use, [Found longdesc to be unhelpful and possibly annoying http://www.cfit.ie/html5_video/Longdesc_IDC.wmv].

• Blind users seem to indicate a preference for in-page text or content presented via a normal link, and a strong preference against the current longdesc UI.

• While in principle the user experience for locating and identifying longdesc descriptions could be changed, there is one downside that cannot easily be fixed: the fact that the long description requires a separate page load to retrieve. This means that it will be inherently slower to access than in-page content.

• Noted Web accessibility experts including Richard Schwerdtfeger and Mark Pilgrim have spoken out against longdesc. While this is not necessarily a consensus view, it shows that even many domain experts think there are problems.

There is a superior alternative to longdesc: aria-describedby

HTML5 includes aria-describedby, a mechanism to programmatically associate an in-page long description (visible or invisible) with any element. aria-describedby has a number of advantages:

• Because it links to in-page content, aria-describedby does not require the performance hit or disruption of the user experience that would be caused by a full page load.

• aria-describedby as practiced today is not poisoned by a mass of bogus content.

• aria-describedby makes it easy to associate in-page visible text or a visible link following the image. Visible content, when it can be used and is appropriate to the design, has a better chance of being accurate and up-to-date than metadata that is not visible in the default presentation. aria-describedby pushes authors in this direction, though it does allow them to point to invisible content if they choose.

• aria-describedby makes it easy to implement any of the most preferred interaction modes reported by blind users for text descriptions.

Nonetheless, a few sites may be using longdesc properly

• A handful of sites (organizations for the disabled, government entities, nonprofits, etc) go far beyond the norm in trying to provide a good accessibility experience. They may be relying on longdesc to improve the experience, and it would be disruptive to immediately make such content nonconforming.

• Some laws, regulations and organizational policies may refer to longdesc by name.

Conclusion: allow it, but with a warning

Most of the time, when an author chooses to use longdesc, it would be valuable to encourage her to consider aria-describedby instead. It would be a positive benefit if the validator could do that encouragement. However, it would be unfortunate if in the process we harmed the few who were validly relying on longdesc and made good use of it.

We can strike a balance by making longdesc conforming, but requiring it to trigger a validator warning. That way, sites that use it won't have to be changed right away. But authors using it will be warned of the common mistakes in using longdesc, and encouraged to use the superior aria-describeby mechanism.

Details

• Change longdesc from nonconforming to conforming.

• Require a validator warning for longdesc, which is encouraged to mention some of the superior alternatives.

• List more alternatives to longdesc besides just a visible link - for example, immediately following text or a link associated using aria-describedby, or hidden text associated using aria-describeby).

• Open question: should longdesc be considered "obsolete but conforming", or conforming with a separately defined validator warning? My suggestion is that we defer the final call on this until we have settled the summary issue, and in the meantime go with the first of the options below:

• • If it's "obsolete but conforming", its description should move to the "Obsolete but conforming features" section.
  • If it's just conforming with a warning, its description should move to the definition of the img element.

Impact

Positive Effects

• Compared to the current spec, the few sites that use longdesc properly will not immediately be rendered nonconforming.
• Compared to the proposal to make longdesc fully conforming, we will have the opportunity to warn authors who validate about the problems of longdesc, and advise them to use the superior aria-describeby.

Negative Effects

• A warning might be slightly less effective than an outright conformance error at discouraging authors from using a problematic mechanism.
• A warning might be seen as discouraging by maintainers of sites that used it correctly.

Conformance Classes Changes

Document conformance requirements will change. Conformance requirements for validators will change.