Keyboard Navigation Behavior (Arrow key vs Tab)

[jcfilben]

Currently on Grommet we have a mix of components that use arrow keys to navigate and some components that use tab to navigate. There are also components that leave the focusIndicator on the container, components that have the focusIndicator on items within the container, and components that don't show a focusIndicator.

It would be great to gain more clarity on what the correct accessibility behavior is.

• Should we settle on 1 type of interaction tab or arrow key?
• Do we need to support both types of keyboard navigation (perhaps with a global theme prop to switch between tab vs arrow key based interaction)?
• Should the focusIndicator be on the container or on an individual item within the container?

Tab based navigation components:

• CheckBoxGroup (focusIndicator is on individual CheckBox)
• Pagination (focusIndicator is on individual button)
• Tabs (focusIndicator is on individual Tab)

Arrow key based navigation components:

• Calendar (focusIndicator is on the container)
• DataTable (focusIndicator is on the container)
• List (focusIndicator is on the container)
• RadioButtonGroup (focusIndicator on individual RadioButton)
• Select (no focusIndicator)

Supports both:

• Menu (no focusIndicator)

[jcfilben]

Related to discussions in https://github.com/grommet/grommet/issues/5677

[jcfilben]

Adding notes from Chat GPT prompts on this topic...

1. Tab Key Navigation

• Purpose - The tab key is used to move focus between interactive elements in a form or interface, following the document's natural flow. It's a key component of keyboard accessibility.

• Appropriate for

  • Forms and Input Fields - Moving between text fields, buttons, checkboxes, and other form controls.
  • Links, Buttons, and Focusable Elements - When a user needs to move between different actionable elements on a page (e.g., links in a navigation bar, buttons on a form).
  • Screen Readers - The tab key is fundamental for screen reader navigation, where users move between interactive elements in sequence.

• Limitations

  • Not for Content Scanning - Tab is not appropriate for navigating through content like menus or lists where arrow keys are expected (e.g., selecting items within a dropdown).

• Example Components

  • Forms with multiple fields - Users can tab through text inputs, checkboxes, and buttons.
  • Modal Dialogs - Tabbing helps users navigate between controls (e.g., close button, submit button).

2. Arrow Key Navigation

• Purpose - Arrow keys are typically used for fine-grained navigation within a confined component, like moving between options in a dropdown, tabs, or rows in a data grid. They provide more detailed control within a component's options.

• Appropriate for

  • Menus and Dropdowns - Navigating between items in a list where selection is necessary.
  • Tab Interfaces - Moving between different tabs without triggering a new page focus or navigation.
  • Sliders/Carousels - When cycling through images or items horizontally or vertically.

• Limitations

  • Not for Inter-Component Navigation - Arrow keys are confined to navigating within a specific component or set of items; they don’t shift focus between different groups of interactive elements. This is why they aren’t interchangeable with tab keys.

• Screen Reader Reservations - In screen readers, arrow keys are often reserved for content reading (moving line by line or through headings), so relying on arrows for main navigation could interfere with the screen reader’s function.

• Example Components

  • Dropdown Menus - Use arrow keys to move up and down through a list of selectable options.
  • Tab Navigation - Moving horizontally across a row of tabs without leaving the current focus scope.

3. Why Tab and Arrow Keys Are Not Interchangeable

• Tab Key - Reserved for moving between interactive elements on a page, maintaining a predictable flow for keyboard users and screen readers. Misusing the tab key for intra-component navigation breaks this predictability and could cause accessibility issues for screen reader users.
• Arrow Keys - Used within a confined component to navigate between items (e.g., menu items, tabs, grid cells). These keys allow movement within a specific scope but are not designed for moving between different sections or interactive elements on a page.

4. Communicating the Rationale

• Accessibility Standards - Emphasize that keyboard users, including those using screen readers, expect a predictable experience. Screen readers, for example, use the arrow keys to navigate content, so overloading arrow keys for component navigation can interfere with their experience.
• Consistency and Usability - Highlight that having a clear rule for when to use tab vs. arrow keys ensures a consistent user experience across components, which is key for both accessibility and usability.
  • Testability - Implement and test the rule in real-world components (e.g., dropdowns, menus, and forms) to ensure that keyboard navigation behaves as expected and doesn't interfere with screen reader functionality.

5. Draft Rule (for Testing)

• Tab Key - Always use for navigating between focusable elements, such as buttons, form fields, and links.
• Arrow Keys - Use for navigating within a group of options or a list (e.g., within menus, dropdowns, or tabbed interfaces).

---

When using arrow key based navigation in a component should the focus indicator remain on the container or be placed on the individual item within the component?

Answer:

The focus indicator should generally be placed on the individual item within the component rather than the container. Here’s why:

Clear Selection: Placing the focus indicator on the individual item helps users easily see which item is currently selected, especially when navigating through lists or grids.

Intuitive Navigation: Users expect the focus to move with the arrow keys. Highlighting the item directly conveys that the selection has changed.

Accessibility: This approach supports screen reader users and those relying on keyboard navigation, making it clear which specific element is active.

Consistency: Keeping the focus indicator on items aligns with common UI patterns, making it familiar and intuitive for users.

In summary, the focus should be on the individual items to enhance usability and accessibility.

[SmWorkGitHub]

Hi @jcfilben. @SOjaHPE showed this to me today. I filed an accessibility epic against the global header which is relevant to this. GLCP-176633

I detemined that Bill T has to navigate using arrow keys because they reads the UI text and tab stops in the global header don't provide enough context.

The global header, and the UI components I've worked with in the past, are designed for tab navigation between components and arrow navigation within components. The global header works great that way but is a nightmare when you navigate between components with arrow keys. The issue is that the tab stops have to provide good context for screen reader users.