Keyboard Navigation

Overview

Many people navigate through digital content either primarily or exclusively using the keyboard, instead of the mouse or swipe gestures. This includes people with limited vision who rely on screen readers, and people with limited motor functionality.

All functionality of your digital content must be accessible via the keyboard alone. This includes standard content navigation, using menu options, and filling out forms. If certain functionality is not accessible from the keyboard, some users will be prevented from using parts of the digital content.

Guidelines

Focus Order and tabindex

• All interactive content must be accessible using the keyboard. This includes links, buttons, forms, and controllable elements like image carousels. It does not include images, headings, and standard text.
• Elements receive focus in a logical reading order. This is generally left-to-right, top-to-bottom, but may vary slightly if someone would reasonably read this content in a different order.
• Items can be explicitly allowed keyboard focus with the tabindex attribute. 
• The focus order is calculated as follows:    
  • First: cycle through all elements on the page with a tabindex greater than 0, in ascending order. Items with duplicate tabindex values are highlighted according to their order in the DOM. This allows you to override the default tab order, and might be appropriate in cases where CSS makes certain page elements render outside of where they would otherwise fall in the DOM. Overuse of positive tabindex values can create maintainability problems and should be used sparingly.
  • Next: focus on all other interactive items, including items with tabindex=0, according to their place in the DOM.

Visual Focus

• The element that has active focus should have a visual indicator so the user knows where they are on the page.
• This visual indicator should be consistent for all elements on the page, whenever possible. For example, give all elements a large black rectangle border when they receive focus.    
  • Provide backup custom focus styles when the default focus style is not noticeable. If a button has a default inactive state with a black border, adding an additional black border on focus is not sufficiently perceivable.

Maintain State

• If the state of the content changes, such as a dialog box opening up, the keyboard focus should shift to the first element in that box. Closing the box should return the keyboard focus to where it was before the change of state.
• The user changing focus should never cause new pages to open (dialogs and popups are ok), forms to submit, or page content to change in a substantial or irreversible way.
• There should not be any “keyboard traps”, windows, options, or other states where a user is unable to back out of their current selection without reloading the page.

How to Test

Keyboard navigation can be done manually without any special tools. Keyboard navigators use the following keys to navigate around the pages:

• Tab, to move forward through the content.
• Shift-Tab, to move backwards through the content.
• Enter, to activate the current element.
• Escape, to back out of any open prompts or dialog boxes.
• Arrows, especially when navigating dropdown menus, and for some types of tabular content like spreadsheets.
• Less commonly, Spacebar is used as an alternative to Enter for selecting items, especially in forms.

Tab through all the elements on the page, then shift-tab back up to the top. Verify every interactive element is accessible, that the items receive focus in a logical reading order, that each item has a consistent visual focus indicator.

Select interactive items and verify they behave the same as if you clicked on them with a mouse.

Open up menus or dialog boxes, if applicable, and verify you are able to back out of them with the escape key. Verify that these actions do not substantially change the state of the page.