Re: Is longdesc a good solution?

Lachlan Hunt 2008-09-05 18.34:

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


Well, extra links can be confusing, as noted in my reply, or may 
be I should that @longdesc can clarify the relationship better.

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


I have always said that long descriptioons could be useful for all 
users. The solution to the claimed contradiction is to make it 
clear that the @longdesc link represents an alternative.

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

Do you you talk about authors doing the following?:

<img longdesc=sameURI ...><a href=sameURI ...>link</a>

Two possible answers to that author behaviour:

* Because one do not trust that UAs support @longdesc.
* Because the author did not know how to make the @longdesc 
attribute accessible for sighted users.

I think there exist accessibility advices (I have been told so 
myself) that due to the @longdesc status one should have a 
@longdesc and an extra link close to the <img>.

Are @cite URLs for <blockquote> and <q> duplicated with links too?

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


I did not use the "it-doesn't-fit-the-design" argument. I used the 
"it is fitting" argument. Namely, that it is fitting to place the 
link from one resource to another resource inside the "from" 
resource. And not outside it. (Consider @for/@id, @headers/@id, 
@cite/URI - and @longdisc/URI.)

When it comes to "Skip to content" links, the thing with that 
practise, is that it is quite well established. There is a "how 
to" for this. @longdesc is much lower on the radar for most 
designers. For instance, I have not found any "how to" when it 
comes to enabling @longdesc for all users.

Also, for Skip-to-content links, the content is always on the same 
page. Wheras when it comes to @longdesc, authors have received 
conflicting advices regarding whether to place the alternative 
resource on the same page or on another page. (Typically on 
another page, but this isn't optimal for authors, I think.)

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

I did explain why it is beneficial that the @longdesc link can be 
discerned from <a>regular links</a>: it allows the user to 
understand if it is necessary to follow that link or not. For 
normal links, the expection is - as the ALA-article explains - 
that it leads to something new (and not a repetion of the same 
thing in another format, as with the @longdesc.)

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


Thanks for asking.

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

Is it? A page is a resource. The graphic in an <img> is also a 
resource. A @longdesc points to an alternative representation of 
that resource. Thus, semantically, it points to the same resource 
- except in another format.

If you have consumed a graphic showing a diagram, and then saw a 
link with the words "description of the diagramme", and you 
followed that link, only to be served a description of what you 
have already consumed, then you have essentially experienced what 
that ALA article describes.

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


Thanks for asking. See explanation in the paragraph I wrote above.

> You have not presented any reason why a 
> link to a long desription should be presented any differently from an 
> ordinary link. 


That was bad. Not at single reason? Yes I have. See above.

> Besides, there are plenty of ways a designer could style 
> such links differently from the others if they want.

If they want.  Well, that is an answer to the way you want to 
solve this question then: Everytime invent the wheel. Much better 
to have formal way to do it. (The option to do it as you recommend 
never disappears anyway.)

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

I am not surprised.

So, where XHTML 2 has added the @href attribute on all elements, 
you do not want that solution. OK. But in addition you want to 
remove all other link and reference attributes - @cite, @longesc, 
@headers  - as well.

What for?

Perhaps you can explain how this will benefit accessibility?

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


Do you really agree to the third point? Because, actually, that is 
a reason for having both @cite and @longdesc.

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


If you think the general problem with @cite is how it should be 
presented, then let's work on it (with the intent of solving it.)

Reasons for optimism: IE8 is getting better support for @longdesc. 
Better support across browsers for advanced CSS selectors make it 
possible to signal that the element has a @longdesc or a @cite.

> Besides, the spec generally tries to avoid specifying user interface 
> designs.


Partly because many things are taken for granted, I suppose.

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

I forgot to say that on Anne's page, a tooltip shows the text 
"Visit source". For @longdesc, perhaps "Visit text description"?

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

* Nesting <a>-s is impossible: Links in <q> would be impossible.
* Simpler with a @cite in the quote element, for authors.
* Semanitc: The meaning of the link is clear.
* Henceforth (and I need not repeat) this can enable users to 
discern between different link types (in both AT and regular UAs).

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

I try to discuss how @longdesc can be made available to all users. 
   (If authors cannot test it easily one cannot expect correct use.)

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

Without @longdesc or @cite, then of course one are left with that.
-- 
leif halvard silli

Received on Friday, 5 September 2008 23:28:15 UTC