172817 2017-06-01 08:59:31 -0700 AX: Feature request: Landmark navigation 2020-07-30 13:35:33 -0700 1 1 1 Unclassified WebKit Accessibility WebKit Nightly Build All All NEW InRadar P2 Normal --- 146930 1 carolynmacleod4 webkit-unassigned aroselli Carolyn_MacLeod jcraig nurthen webkit-bug-importer oldest_to_newest 1314632 0 carolynmacleod4 2017-06-01 08:59:31 -0700 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. 1314633 1 webkit-bug-importer 2017-06-01 09:00:16 -0700 <rdar://problem/32512079> 1676173 2 Carolyn_MacLeod 2020-07-29 15:20:46 -0700 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.