Accessible modal dialogs (focus trap + Escape)

A short, practical UI accessibility note for games and web UIs. No tracking.

Try the micro-demo: modal-demo.html

It compares a modal dialog where focus can escape into background controls (BEFORE) with a focus-trapped modal that supports Escape and restores focus (AFTER).

What goes wrong in many modals

A modal dialog is supposed to be a temporary “mode” where the user must finish a decision (or dismiss it) before interacting with the rest of the UI.

Common failure mode: the modal looks like it blocks the background, but keyboard focus can still move to background links/buttons when the user presses Tab.

Why it matters

Keyboard users: focus escaping makes the UI confusing — you can “interact with” things you can’t see.
Screen readers: if focus can leave the dialog, the user may lose context or miss that a dialog is open.
Game menus: an inventory/settings overlay that doesn’t trap focus can make navigation feel broken.

A safe pattern (minimal version)

Move focus into the modal when it opens (to a heading, close button, or first control).
Trap focus so Tab and Shift+Tab cycle within the dialog.
Support Escape to close the dialog (unless there’s a strong reason not to).
Restore focus to the opener when the dialog closes.
Hide or inert the background while the modal is open (e.g., aria-hidden or inert), so assistive tech isn’t pulled into the wrong region.

The goal isn’t extra ceremony — it’s to make “open modal” a reliable mode switch for everyone.