Dialog (Non-Modal)

A non-modal dialog presents additional content or options in a floating panel without blocking interaction with the rest of the page.

Demo

Activate the trigger button to open the dialog panel. Once open, explore the content inside with the keyboard — notice that focus moves into the dialog but you can still tab to content outside it. Press Escape to close the dialog and observe where focus returns. Try activating the trigger again from the keyboard to verify the round-trip focus behavior.

What to Observe

Focus moves into the dialog when it opens, landing on the first focusable element or the dialog itself.
The dialog is announced as a distinct region by screen readers when it appears, including its accessible name.
Unlike a modal dialog, keyboard focus is not trapped — users can freely tab to content in the background page.
Pressing Escape closes the dialog and returns focus to the trigger button that opened it.
The trigger button communicates the dialog's open or closed state via aria-expanded.

Anatomy

[Anatomy image placeholder — will be added when assets are available]

Trigger button — The button that opens the dialog; carries aria-expanded and references the dialog via aria-controls.
Dialog container — The panel element with role="dialog" and an accessible name provided by aria-labelledby pointing to the dialog heading.
Dialog heading — An <h> element inside the dialog that names it for both sighted users and screen readers.
Dialog content — The body of the panel, which may include text, forms, links, or other interactive elements.
Close button — A button inside the dialog to dismiss it explicitly, with a descriptive accessible name.

Accessibility Behavior

The dialog must carry role="dialog" and be named via aria-labelledby so screen readers announce its purpose when focus enters.
Focus must move into the dialog automatically when it opens, without requiring the user to navigate there manually.
Because this is a non-modal dialog, focus must not be trapped — users must be able to tab freely between the dialog and the rest of the page.
The trigger button must reflect the dialog state with aria-expanded so users know whether the panel is open or closed before activating it.
Pressing Escape must close the dialog and return focus to the element that triggered it.
If the dialog is dismissed by any means, the background page content must remain fully operable.

Common Mistakes

Using a plain <div> for the panel without role="dialog", so screen readers never announce it as a distinct context.
Failing to move focus into the dialog on open, leaving keyboard users stranded outside the panel they just triggered.
Omitting aria-labelledby so the dialog has no accessible name and screen readers announce it without context.
Not returning focus to the trigger button on close, causing keyboard users to lose their position in the page.
Forgetting to handle Escape, which is the expected and intuitive way to close any dialog.

Why This Matters

Non-modal dialogs appear in help panels, inline notifications, tooltips, and contextual actions — patterns that are common across enterprise and consumer products alike. When focus management is missing or incorrect, keyboard and screen reader users either cannot reach the dialog content or, after closing it, find themselves at an unpredictable location in the page. This disrupts the flow of a task and forces users to re-orient themselves from scratch, a compounding cost that adds up across every dialog interaction in a session.

Accessibility Validation

This component is validated against internal accessibility criteria aligned with WCAG standards, using our internally developed system, Resonance Specs.

To learn more, please contact us.