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

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 UTC