Modal dialogs are overused on the web. They are the default response to many design questions where a less interrupting pattern would serve the user better, and the accessibility cost of getting modals right is high enough that most teams ship modals that fall short of the standard.
The cheaper path is often to avoid the modal pattern entirely. Here are seven non-modal patterns that solve the same use cases without the focus management, scroll lock, focus trap, and back-button complications that come with modals.
Photo by Campaign Creators on Unsplash
1. Toast Notifications for Routine Confirmations
The most common bad modal is the one that confirms a routine action. "Your draft has been saved." "Email sent." "File uploaded." None of these need to interrupt the user.
A toast notification (sometimes called a snackbar) appears at a corner of the screen, communicates the success, and dismisses itself after a few seconds. The user keeps their context. The interface keeps moving. The success is communicated without ceremony.
Libraries like Sonner and React Hot Toast handle the implementation cleanly. The Smashing Magazine pattern library covers toast design considerations including timing, queue management, and accessibility.
Use a modal here only if the user must acknowledge before continuing. For routine save success, a toast is the correct pattern every time.
2. Inline Confirmation for Low-Risk Destructive Actions
The "are you sure" modal for routine deletions is friction without value. The user clicks delete. The modal asks if they really want to delete. The user clicks delete again. The deletion happens. The modal added a step without adding meaningful protection.
Inline confirmation works better for low-risk destructive actions. The delete button transforms into a confirm bar that says "Deleted - undo?" with a 5-second window to recover. The user gets undo affordance without the modal.
For high-risk destructive actions (deleting an account, dropping a database), a modal is genuinely appropriate. For removing a row, archiving a file, or hiding a section, inline confirmation with undo is the better pattern.
3. Side Panels for Scoped Detail
When the use case is "the user needs to focus on this content but should keep context from the underlying app," a modal is technically possible but a side panel is usually better.
A side panel slides in from one edge of the screen, occupies a fixed width, and leaves the underlying content visible. The user can still see what they were working on. The panel can be wider than a modal because it does not need to be centered with margins. Mobile bottom sheets serve the same purpose.
Settings panels, secondary detail views, comment threads, and chat assistants all work better as side panels than as modals. The user keeps context, the focus management is simpler, and the back-button integration is easier.
4. Bottom Sheets on Mobile
A modal on a phone is almost always wrong. The screen is too small, the layout is awkward, and the gesture-based navigation conflicts with the modal's expected behaviors.
A bottom sheet is the native mobile pattern for the same job. It slides up from the bottom, can be dragged to expand or dismiss, and integrates with the system back gesture by default. Users know how to interact with bottom sheets because every mobile OS uses them for system UI.
For any modal use case that needs to work on phones, prototype the bottom sheet first. It will usually be the better pattern, and the accessibility model is simpler.
MDN covers the implementation of native bottom sheet patterns using the dialog element and CSS transitions, plus the accessibility requirements that overlap with modal dialogs.
5. Separate Page Routes for Substantial Flows
Multi-step forms, onboarding flows, checkout processes - these are commonly built as multi-page modals, and they almost always work better as separate page routes.
A separate route gives you:
- Working back button by default
- Shareable URLs for support and bookmarking
- Refresh that does not destroy state if the form uses URL params or storage
- Larger usable area than any modal can comfortably provide
- Standard browser navigation patterns the user already knows
Modals for multi-step flows usually fight every one of these. The team ends up reimplementing routing inside the modal, which produces a worse version of what the framework already provides for free.
If the flow has more than two steps, default to a route, not a modal.
6. Non-Modal Popovers and Dropdowns
For transient information that does not need to block the rest of the interface, a non-modal popover works better than a modal. Tooltips, dropdown menus, command palettes, autocomplete suggestions, and date pickers are all examples.
Non-modal popovers do not trap focus, do not block background scroll, do not prevent interaction with the rest of the page. They dismiss on outside click or escape. They are positioned relative to a trigger element rather than centered on the viewport.
The W3C covers the popover patterns and how they differ from modal dialogs in their interaction model. The native HTML popover attribute now supports many of these patterns directly, with browser-managed dismissal and accessibility.
A pattern that does not need to interrupt the user should not interrupt the user.
7. Inline Expansion and Disclosure Widgets
For supplemental detail that some users want and others do not, an inline disclosure pattern works better than a modal. The user clicks "more info" and the detail expands in place. The information becomes available without leaving the context.
This is the right pattern for FAQs, optional form-field help text, expandable card content, and detail-on-demand throughout a settings interface.
The pattern uses the native HTML <details> and <summary> elements, which handle the show/hide behavior and accessibility for free. Custom implementations add risk without adding value in most cases.
Photo by Tima Miroshnichenko on Pexels
When to Still Reach for a Modal
The seven patterns above cover most use cases that get implemented as modals. A few situations remain where a modal is genuinely the right choice:
- Destructive actions with meaningful consequences (deleting an account, processing a payment)
- Critical confirmations that the rest of the interface cannot proceed without
- Image lightboxes and media that benefit from scoped focus
- Authentication or contract acknowledgment that must be deliberate
For these, build the modal properly: focus management, escape key, scroll lock, ARIA roles, back-button integration, form-data persistence. The cost of doing this once correctly is repaid by every subsequent modal that uses the same component.
For everything else, the non-modal patterns above are usually the better choice. Less interruption, simpler accessibility, faster development, better user experience.
A Pattern Decision Walkthrough
When a design question seems to call for a modal, walk through this short tree:
- Is the user being notified of a routine action? Use a toast.
- Is the user being asked to confirm a reversible action? Use inline confirmation with undo.
- Does the content need scoped scroll but should keep app context visible? Use a side panel.
- Is this on mobile? Use a bottom sheet.
- Is the flow more than two steps? Use separate routes.
- Is this transient supplemental information? Use a popover or inline expansion.
- None of the above and the action is genuinely critical and irreversible? Use a modal.
The default direction is away from modal, not toward it. Most teams default the other way and produce interfaces full of unnecessary overlays.
The Architectural Case
There is also a code-architecture case for non-modal patterns. Modals require focus management infrastructure, scroll lock infrastructure, ARIA infrastructure, animation state machines, and (if implemented well) integration with the routing layer. All of this is real complexity, and the marginal cost of each additional modal is non-trivial.
Non-modal patterns leverage the browser's native models for focus, scroll, and navigation. The cost per pattern is lower. The bugs are fewer. The accessibility comes closer to free.
For deeper architectural context on when modal patterns earn their complexity and when they do not, 137Foundry has done extensive front-end review work on this question, and the longer guide on modal dialog design walks through the decision framework in detail. The Nielsen Norman Group maintains usability research on each of the alternative patterns above.
Bottom Line
Most modals do not need to be modals. Toasts, inline confirmations, side panels, bottom sheets, separate routes, popovers, and disclosure widgets cover most use cases that currently default to modal overlays.
The result is interfaces that interrupt the user less, ship with fewer accessibility bugs, and require less complex frontend infrastructure to maintain. That is a better outcome along every axis the team cares about.
Top comments (0)