- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 16 Sep 2012 10:12:33 -0700
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: "www-archive@w3.org" <www-archive@w3.org>
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