ISSUE-30 counter-proposal (update)

This updates my earlier counter-proposal for ISSUE-30. I've filled in some 
sections that were previously blank, inserted some counter-arguments for 
comments that were raised, and attempted to address the points raised by 
Maciej's proposal.


== 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.)


== Rationale ==

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). [http://blog.whatwg.org/the-longdesc-lottery]

* When used, longdesc="" is extremely rarely used correctly (over 99%
  were incorrect in a study that only caught the most obvious errors
  [http://blog.whatwg.org/the-longdesc-lottery]; the correct values
  were below the threshold of statistical significance on another
  study that examined each longdesc="" by hand
  [http://wiki.whatwg.org/wiki/Longdesc_usage]).

* Most users (more than 90%) don't want the interaction model that
  longdesc="" implies.
  [http://webaim.org/projects/screenreadersurvey2/#images]

* 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.")
  [http://www.cfit.ie/html5_video/Longdesc_IDC.wmv].

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="".

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

* IBM's Rich Schwerdtfeger: "longdesc was a disaster"
  [http://lists.w3.org/Archives/Public/public-html/2009Sep/0596.html]
  (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"
  [http://blog.whatwg.org/the-longdesc-lottery] (based on the data
  collected by Google cited above)

Even the XHTML2 working group described the longdesc="" attribute as a
failure. [http://www.w3.org/2008/02/19-xhtml-minutes.html]

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


=== 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 23 February 2010 01:27:38 UTC