- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 16 Sep 2012 12:40:39 -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 12:16 PM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: >> >> 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. 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. > > 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. VoiceOver reads based on the VoiceOver cursor, not the keyboard focus. > > 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.) 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) > 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. Nor does fragment navigation - that's the bug you cited. Regards, Maciej
Received on Sunday, 16 September 2012 19:41:08 UTC