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
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)
Here's the same feature request on other platforms (plus background discussion):
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.
The following will work (and if preferred, can be implemented just for HTML elements that have an implicit landmark role ):
- User types next-landmark shortcut key
- Browser scrolls to start of next landmark (similar to scrolling to a fragment )
- Browser moves Sequential Focus Navigation Starting Point (SFNSP)  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  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).
 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] 
- 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.
 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
 Matt Atkinson's Landmarks extension: http://matatk.agrip.org.uk/landmarks/
 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.