Nascent Proposal: keyboard navigation of headings and HTML5 ‘landmark’ elements

Problem description: Keyboard only users get an onerous user experience when navigating content on web pages because they can only use the tab key to move through focusable elements.

For example: the guardian.com home page has 535 links, 100 buttons and various other elements that are included in the focus order… It does provide an affordance for keyboard only users via a ‘skip to main content’ link which skips over 135 links. This leaves 400+ focusable elements to tab through. The page has 91 correctly marked up headings. It also has a mixture of ARIA landmark roles and HTML5 elements that map to landmark roles.

Suggestion: By implementing an interoperable keyboard navigation system in UA’s (that support keyboard input) the amount of keystrokes a user requires to navigate to and interact with page content can be significantly reduced. It will also mean that developers don’t have to bolt on navigation affordances (skip links) for users and web content will automatically conform (if headings and/or HTML5 header/main/footer elements are used) to the WCAG 2 bypass blocks criteria.

Related reading:

• Firefox integrated landmark navigation
• Bypass blocks thread on Webaim mailing list

That sounds extremely useful! Would such a mechanism be Web exposable in any way, or is it just something that UAs need to implement?

/cc @RickByers @jacobrossi

It can/has been done via DOM and JavaScript, also Opera pre blink provided built in keyboard navigation. I suggest that in order to achieve a robust interoperable navigation feature UA’s need to implement.

I’ll further add that users of assistive technologies (such as screen readers) who navigate with the keyboard usually have some advanced keyboard navigation mechanisms provided by the AT (e.g. navigating by heading or landmark - be it a structural element or something denoted with role="..."). The one user group currently left out high and dry are sighted, non-AT-using keyboard users.

Additionally, worth noting that there are some extensions that try to add this functionality, but that currently they have to wastefully walk the entire page’s DOM to not only try to match specific elements (e.g. look for all instances of <h1>, <h2>, <nav> etc), but then ALSO check all elements for the possible presence of a role="..." that may have blessed the element with a different mapping. As browsers internally already assign the correct role to elements (i.e. they know that an element <nav> has a navigation role, same as any arbitrary <div role="navigation">), it would at least be nice if browsers also exposed their built-in/calculated roles, so that an extension can avoid having to parse the entirety of the DOM and only select them by their role. See part of the discussion here https://www.w3.org/Bugs/Public/show_bug.cgi?id=27294

What I’m trying to understand is if this is something that should be Web exposed (i.e. Web developers would have to do something with it), Extension exposed (i.e. extension developers would have to do something to help users with it) or simply a browser UI feature.

From what I understand so far, it’s mostly the latter two: We want browsers to expose some UI to users that would help them skip to the “important” parts of the page (where “important” is decided by the user, based on ARIA roles and heuristics), and possibly expose the same to extensions, so that extensions devs can also do the same, creating possibly better adapted UIs to their audience.

Is that correct?

Is what i suggest, as otherwise it would be too fragmented and patchy in implementation.

Cool! In that case, I think there’s no spec/standardization needed.

Just need to bug the corresponding browser folks

+1 to this. Web developers have already done something, namely, they have marked up their HTML correctly with HTML 5 semantics and, potentially, WAI-ARIA. That’s all of the information they need to add to allow users to identify (and therefore jump to) the important parts of the page. Now there just needs to be a browser UI enabling access to those existing semantics.

I think that the feature would benefit from some sort of spec/standardisation/guidance doc, so we can get agreement (or not) on how the feature will work. Guess I should throw something together…

Isn’t that what the HTML Outline and ARIA specs are?

Details past that (what keys perform what operations etc) seem like UA concerns, in line with @yoavweiss’s thoughts from Gitter.

I don’t completely understand this proposal but I do know that there’s a sort of gray area with respect to standardization of what implementations expose to AT software through platform accessibility APIs. What I mean is, it seems like there are certain behaviors that, while not exposed to Web content in a way that needs to be standardized, are exposed to AT software through platform accessibility APIs.

So maybe this idea kinda falls into that gray area? I dunno in this specific case but I do know that @SteveF has had some success in the past at writing specs related to that stuff that has to do with that platform-accessibility-API layer.

Thank you, Steve.

Okay, so I’ve been thinking about this too and I kind of came round to a PC gaming metaphor. In games I used to play like Carmageddon, there was a screen where you could customize key combinations for certain actions. For instance, SPACE for accelerate might be the default but you could change it to ALT or whatever.

What I’d like to see in browsers is a browser chrome menu option which is already keyboard accessible where you can easily set custom keyboard commands for certain actions. So maybe there’d be a field for landmarks where you could focus an input and simply press a combination of keys and those keys would be set. I think I might set ALT + TAB for going to the next landmark and ALT + SHIFT + TAB for going to the previous landmark. The UA would then apply a UA style for focusing the landmarks via these shortcuts.

You could have an option for saving kbd shortcut combinations just for that web page / domain or as default for all your browsing and could specify overrides where you felt certain pages needed different shortcuts.

?

Hi @heydonworks, all

I think this is an important question, but different from the one Steve asked.

So I started a different thread.

Related Guidance for UA implementers:

2.5.2 Provide Structural Navigation by Heading and within Tables:
The user agent provides at least the following types of structural navigation, where the structure types are recognized:

• By heading
• By content sections
• Within tables

Intent of Success Criterion 2.5.2: Users who find it difficult or impossible to use the mouse require an efficient way to jump among elements without having to navigate through intervening content. Navigating by heading is especially important when scanning a web page to find a pertinent section. Navigating by table element is especially important when building or reading tables.

http://www.w3.org/TR/2014/WD-UAAG20-Reference-20140925/#sc_252