Why We at 137Foundry Replace Half the Modal Dialogs We Encounter in Front-End Audits
A note from the case-study notebook: across the last year of front-end review work at 137Foundry, roughly half of the modal dialogs we have encountered have been replaced rather than fixed. The replacement work is usually faster than the alternative (rebuilding the modal to meet accessibility standards) and the resulting UI is consistently better along every axis the client cares about.
This is not a position statement about modals being inherently bad. They are not. The position is more specific: the modal pattern is consistently the wrong choice for use cases that have better alternatives, and the better alternatives are almost always available.
Photo by Yuliya Duzhaya on Pexels
What We Actually See in Audits
A representative audit on a mid-size web app turns up between five and fifteen modal dialogs scattered across the application. The composition is usually predictable:
About 20% are confirmation modals for routine save actions ("draft saved," "settings updated"). These should be toasts, not modals.
About 15% are "are you sure" prompts for reversible actions ("archive this item"). These should be inline confirmations with undo.
About 15% are multi-step forms or onboarding flows wrapped in modal containers. These should be separate routes.
About 10% are cookie banners, newsletter signups, or first-load promotional overlays. These should be banners or skipped entirely.
About 10% are settings panels or detail views built as modals. These should be side panels.
About 30% are legitimate modal use cases (destructive confirmations, payment confirmations, scoped media viewers). These should stay modals and get fixed to meet accessibility standards.
The 70% replacement rate is roughly what we see, and the replacement work is usually less than the team estimates upfront.
Why the Replacement Work Is Faster Than the Fix Work
This is the part that surprises clients. When we recommend replacing a modal with a toast, or a multi-step modal with a route, the team's first reaction is usually "the rewrite will take longer than fixing the modal." It almost never does.
The reason is that the modal pattern has high incidental complexity that the replacement pattern does not have. Replacing a confirmation modal with a toast removes:
The focus trap implementation
The scroll lock implementation
The ARIA role management
The escape key handler
The backdrop click logic
The animation state machine for open/close transitions
The mobile back-button integration
That code goes away, replaced by a much smaller toast call. Net code shrinks. Tests get simpler. Edge cases disappear because the toast library handles them.
The same analysis holds for most of the replacement patterns. Side panels are simpler than modals. Routes are simpler than multi-step modals. Inline confirmations are simpler than confirm-prompt modals. The complexity is in the modal pattern itself, and removing it actually reduces work.
What We Keep as Modals
The 30% that stay modals after the audit share a few characteristics:
The action is genuinely critical. Deleting an account, processing a payment, signing a contract, acknowledging a safety-critical disclosure. These are decisions the user should make deliberately, and the modal pattern's interruption is appropriate.
The content benefits from scoped focus and a centered presentation. Image lightboxes and media viewers where the user is examining specific detail.
The interaction is irreversible or has meaningful consequences. The modal earns its interruption by representing a decision that genuinely deserves the user's full attention.
For these, we fix the modal properly. Focus management, escape key, scroll lock, ARIA labels, back-button integration, form-data persistence. The fix work is real but bounded, and the resulting modals are genuinely good.
A Specific Example from a Recent Project
A client had a SaaS dashboard with thirteen modal dialogs across the main user flows. The audit:
Two save confirmations (replaced with toasts)
One "delete this widget" confirmation (replaced with inline undo)
One four-step user onboarding flow (replaced with separate routes)
One settings panel (replaced with a side panel)
One filter configuration (replaced with a popover)
Four "are you sure" prompts for reversible actions (replaced with inline confirms)
Three remaining modals: account deletion confirmation, payment confirmation, and an image lightbox
Of the three remaining modals, all three had accessibility failures that we fixed (focus trap missing in two, escape key missing in one, screen reader announcement broken in all three).
The replacement work for the ten replaced modals took roughly two engineering weeks. Reviewers noted that the post-audit application felt substantially calmer and easier to navigate, even before the explicit accessibility fixes landed.
Public commentary on this kind of work is well-covered by resources like the a11y Project, which catalogs the failure modes we end up fixing, and the W3C maintains the canonical reference on dialog patterns we use during reviews.
Photo by Christina Morillo on Pexels
The Pattern Recognition Becomes Faster
After running this audit a few dozen times, the pattern recognition gets fast. Within ten minutes of opening a client's application, we can usually estimate the replacement count to within two or three. Within thirty minutes, we have a list of which modals stay and which go, with rationale for each.
The categories above are stable across industries. SaaS dashboards, e-commerce checkouts, productivity apps, B2B internal tools - the modal composition is broadly the same, and so is the replacement profile.
This is partly because the bad modal patterns come from a small number of sources. Off-the-shelf UI kits ship with modal-heavy patterns. Design tools default to modal templates. Online tutorials cover modal implementation more than the alternatives. The result is that the same mistakes propagate.
The fix is to be deliberate about the question "should this be a modal." Default to no. Reach for the modal pattern only when one of the legitimate use cases above applies.
What We Tell Engineering Teams
When the audit finishes and the client is deciding which findings to act on, the conversation usually goes through the same arc:
The engineering team initially resists the scope of the replacement work. The modal-replacement findings look like more change than fixing the modals would be.
We walk through the complexity comparison above. Modal patterns have high incidental cost that the replacement patterns do not. Net change usually shrinks the codebase rather than growing it.
The team agrees to replace one or two as a pilot. They report back that the replacement was easier than expected and the resulting UX is noticeably better.
The team then accelerates the rest of the replacement work because the pattern recognition has clicked into place.
This arc has played out enough times now that we mention it upfront. The skepticism is understandable; the resolution is consistent.
Where to Go Deeper
The detailed write-up on when to use modal patterns and when to replace them is on the longer 137Foundry guide on modal dialog design. For broader front-end architecture context, the 137Foundry homepage has additional case studies and recent project notes.
The Nielsen Norman Group maintains usability research on modal versus non-modal patterns that pairs well with the architecture discussion, and Smashing Magazine covers implementation patterns for the alternative widgets.
The Closing Frame
Replacing modals is not about making the team work harder for accessibility's sake. It is about choosing the right pattern for each interaction, and the right pattern is rarely the modal. When the right pattern is the modal, build it properly. When it is not, replace it with the pattern that actually fits.
Half the modals we encounter in audits do not fit. That is what we have learned by doing this work across many projects. The fix is faster than the alternative and produces better UX. Worth doing on any application where the modal density has accumulated past the point of design coherence.
