Re: Is longdesc a good solution?

John Foliot wrote:
> 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,

This is not a flaw in the study.  It's is precisely one of the problems 
I designed the study to reveal.  But if you're just going to concede 
that this is indeed the case, then we can conclude that longdesc is not 
a well designed solution, and that it doesn't meet the needs of users, 
and move on.  Although having the quantifiable data from the proposed 
study to verify this would still be useful.

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

Of course, it would be unfair to include a user in the group expected to 
use the longdesc attribute if their tool was incapable of it. 
Performing the test with users of varying skill levels, to ensure that 
they are as representative of the wider community as possible, who use 
versions of assistive technology known to support the longdesc attribute 
eliminates this variable.

> although the  visually impaired are not the only potential beneficiaries of
> @longdesc.

Assuiming you meant "potential beneficiaries of *long descriptions*", 
rather than just the attribute, then agreed. And so hiding the link to 
that information in the longdesc attribute where it is rarely, if ever, 
revealed to anyone but AT users, and even then only when the user 
explicitly queries for it, is clearly not a good solution.

> This is also presumably the main reason why mainstream developers under-use
> or simply do not use the element [hypothesis].

I assume you're referring to the longdesc attribute, rather than an 
element. But there are many possible reasons why authors don't use it, 
none of which were intended to be revealed by the proposed study.

> Second, your proposed study does not take into account the influence the
> "Photoshop" crowd have over screen real estate and visual design.

The proposed study was explicitly scoped to focus getting quantifiable 
data about the usability of the longdesc attribute.  So that is not a 
flaw in the study, it is by-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).

I also conceded that using "[D]" as link text was not an ideal link text 
to use, but this not preclude other alternatives, which can be more 
easily incorporated into the design of the page.  But again, the page 
design aspects are not the intended focus of the proposed study.

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

Regardless of whether or not that is the case and regardless any other 
possible solutions, the question still remains as to whether the 
longdesc attribute itself is a good solution.

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

No, why should we include an ineffective solution in the spec at all?

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

I realise it doesn't those stats don't prove anything beyond that. 
That's why I only mentioned them as observational data.

>  It certainly does not explain *WHY* this is the current case, nor does it
> "prove" that it does not have an important use.

I never claimed it did, and answering that question was not part of the 
proposed study either.

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

Agreed.

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

Those are really good and very useful examples, thanks.

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

Received on Friday, 5 September 2008 10:32:35 UTC