Re: ISSUE-30 counter-proposal

Ian Hickson wrote:
> Here's a counter-proposal for ISSUE-30:
>
> == Summary ==
>
> The longdesc="" attribute does not improve accessibility in practice and 
> should not be included in the language.
>
> == 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 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].
>   

I'll let the accessibility folks respond to the accessibility components 
of your proposal, but we've had discussions in the past about your 
"studies", and the flaws associated with them.

First of all, you've not provided access to the same data, so your 
results cannot be confirmed or denied.

Secondly, you have a bias in the results, and bias has been shown to 
compromise the integrity of studies. That's why researchers use blind 
studies, in order to ensure their biases and assumptions do not impact 
on the results.

Third, there is no way to determine the cause of results found on the 
web. Were incorrect uses because longdesc is inherently too difficult 
for users? Or because it was inadequately documented? What is the age of 
the results, and is there a trend to a more positive useful effect, as 
understanding grows about longdesc?

There is no way to form an irrefutable conclusion from nothing more than 
scraped data found on the web -- there are no controls in place to 
separate out the various cause agents, and focus specifically on one or 
another. The most you can do is make an anecdotal observation, and 
again,  your own biases in regard to longdesc undermine the 
effectiveness of the observation.

You don't have to take my word for any of this: I would suggest you run 
my comments by your Google "experts", and I think you'll find that they 
agree with me.

Therefore, your studies cannot, by themselves, be used to form a 
legitimate decision about longdesc, or any other aspect of the HTML5 
specification. All that remains is your other arguments, which I'll 
leave to others to debate, or not.


> 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="".
>
> Including the longdesc="" attribute in the language therefore seems like a 
> poor design decision.
>
> == 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 ===
>
> * ?
>
> === 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 ===
>
> * ?
>
> == References ==
>
> Links included inline.
>
>   


Shelley

Received on Sunday, 14 February 2010 15:37:59 UTC