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

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

Perhaps instead we need a survey of sorts that asks these users what they
need, how they would look for it, and then ask them if they know about
@longdesc.  This way at least we have some data on actual user needs.  The
study as proposed simply will prove that end users will rarely if ever seek
to use a feature that rarely if ever is supplied by authors - it does not
determine whether or not the information would be sought out if it were
consistently provided across the board, nor does it prove whether @longdesc
is or is not the best vehicle for the delivery of this information.

Lachlan further wrote:
> Yes, I'm aware of that. But my point was that until we have objective
> evidence to verify his claims, all we have is speculation and
> hypotheses; and speculation about usability problems is not a reason
> to avoid doing a usability study that would verify that.

And herein lies the problem.  The study as proposed simply serves to prove
that there is a problem. We already know this, and it is conceded. @longdesc
today is problematic: nobody really uses it - content authors especially,
but end users as well as they have been conditioned to not expect it.
User-agent support is only now starting to emerge, and that support is
inconsistent, and poorly documented.  What else do we need to "prove"?

However, actual users have stated (here on this list, in this thread) that
they want a feature that delivers this functionality.  If you want more
empirical data that confirms this assertion, this can be had (see survey
above), but those of us who deal with this stuff daily are sure that the
need exists.  So, if we can move beyond that, or at least work with that
hypothesis the question once again becomes, how do we do this?  What we have
not heard from the WG is a *better* way forward, and that is the real
problem here.

HTML 4 suggested and implemented @longdesc, which apparently many within the
HTML5 WG are unconvinced is appropriate or effective.  History has taught us
that uptake of this useful feature has been extremely poor, but the reason
for that is unclear: was it because no user-agent supported it for so long,
or was it that user-agents did not support it because content authors did
not use it?  We do not have an answer to that question, although I suspect
it was the latter rather than the former - to paraphrase Ian Hickson, there
is no point adding features if the browser developers will not support it -
and @longdesc is as much proof of that truism as any.  Only now, almost 10
years later, are we starting to see support for @longdesc emerge, and now
you want to do away with the attribute.  This is a real frustration!

Lachlan (and others), this is again like the @alt debate; you seek to remove
something but do not propose an alternative.  Once Ian's @alt proposal
framed the "optional" piece within the context of "but to be optional and
conformant one of these other conditions must exist" then the pain went away
- not completely but sufficiently.  The current @alt solution is not
perfect, but it delivers on the larger requirement and so is palpable.  We
need the same for @longdesc - it is not a slavish demand for the attribute
but rather the persistent need for this functionality.  Instead of arguing
about it, help us deliver it.

JF

Received on Saturday, 6 September 2008 16:10:15 UTC