Dialogs display important information that users need to acknowledge. They appear over the interface and block further interactions.
All dialogs must have a title. Titles appear in bold at the top of the dialog, and use a few words to convey the outcome of what will happen if a user continues with an action.
Dialogs can include a description. Descriptions briefly communicate any additional information or context that a user needs to know in order to make one of the decisions offered by the buttons.
Information dialogs should be used to communicate important information to users that they need to acknowledge. Before using an information dialog, make sure this is the appropriate communication channel for the message, rather than a toast or a more lightweight option.
Destructive dialogs should be used when a user has to confirm an action that will impact their data in a destructive way, such as deleting files or contacts. The destructive dialog has a red (negative) button to highlight that action.
Error dialogs should be used to communicate critical information to users in relation to an issue that needs to be acknowledged. The error dialog has a red title and a warning icon to reinforce its importance.
A dialog must have at least one button. The primary action label is for the first (right-most) button. It communicates what the button will do with a short, actionable phrase to either describe the next step, if selected, or to acknowledge the dialog’s message (“OK”).
A dialog can have a total of 3 buttons if the secondary button label is defined. If left undefined, the button won’t appear. The secondary button label communicates what the button will do with a short, actionable phrase to describe what will happen in the next step, if selected.
A dialog with a button that offers an option to go back and cancel the action will have a label of “cancel,” by default.
From the design point of view, each component has a number of options. These options and their names are platform agnostic, and each implementation should adapt these to fit into their framework.
confirmation / information / destructive / error
If undefined, this button does not show up.
If undefined, this button does not show up.
When the title and body text are too long for the available horizontal space, they wrap to form another line.
A dialog can have up to three buttons. When horizontal space is limited, button groups stack vertically. They should appear in ascending order based on importance, with the most critical action at the bottom.
Dialogs are best for displaying important information that users need to acknowledge. Use dialogs only when absolutely necessary, not for simple notifications or excessive confirmations.
Dialogs are meant to interrupt the experience until a resolution is reached, so there should only be one dialog displayed on the screen at a time. Don't open a dialog from within another dialog. If the situation seems to require a sequence of decisions, look into using a different design altogether.
For RTL (right-to-left) languages, the layout of the dialog is mirrored. Texts are right-aligned and buttons are left-aligned.
|Tab||Moves focus to the next button inside the dialog (last becomes first). If none of the buttons are selected, the focus is set on the first button.|
|Shift + Tab||Moves focus to the previous button inside the dialog (first becomes last). If none of the buttons are selected, the focus is set on the last button.|
|Esc||Dismisses the dialog. This is equivalent to choosing “Cancel” or an “OK” confirmation.|
|Aug 22, 2019||5.1.0|
|May 20, 2019||5.0.1|
|Apr 19, 2019||5.0.0|
Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)
Works properly across all four color themes (lightest, light, dark, darkest).
Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).
Includes guidelines for layout (wrapping, truncation, overflow), animation, interactions, etc.
Includes a list of dos and don’ts that highlight best practices and common mistakes.
Follows WCAG 2.0 standards for contrast (AA).
Works properly across various locales and includes guidelines for bi-directionality (RTL).
Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.
Includes a downloadable XD file that has been generated by code and shows multiple variations, states, color themes, and scales.
All design attributes (color, typography, layout, animation, etc.) are included in Spectrum DNA.