RE: Is longdesc a good solution? (was: Acessibility of <audio> and <video>)

James Craig wrote:
> 
> I'd disagree with you on the usefulness of longdesc as a standard
> description mechanism. There is a better, in-document alternative now:
> ARIA's describedby property, which is also implemented in more
> browsers than longdesc.

James, 
There is no doubt that ARIA describedby is useful for in-document
description, but sometimes we cannot provide in-document description due to
other competing demands, such as graphic design considerations. To ignore
this critical aspect does accessible (universal) design a dis-service, as it
perpetuates the notion that to "accessible" your page somehow needs to be
ugly: every important image needs to be fully described in page, or needs an
in-the-clear link to this description. Yech!  You think selling @longdesc is
tough? Try selling *that*.

No, what we have is a unique attribute that performs a useful function.
Nobody is asking that this attribute be made mandatory, or expect that all
authors will use it - I suspect the majority will not fully use <canvas>
either, but we move forward with that because there is real value there.
What we are asking/saying is that there is a value to @longdesc as well that
to date has not been fully replaced with a better alternative.  Further,
while usage remains quite minimal today, evidence clearly points to the fact
that this may very well be due to a historic lack of browser support,
and/but this support is improving significantly.  A Google search about
LONGDESC turns up volumes of How-to pages at institutions such as higher-ed
(Universities) and governmental entities, where the mandate to ensure
complete accessibility exists, that extols authors to use @longdesc.  Why is
it so strongly objected to by some to maintain this optional attribute in
the spec so that the accessibility community can build upon emergent support
(in the better-late-than-never category) and continue to educate on proper
usage?

Basically what we have is an attribute that was originally conceived as an
accommodation piece for the visually impaired.  It was poorly explained,
even more poorly supported, and now, a group of engineers who probably have
never attempted to regularly implement usage of this function want to remove
it from the technical spec simply because they have stats that indicate that
to date it has been poorly supported and thus under-used/abused. No
argument, but this does not negate the unique functionality that @longdesc
can provide, nor it's value or usefulness. Further, they have not proposed a
better alternative that delivers an equivalency.

> 
> You could achieve the same thing by using the 'rel' attribute on a
> link, and it would have the added benefit of providing that link to
> all users, not just the power users of a few AT products.

Sure, *if* a link were present.  But what if there isn't a link present?  

For maximum effectiveness, content creators need multiple tools in their
tool box to address issues as they arise. @rel, aria:describedby,
@longdesc... Each has it's value and function, and all should be in the
authors palette of possible solutions.  If all you have is a hammer, then
everything needs to be solved with a nail, whether or not the nail is the
best solution.  We want hammers, wrenches, screwdrivers, and more, and most
sane developers would have to agree with this notion.  It is the very same
notion BTW that fostered the emergence of both <audio> and <video> (the
original launch pad for this thread), as opposed to simply <media> or even
more abstractly <object>.

Time and time again, we keep running into this 80/20 "rule", which by it's
very nature is discriminatory to the "edge" 20%, which most often is the
constituency that I and others advocate for.  NOBODY however has made a
clear case on why maintaining @longdesc is harmful to HTML 5, outside of the
fear of "bloat", which is rather fey - if you want to avoid bloat why then
<audio> *and* <video> and not simply <media>? (and if you argue that they
are sufficiently different, then so too can we argue that @longdesc and
aria:describedby are sufficiently different)  

Lachlan's proposed study does not ask the right questions - he wanted to see
if currently users take advantage of @longdesc when present, but doesn't
stop to ask if the "feature/function" that @longdesc is supposed to provide
(but doesn't due to poor user-agent support today) is required, demanded or
not needed by end users.  At least one contributor to this thread, a blind
user himself, says yes.  So far I've not heard from any blind users saying
no...

> Overloading
> longdesc is a creative workaround to the inaccessibility of the Flash
> Player on Mac, but a better long-term solution is to hound Adobe to
> make the player accessible.

Agreed, but this has nothing to do with maintaining @longdesc in HTML5. 

Cheers!

JF

> 
> James

Received on Saturday, 6 September 2008 22:45:09 UTC