- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sun, 16 Sep 2012 21:16:31 +0200
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: "www-archive@w3.org" <www-archive@w3.org>
Maciej Stachowiak, Sun, 16 Sep 2012 10:12:33 -0700: > On Sep 16, 2012, at 9:40 AM, Leif Halvard Silli 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). Ok. Thanks for looking at bug 17450 too. The two bugs seem related. (At least from a conceptual point of view - that's reason I stumbled upon bug 22261 despite that I had intended to find bug 17450.) >> (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. What does 'code path' refer to? I think 'totally different' is too strong: Using different screenreaders, try to visit the longdesc resource *fragment* of the demo page that I posted.[1] You will then find: * that VoiceOver reads the page, from the page top. Thus it reads the visually hidden text behind the longdesc resource. * that by contrast, using IE8 or Firefox, JAWS will read the page title, and then jump over the page content and down to the start of the longdesc fragment. * There is no AT the works [well enough] with it, so I cannot report how screenreaders work with Opera. On ironic detail w.r.t. VoiceOver is that it *stops* reading at the bottom of the focused fragment (this is due to the CSS). The irony being that it respects the *end* of the focus, but not the beginning of it ... A simple focus test can be performed by visiting the HTML5 spec:[2] a. Search for '2.5.5' with your browser's Find-in-page tool. (You will then come to point 2.5.5 in the ToC) b. Hit the Esc key (or similar) to get out of Find-in-page modus. c. Press Tabulator to move to next link - (2.5.5.1) Results: Safari - first link of the page (Homepage link) Chrome - next link (2.5.5.1) Firefox - next link (2.5.5.1) Opera - first FORM FIELD of the page W3m textbrowser - next link (2.5.5.1) IE8 - next link (2.5.5.1) (Surprising that Chrome was different from Safari.) Another test: a. Follow a fragment link to the middle of a page http://dev.w3.org/html5/spec/common-microsyntaxes.html#yearless-dates b. Press Tabulator to move to next link Results - the link that get chosen: Safari - first link of the page (Homepage link) Chrome - first link of the page (Homepage link) Firefox - next link (Link text: 'digits') Opera - (may not work at all?) W3m textbrowser - next link (Link text: 'digits') IE8 - first link of the page (Homepage link) So worse results for the second test. There does not seem to be a 100 percent correlation between the Find-in-page focus and the link focus. [1] fragment URL/hash name: http://malform.no/testing/a-demo-of/longdesc-with-hidden-iframe/#longDesc [2] http://dev.w3.org/html5/spec/ -- leif halvard silli
Received on Sunday, 16 September 2012 19:17:02 UTC