Disclosure navigation: via tabbing, arrows, or both?

[hellogreg]

This is a topic @zeroedin , @adamjohnson , and I chatted about a bit when talking about the ux dot sidenav. I’m bringing it here to make it a little more formal.

The situation

Currently, ux dot’s <rh-sidenav> and <rh-navigation-secondary> incorporate roving tabindex, meaning any top-level links or disclosure buttons must be navigated via the arrow keys.

The question

How should users be able to move across these elements? Via tabbing, RTI, or some combo?

Options

1) Tabbing-only

• Advantage: Predictability. Pretty much every site operates this way, so users are likely to expect that our sites will too.
• Disadvantage: No single-key exit from navigation.*

2) RTI-only menubar

This is what we have now with <rh-sidenav> at ux dot.

• Advantage: Speed of exiting navigation via tab.
• Disadvantage: Less common than tab key navigation (unpredictability).

3) Combo: top-level RTI menubar, secondary level tabbing

This is what we have now with <rh-navigation-secondary>.

• Advantage: Speed of exiting top-level navigation via tab.
• Disadvantages: Less common than tab key navigation (unpredictability). Inconsistency of navigation method between levels.

4) Combo: tabbing and RTI at all levels

The WAI Disclosure Navigation uses this approach, where either tabbing or arrows can be used to move focus interchangeably.

WAI’s key pull quote on this option is that, "if implemented, the [arrow] keys supplement, but do not replace, tabbing among buttons and links." In other words, tabbing is still the required means of moving focus; RTI is optional.

• Key advantage: Predictability. Works for users who might expect either tabbing or arrows. (Side benefit: disables page scrolling on arrow press when focus is in the nav)
• Disadvantage: No single-key exit from navigation.*

My recommendation

I think predictability is key. So, I say we’re safe to go with tabbing-only for starters (#1).

We can then investigate (including user testing, if desired) tabbing with RTI enhancement down the line (#4). Or, if we think we’re good to just jump straight to #4 – and it won’t hold us up – I won’t argue with that!

Whatever we decide upon, we can then make issues to update the existing elements, in addition to keeping this in mind for the future.

I don’t think we should continue to use options #2 or #3 (though at least #2 is consistent). WAI even says the following about its RTI-only menubar pattern: “the disclosure pattern is better suited for most web sites.”

* - I’m not worried that neither #1 nor #4 allows for quick tabbing out of the navigation. First, I think users are unlikely to expect that behavior. Second, we already have a skip link section at the top of the page for all keyboard users (as @zeroedin brought up in our initial chat about this). Third, screen reader users can use keyboard shortcuts (and/or the VoiceOver rotor) to quickly jump out of the nav to another landmark.

[markcaron]

I'm with @hellogreg, though I like the idea of #4 too.

IMO, navigation through hyperlinks is a basic function of the web and shouldn't be treated like more complex widgets that require RTI, like menus. And, as Greg mentioned, these navigational landmarks are often accompanied (or should be accompanied) by a skip link.

Requiring a screen reader user to navigate using a more complex/advanced pattern (like RTI) could potentially be a barrier for an essential need like navigation. Navigation is not synonymous with menus (which require RTI) even though they are often conflated.

Navigation should be simple.

Also, to Greg's point, predictability for sighted keyboard users is another good reason. The more predictable and simpler the interaction the better in this case.

[zeroedin]

I agree with all of this. Consistency is definitely warranted.

The only concern I have with RTI all the way through is that the content of secondary-nav is not predetermined as I understand it. It could literally be anything the implementation adds. If I remember correctly the conversations that Nikki and I had while adding RTI was that RTI becomes more complex given grid style content.

The following links only represent grid based directionality with RTI not as a source of explicit expert knowledge:

https://rajeev.dev/mastering-keyboard-navigation-with-roving-tabindex-in-grids
https://opensource.adobe.com/spectrum-web-components/tools/roving-tab-index/#options (direction grid option)

If I understand correctly because we use a mega menu style dropdown/disclosure content we'd have to implement that form of RTI for content based on its style? Maybe I am conflating that idea or miss-recalling it but I pretty sure I remember it being a concern at the time. Note: I could and most likely am totally incorrect here and defer to @hellogreg and @adamjohnson.

[hellogreg]

Yeah, I agree with you re: complexity. I feel most comfortable omitting RTI (at least for now), but I also wanted to respect any previous conversations/decisions/labor from before I got involved!

[adamjohnson]

As others have said, it seems like the options here are either #1 or #4.

Since the content in secondary-nav could be anything, it seems we can't reliably prescribe RTI out of the box (even though in many cases RTI may be warranted).

Which may mean we go with #1 for optimal UX and perhaps encourage authors to implement #4 if their content warrants it (eg: they are implementing a Disclosure Navigation Menu.