Restoring Focus After Closing Complex Modals

Q: Should I use a timeout or requestAnimationFrame to delay focus restoration?

requestAnimationFrame is the correct primitive: it fires after the browser has painted the next frame, giving the framework time to finish unmounting without introducing an arbitrary millisecond delay. A hard setTimeout is fragile because the correct duration varies with device speed and framework batching strategy.

Focus restoration is the sub-pattern that returns document.activeElement to the element that opened a dialog once it is dismissed — preventing the single most common keyboard-navigation failure in data-rich single-page applications: the user’s position in the interface disappearing entirely after a modal closes.

Without it, screen reader users must re-orient from the top of the document, and keyboard-only users lose their place in dense data grids. WCAG 2.2 Success Criterion 2.4.3 (Focus Order, Level A) and 3.2.2 (On Input, Level A) both apply: focus must move in a predictable sequence, and closing a component must not cause an unexpected context shift.

Spec Reference

Source	Requirement
WCAG 2.2 SC 2.4.3 Focus Order (Level A)	Focus must move in an order that preserves meaning and operability.
WCAG 2.2 SC 2.4.11 Focus Not Obscured (Level AA)	When focus returns to the trigger, it must be fully visible and not hidden behind other content.
ARIA Authoring Practices Guide — Dialog Pattern	“When the dialog closes, focus must return to the element that invoked it.”
HTML Living Standard — `inert` attribute	Elements with `inert` cannot receive focus; must be removed before focus restoration.

The ARIA APG dialog pattern is the normative source for this requirement. It is not an advisory best practice — every dialog implementation that traps focus while open must return focus on close.

The Capture-Validate-Restore Lifecycle

The core pattern is three deterministic steps: capture the trigger before the modal opens, validate the reference before restoring, and restore focus inside a deferred callback.

When to Use vs. When Not To Use

Use this pattern when:

A role="dialog" or role="alertdialog" overlay is closed by any mechanism: Escape key, a close button, backdrop click, or programmatic state change.
A drawer, side panel, or popover that traps focus is dismissed.
A multi-step wizard or confirmation sheet is completed or cancelled.

Do not apply raw .focus() calls without the validate step when:

You assume the trigger still exists — virtualized rows and conditionally rendered components routinely disappear between the open and close events.
The modal closes as a result of a route navigation — the trigger will often be in a component that has already unmounted. Use a route-change callback to defer restoration until the new layout is mounted.
The trigger was a menu item that is now hidden — focus the menu’s toggle button instead.

Common misapplication: calling triggerEl.focus() in the same synchronous event handler that unmounts the modal. The element ceases to exist before the call executes.

Annotated Code Example

// WCAG 2.4.3 Focus Order — capture, validate, restore lifecycle
function useModalFocusManager() {
  const triggerRef = useRef<HTMLElement | null>(null);

  const openModal = useCallback(() => {
    // Step 1 — Capture: record the element with focus right now
    // Satisfies ARIA APG dialog pattern "remember invoking element"
    triggerRef.current = document.activeElement as HTMLElement;
  }, []);

  const closeModal = useCallback(() => {
    // Step 2 — defer until after the framework unmounts the modal
    // (synchronous .focus() would target a node that no longer exists)
    requestAnimationFrame(() => {
      const target = triggerRef.current;

      // Step 3 — Validate before restoring (WCAG 2.4.3)
      const isAttached = target && document.body.contains(target);
      const isFocusable =
        isAttached &&
        !target.hasAttribute('disabled') &&
        !target.closest('[inert]') && // inert ancestors block focus
        typeof target.focus === 'function';

      if (isFocusable) {
        // preventScroll avoids jarring viewport jumps (UX improvement)
        target.focus({ preventScroll: true });
      } else {
        // Fallback — focus the nearest landmark or grid root
        fallbackFocus();
      }

      triggerRef.current = null; // clean up reference
    });
  }, []);

  return { openModal, closeModal };
}

// Fallback strategy when the original trigger is gone
function fallbackFocus() {
  // Query a stable landmark — adjust selector to your layout
  const fallback =
    document.querySelector<HTMLElement>('[data-grid-root] [tabindex="0"]') ??
    document.querySelector<HTMLElement>('main h1') ??
    document.querySelector<HTMLElement>('main');

  fallback?.focus({ preventScroll: true });
}

Keyboard & AT Behaviour

Key / Event	Expected browser behaviour	Screen reader announcement	Failure indicator
`Escape`	Modal unmounts; focus returns to trigger	Screen reader reads the trigger’s label (e.g. “Edit row 4, button”)	Screen reader says “document” or goes silent
Close button (`Enter` / `Space`)	Same as Escape	Same as Escape	Focus moves to `<body>` or address bar
Backdrop click	Same as Escape (if implemented)	Same as Escape	No announcement; user must Tab to find active element
Route navigation away	Modal closes; focus deferred to new route’s primary heading or landmark	New page’s H1 or landmark announced	Old route’s trigger announced (element still briefly in DOM)

NVDA deviation: NVDA with Firefox may announce the trigger twice if a polite aria-live region fires at the same moment as the focus move. Sequence the live region update 50–100 ms before the focus call to avoid collision (see the sequencing example below).

JAWS deviation: JAWS 2024 on Chrome reads the trigger correctly in virtual cursor mode only if role="dialog" is removed from the DOM before .focus() fires. If the dialog element remains in the DOM with hidden applied, JAWS may not exit virtual mode. Remove the dialog node or set display:none before restoring focus.

