AX: Feature request: Landmark navigation

• Component: Accessibility
• Status: NEW ---

[Carolyn MacLeod]

I would like a feature for navigating to "landmark regions" using the keyboard; _without_ using a screen reader.

Landmark regions can be defined by the page author by either using ARIA landmark roles (http://w3c.github.io/aria/aria/aria.html#landmark_roles), or HTML5 elements that default to having landmark roles (see summary, below, for a list of these elements).

Note that the generic landmark role="region" - and its corresponding html "section" element - must have a label before it is considered a true landmark, whereas nav, aside, etc do not technically require a label to be a landmark (but they really ought to have one, particularly if there are more than one on a page).

Headings (h1, h2...) should also be navigable because they can implicitly define a section, however it would be easiest to treat implicitly-defined sections separately from explicitly-defined sections because unfortunately (without the guidance of a working outline algorithm) they can conflict.

Summary of roles and elements that should be navigable: 
- landmark roles: banner, complementary, contentinfo, form, main, navigation, region, search 
- html elements whose default role is a landmark: header, aside, footer, form, main, nav, section 
- heading content that may define an implied section: h1, h2, h3, h4, h5, h6

Some links:
Here's a really nice landmark and heading "explainer" page: https://www.w3.org/TR/wai-aria-practices/examples/landmarks/index.html

Here's a few little test sites: 
http://html5accessibility.com/tests/roles-land.html (note that "application" is no longer a landmark) 
http://html5accessibility.com/tests/structural-elements.html (note that "article" is not a landmark)
http://pauljadam.com/demos/landmarks.html

Here's the same feature request on other platforms (plus background discussion):
Edge: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/19436788-landmark-navigation
Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=704698
Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=670928

Note that there's already an excellent Landmarks extension: https://www.paciellogroup.com/blog/2017/05/improving-access-to-landmark-navigation/
However I still think that having this type of functionality native in the browsers would enable more users to discover it, use it, like it, and then _demand_ it, which has the potential to make more web devs put more thought into the semantic layout of their pages... which would benefit everyone.

[Radar WebKit Bug Importer]

<rdar://problem/32512079>

[Carolyn MacLeod]

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.