ui patterns
Modal dialog
What is a modal dialog?
A modal dialog blocks interaction with the page behind it while open. Focus should enter the modal, stay within its controls, and return to the trigger when it closes. Some modals ask for a decision; others just present information or a short task. It becomes a keyboard trap only when there’s no reliable way to complete or dismiss it - not because focus is contained.
Also known as: modal, dialog box, lightbox
Prefer to watch?
Watch the recap 0:37
The demo
Click "open dialog", then drive it with the keyboard - Tab to move, Esc to close. In broken mode, Tab escapes to the link behind and Esc is ignored; in accessible mode, focus stays put and comes back when you close.
Click "open dialog" to begin.
Background content. A link behind the dialog - in broken mode, Tab can still reach this while the dialog is open.
What this demo shows (text version)
An "open dialog" button and a link sitting in the background. Opening the dialog shows a small window with a text field, a cancel button, a confirm button and a close control, over a dimmed page.
In accessible mode, opening the dialog moves focus into it, the Tab key cycles only through the dialog's controls, Escape closes it, and focus returns to the "open dialog" button. In broken mode, focus never enters the dialog, Tab can reach the background link while the dialog is still open, and Escape does nothing - so a keyboard user can be stranded or lose the dialog completely. A running line reports what focus is doing throughout.
A modal blocks interaction with the page behind it. Done well, focus moves in, stays within its controls, and returns to the trigger on close, with a reliable way out (a close button and Escape). Containing focus is correct - the bug is when a keyboard user can’t reach a control or can’t dismiss it. And not every modal needs a decision; some just show information or a temporary task.
In the broken dialog, Tab leaked out to the page behind and Escape did nothing - so a keyboard user could lose the dialog, or get stranded in it. The accessible one kept focus inside, closed on Escape, and handed focus back to the button you came from. Same window; completely different experience depending on who is at the keyboard.
A modal makes three promises to the keyboard: focus moves into it on open, focus is trapped inside while it is open (Tab cycles, it never reaches the page behind), and focus returns to the trigger on close. Escape must close it, and the markup needs role="dialog" with aria-modal="true". Miss any of these and sighted mouse users may never notice, while keyboard and screen-reader users are stuck.
My rule: reach for a modal only when the decision genuinely cannot wait. Every modal interrupts, steals focus and hides context; that is the cost. If the content could live on the page, or in a non-blocking panel, it usually should - a dialog you can't dismiss with Escape is a small prison.
Try the modal dialog demo on this page to see focus flow and dismissal in action. Not every ux dialog needs a decision - some just show info or a short task, and that’s perfectly fine.
Try the modal dialog demo to see focus flow and dismissal in action - it’s the best way to understand ux dialog behaviour. Not every ux dialog asks for a decision; some just show info or let you complete a short task - the demo lets you test both types.
A modal dialogue blocks interaction with the page behind it - try the live demo to see how focus moves in and out correctly. Not every modal needs a decision; some just show info or a short task - and they must still offer a reliable way to close.
A modal dialogue blocks interaction behind it and traps focus - but only if there’s no reliable way out, like a close button or Escape. Try the interactive modal dialogue demo here to see focus flow, dismissal, and keyboard accessibility in action.