Focus management

Always set keyboard focus to an element that makes sense to the user in the user’s context — this is the practice of focus management.

Meeting the Web Accessibility Standard

When keyboard focus is managed in a way that content and functionality continue to make sense and work as expected for the user, this meets WCAG 2 Success Criterion 2.4.3 Focus Order (Level A).

When an interactive component receives focus and does not cause any change of context, this meets WCAG 2 Success Criterion 3.2.1 On Focus (Level A).

On this page

• Functionality must make sense and work as expected
• Moving focus programmatically
• Moving focus to the right location
• No changes of context on focus
• Managing focus in complex widgets

Functionality must make sense and work as expected

Most of the time, users can and should be left alone to move focus around the content as they wish.

But there are scenarios where the developer needs to move focus programmatically to specific elements in response to user actions or other events in a web page.

The developer does this to ensure that the content and functionality continue to make sense and work as expected for the user.

Moving focus programmatically

Often a developer needs to move focus programmatically in response to some keyboard input by the user. To do that, event handlers need to be programmed to listen for keyboard input, and when the right key or keys are pressed, that will trigger focus to be moved.

For more on keyboard events and programmatically responding to them using event handlers, see Responding to keyboard input.

Using the focus() method

To move focus to a specific element, use the JavaScript focus() method.

The element to be focussed needs to be programmatically focusable, which includes:

• natively focusable elements
• elements with any tabindex value.

When using focus() to programmatically set focus to a non-interactive element like an <h1> or <main> element, give it tabindex="-1". This makes the element focusable via JavaScript, while keeping it out of the keyboard focus order, as is expected for non-interactive content.

For more information on the focus() method, see HTMLElement.focus() — MDN Web Docs.

Moving focus to the right location

Where focus should go following any user action or event on the page depends on the context of the particular widget or interactive element involved.

• When activating a button that expands or collapses an accordion widget, focus should remain on the button.
• When opening a dropdown application menu, focus is expected to move to the first item in the dropdown.
• When using a “Load more” button pattern, focus should move to the additional hidden content.

Keyboard interaction patterns for common widgets

There are conventional keyboard interaction patterns for most common widgets, and it’s up to the designer and developer to understand and implement these. For more, see Common keyboard interaction patterns.

Single-page applications

The question of where to send focus also comes up with single-page applications or SPAs. For more, see Focus in single-page applications (SPAs).

No changes of context on focus

When an interactive control receives focus, it must not result in any major changes to the web content.

Major changes to the content on a page can confuse users who cannot take in the whole page at the same time. Such changes to content are called ‘changes of context’ and include things like:

• keyboard focus automatically moves somewhere else on the page when an element receives focus
• a help dialog opens up when a text field in a form receives focus
• a form submits unexpectedly when the user presses the Tab key to move out of a <select> dropdown menu.

For more information on ensuring that keyboard focus does not cause a change of context, see Understanding Success Criterion 3.2.1: On Focus — WCAG 2 — W3C.

Managing focus in complex widgets

Complex or compound widgets are groups of individual, keyboard focusable controls that combine to provide a particular user interface that HTML does not natively provide, such as:

• tree views
• menus
• tabbed interfaces.

Interacting with the widget’s contents usually requires using the ← ↑ ↓ → keys to change the currently selected or active item, such as the:

• different options in an application menu
• active panel in a tabbed interface
• cells in a spreadsheet.

The widget is usually a single item in the keyboard focus order. Pressing the Tab key moves focus to the widget. Pressing Tab a second time moves focus away from the widget entirely and to the next item in the focus order.

When the widget receives focus via the Tab key, it could be the widget container itself or a single user interface component within the widget that actually receives focus. Which one it is depends on which of the following 2 approaches is taken:

• using a roving tabindex
• using aria-activedescendant.

Roving tabindex

In the roving tabindex approach, only one interactive element in a widget is keyboard focusable at any one time — all other controls in the widget are set with tabindex="-1" to remove them from the focus order.

As the user interacts with the widget, for example, using the ← ↑ ↓ → keys to activate the next panel in a tabbed interface, the previously focused element is removed from the tab order with tabindex="-1". The newly selected or active element is added to the tab order with tabindex="0" and then focused programmatically.

If the keyboard user moves focus away from the widget, the last element within the widget to have focus will regain it when the user moves focus back to the widget, as that element will still have tabindex="0" and be the widget’s only focusable item.

For more on the roving tabindex approach, see:

• Managing Focus Within Components Using a Roving tabindex — ARIA Authoring Practices Guide — W3C
• Technique 1: Roving tabindex — MDN Web Docs
• Managing focus in components — Web Fundamentals — Google Developers
• YouTube video: Roving tabindex — A11ycasts #06 — Google Chrome Developers.

aria-activedescendant

In the aria-activedescendant approach, focus moves to and remains on the widget’s container element.

Manage changes in focus within the widget by updating the aria-activedescendant attribute with a reference to the element within the widget that the user has selected or activated. This provides a programmatic way to identify which element in a widget the user is interacting with, and enables assistive technologies to relay this information to their users.

The aria-activedescendant property is part of Accessible Rich Internet Applications (WAI-ARIA), a web technology for making custom web content and widgets accessible to assistive technology users.

For more on using aria-activedescendant, see:

• aria-activedescendant property — Accessible Rich Internet Applications (WAI-ARIA) — W3C
• Managing Focus in Components Using aria-activedescendant — ARIA Authoring Practices Guide — W3C
• Actions Menu Button Example Using aria-activedescendant — WAI-ARIA Authoring Practices Guide — W3C.