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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jun 1 08:59:31 PDT 2017


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

            Bug ID: 172817
           Summary: AX: Feature request: Landmark navigation
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Accessibility
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: carolynmacleod4 at gmail.com
                CC: webkit-bug-importer at group.apple.com

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.

-- 
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/20170601/53463c1f/attachment.html>


More information about the webkit-unassigned mailing list