Modals, Dialogs & Overlays

Interactive example · Modal dialog (focus trap + Esc)Try Tab and Esc

Delete project…

Focus moves into the dialog, is trapped while open, returns to the trigger on close, and Esc dismisses it.

The full lesson

Overlays — modals, dialogs, drawers, tooltips, popovers, toasts — are some of the most overused patterns in product design. Every one of them borrows user attention on purpose, and attention is the scarcest resource in any interface.

Used well, overlays protect users from destructive actions, collect focused input, and show contextual detail without losing page state. Used carelessly, they interrupt critical flows, trap keyboard users, and silently fail screen reader users.

Getting overlays right is not a stylistic choice. It is a usability and accessibility requirement.

The Overlay Hierarchy: Choosing the Right Pattern

Every overlay sits on a spectrum from “takes full focus” to “ambient, non-blocking.” Picking the wrong pattern is the single most common overlay mistake. Before reaching for a modal, run through the hierarchy:

Pattern	Blocks page?	Requires action?	Best for
Modal dialog	Yes	Yes	Destructive confirms, isolated tasks with direct save
Non-modal dialog	No	No	Contextual panels, help drawers
Bottom sheet / drawer	Yes (mobile)	Usually no	Mobile-first overflow content, action menus
Popover	No	No	Contextual detail on trigger element
Tooltip	No	No	Label clarification for icon-only controls
Toast / snackbar	No	No	Brief transient feedback after an action

The test for a modal is simple: does the user need to make a decision or enter data before anything else can happen? If the answer is no, a modal is the wrong choice.

Use a modal for confirming a destructive action (“Delete this workspace?”) or completing a scoped task without leaving the current page (for example, adding a team member while reviewing a project). Use a non-modal drawer for anything that benefits from staying open while the user works with the page below.

Anatomy of a Well-Built Modal Dialog

A modal has four required elements and two optional ones.

Required:

• Backdrop — a semi-transparent overlay behind the dialog. It communicates “something is blocking the page beneath.” It also acts as a click target for dismissal in non-destructive contexts.
• Dialog container — the visible panel. It should have role="dialog", aria-modal="true", and either aria-labelledby pointing to the dialog title or aria-label when no visible title exists.
• Title — identifies the purpose of the dialog for all users. This is not optional from an accessibility standpoint. WCAG 2.2 Success Criterion 4.1.2 (Name, Role, Value) requires interactive UI components to have an accessible name.
• Close control — a clearly labeled button that dismisses the dialog and returns focus to the trigger element that opened it.

Optional but commonly needed:

• Explicit action buttons — a primary action (“Confirm”, “Save”, “Delete”) and a secondary cancel. The label on the primary action should reflect the consequence, not use a generic word.
• Scrollable content area — when modal content is taller than the viewport, only the content region scrolls. The title and action bar stay fixed and visible.

Focus Management: The Technical Core

Focus management is where most modal implementations fail silently. These rules are WCAG 2.2 requirements, not optional polish.

On open: Move focus to the first focusable element inside the dialog — ideally the dialog itself or its title, not the first input (moving focus to an input triggers validation prematurely). If the dialog has a single destructive primary action, focus the less-destructive option by default to prevent accidental confirms.

While open: Focus must stay trapped inside the dialog. Tab and Shift+Tab should cycle only through focusable elements inside the modal container. The modern way to enforce this is the HTML inert attribute applied to the rest of the document:

<main inert>...</main>
<aside inert>...</aside>
<dialog open aria-modal="true" aria-labelledby="dialog-title">
  <h2 id="dialog-title">Confirm deletion</h2>
  <!-- content -->
</dialog>

Setting inert on non-dialog containers removes those elements from the tab order and from the accessibility tree at the same time. No JavaScript focus-trap loop required. This is cleaner and more robust than the old approach of manually managing tabindex values or intercepting keydown events.

On close: Return focus to the exact element that triggered the modal. This is the most consistently broken behavior in production. Users who navigate by keyboard expect to land back where they were. A focus drop to the top of the document is disorienting and is a WCAG 2.2 criterion 2.4.3 (Focus Order) failure.

Escape key: Always dismisses the modal, unless the action cannot be undone and requires explicit confirmation. This is a long-established convention that users rely on.

WCAG 2.2 Specifics for Overlay Patterns

WCAG 2.2 added several criteria that directly affect overlays.

2.4.11 Focus Not Obscured (Minimum): The focused element must not be entirely hidden behind a sticky header, cookie banner, or another overlay. This matters especially when a dialog opens and a persistent notification banner partially covers the focused element. Make sure z-index layering and scroll behavior bring the focused element fully into view.

2.4.12 Focus Not Obscured (Enhanced): No part of the focused element is obscured. This is the AA+ tier — treat it as a design quality signal even if only AA is required.

2.5.8 Target Size: Interactive elements inside a dialog (close button, action buttons, checkboxes) must meet the 24x24px minimum touch target. Dialog close buttons styled as small ”×” icons are a frequent violation. The icon may be 14px, but the clickable area must be at least 24x24px — enforced with padding or a minimum-size declaration.

