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

Lachlan Hunt wrote:
> 
> Hypothesis don't have to be based on just facts.  They can be and
> often are based on observations.  I formulated my hypothesis based on
> observations relating to to the use of longdesc in practice, such as
> Hixie's statistics showing very limited use in practice, looking at
> pages that use it as intended and seeing that they often duplicate
> with an ordinary link, and Joshue's videos showing that the user
> didn't even make use of the longdesc attribtue at all.
> 

<opinion cite="Lachlan">

> Longdesc seems to have been added to HTML4 as a potential solution for
> providing long descriptions of images for the cases where alt is
> insufficient.  Yet that doesn't mean its necessarily the best
> solution, and based on those observations above, it really doesn't
> appear to be a good solution at all.

</opinion>

Lachlan, your hypothesis and proposed study surrounding @longdesc is flawed
in a few ways.  

First off, many users of AT today do not query for longdesc as it is rarely
if ever provided - a chicken and egg problem accelerated by the fact that
most (all?) browsers today still do not natively support this element, and
support within the major AT tools in the marketplace has only recently
emerged. Given the slower uptake of this (acknowledged) expensive software
in a community with very little discretionary income, said support is still
not "universally" available to the primary target community - although the
visually impaired are not the only potential beneficiaries of @longdesc.
This is also presumably the main reason why mainstream developers under-use
or simply do not use the element [hypothesis]. I must also concede that at
this writing, the web accessibility community has failed in both explaining
proper usage of the element, as well as the value that is supplies to the
mainstream development community.  This however is less an evaluation of the
usefulness of @longdesc and more a commentary surrounding the failure of the
browser developers to take advantage and provide support of this element, as
well as a failure in education.

Second, your proposed study does not take into account the influence the
"Photoshop" crowd have over screen real estate and visual design.  There is
a real reason why the "d" link never saw any real uptake, and it's not
because it wasn't useful... No, designers were aghast at having these random
blue "d"s beside complex images... It destroyed any kind of visual
cohesiveness and was, frankly, ugly. (Contrary to misconception, the
accessibility community both appreciates good and engaging visual design and
values the contributions that effective visual design has in the area of
usability and cognition).

There is no doubt that "in the clear" links to robust explanations of
complex images benefit all users, but there are times when, due to other
competing demands, this type of link cannot be provided.  In these instances
an alternative mechanism of linking this information to visual assets is
still required.  

Until such time as a better, unobtrusive alternative to @longdesc can be
presented I suggest that removing it from the spec is premature and not
fully defended.  Having Ian Hickson spout Google stats that show @longdesc's
underuse or misuse simply proves that the attribute to date has been
underused and misused - nothing more, nothing less. It certainly does not
explain *WHY* this is the current case, nor does it "prove" that it does not
have an important use.

As far as implementing @longdesc as a vehicle for improving the
accessibility of <audio> and <video>, I personally do not think that it is
the right choice, and instead would probably like to see something closer to
what SMIL tried to do, but did not succeed at due to inter-operability
issues with media players.  

Still and all, having a linked association to transcripts or time-stamped
captions, as well as descriptive texts and/or audio streams that could be
toggled on or off by the end user would likely provide a better user
experience overall.  


TEST CASES / EXAMPLES:
Some good examples "in the wild" of this type of functionality can be found
at:
	http://ecorner.stanford.edu/authorMaterialInfo.html?mid=1716
	http://ecorner.stanford.edu/authorMaterialInfo.html?mid=1171
(both videos feature multi-language text options (subtitles) that can be
toggled on or off  - a perfect case where this type of functionality
enhances all user's experience and extends the usefulness of the media
asset.  As well, the time-stamped transcripts, being external files, can
also be further processed via XSLT <sic> or similar [the "Transcript" link]
and provided as on-screen html text - a real SEO consideration as well - a
virtual "cut-curb" of the highest value.  This has to be seen as a win-win
IMHO)
	http://www.jeroenwijering.com/?item=Making_video_accessible 
(the Coronation street example features both closed captioning *and*
descriptive audio - almost completely unheard of on the web today, but not
due to a lack of need, but rather of complexity in implementation to date)

While these examples have some problems (my friends at Apple have issues
with a flash based player and Voiceover, and of course these do not work in
the iPhone), but the *idea* I believe is worth exploring as a starting point
for the type of functionality that HTML 5 should afford natively.

JF

Received on Friday, 5 September 2008 04:45:30 UTC