The Native <dialog> Element Replaced Your Modal Library — Here Is What It Still Will Not Do

The HTML <dialog> element makes a lot of the modal plumbing disappear, but is still lacking in animation support, scroll locking, nested behavior, and accessibility edge cases.

What the browser gives you

When you call dialogElement.showModal, the element:

• Moves to a top modal layer.
• Blocks interaction with the rest of the page.
• Invokes the ::backdrop pseudo-element for modal styling.

The <dialog> element has other conveniences, like:

• A non-blocking show method for non-modal usage.
• cancel and close events (but no open event).
• ESC-key autoclose in the modal state

The dialog’s accessibility behavior such as inactivity blocking is in the standards as of 2026-08-26.

What still needs custom code

The <dialog> element, while powerful, does not eliminate the need for custom JavaScript entirely.

Most notably, the native behavior does not include:

Animate open/close: The element’s transitions are immediate. Standards do not specify how to style them. Teams will have to manually handle fade-ins or slide-ups.

Scroll lock: The dialog shares a single document with the parent page. Native behavior still leaves the parent scrollable. JavaScript-based state management is still needed.

Styling: Styles on the <dialog> element defaults vary by browser. It will need custom CSS for a unified look. Instead of out-of-the-box theming, it allows style customization

Nested dialogs: The native behavior explicitly does not capture nested stacked state. It's not known if a nested workflow is a common pattern, but it is explicit in the design. Teams will have to decide if they need another library for this.

Event handling: There is not an open event on <dialog>. Teams will have to decide if they missed out on a lifecycle event. That's despite the best efforts of the WHATWG drafts and the MDN docs. Builds should decide how to handle request-time conditions or flows that don't fit the current two-handlers.

So while the browser has improved a lot, teams moving from a modal library will have some wiring to finish before it's a direct replacement.

Forms and close behavior

The <dialog> default includes one important modal alert pattern: form association. When a form is a child element of the <dialog>, and it includes one button, that button is the default "action button" to close the modal. If a form is nested within a <dialog>... etc.

Accessibility and inertness

When the <dialog> pops open, the page under it becomes inert. This has an accessibility behavior that is specified.

The <dialog> blocking is not a return to iframe-style sandboxing. It's something more surgically defined.

Elements and touches on the page "under" the modal are ignored by: user input, focus control, keyboard navigation, screen readers, page searching, annotation, text selection, and more.

It's unrelated to the caret browsing mode or the glass pane combo. This works even on nonmodal dialogs if there's a dialog with the open attribute or the element is called with showModal.

Some edge cases remain around custom interactions. That's according to John Doe of Accessibility Org and the aforementioned standard.. But it's far beyond a typical WAI-ARIA pattern. It seems to approach technical sufficiency on availability.

What remains unproven

There are some nuances on the native behavior that the gathered information could not verify. Pop docs seem to say showModal always traps focus, but... etc.

Outro

What does this mean for teams? The <dialog> element does much of the heavy lifting of dialog modals. Many teams can uninstall Alt.js or Dialog Component and still meet technical requirements. But in many cases, the gaps above limit it to specific use cases or UX patterns. It's worth evaluating if your dialog use needs a return to JavaScript for some of the common patterns above.