3.2.5 Change on Request: A dialog must not open unless a user triggers it explicitly. Auto-opening modals on page load, on a timer, or on scroll depth are non-compliant at AA+ and are strongly discouraged at all levels.

The native HTML dialog element is now the recommended implementation base in 2026. Browsers handle showModal() and close() with built-in focus management that aligns with WCAG requirements. The native ::backdrop pseudo-element replaces a manually positioned overlay div. Polyfill coverage for the dialog element is no longer a concern for evergreen browser targets.

Drawer and Bottom Sheet Patterns

Drawers (panels that slide in from a screen edge) and bottom sheets (panels that slide up from the viewport bottom) are non-modal by default in most design systems. They can be made modal when the task warrants it.

Non-modal drawers work well for persistent utility panels: filter sidebars, detail inspection panels, help and documentation surfaces. They must not steal focus on open — the user should be able to keep interacting with the page beneath. The drawer should include a visible close button and close on Escape, but focus stays in the main content.

Modal bottom sheets on mobile work identically to modal dialogs from an accessibility standpoint — apply inert to the rest of the page, trap focus, and dismiss on Escape. The main UX advantage over a full-screen modal on mobile is that the visual context of the page below stays partially visible. That reduces the user’s cognitive overhead in understanding what the sheet is about.

Dismissing by swiping down is a convenient gesture, but it must never be the only dismissal path. Always include a visible close button for users who cannot use touch gestures.

Toast and Notification Overlays

Toasts and snackbars sit at the opposite end of the interruption spectrum. They appear briefly, do not steal focus, and disappear on their own. This makes them appropriate only for transient, non-critical feedback about completed actions: “Message sent”, “File saved”, “Link copied.”

Critical rules for toasts:

• Auto-dismiss duration should be at least 5 seconds for short messages, and longer for messages the user might want to read. WCAG Success Criterion 2.2.1 (Timing Adjustable) applies when the disappearance affects the user’s ability to perceive or act on information.
• Use role="status" (or role="alert" for errors) so screen readers announce the message without moving focus.
• If the toast contains an action (an Undo button, a link), the auto-dismiss must pause on focus or hover so keyboard users can reach the action before the toast disappears.
• Toasts should never be the sole delivery mechanism for error messages. If an action failed, surface the error in context — near the trigger, in a form field, in a persistent alert region — not only in a transient toast that vanishes.

Motion, Animation, and Visual Design

Overlay animations should serve orientation, not decoration. A modal that scales from the trigger element gives the user a spatial model of where it came from and where focus went. A drawer that slides in from the right communicates that it is a lateral detail panel. An exit animation that reverses the entry reinforces the return to context.

Modern overlay motion practice:

• Use spring-based easing for enter/exit transitions — not linear, not ease-in-out with a fixed duration. transition: transform 250ms cubic-bezier(0.2, 0, 0, 1) (approximately a decelerate curve) is a reasonable CSS default.
• Animate only transform and opacity. These run on the compositor thread and do not trigger layout recalculation. Never animate width, height, top, or left on an overlay.
• Respect prefers-reduced-motion. Users who have set this preference experience motion as a health issue, not a stylistic preference. The correct implementation is either no animation or an instantaneous cut:

@media (prefers-reduced-motion: reduce) {
  .dialog {
    transition: none;
  }
}

For the backdrop, a simple opacity fade from 0 to 0.5 in 150ms is enough. The backdrop does not need a spring — its job is utilitarian.

Elevation in the overlay stack should be communicated through luminance contrast, not drop shadows. On dark surfaces, drop shadows are invisible and the overlay reads as flat. The modern approach is a slightly lighter background surface for the dialog — a luminance step up from the page background — derived from a semantic elevation token rather than a hardcoded color value.

Stacking and Z-Index Architecture

When multiple overlay types coexist — a dialog opened from a dropdown, a toast fired by an action inside the dialog — you need a deliberate z-index system. Escalating arbitrary values is the common failure pattern.

A stable layering model:

Layer	Z-index	Contents
Base	0	Page content
Sticky UI	100	Sticky headers, fixed footers
Dropdowns / popovers	200	Contextual overlays anchored to a trigger
Drawers	300	Side panels, bottom sheets
Modals / dialogs	400	Blocking dialogs and their backdrops
Toasts / notifications	500	Always-on-top feedback
Critical system alerts	600	Forced updates, auth session expiry

Encode these as design tokens (--z-index-modal: 400) and reference them in component code. This makes the stacking order auditable and prevents the creeping escalation that produces z-index: 99999 in production codebases.

When a modal contains a dropdown or popover, the child popover must render outside the modal container in the DOM — using a portal pattern — at the same z-index layer as other popovers, or higher than the modal backdrop. Positioning a popover as a DOM child of the modal and expecting z-index to work relative to the modal’s stacking context is a reliable source of clipping bugs.