Re: FW: [NVDA] #809: Support for longdesc in web browsers

On Fri, 09 Nov 2012 21:51:35 +0100, Silvia Pfeiffer
> <chaals@yandex-team.ru> wrote:
>> On Thu, 08 Nov 2012 21:39:10 +0100, Silvia Pfeiffer

>>> It is good to see more support for long description type features in  
>>> screenreaders.
>>
>> Yes. But I agree with the NVDA guys - it is a shame that they have to  
>> do this because browsers aren't picking up the functionality themselves.
>>
>>> That actually supports the argument made in [1] that we need a  
>>> screen-reader only long description attribute

I don't think so. The following are some of the reasons.

To me it suggests that the screenreader guys are ahead of the browser  
people in their thinking. After all, many arguments against longdesc boil  
down to "but it should be for everyone, not just the blind" (something  
with which I agree).

In "complete" browser-based implementations it does work for everyone.  
This appears to be what the NVDA guys hoped would happen with the browsers  
most relevant to them.

Longdesc works with content that is visible on the page, as well as  
content that is at a different link. There are important use cases for  
both of these methods. Using in-page content satisfies people who want  
everything in front of them, although it often leads to a pretty poor user  
experience. Especially for the people expected to get the most benefit  
 from longdesc. Likewise, the ability to have images in multiple places  
refer to the same description allows for optimisations like caching. It  
provides a basis for detecting spam vs real content. It often allows for  
more efficient maintenance of high-cost information.

Experience shows that designers will simply leave out something that  
doesn't fit their layout, and this leads some to conclude that we should  
therefore enable special content for screen-readers. Although I note that  
few people who make screen readers seem to think that. I think that we  
should be able to build mechanisms which support the screen reader use  
case, but also work for a more general audience - more like the actual  
audience who are using the web.

>>> (such as the proposed @aria-describedat) and should mark @longdesc
>>> deprecated for HTML5 and obsolete when @aria-describedat has arrived.

I'll happily obsolete longdesc with something better. I said that 5 years  
ago.

>> One of the basic tenets behind my longdesc extensions spec is that this  
>> is a very minimal thing. I honestly hope that it gets overtaken by  
>> events.
>>
>> On the other hand, I have waited for that a long time. 4 1/2 years ago  
>> when I raised issue 30 I hoped something better would have already come  
>> along. If the best we can get is longdesc, it's better than nothing, so  
>> I'll take it over a promise of some wonderful future that might happen.
>>
>> (Actually, no. When I am done with that, I'll be busy trying to build  
>> that wonderful future too. But the pessimist in me fears that the  
>> longdesc spec will prove to have been useful in its own right).
>>
> I'd like to encourage you to do both! :-)

Sadly, I am confident that I could do both. I'd love to be proven wrong.

Cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
         chaals@yandex-team.ru         Find more at http://yandex.com

Received on Saturday, 10 November 2012 11:40:04 UTC