Re: @longdesc - starting over (was RE: Acessibility of <audio> and <video>)

An error of assumption here is that the final decision rests with Laclan 
Hunt.

----- Original Message ----- 
From: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>
To: "John Foliot" <foliot@wats.ca>
Cc: "'David Poehlman'" <david.poehlman@handsontechnologeyes.com>; 
<public-html@w3.org>; "'W3C WAI-XTECH'" <wai-xtech@w3.org>
Sent: Saturday, September 06, 2008 2:34 PM
Subject: Re: @longdesc - starting over (was RE: Acessibility of <audio> and 
<video>)


John Foliot wrote:
> Lachlan Hunt wrote:
>> However, I wouldn't object to the study being performed
>> by users with screen readers that are known to support longdesc, as
>> long as each individual used their own normal settings and
>> preferences, to avoid biasing the test in anyway.
>
> But again, you introduce a chicken and egg scenario.  Those AT tools that
> *do* support @longdesc are generally configured so that announcing 
> @longdesc
> is a toggle ON setting; it is toggled off by default.  That this is wrong 
> or
> ineffective is not under discussion, it simply is the fact.  Because most
> content authors today do not use @longdesc, most users do not toggle this
> feature on.  So having users with their "normal" settings test to see if
> they query for longdesc is a predetermined outcome - you don't need to 
> test
> this, the answer is normally they do not, *unless* they were first advised
> that a site supplied such (a rare occurrence).  So your test is once-again
> flawed if we cannot first advise these users that it is a test of 
> @longdesc,
> which shines a light on that fact and thus biases the results.  We can't 
> win
> this one...

All you are saying, despite the fact that you refuse to admit it, is
that longdesc is a lost cause and will be until the AT vendors can
develop a suitable UI for it that solves those problems.  But then you
still push for it being included in HTML5 in the hope that one day all
these problems with it will somehow magically resolve themselves.

Well, here are the facts:

* Including longdesc in HTML5 won't make authors use it any more than
   they do today, let alone getting them to use it properly.
* Authors that do include longdesc in their markup are wasting their
   time since the users won't see it anyway.

Yes, this is a chicken and egg problem.  But it's not a problem the spec
can solve.  It's a problem the accessibility community needs to solve,
and then come back with the evidence if and when it is solved.  Until
that time, longdesc hasn't got a chance of being included in HTML5,
whether you like it or not.

Now, I have been informed that that beta of JAWS 10 turns on the
announcement of longdesc by default.  That could potentially be a step
in the right direction towards solving this problem.  But that alone
isn't sufficient evidence.  If you want to perform the study with the
beta, go ahead.  This will do two things:

1. If the results are positive, it will provide evidence for the AT
vendors showing them a workable solution for longdesc, thus resulting in
a more widespread solution.

2. It will give evidence that can be communicated to the web development
community showing that using longdesc is finally not a complete waste of
their time, potentially encouraging more authors to use it properly.

The study may also have to be modified to test the effect of false
positives, since as Hixie's stats showed, the vast majority of authors
who do use the longdesc attribute, use it wrongly.  Whatever the ATs
implement will have to deal with that problem somehow.

If that works, then the chicken and egg problem could finally be solved.
  But it's still a big IF, and we would need good, solid evidence to
prove that has happened when it happens.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Saturday, 6 September 2008 19:31:54 UTC