Re: Is longdesc a good solution?

Leif Halvard Silli wrote:
> Lachlan Hunt 2008-09-05 01.30:
>> David Poehlman wrote:
>>> Why do we have longdesc in the first place?  It was certainly not 
>>> born in a vacume.
>>
>> 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.
> 
> What, in your opinion, is the best solution?

On several occasions I have noted my preference for using ordinary links 
in the surrounding content.  I shouldn't have to repeat myself.

> Here are some reasons why we have @longdesc:
> 
> * It lets authors offer a mark-up alternative for the graphic of an 
> <img> without stealing attention from those who do not need it.

You conceded below that long descriptions can be useful for all users, 
so that seems contradictory.  Also, based on observational evidence of 
how people use longdesc in practice, it's quite common for authors to 
include a redundant link nearby with little to no effort taken by those 
authors to conceal it visually.

Compare with, for example, skip links that lots of authors do use.  They 
are intended for people using assistive technology and many authors 
simply used stylesheets to hide them visually so they didn't interfere 
with the page design. Since the same is demonstratively not the case 
with long description links in the content, and the fact that the same 
technique could be used here if desired, the it-doesn't-fit-the-design 
argument (and all variations of it) is bogus.

> * Related to the last point: The way it is specified in HTML 4, it lets 
> users discern between regular links and fallback links.

Why is that beneficial, and what makes a plain text link like _read 
description_ or similar any less informative of its purpose?

> A List Apart has an article called "Where am I" [1] which says:
> 
>     <quote> When the user clicks, their expectation is that click will 
> make something happen or take them to a new place. If that does not 
> happen, that’s a bad experience and the user is filled with doubt and 
> uncertainty. Your site’s trustworthiness just went down a notch. </quote>
> 
> Likewise, I conclude that it is confusing to if a link to an alternative 
> representation is presented in a way that make users think "Oh, I here 
> is a resource I have not studied yet."

I have no idea what you are trying to say here.  The text you quote from 
the ALA article is talking about links that point to the same page, and 
thus clicking them doesn't go anywhere.  This is clearly different from 
a link to a long description that does go somewhere.

> And therein also lays the reason why @longdesc links should - as HTML 4 
> says - be presented differently from regular links.

Sorry, that doesn't follow.  You have not presented any reason why a 
link to a long desription should be presented any differently from an 
ordinary link. Besides, there are plenty of ways a designer could style 
such links differently from the others if they want.

>> Besides, there are lots of things in HTML4 that have been poorly 
>> designed and implemented, and I could ask the same question about lots 
>> of things in it.  For example, why is there a nohref attribute on area 
>> elements?  Why is there an accept attribute on form elements?  Why do 
>> we have the scheme attribute on meta elements?  What is the version 
>> attribute for on the html element?  While each of those may have had 
>> hypothetical uses in mind when they were added, none of those have any 
>> practical value at all and none of them have been included in HTML5 as 
>> a result.
> 
> Asking good questions and demanding answer is not difficult. Why don't 
> we remove support for the @cite attribute?

That's a good question.  I and others have suggested dropping the cite 
attribute before too.

> Here are some similarities between @cite and @longdesc:
> 
> * Support likely on same level for both, even in AT UAs.
> * Most users will not care to follow the @cite or @longdesc URI.
> * It would be confusing if the user were lead to think "Oh, I here is a 
> resource I have not studied yet."

Indeed.

> What we need, however, is
> * good advice about how to use @longdesc and @cite (perhaps HTML 5 
> adequately describes how to use @cite);
> * better specification (or examples) of how UAs should present the @cite 
> and @longdesc links to users.

Since UAs haven't been able to come up with a good UI for presenting 
cite to the user, what makes you think that the spec could do so? 
Besides, the spec generally tries to avoid specifying user interface 
designs.

> Anne in his weblog shows a good example of how one can present @cite 
> links to users in a way that discern them from regular links. [2] (Note 
> the right arrow on the @cite links.)

Sure, using JavaScript to obtain the cite URI and insert a link into the 
DOM that users can access is one alternative.  But why is that any 
better than just using an ordinary link in the first place?

> It can be useful for all users to access long descriptions.

Agreed.  So why do you want to hide such links away from everyone by 
using a solution like longdesc?

> But it is then crucial that they understand that this is what they are. 
> And this is also what we need for <video>, <audio> and <object> as well 
> - a way to select the alternative representations, knowing that this is
> what they are. Users should not be confused to think that they loose 
> something by not clicking the button/link to an alternative representation.

Plain text links using natural language (not "[D]"-links) seem 
reasonably sufficient in being able to adequately convey the purpose of 
a link.

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

Received on Friday, 5 September 2008 16:34:56 UTC