Integration Context

This pattern lives inside the broader keyboard focus trapping & navigation lifecycle. Focus trapping keeps users inside the dialog while it is open; focus restoration returns them to their prior location when it closes. Neither is optional — omitting restoration renders the trapping useless for real workflows.

When modals surface data from aria-live regions for dynamic data, the live region must be cleared of modal-specific announcements before the focus move, otherwise the AT will read stale content over the restored trigger’s label.

In single-page applications, focus management intersects with focus management in single-page apps at route boundaries. Modal close events that trigger a navigation must defer focus restoration to a useEffect or onMounted hook in the incoming route, not the outgoing component’s cleanup.

Focus movement and live region announcements must be strictly sequenced to prevent auditory collisions — two simultaneous state changes that cause the AT to drop one of them.

// WCAG 2.4.3 + 4.1.3 — sequence live region before focus move
function closeFocusAwareModal(announcer, trigger) {
  // 1. Polite live region first — gives AT time to queue the announcement
  // aria-live="polite" (not assertive) avoids interrupting in-progress speech
  announcer.textContent = 'Filter dialog closed.';

  // 2. Focus restoration deferred one frame — browser yields to AT between frames
  requestAnimationFrame(() => {
    if (trigger && document.body.contains(trigger)) {
      trigger.focus({ preventScroll: true }); // WCAG 2.4.3
    }

    // 3. Clear the live region after AT has processed it
    // Prevents stale announcement on next open (live region flooding risk)
    setTimeout(() => {
      announcer.textContent = '';
    }, 500);
  });
}

Use aria-live="polite", not aria-live="assertive", during dismissal. Assertive regions interrupt any in-progress speech and can cause the AT to skip announcing the trigger label entirely.

Gotchas

1. Virtualized grid rows recycle the trigger element

Virtualized lists (React Window, TanStack Virtual) reuse DOM nodes as the user scrolls. When the modal opens on row 40 and the grid scrolls during the modal’s lifetime, the stored triggerRef may now point to a recycled node that renders row 12. The element is in the DOM and passes body.contains(), but focusing it moves the user to the wrong row.

Fix: Store the row index and column key alongside the element reference. On restore, scroll the virtual list to the correct row, wait for the DOM update with await nextTick() or a MutationObserver, then query the rendered cell by its data attributes.

2. The `inert` attribute on the background silently blocks focus restoration

When the modal opens, you may apply inert to the page background to prevent interaction. If inert is not removed before the close-and-restore sequence runs, trigger.focus() will silently fail — the element is in the DOM and not disabled, but inert prevents it from receiving focus.

Fix: Remove the inert attribute from background containers synchronously in the close handler, before queuing the requestAnimationFrame callback.

// Remove inert BEFORE deferring focus restoration
function closeModal(backgroundEl, trigger) {
  backgroundEl.removeAttribute('inert'); // must happen synchronously
  requestAnimationFrame(() => {
    trigger?.focus({ preventScroll: true });
  });
}

3. Nested dialogs lose the original trigger reference

When dialog A opens dialog B, closing B should restore focus to whichever element inside A had focus before B opened — not to the trigger that opened A. A single triggerRef only stores the most recent capture and will point to A’s trigger, not B’s.

Fix: Use a stack (array) of trigger references rather than a single ref. Each modal open pushes the current document.activeElement; each close pops and restores.

const triggerStack = useRef<HTMLElement[]>([]);

function openModal() {
  triggerStack.current.push(document.activeElement as HTMLElement);
}

function closeModal() {
  const target = triggerStack.current.pop();
  requestAnimationFrame(() => {
    if (target && document.body.contains(target)) {
      target.focus({ preventScroll: true });
    }
  });
}

FAQ

Why does focus jump to the body or browser chrome after closing a modal?

Frameworks unmount the modal’s DOM subtree during the same synchronous render cycle that processes the close event. If .focus() is called before the unmount completes, the target element no longer exists and the browser falls back to document.body or, in some browsers, the address bar. Wrapping the focus call in requestAnimationFrame defers it until after the framework has flushed DOM changes.

Should I use a timeout or requestAnimationFrame to delay focus restoration?

requestAnimationFrame is the correct primitive: it fires after the browser has painted the next frame, giving the framework time to finish unmounting without introducing an arbitrary millisecond delay. A hard setTimeout is fragile because the correct duration varies with device speed and framework batching strategy. The one exception is NVDA/Firefox live region collision — a short setTimeout of 50–100 ms before the focus call prevents the AT from dropping the trigger label announcement.

What fallback should I use when the original trigger element has been removed from the DOM?

Walk up the stored trigger’s known ancestor using a stable selector — for example the data grid’s toolbar or the first interactive cell in the row the trigger belonged to. In virtualized grids, store both the element reference and its positional context (row index, column key) so you can derive a fallback query if the element has been recycled. As a last resort, focus the primary <main> landmark or the page’s first focusable element — never leave focus on document.body without an explicit tabindex="0" and a visible focus ring.

Keyboard Focus Trapping & Navigation — the parent cluster covering focus trapping patterns inside open dialogs
Focus Management in Single-Page Apps — route-change focus management and roving tabindex in data grids
Choosing Between Polite and Assertive aria-live Regions — live region politeness levels for modal closure announcements

← Back to Keyboard Focus Trapping & Navigation