Dialog component overview
Keep dialog content concise and purposeful. Always provide a clear way to dismiss the dialog, such as a close button, a cancel action, or both.
When to use
Use dialogs when
- The user must acknowledge or confirm something before continuing
- A short task or decision should stay in the current page context
- The content is important enough to temporarily interrupt the flow
Do not use dialogs when
- The content can live inline without blocking the current task
- The interaction is long, complex, or better suited to a full page
- The interruption would add friction without adding clarity
Patterns
Anatomy
Dialog anatomy
Design guidelines
Use dialogs only when the interruption is worth the attention shift and the next step is clear.1
Choose the right level of interruption
Use a dialog only when people must pause to confirm, review, or complete a short task before continuing.
2
Write clear actions
Make button labels describe the outcome, especially in destructive or irreversible flows.
3
Use confirm dialogs carefully
Reserve locked-down confirmation dialogs for actions that carry real risk, such as deletion or deactivation.
If the content grows beyond a short decision or focused task, move the interaction to an inline flow or a dedicated page instead of expanding the dialog.
Usage
Default
Use thedefault dialog when you want to overlay content for focused user engagement.
Options
Highlight footer
Usefooter-appearance="highlight" when emphasis on the footer is important.
No footer
This kind of dialog omits the footer section for situations where a minimal and distraction-free interface is preferred.No backdrop
Usedisable-backdrop when you want to allow users to focus on the dialog content without an overlay.
Confirm dialog
Use this variant to confirm irreversible actions with clear messaging and focused choices.Best practices
DoMake the title and primary action work together so the outcome of the dialog is unmistakable.
Don’tDo not use vague titles or button labels that force people to infer the meaning of the decision.
DoUse concise content and keep the structure easy to scan with a clear title, short body copy, and focused actions.
Don’tDo not duplicate actions in the footer or offer too many equally weighted choices.
DoMatch the dialog size to the amount of content so the layout feels intentional and easy to scan.
Don’tDo not force long forms, dense tables, or multi-step workflows into a dialog that needs more room than the pattern is meant to provide.
DoKeep a reliable dismissal path available, especially in confirmation flows where people may need to back out safely.
Don’tDo not disable the close button, backdrop dismissal, and Esc handling together unless the action carries real risk and the remaining actions are explicit.
Accessibility
- Built-in dialog semantics — the component applies
aria-labelledby="bq-dialog--title"andaria-modal="true"to the native<dialog>element, so assistive technology can identify it as a modal surface. - Built-in close control labeling — when the default close button is shown, it includes an accessible
label="Close"and a decorative close icon marked witharia-hidden="true". - Built-in focus management — the native
<dialog>element automatically traps keyboard focus within the dialog while it is open and restores it to the previously focused element when the dialog closes. - Provide a meaningful title — the content you place in the
titleslot becomes the dialog’s accessible label, so it should clearly describe the decision, task, or message. - Include an explicit dismissal path — if you hide the close button or disable outside dismissal, provide a clear cancel or close action in the footer.
- Preserve keyboard expectations — keep Esc enabled for dismissible dialogs unless there is a strong product reason to require an explicit choice.
- Use precise action labels — button text should describe the result of the action, especially in confirmations and destructive flows.
- Use
disable-backdropcarefully — removing the backdrop changes the modal emphasis, so make sure the surrounding page does not compete visually with the dialog content.
API reference
Properties
Events
Methods
Slots
Shadow parts
CSS custom properties
Resources
Interactive playground
Explore dialog examples and states in Storybook
Source code
View the component source on GitHub