W3C home > Mailing lists > Public > public-html@w3.org > September 2008

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

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Sat, 06 Sep 2008 20:34:48 +0200
Message-ID: <48C2CD48.2020106@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>

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
Received on Saturday, 6 September 2008 18:36:01 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:38 UTC