Focus Restoration

When a transient UI component closes, keyboard focus should usually return to the element that launched it or to another predictable, logical target. This preserves keyboard continuity and prevents users from unexpectedly losing their place in the interface.

Focus restoration is the practice of deliberately returning keyboard focus after an interaction temporarily moves it elsewhere. Common examples include dialogs, popovers, menus, and other transient components that take focus while open.

For a modal dialog, the usual pattern is to remember the invoking element, move focus into the dialog when it opens, and restore focus to the invoker when it closes. The invoker may no longer be usable, so restoration should fall back to a sensible element when necessary.

In component-based applications, focus restoration is part of the component's interaction lifecycle rather than merely a visual concern. The implementation should account for unmounting, conditional rendering, nested interactions, and cases where the original target disappears.

A robust implementation also avoids stealing focus unnecessarily. Programmatic focus changes should have a clear accessibility purpose, and the resulting focus position should make sense to keyboard and assistive-technology users.

Key points

• Save the invoking element before moving focus.
• Move focus into a modal or other focus-managed component when appropriate.
• Restore focus to the invoker when the transient component closes.
• Provide a logical fallback if the original element was removed or disabled.
• Do not move focus programmatically without an interaction-related reason.

Interview questions

Why is focus restoration important for keyboard accessibility?

A keyboard user needs to know where they are after a transient interaction closes. If focus disappears or jumps to an unrelated location, they may have to navigate through the page again. Returning focus to the initiating control usually preserves the user's position and interaction context.

How would you implement focus restoration for a modal dialog?

Before opening the dialog, I would save the currently focused element, typically the control that initiated the interaction. When the dialog opens, I would move focus to an appropriate element inside it and manage focus while it is active. When it closes, I would restore focus to the saved element if it is still available; otherwise I would choose a logical fallback.

What can go wrong if the original focus target is unmounted?

The saved element may no longer be connected to the document, so calling focus on it cannot provide the intended user experience. The component should check that the target is still valid before restoring focus. If it is gone, focus should move to a nearby logical control or another appropriate destination based on the interaction.

How does focus restoration differ from focus trapping?

Focus trapping controls where focus can move while a modal interaction is active, preventing keyboard users from escaping the active modal unintentionally. Focus restoration addresses what happens after that interaction ends. A well-designed modal often needs both behaviors, but they solve different lifecycle problems.

When should an application avoid programmatically moving focus?

Focus should not be moved simply to make a visual state change appear complete. Unnecessary focus changes can interrupt keyboard navigation and create confusing experiences for assistive-technology users. Programmatic focus is appropriate when the interaction changes the user's active context and the intended focus destination is clear, such as entering or leaving a modal workflow.