The modal dialog is the most overused interaction pattern on the modern web. It started as a way to focus attention on a critical, non-dismissable decision. It has become the default response to every product question, from "should we collect this email address" to "did you read our cookie policy" to "do you want to subscribe to our newsletter just thirty seconds after landing on the page."
The result is interfaces that fight the user. Modals stack on top of modals. Background tasks vanish. Form data is lost. The back button does the wrong thing. The escape key sometimes works, sometimes does not. Screen reader users get stranded in dialog regions they cannot escape.
This guide walks through how to design modal dialogs and overlays that respect the user's attention, do not destroy work in progress, stay accessible, and degrade gracefully on mobile. It covers when to use a modal at all, the technical requirements every modal must meet, the behavioral patterns that decide whether the modal feels respectful or hostile, and the alternatives that are usually a better choice.
Photo by Jesus Rivera on Pexels
When a Modal Is Actually the Right Pattern
Before the technical and behavioral discussion, the harder question is whether a modal should appear at all. The default answer should be no. A modal is the right pattern in a small number of cases:
Confirming a destructive action. "Are you sure you want to delete this account" is a legitimate modal because the action is irreversible and the user needs to make a deliberate choice.
Capturing a focused decision the rest of the interface cannot proceed without. A payment confirmation step, a contract signature, a critical safety acknowledgment. The interface genuinely cannot continue until the user decides.
Showing content that needs its own scoped scroll. An image lightbox where the user is examining detail. A video player in fullscreen-like mode. A help article that the user wants to read without losing their place in the underlying app.
Outside these cases, a modal is almost always the wrong pattern. A side panel, a toast, an inline expansion, a separate page route, or a non-modal flyout will usually serve the user better.
A few examples of modals that almost always should not exist:
- Email collection on first page load
- Cookie banners (these are notices, not decisions; design them as banners)
- Tour or feature announcement overlays that block content the user came to read
- Confirmation of routine save actions (those need a toast, not a modal)
- Login prompts triggered by scrolling
If the design conversation starts with "let's add a modal that asks..." the right pushback is usually "what if we did not."
The Technical Floor Every Modal Must Meet
A modal that meets the technical floor is one that does not actively damage the user's experience. Most modals on the web do not meet this floor, which is why the pattern has the reputation it does.
Focus management. When the modal opens, keyboard focus moves to the first interactive element inside it (usually the primary action or the close button). When the modal closes, focus returns to the element that triggered it. Without this, keyboard users get stranded in the document, often miles from where they were working.
Keyboard escape. The escape key must close the modal. This is the universal expectation, and a modal that does not respond to escape feels broken even to users who could not articulate why.
Background scroll lock. When the modal is open, scrolling the background document must be disabled. Without this, the user can scroll the page behind the overlay, which produces a confusing impression that the modal is not really there. Some implementations handle this with overflow: hidden on the body; others use position-fixing with a measured scrollbar gutter to avoid layout shift.
ARIA roles and labels. The dialog needs role="dialog" or role="alertdialog" for screen readers. It needs aria-labelledby pointing to the heading and aria-describedby pointing to the description. Without these, the screen reader user gets context-free output that is hard to act on. The W3C maintains the canonical reference on ARIA dialog patterns and the trade-offs between dialog and alertdialog.
Backdrop click behavior. Whether clicking the backdrop closes the modal is a design choice, but it must be consistent and predictable. A backdrop that sometimes closes the modal and sometimes does not is a usability failure.
Focus trap. The user cannot tab out of the modal into the background page while the modal is open. Tab cycles within the modal until the user closes it. This is hard to get right; off-the-shelf implementations from accessible component libraries usually handle the edge cases better than custom code.
These are the table stakes. A modal that misses any of them is not designed; it is just markup.
Photo by Walls.io on Pexels
The Behavioral Patterns That Decide Whether the Modal Feels Hostile
The technical floor is necessary but not sufficient. A modal can meet every accessibility requirement and still feel adversarial because of how it behaves.
Do not stack modals. A modal opening on top of another modal is a design failure. The user is now two layers deep in interruption and the back-out path is unclear. If the design seems to require stacked modals, the structure is wrong; redesign the underlying flow.
Do not destroy work. If the user is filling out a form when a modal interrupts (a session timeout warning, an error notice), the form data must survive when the modal closes. Modals that wipe forms produce some of the deepest frustration in interface design.
Honor the back button. On mobile especially, users expect the back gesture to close the modal. The current URL should reflect the modal state, either via a route or via a fragment. A modal that hijacks the back button to do something else (or to do nothing) feels broken.
Match the close affordance to the action. A modal that asks for a destructive confirmation should have its destructive action visually distinct (red, secondary alignment) and its safe action prominent. A modal that conveys information should have a clear, single dismiss action without "cancel" and "okay" both leading to the same place.
Time it deliberately. Modals that trigger on page load are aggressive. Modals that trigger on intent (clicking a button that explicitly opens the dialog) are respectful. Modals that trigger on scroll, mouse-leave, or hover are almost universally hostile and should be replaced with a less interrupting pattern.
Match the size to the content. A full-screen modal for a single yes/no decision is bullying. A tiny modal for a complex form is cramped and forces awkward scrolling. Size the modal to the content with sensible mobile breakpoints (full-screen sheet behavior under a certain viewport width is usually the right call).
"Most modal dialogs we audit during front-end reviews fail one of two tests. Either they trap keyboard focus poorly, which kills accessibility, or they fire at the wrong moment, which kills trust. Both are design choices the team made by default, and both can be redesigned without rewriting the underlying app." - Dennis Traina, founder of 137Foundry
Patterns That Are Almost Always Better
A surprising fraction of modal use cases have a better non-modal alternative. Worth considering each before reaching for the overlay:
Toasts and snackbars for confirmations of routine actions. The user saved a draft, the email sent, the file uploaded. A short, dismissable notice at the corner of the screen communicates success without taking over the interface.
Inline expansion for small confirmations or detail. Instead of a modal asking "are you sure," an inline confirm bar above the action that can be canceled with a single click. Less interruption, faster flow.
Side panels for content that needs scoped scroll but where the user benefits from seeing the underlying app. Document preview, settings, secondary detail.
Bottom sheets on mobile for any modal-like interaction. The dragging interaction is familiar to mobile users, the back gesture closes them by default, and they leave background content partially visible so users keep context.
Separate page routes for substantial flows like onboarding or multi-step forms. A modal that contains three steps with progress indicators is almost always better as a route. The URL is shareable, the back button works correctly, and the user can refresh without losing state.
Non-modal popovers for transient information like tooltips, dropdown menus, and command palettes. These respect focus, do not block background interaction, and dismiss naturally on outside click or escape.
Resources like the Nielsen Norman Group and Smashing Magazine maintain pattern libraries that compare the trade-offs across these alternatives for common use cases. The a11y Project covers the accessibility implications of each pattern in depth.
Mobile-Specific Considerations
Modal dialogs translate poorly to mobile, and the responsive failures are predictable.
Viewport units behave inconsistently. The mobile browser chrome appears and disappears on scroll, which changes 100vh. A modal sized at 100vh may exceed the visible area on some scrolls. Use small/large/dynamic viewport units (svh/lvh/dvh) deliberately or avoid relying on viewport sizing for modal containers.
Soft keyboards push content. When a modal contains a text input and the soft keyboard appears, the layout can collapse or push critical content off-screen. The modal needs to handle viewport changes from keyboard appearance, usually by scrolling the input into view rather than expecting the layout to adjust automatically.
Tap targets must be larger. A modal designed for desktop with 32px buttons becomes a misclick generator on mobile. 44px minimum tap targets, with comfortable spacing between actions.
Full-screen sheets are often the right call. Below a certain viewport size, a modal becomes a sheet that covers the screen. This is usually a better experience than a centered modal trying to maintain proportions on a small device.
MDN Web Docs covers the responsive considerations and the viewport unit behavior in depth, including the relatively new dynamic viewport units that handle the mobile chrome issue more gracefully than the legacy vh unit.
Photo by Walls.io on Pexels
Implementation Notes
For most projects, the right implementation is a vetted accessible component library rather than custom code. The edge cases in focus management, scroll lock, and ARIA labeling are easier to get wrong than to get right. Libraries that take this seriously (Radix, Headless UI, React Aria, Reach) have done the hard work and exposed the right hooks for customization without breaking the core accessibility model.
If you must build a custom modal component:
- Test with the keyboard first. If it does not work with the keyboard, it does not work, regardless of how nice the mouse experience is.
- Test with a screen reader. NVDA on Windows, VoiceOver on macOS and iOS, TalkBack on Android. The behavior differs across these and across browsers.
- Test with the back button on mobile. If pressing back closes the page instead of the modal, the back-button integration is missing.
- Test with the form-data persistence case. If the user has typed something into a form and then a modal interrupts, what happens when they close it.
The 137Foundry web design and development team audits modal and overlay implementations regularly during front-end reviews, and the pattern of failures is consistent enough that we keep a checklist for it. The list above covers the most common ones.
The Trust Frame
Modal dialogs are about consent. The user is being asked to accept an interruption to whatever they were doing. The design question is whether the interruption is worth their attention.
A modal that earns its interruption (because the decision matters, because the work cannot proceed without it, because the content needs scoped focus) is a legitimate use of the pattern. A modal that hijacks attention for a reason that primarily serves the business (collecting an email, surfacing a feature the user did not ask about) erodes the trust the product needs to operate over time.
For deeper architectural context on building web applications that handle interaction patterns like this consistently across teams, the 137Foundry services overview covers how these decisions fit into broader front-end architecture work. The 137Foundry homepage has additional case studies and write-ups from production review work.
Designing modals that respect users is harder than not designing them at all. The product wins on the harder path. Every modal that does not appear is one fewer interruption the user has to absorb, and every modal that does appear earns its attention because it is rare and meaningful.
A Short Checklist
If a modal is going to ship, run through this list before it goes live:
- Is this actually the right pattern, or would a toast, side panel, or inline expansion serve better?
- Does keyboard focus move correctly on open and close, and does tab cycle within the modal?
- Does escape close the modal? Does backdrop click do so predictably?
- Is the background scroll locked, and is layout shift handled with a scrollbar gutter?
- Are the ARIA roles, labels, and descriptions correctly wired?
- Does the back button close the modal on mobile?
- Does form data survive if the modal interrupts a form fill?
- Are tap targets large enough on mobile, and does the layout collapse to a sheet at small viewports?
A modal that passes the checklist is genuinely designed. A modal that does not is a fight the user has to win every time it appears.
