uioverlaydialogfocus-trapaccessibility

Modal

A modal — also called a dialog — is a temporary surface that appears on top of the page and prevents the user from interacting with anything else until they deal with it. Modals are used for tasks that genuinely can't be ignored: confirming a destructive action, completing a critical form, or viewing a piece of content in full focus.

Explanation

A modal is the strongest interruption pattern in interface design. When one opens, the rest of the page is dimmed and disabled, and the only way out is to either complete the modal's task or explicitly cancel it. That blocking quality is the whole point — it forces a single, focused decision.

Use a modal when the rest of the page genuinely doesn't matter until the user makes a choice. Deleting an account, confirming a payment, or starting a multi-step setup wizard all qualify. Treat modals as expensive: every one is a context switch the user has to pay for, and a stack of unnecessary ones makes an app feel hostile.

Don't reach for a modal when an inline message, a non-blocking notification, or a regular page would do. Newsletter popups, low-priority announcements, and most forms with more than two fields belong somewhere else — the modal pattern is too heavy for content the user could reasonably ignore. Two modals stacked on top of each other is almost always a sign that the flow needs rethinking.

Accessibility concentrates a lot of detail in this pattern. Focus must move into the modal when it opens and back to the trigger when it closes. The Tab key must be trapped — pressing Tab on the last focusable element wraps back to the first inside the modal, never into the page behind it. The Escape key must close it (unless the task forbids cancelling). Screen readers need role='dialog', aria-modal='true', and an aria-labelledby reference to the modal's title so the change of context is announced clearly.

Examples

Mechanics

A bare-minimum modal

Open it, then try clicking outside it, pressing Escape, or pressing Tab — focus stays trapped inside the modal until you close it. Notice the body underneath does not scroll while it is open.

Confirm or cancel

The classic two-button pattern. The primary action is on the right and visually emphasized; the dismiss action is left of it. Either action ends the dialog.

Long content inside the modal

When the modal's content is longer than the viewport, the modal itself becomes the scroll container — the page underneath stays locked. The user gets a single, predictable scroll target.

Common use cases

Destructive confirmation

The canonical reason a modal exists. The action is irreversible, so the user is asked to slow down. The destructive button is styled differently — red here — to make the consequence visible at a glance.

A small focused form

A single-input edit form is exactly the kind of small task a modal handles well. The first input is auto-focused on open, the form submits on Enter, and the user is returned to the page they came from.

No backdrop dismiss, no escape

Sometimes the task must complete one way or another — clicking outside or pressing Escape would be a footgun. This trades user comfort for safety; reserve it for cases like 'accept these terms' or 'complete required setup' where a half-finished state is worse than friction.