AX: navigating to a new URL with a fragment identifier, VoiceOver moves accessibility focus to top of document regardless

• Component: Accessibility
• Status: RESOLVED DUPLICATE

[Patrick H. Lauke]

Created attachment 292162 [details]
Test case

When opening a URL with a fragment identifier, Safari correctly opens the new page and visually scrolls to the relevant part of the document referred to in the fragment/hash (if present). However, when VoiceOver is running, after the initial visual scroll VoiceOver resets the accessibility focus/caret all the way back to the first element at the very start of the document. This currently makes URLs with fragment identifiers useless for iOS/VO users (which is particularly problematic for very long documents, as VO users then have to still explicitly navigate all the way through the document to finally reach the actual section they were after).

Video of the bug in action: https://www.youtube.com/watch?v=LvlM8Z71oWE

Steps to reproduce:

- with VoiceOver enabled, open a fresh tab in Safari
- enter a URL with a fragment identifier (in the attached test case, there is a #target1, for instance)

Expected:

- Safari opens the document, visually scrolls to the location of the fragment identifier
- VoiceOver sets accessibility focus/caret to the targeted element (or its first child element)

Actual:

- Safari opens the document, visually scrolls to the location of the fragment identifier
- VoiceOver sets accessibility focus/caret to the very first element of the document
- the visual viewport is scrolled back to the top of the document

This is potentially a side effect of https://bugs.webkit.org/show_bug.cgi?id=116046, but filed separately as requested https://bugs.webkit.org/show_bug.cgi?id=116046#c57
The issue does not appear in Safari/VoiceOver on MacOS/OS X, so it seems iOS/Safari/VoiceOver specific.

[Radar WebKit Bug Importer]

<rdar://problem/28866720>

[Anika Henke]

It seems Safari iOS with VoiceOver always has its virtual focus on the first thing on the page after a page refresh or opening any page. No matter if you try to focus on another element via linking to an anchor or do the focus via JavaScript or use an input with the HTML5 autofocus attribute (all of which I've tried), the result is always the same, Safari/VO's virtual focus will be at the very top of the page. (The actual browser focus stays where it is supposed to be, only the virtual focus is affected.)

I've got another reduced test case for this:

1. Activate VoiceOver on an iOS device
2. Open http://jsbin.com/cadocaj in Safari
3. Submit the form

The browser focus (which I have made visible with a dotted blue outline) will be correctly on the error message and the virtual focus is on there as well at first. But after a split second the virtual focus will move to the first thing on the page, i.e. the heading. The time it takes for that "re-focus" is somewhat unpredictable. Sometimes VO manages to read the whole message, sometimes it just reads the first two words, and sometimes it skips it altogether.

You can see another example in the wild here: http://govuk-elements.herokuapp.com/errors/example-form-validation-multiple-questions. After submitting the form, the virtual focus will end up wrongly on the skip link at the top and not on the error message box.

[James Craig]

*** This bug has been marked as a duplicate of bug 185264 ***