[Webkit-unassigned] [Bug 172817] AX: Feature request: Landmark navigation

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=172817

--- Comment #2 from Carolyn MacLeod <Carolyn_MacLeod at ca.ibm.com> ---
The following will work (and if preferred, can be implemented just for HTML elements that have an implicit landmark role [1]):
- User types next-landmark shortcut key
- Browser scrolls to start of next landmark (similar to scrolling to a fragment [2])
- Browser moves Sequential Focus Navigation Starting Point (SFNSP) [2] to start of next landmark
- Browser moves focus to body if landmark is not focusable (same as for in-page links with non-focusable target element)
- User can type tab (or shift+tab) to move focus to next (previous) focusable element after (before) SFNSP

Similar behavior for previous-landmark.
If there's no next (previous) landmark then wrap to first (last) landmark.

Just need to decide what shortcut key(s) to use.
Ctrl+F6 and Shift+Ctrl+F6 (Cmd+F6 and Shift+Cmd+F6 on Mac) may be the best choice, but that's up to you to decide. Would be nice if it was the same in all browsers.
Matt Atkinson's excellent Landmarks extension [3] uses Alt+Shift+N and Alt+Shift+P which works nicely in most places, but not in text fields on a Mac (Alt inserts special characters).

[1] HTML elements that have an implicit landmark role:
- HTML header (in body scope), footer (in body scope), main, nav, aside
- HTML form and section if aria-label[ledby] [4]
- The only ARIA landmark not covered by the above HTML elements is search (input type=search defaults to searchbox role, not search). Willing to live with that 1 omission.

[2] Sequential Focus Navigation Starting Point (SFNSP):
- HTML spec Scrolling to fragment: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-fragid:the-indicated-part-of-the-document-5
- HTML spec Sequential focus navigation starting point: https://html.spec.whatwg.org/multipage/interaction.html#sequential-focus-navigation-starting-point
- Removing Headaches from Focus Management: https://developers.google.com/web/updates/2016/03/focus-start-point
- Focus management still matters: https://sarahmhigley.com/writing/focus-navigation-start-point/
- Where focus goes when following in page links: https://hiddedevries.nl/en/blog/2017-04-24-where-focus-goes-when-following-in-page-links
- In-Page Links and Input Focus Tests: http://accessibleculture.org/research-files/in-page-links/testPage.php#a-name-id

[3] Matt Atkinson's Landmarks extension: http://matatk.agrip.org.uk/landmarks/

[4] From the User Agent Support section of the ARIA spec: https://w3c.github.io/aria/#ua-support
> The WAI-ARIA specification neither requires nor forbids user agents from enhancing native presentation and interaction behaviors on the basis of WAI-ARIA markup. Mainstream user agents might expose WAI-ARIA navigational landmarks (for example, as a dialog box or through a keyboard command) with the intention to facilitate navigation for all users. User agents are encouraged to maximize their usefulness to users, including users without disabilities.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200729/609fb6f0/attachment.htm>