Ensure that all content and function can be done with a keyboard alone.

Keyboard accessibility is one of the most important aspects of web accessibility. Many users with motor disabilities rely on a keyboard. Blind users also typically use a keyboard for navigation. Some people have tremors which don’t allow for fine muscle control. Others have little or no use of their hands. Some people simply do not have hands, whether due to a birth defect, an accident, or amputation. In addition to traditional keyboards, some users may use modified keyboards or other hardware that mimics the functionality of a keyboard.1

Contents


Keyboard Testing

Testing with a keyboard is an essential part of any accessibility evaluation. The basics of keyboard testing are simple—the Tab key can be used to navigate through links and form controls, Enter (and sometimes Spacebar) selects an element, and the arrow keys are sometimes used for other navigation. However, when testing with a keyboard, you are not just trying to interact with the page successfully, you also want to ensure all interactions are predictable. This requires an understanding of common keyboard interactions(external link).2

Tab Order

The general rule of thumb is that any control a user can interact with or provide input to should aim to be focusable and display a focus indicator (e.g., a focus ring).3 Typically the tab order follows the DOM order, that is, the order of elements in the markup. While floats, flexbox or CSS grid styles can be used to visually reorder content, you should consider the impact to keyboard users when focus could jump around the page. If you‘re unsure what elements should be focusable read through this Introduction to Focus(external link).

Navigation tab order example
Navigation tab order example
Tab order traversing into focused item
Tab order traversing into focused item

The tabindex attribute can be added to elements to make them focusable. Built-in interactive HTML elements like text fields, buttons, and select lists are implicitly focusable, meaning they are automatically inserted into the tab order and have built-in keyboard event handling without developer intervention.4

  • tabindex = -1: programmatically focusable, but isn‘t included in the tab order
  • tabindex = 0: focusable per DOM order
  • tabindex = 1+: higher focus priority (not recommended)

What to Expect

  • Only focusable elements should receive focus
  • Focus order should follow the DOM order
  • Focus order typically follows reading order (similar to DOM order)
  • When interacting with a component, like expanding a dropdown menu, the focus should travel within that component before moving on
  • You should be able to tab through the entire page and return focus to the address bar

Troubleshooting

Focus order is not sequential, or lacks a natural reading flow:

  • Inspect the DOM order
  • If the DOM order is correct see if the CSS is visually reordering content
  • Check to see if the tabindex is set to a positive integer (e.g. 1+)

Elements are recieving focus, but shouldn‘t:

  • Check to see if the tabindex attribute is present on the element

Elements should recieve focus, but don‘t:

  • Make sure element has a visible focus state (see next section)
  • Use tabindex = 0 for custom controls

You cannot tab through the entire page without the keyboard getting trapped in a section:

Focus States

For sighted users a visible state must be provided for items that recieve keyboard focus. The visual state lets a user know that the element has keyboard focus and can be interacted with. By default browsers provide a focus ring (outline), but many times this has been overriden with CSS.

Example of a button without and with a focus state
A button without and with a focus state

What to Expect

All focusable elements should have a visible focus state when navigating with a keyboard. If you can’t tell that an element has focus, odds are most other users can’t either.

Troubleshooting

If there‘s no visible focus state:

  • Take a look at the CSS, is outline: set to none? If so consider removing this declaration or using :focus to add styles.
  • Make sure you‘re using the keyboard. This seems obvious, but there are libraries like What Input that can provide the ability to have different focus states depending on a user‘s detected input.

Restricting Focus

Sometimes it makes sense to contain the focus to content sections. For example, when a model is active and the focus is within it a user cannot interact with page elements behind the modal (sometimes covered by the component) until the modal is closed. Within these keyboard traps a user must be able to exit the state and ”untrap” the focus.

Example of modal covering content
A modal with a focus trap and multiple ways to dismiss

What to Expect

Modals, pop-ups and other UI widgets that have a subset of keyboard interaction should trap the keyboard—creating a cyclical focus order within. A keyboard mechanism must be available, however, from within the component‘s focus order to dismiss or close the element. Typically focus is placed back on the item that triggered the component upon dismissal.

Troubleshooting

When a modal, pop-up or similar widget is open items behind are still in the focus order:

  • Ensure that a keyboard trap has been created and that controls exist to dismiss or close the component

Skip links are typically placed at the beginning of a page or section and help a user ”skip” to the main content or another section without having to tab through additional navigation or redundant page elements or sections. They are often not visible to sighted users unless they have received keyboard focus, at which point their focus state should be visible to everyone. Although skip links aren‘t required to satisfy any particular success criterion they are beneficial and easy to include.

When tabbing through a page, look for skip links as the very first tabbed item. Make sure that the skip link does indeed go to the content referenced in the link.

Example of a skip link
A skip link on lifetime.life

Resources


References