W3C home > Mailing lists > Public > www-archive@w3.org > September 2012

Re: My case for the obsoletion of longdesc (Was: 48-Hour Consensus Call: InstateLongdesc CP Update)

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 16 Sep 2012 10:12:33 -0700
Cc: "www-archive@w3.org" <www-archive@w3.org>
Message-id: <74F8BF71-D7DB-46DE-84C9-AB47F039B580@apple.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>

On Sep 16, 2012, at 9:40 AM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote:

> Maciej Stachowiak, Sun, 16 Sep 2012 08:57:54 -0700:
>> On Sep 16, 2012, at 3:39 AM, Leif Halvard Silli wrote:
>>> Maciej Stachowiak, Sat, 15 Sep 2012 21:46:47 -0700:
>>>> On Sep 15, 2012, at 7:55 PM, Leif Halvard Silli wrote:
>>>> 
>>>>> However, due to bug 22261 - "Clicking on a non-text 
>>>>> input element does not give it focus",[1] Webkit and Chromium suffers 
>>>>> from the following: if one opens a longdesc link (e.g. with Webkit 
>>>>> based iCab) VoiceOver will start to read from the top of the page 
>>>>> instead of from the section where the particular longdesc was situated. 
>>>>> Something which takes away lots of flexibility with regard to longdesc. 
>>>>> And, in fact, it also impacts regular links as well - it is is real 
>>>>> hole in VoiceOver and Webkit's elegance.
>>>> 
>>>> I would say this is the responsibility of the implementors of iCab, 
>>>> not WebKit or VoiceOver. There is no native support of any kind for 
>>>> longdesc in WebKit or in VoiceOver. iCab authors have not reported 
>>>> any bugs indicating that they are blocked. And it is my belief that 
>>>> iCab can handle this detail by itself.
>>> 
>>> I have forwarded your view to iCab. It is true that iCab works around a 
>>> few bugs as well as issues that the developer disagrees with. So may be 
>>> this would be one such issue.
>>> 
>>> However - and may be this was not sufficient clear in what I said 
>>> above: I would say that that bug also affect skip-to links - and all 
>>> links where it is important that focus is moved to the target. This 
>>> bug, therefore, is a mayor drawback for Webkit keyboard users.
>> 
>> I did comment in the bug - I tentatively think links should get focus 
>> on click if the user has enabled tabbing to links (or is on a 
>> platform where you always tab to links). 
> 
> This bug? https://bugs.webkit.org/show_bug.cgi?id=17450

No, the one you actually mentioned (about buttons getting focus on click).

> 
> (I mentioned the wrong bug above.)
> 
>> But I think that issue is 
>> off-topic-for longdesc. Happy to discuss elsewhere if you wish.
> 
> I hope you see that there is a number of longdesc techniques that do 
> not work very well (for unsighted users and for keyboard users) because 
> of that bug. It doesn't even work well to e.g. replace Jamesís <iframe> 
> with a <a> element. The only thing that works (unless you add extra 
> JavaScript and/or CSS) is to make sure the longdesc resource is a dull, 
> naked page that contains nothing but the longdesc resource.

That seems like a totally different bug. I am not sure what it has to do with longdesc though. You may think longdesc is like following a link, but I'm pretty sure the way iCab implements it does not follow the code path for clicking on a link.

Cheers,
Maciej
Received on Sunday, 16 September 2012 17:13:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:57 GMT