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

Lachlan Hunt 2008-09-08 00.07:

> John Foliot wrote:
>> Henri Sivonen wrote:
>>> "something else" in the last sentence could be:
>>>   * Merely juxtaposed text that restates whatever it is the image
>>> illustrates.
>>>   * Juxtaposed text associated with aria-describedby.
>>>   * Link to a different page phrased as a "more information" link for
>>> all audiences as opposed to a [D]-link.
>>>   * <object> element with HTML fallback content.
>>
>> Henri, none of these "solutions" provide what @longdesc provides now: 
>> yes, they are alternative ways of providing the required information,  
>> but none of them deliver the same functionality

John, why so categorical with regard to <object>?

> Another solution is to make the image itself a link:

> <a href="description" title="More information"><img 
> src="sales-chart.png" alt="Sales increased 20% over the period"></a>

This makes the *<img>* a link.

> This has several advantages over any of the other solutions:
> 
> 1. It is available to everyone.


It is an actual fact that I have spent much time in my life 
comparing resources, trying to find out whether that other copy is 
any different from the first one. As told in an ALA article I 
mentioned [1], users expect regular links to represent something 
new and may get bored if they click and get something which, after 
some investigation, only turns out to be the same sales chart.

> 2. This link is unambiguously associated with the image, just like
>    longdesc.


* @longdesc is unambiguously associated with the *graphic* of the 
<img>. There is no guarantee that an <a> wrapper leads to a long 
fallback text for the graphic.

> 3. It doesn't affect the design of the site like a separate
>    _more information_ link would.


Well, if you want to signal that it is only a fallback for the 
<img> graphic - or even a link at all, you got to do something.

> 4. We already have proof that regular links work and are compatible with
>    all browsers and assistive technologies, unlike longdesc.


On the contrary, as you know, longdesc URIs can be activated via 
JavaScript in all UAs supporting DOM 1.0. (Of course, they should 
support it without JS.) Classic AT software support it as well.

> 5. It also does not require new versions of ATs to be deployed before
>    it potentially becomes useful and practical for anyone.


New versions must be deployed before we would get support for the 
required (!) rel=longdesc as well.

 
> Finally, if any other indication may be needed to indicate that it's a 
> link to a long description, then adding rel="longdesc" is a possibility. 
> But I didn't include it in the example, because the need for it is not 
> yet clear.

Eventually, a rel=longdesc should be required, as current UAs open 
@longdesc URIs differently from regualar links (in a new window) - 
see my prev. message.[2]  (Maybe rel=fallback could avoid possible 
confusion with aria-describedby as well as be understood better.)

But what would be simplest and least error prone ? Adding a single 
@longdesc or adding an extra element with a required extra 
rel=longdesc? What about the problem of people copy-pasting code?

> It has been suggested to me that there may be cases where an image needs 
> to have a description and provide a link elsewhere, which would make 
> this solution unusable. But no-one has yet been able to provide a valid 
> use case illustrating that.


The link might only lead to a <img> with a bigger version of the 
same graphic. That page might also contain a better description of 
the image. But I would not see that a long fallback for the image.

[1] http://www.alistapart.com/articles/whereami
[2] http://lists.w3.org/Archives/Public/public-html/2008Sep/0247.html
-- 
leif halvard silli

Received on Monday, 8 September 2008 01:58:57 UTC