None of React's dynamic UI changes — a modal opening, closing, or a route change — move keyboard focus automatically. This lesson covers moving focus into new content, trapping it inside open modals, returning it to the trigger on close, and redirecting it on route changes.
1Where Did the Keyboard Focus Go?
Opening a modal should move focus into it; closing it should return focus to whatever triggered it; navigating to a new page should move focus to the new content. None of this happens automatically in a client-rendered React app — it must be explicitly managed.
2Moving Focus When a Modal Opens
When a modal opens, calling .focus() on its first focusable element or its own container (given tabIndex={-1}) inside a useEffect running on mount ensures a keyboard user's focus moves into the newly visible content, rather than remaining stuck on whatever is now hidden behind it.
3Focus Trapping Inside a Modal
Once a modal is open, Tab should cycle only through elements inside it, never escaping into the visually hidden page behind it — a pattern called a focus trap. Libraries like focus-trap-react implement this correctly, handling edge cases that are easy to get wrong when hand-rolled.
4Returning Focus When Something Closes
When a modal closes, focus should return to the element that originally opened it, not reset to the top of the page or disappear entirely. Saving a reference to the trigger element before opening, and calling .focus() on it in the close handler, achieves this.
5Focus on Route Change
Client-side routing doesn't reload the browser, so focus silently remains wherever it was on the previous page, disconnected from the new content. Moving focus to the new page's main heading on every route change keeps navigation coherent for keyboard and screen reader users.
6Step-by-Step Breakdown
Where Did the Keyboard Focus Go?. Open a modal, and browser focus should move INTO it. Close it, and focus should return to whatever triggered it — usually the button that opened it. Route to a new page, and focus should move to the new page's heading. None of this happens automatically in a client-rendered React app; you have to manage it.
Moving Focus When a Modal Opens. When a modal opens, call .focus() on its first focusable element (or the modal container itself, if given tabIndex={-1}) inside a useEffect that runs when it mounts — without this, a keyboard user's focus stays stuck on whatever was behind the now-visually-covering modal.
Without explicit focus management, where does a keyboard user's focus remain after a modal visually opens on top of the page?
- →It stays on whatever element it was on before, now hidden behind the modal
- →React automatically moves it into the newly visible modal content
Focus Trapping Inside a Modal. Once a modal is open, Tab should cycle only through elements INSIDE it — a keyboard user should never be able to Tab past the modal into the (visually hidden) page behind it. This is called a 'focus trap', and libraries like focus-trap-react implement it correctly so you don't have to build the edge cases yourself.
Returning Focus When Something Closes. When a modal closes, focus should return to the element that opened it — not reset to the top of the page, and not stay lost in limbo. Save a ref to the trigger element before opening, and call .focus() on it in the modal's close handler.
When a modal closes, where should keyboard focus move to?
- →Back to the element that originally opened the modal
- →Automatically to the very top of the page's <body>
Focus on Route Change. In a client-rendered single-page app, navigating to a new page doesn't reload the browser, so focus silently stays wherever it was on the old page — completely disconnected from the new content. Move focus to the new page's main heading (or a skip-target) on every route change to keep navigation coherent.
Mastery Achieved. You now understand focus management: moving focus into new UI as it appears, trapping focus inside open modals, returning focus to the trigger element on close, and redirecting focus on client-side route changes. This closes out React Accessibility — next, you'll move into React Security.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1A Focused Element Needs a tabIndex to Receive Programmatic Focus
Calling .focus() on a non-interactive element like a <div> or <h1> only works if it has a tabIndex attribute (typically tabIndex={-1} to allow programmatic focus without adding it to the natural tab order).
SEO Implications
- 1
Focus Management Is a Client-Side Interaction Concern
This governs keyboard/assistive technology behavior after hydration and has no bearing on server-rendered content or crawlability.
Best Practices
Always Pair Focus Trapping with a Working Escape-to-Close
Trapping focus inside a modal makes an Escape key handler even more essential, since it may be the only convenient way for a keyboard user to exit the trapped context.
Use tabIndex={-1} for Programmatically-Focused, Non-Interactive Elements
A heading or modal container that needs to receive focus via .focus() but shouldn't be part of the normal tab order should use tabIndex={-1}, not tabIndex={0}.
Frequent Bugs
After closing a modal, keyboard focus is lost, and the next Tab press starts from the top of the page.
Save a reference to the element that had focus before the modal opened (e.g. document.activeElement), and call .focus() on it in the modal's close handler.
Navigating between pages in a single-page app leaves a screen reader user disoriented, with no indication anything changed.
Move focus to the new page's main heading (or a dedicated live region announcing the navigation) inside a useEffect that runs when the route changes.
Real-World Examples
A Fully Focus-Managed Confirmation Modal
A 'Delete Account' confirmation modal needed complete focus handling: focus moves to the modal's heading when it opens, Tab is trapped within the modal's buttons while open, Escape closes it, and focus returns to the 'Delete Account' button that originally opened it once closed — giving keyboard users a fully coherent, predictable experience.
function ConfirmModal({ isOpen, onClose, triggerRef }) {
const headingRef = useRef(null);
useEffect(() => {
if (isOpen) headingRef.current?.focus();
}, [isOpen]);
function handleClose() {
onClose();
triggerRef.current?.focus();
}
return isOpen ? (
<FocusTrap active={isOpen}>
<div role="dialog" aria-labelledby="confirm-heading">
<h2 id="confirm-heading" tabIndex={-1} ref={headingRef}>Delete Account?</h2>
<button onClick={handleClose}>Cancel</button>
</div>
</FocusTrap>
) : null;
}