E4.10.2modal focus trap and restoredesignresearch

A modal must trap focus and restore it on close

Aliases: focus trap · focus restoration · inert background

What it is

Once a modal is open, keyboard and assistive-tech focus must stay inside the dialog; Tab must not reach the locked main surface behind it. On close, focus must return to the control that opened it. That is focus trap and restore. It is about who receives input, not about whether to use a modal, and not about which key dismisses it. Without a trap, a visually locked surface can still be read and changed. Without restore, close dumps the user at the top of the document or on an unrelated control.

Why it happens

Focus is the only door for input. The main surface looks locked under a modal; if those nodes remain in the focus order, keyboard users type and activate controls they can neither see nor tap, and a screen reader concatenates two documents into one. The trap cycles focus among the dialog’s interactive nodes, and on open moves to the first sensible control inside (not, unprompted, to Close, skipping the question). If close does not restore, focus follows document order to the start of the page, spatial memory (“I was on the third card”) is torn, and a top-bar control may fire by accident. Restore should target the trigger; if the trigger has unmounted, land on a logical substitute (the neighbour of a deleted row), not on the document body. Trapping is not pinning focus to one control: Tab must still cycle inside the dialog.

Studying it

Walk the sequence with keyboard and a screen reader: focus before open, whether Tab leaves the dialog after open, landing place after close. Independent variables: how it opened (button versus auto-pop), number of controls inside, whether the trigger still exists after close. Dependent variables: escape-from-trap counts, whether close lands on the trigger, whether speech reads the layer below. Auto-pop with no trigger needs a restore policy specified up front, or tests will show a random landing.

Where it stops holding

Touch users do not Tab, so the trap is almost invisible to them until a screen reader is on. A non-modal panel must not trap, or parallel work is broken by focus policy. If nesting happens (it should not), the inner dialog must trap to itself, the outer must not take focus while the inner exists, and closing the inner restores to the outer, not to the main surface. Platform system dialogs trap by default; custom-drawn modals often forget, and must not assume the system behaviour is already in place.

Applying it

  • On open, move focus into the dialog and cycle among its interactive nodes; take lower-layer nodes out of the order or mark them unreachable.
  • On close, return focus to the trigger; if it is gone, return to a pre-agreed substitute.
  • Do not focus a destructive button by default on open.
  • How to check: keyboard only — open, Tab a full cycle inside, close. Focus must never appear on the layer below, and after close it must be back on the original button.

Related

  • Within the group: E4.10.1 A modal blocks the main flow and belongs only on matters that must be answered · E4.10.3 A modal should not open another modal · E4.10.4 A modal must offer a keyboard-reachable way to close
  • Adjacent: E2.22 Autofocus and focus stealing · E4.16 Overlay stacking and escape
  • Search terms: focus trap · focus restoration · inert background

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E4.10.2