☂️ Keyboard navigation with arrow keys

[Kiarokh]

New feature motivation

Many users use keyboard to navigate a software's UI. They are either power users, or those who have accessibility needs and rely extensively on keyboard (e.g. due to limited or no vision). Many of our components do not properly support keyboard navigation.

New feature description

Keyboard navigation pattern

When it comes to navigating a user interface, there are at least three major keyboard interactions.

1. Using hotkeys: (to quickly perform actions or navigate to certain panes or screens of an app, no matter in which screen r pane the user is located)
2. Using the ⇥ Tab key: to quickly set the focus on or within a primary region of the user interface, such as a navigation bar, action bar, content area, header, footer, tab bar, list, etc….
3. Using arrow keys: to navigate within a primary region, such as focusing items of a list, or going through a dropdown menu, or a tab bar.

Using ⇥ Tab to focus on the next big thing

What's important here is that tabbing should be done to select or set the focus on the next primary region or on an element inside the primary region in the user interface, for example let's say a bread crumbs component. So once a breadcrumb item has received focus through tabbing, users should also be able to use the arrow keys (usually left and right arrows) to navigate between the breadcrumb items sequentially. This provides a more fluid navigation experience for users who are already focused on the breadcrumb component.

So it is not always right to have individual items inside a component, or a primary region of the UI that are all tabbable. In many cases, (usually in UI components that include an array of similar things, like list items, or buttons) only one of their items should be tabbable. The rest should be navigatable using arrow keys.

What's needed to be able to use ⇥ Tab and set focus on something?

Some elements are natively tababble, like <button />s and <a />s. But most things are not natively tabable, like <li />s or <div />s. To make such elements tabable, one need to add a tabindex attribute to them.

tabindex Attribute

The tabindex attribute specifies the tab order of an element. It can take three types of values:

1. Positive integer (e.g., tabindex="1")

   • Elements with a positive tabindex value are added to the natural tab order based on the value of the tabindex.
   • This can be problematic because it can disrupt the natural tab order, making navigation confusing for keyboard users.

2. tabindex="0"

   • The element can be focused and is added to the natural tab order of the page.
   • This is useful for elements that are not natively focusable (like <div>, <span>) but need to be focusable due to interactive behavior added via JavaScript.

3. tabindex="-1"

   • The element can be programmatically focused (using JavaScript's focus() method), but it is not reachable via sequential keyboard navigation (i.e., it's skipped when tabbing).
   • This is useful for elements that should not be tabbed to but might need to receive focus in certain scenarios, like when a modal is opened.

Screen Readers and tabindex="-1"

While elements with tabindex="-1" are skipped during normal tabbing, they can still be accessed and read out by screen readers when users navigate with mechanisms other than tabbing (e.g., arrow keys). This allows screen reader users to be aware of all elements on the page, even if they aren't in the natural tab order.

With a screen reader, the behavior can vary based on the screen reader and its settings. Some screen readers, in their default settings, allow users to navigate to all focusable elements, including those with tabindex="-1". This is because screen readers provide mechanisms to navigate through all elements, not just those in the tab order. However, the common way is that screen readers read out elements with tabindex="-1"; even if these elements are still skipped when tabbing.

New feature implementation

1. Manipulating the tabindex: For components that have an array of tabable items, we need to artificially add tabindex="-1" and tabindex="0", either to override the default tabability (if internal elements natively receive focus using the ⇥ Tab key), or to enable receiving focus using the ⇥ Tab.

   Which of the items in the array should have tabindex="0" (be tabable) depends on what the component is designed to do. But here are a few general guidelines:

   • By default, the first clickable item in the array should have a tabindex="0", and everything else tabindex="-1"
   • If the items in the array can get "selected" by the user, the last selected item should get tabindex="0", and everything else needs tabindex="-1".
   • Disabled items in the array should have tabindex="-1"

2. Implementing arrow key navigation: Keep in mind that navigating with arrow keys is not only for non-sighted users. Many keyboard users and power users too use this navigation patterns. Therefore, depending on the direction in which the array of clickable items are laid-out in the user interface (in a column, in a row, or in a grid), two or all four arrow keys are needed to navigate the array. Pressing arrow keys should toggle the tabindex accordingly.

Which elements would need this improvement

Preview Give feedback

1. Tab bar
2. List (already does, but it has a bug)
3. Menu (lists in the menu, has the same bug as above ☝️ )
4. Dock: enable proper keyboard navigation #2503
   +0
5. Breadcrumbs
6. Progress flow
7. Table

Also, many of our disabled clickable elements should get a tabindex="-1", for improved accessibility