- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sun, 16 Sep 2012 22:41:53 +0200
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: "www-archive@w3.org" <www-archive@w3.org>
Maciej Stachowiak, Sun, 16 Sep 2012 12:40:39 -0700: > On Sep 16, 2012, at 12:16 PM, Leif Halvard Silli wrote: >> * that VoiceOver reads the page, from the page top. Thus it reads >> the visually hidden text behind the longdesc resource. > The behavior you observe may be similar, but the underlying mechanism > is totally different. I am pretty confident that fixing the bug you > mention will have no effect whatsoever on iCab's implementation of > longdesc. Effect on which angle of iCab's longdesc implementation? If you meant to say that fixing bug 17450 is not going to improve the way VoiceOver behave with iCab, then I could imagine that it is so ... But it is also matter of defining what to expect, conceptually, even if that concept has to be solved via multiple bugs for more or less, on the surface, parallel features. Both the Devil and the consumer wants more: Give him Find-in-Page focus, and he wants Follow-link focus too, because they logically belongs together. >> 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 ... > > I am not sure if you understand how focus works in our engine or how > VoiceOver relates to focus. To the first: What is it you suspect I don't understand w.r.t. focus in Webkit? To the second: It might very well be. Though I may understand more than A11Y TF members with a Windows only background do, my VoiceOver usage is probably simplistic. > VoiceOver reads based on the VoiceOver cursor, not the keyboard focus. Would the VO cursor be that what I see in that "black bar" at the bottom of the page? But if a VoiceOver user activates a same-page-link, should he/she not expect that VO start to read from the target? Has Roger Johansson not got it when he complains about skip to links not functioning? Would it not help VO users if the skip-to links problem was fixed? http://www.456bereastreet.com/archive/201203/skip_links_and_other_in_page_links_in_webkit_browsers/ > Find in Page does not give keyboard focus to what you find in 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) > Nor does fragment navigation - that's the bug you cited. And getting it would not help VO users? Btw, I seem to remember seeing James (Craig) follow up on a bug related to focus in HTML5. -- leif halvard silli
Received on Sunday, 16 September 2012 20:42:26 UTC