When to manage focus in an accessible way

Focus determines where keyboard events go on a page at any given moment. Managing focus is when you need to programmatically move a user’s focus elsewhere on the page in response to something that happened. Google’s Web Fundamentals has an introduction on the topic if you’d like to dive deeper. Think of it like passing a baton in a relay race. The baton represents the focus you need to pass to the next phase of the race, or in your case, the next step in the experience you’ve shaped.

Popular JavaScript frameworks and tools, which need focus management the most, can’t tell you when to manage focus. If you’re a product manager, designer, or engineer, properly managing focus so users know where to go is on you. In this post, you’ll get guidelines to help you know the when and why of focus management.

Why manage focus?

What triggers the need to manage focus could be a user’s input or a prompt from the application itself. For example, a modal dialog alerting the user that their session will end in five minutes or when new content gets inserted on the page because the user tapped a “Continue” button.

To return to our relay race metaphor, if you don’t manage focus properly, you drop the baton and the race ends. Your users who rely on keyboards or screen readers won’t be able to progress as seamlessly through your experience. They’ll be lost.

When to manage focus

Like most accessibility work, knowing when to manage focus lacks one clear answer. It depends on the context of the situation. Instead of exacts, you can look for certain situations that often need more examination when it comes to focus management. Let’s take a look at some of those.

An event should come before a focus shift

As mentioned, you should only move focus when another action initiates it, like the click of a button or alert from the application. Otherwise, it may surprise users and cause confusion. The WCAG (Web Content Accessibility Guidelines) 2.1 specification includes a handful of criteria to help avoid this. Both 3.2.1 On focus and 3.2.2 On input call for no substantial change to the page when interacting with controls in different ways.

When the page title needs to change

If you’re creating a single-page application, a page title change becomes a common use case. Let’s say a user has clicked a sign-up link on your product. They fill out their username and password, then click “Continue” to work on the rest of their profile. Clicking “Continue” fired an action that likely changed the page title. That’s a good clue that you might need to manage focus. This can occur outside of a sign-up flow too, but that’s a more specific example to help you understand the concept.

For example:

• The route/URL of a page changes
• An error occurs, and the user should know about it. Careful here, because you may not need to move focus in all cases.
• When a form submission occurs

When an action takes the user elsewhere on the page

Users often move through experiences by jumping from one interactive thing to another. Any time something happens on the page that requires the user’s attention, you should consider moving focus.

For example:

• A modal popping up
• A mobile menu pops out on the left or right after a user clicks the “Menu” button
• An error summary, which includes a list of multiple errors on the page

When new content gets added or removed

Single-page applications often include components from design systems that perform all kinds of interactions. Many of these come down to adding or removing content from a page. This might mean that focus needs to shift to that new content or somewhere else if it goes away.

For example:

• An off-canvas menu that displays navigation items
• A filter button is clicked, which removes the button that also indicates whether the filter is active
• Clicking an “Add member” button, which displays a panel for adding a person to a family group
• Closing a modal

When an error occurs, initiated by the application or user

You want your users to perceive and understand any errors that occur during their experience. In some cases, but not all, you’ll want to consider moving focus when error messages occur. This often depends on:

• The location of the message. For example, if a message gets added to the top of a page after clicking a “Continue” button at the bottom of the page, it may make sense to move focus. On narrow or small screens, someone might not see the message at the top.
• How the message gets triggered (by a user action, application action, or when a user leaves a field). As mentioned, it’s important not to shift focus unless initiated by the user, otherwise, it may be unexpected. Moving focus after someone’s cursor leaves a field could be a surprise, and it also may violate WCAG rules.

Questions to ask

Being a good designer, engineer, or product manager comes down to asking the right questions. Making the right choices with accessibility is no different. I like to keep these in mind, in addition to the situations outlined previously:

1. If I navigate by keyboard alone, will I get lost if the focus isn’t moved?
2. Could I draw a flow chart with all the points where the user’s focus will be at any given time?

My colleague, Trevor Pierce, has written a good companion post to this one explaining how to manage focus in a React application from a developer’s perspective.

Excellent focus management means that the baton never gets dropped. That only happens with knowledge and a willingness to ask questions.