Focus Management: Trapping and Restoring Focus

The plain-language idea

When a dialog, modal, or any overlay opens on top of page content, keyboard focus needs active management — the browser won't do the right thing on its own. Three things have to happen, in order, across the dialog's full lifecycle:

• Move focus in, on open. The moment the dialog appears, focus should move to something inside it — usually its first focusable element or its own heading. Without this, focus stays wherever it was on the page underneath, and the very next Tab press lands on whatever was next in that background page's tab order — content that's now visually hidden behind an overlay the user can't even see.
• Trap focus, for the duration. While the dialog is open, Tab and Shift+Tab should cycle only through the dialog's own focusable elements — never escape into the page behind it. This is a focus trap: the boundary elements wrap around instead of letting focus leave. Content behind the overlay is supposed to be inert for as long as the dialog is open, and a focus trap is what makes that actually true for keyboard users, not just visually true for sighted mouse users.
• Restore focus, on close. When the dialog closes, focus should return to the exact element that opened it — not to <body>, not to the top of the page. This is the detail most home-rolled implementations miss. A keyboard user who opened a dialog from a specific row in a table, or a specific item in a list, expects to resume exactly there when they close it — not lose their place and have to re-navigate the whole page to find it again.

See it in a real thing: the full open → trap → close lifecycle

let previouslyFocused;

function openDialog(dialog, trigger) {
  previouslyFocused = trigger; // remember who opened it

  dialog.hidden = false;
  const first = dialog.querySelector("[tabindex], button, input, a[href]");
  first?.focus(); // move focus IN

  dialog.addEventListener("keydown", trapTabKey);
}

function closeDialog(dialog) {
  dialog.hidden = true;
  dialog.removeEventListener("keydown", trapTabKey);
  previouslyFocused?.focus(); // restore focus to the trigger, not <body>
}

function trapTabKey(e) {
  if (e.key !== "Tab") return;
  const focusable = [...dialog.querySelectorAll("[tabindex], button, input, a[href]")];
  const [first, last] = [focusable[0], focusable[focusable.length - 1]];

  if (e.shiftKey && document.activeElement === first) {
    e.preventDefault();
    last.focus(); // wrap backward
  } else if (!e.shiftKey && document.activeElement === last) {
    e.preventDefault();
    first.focus(); // wrap forward
  }
}

Each of the three lifecycle moments has exactly one line doing the real work: first?.focus() on open, the wrap-around logic inside trapTabKey for the duration, and previouslyFocused?.focus() on close. Drop any one of them and the dialog still looks correct to a mouse user — the bug only shows up for someone navigating by keyboard alone.

What people usually miss

Watch out

• Restoring focus to the trigger, specifically, is the part most implementations skip. Moving focus in and trapping it are the two behaviors people remember to build; resetting focus to <body> or just leaving it wherever the dialog's close button happened to be is a common, incomplete substitute.
• A focus trap needs to handle both directions. Shift+Tab from the first element should wrap to the last, and Tab from the last should wrap to the first — a trap that only catches one direction still lets focus leak out the other way.
• "Trapped" content still needs to be inert, not just visually hidden. An element behind the overlay that's still in the DOM and still focusable can be reached by focus-trap code that isn't thorough, even if it's covered by a backdrop and invisible.
• The trigger reference has to survive the dialog's own lifecycle. If the trigger element gets unmounted or replaced while the dialog is open (common in frameworks that re-render lists), the saved reference can go stale — worth checking for, not assuming away.

Why this matters in interviews

"Walk me through what happens to keyboard focus when this modal opens and closes" is a specific, common diagnostic question, and a strong answer names all three lifecycle moments — move in, trap, restore — by name, not just "make sure focus works."