W3C home > Mailing lists > Public > public-html@w3.org > September 2008

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

From: Robert J Burns <rob@robburns.com>
Date: Mon, 8 Sep 2008 17:39:52 +0200
Cc: public-html@w3.org, 'W3C WAI-XTECH' <wai-xtech@w3.org>
Message-Id: <350D86D8-08B7-457C-8F89-759CFB3192D1@robburns.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>

Hi Lachlan,

On Sep 8, 2008, at 12:07 AM, Lachlan Hunt wrote:

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

The problem is that it is incorrect to think of longdesc as a linking  
mechanism. It is more of a cross between a linking and an embedding  
mechanism. What the user often wants is access to the data referenced  
by longdesc without changing the current context (through a floating  
palette, sidebar, inspector, etc).

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

There is no reason why any other mechanism cannot be available to  
everyone. In fact many of us have been arguing that all of the  
features of HTML should be available to everyone. You have  
consistently insisted that things such as longdesc not be available to  
everyone.

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

So its not an advantage "over any of the other solutions"

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

Neither do longdesc and other solutions.

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

They work as links, but they do not work for embedding. No one wants  
to follow a link every time the author has an image associated with a  
document. We want to see the image embedded. Would you also argue we  
should replace the src attribute with a linking mechanism?

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

However, it removes the functionality many authors like to provide:  
that of linking the image to whatever they want (rather using their  
image links for filling in gaps left by the HTML5 WG).

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

The longdesc attribute is not another linking mechanism.

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

You don't browse the web much do you? Image linking is common on the  
web. Sometimes authors link to other pages using images as icons.  
Sometimes authors link to the resource itself with the embedded image.  
I cannot believe you haven't encountered these sorts of practices.

These arguments you're making keep getting more and more ridiculous.  
Are you Opera's 'emissary for screwing over the disabled' or  
something? Why are you trying to remove these essential features?

Take care,
Rob
Received on Monday, 8 September 2008 15:40:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:58 UTC