Spectrum
Alert dialog
Alert dialogs display important information that users need to acknowledge. They appear over the interface and block further interactions until an action is selected.
Table of contents#
Anatomy#
Options#
Title#
All alert dialogs must have a title. The title appears in bold at the top of the dialog and uses a few words to convey the outcome of what will happen if a user continues with an action.
Description#
Alert dialogs can include a description. A description briefly communicates any additional information or context that a user needs to know in order to make one of the decisions offered by the buttons.
Confirmation variant#
This is the default variant for alert dialogs. Use a confirmation variant for asking a user to confirm a choice. This alert dialog has an accent button to highlight a strong preference for which action to take.
Warning variant#
Warning alert dialogs communicate important information to users in relation to an issue that needs to be acknowledged, but does not block the user from moving forward. It has an orange warning icon near the title to reinforce its importance.
Destructive variant#
Destructive alert dialogs are for when a user needs to confirm an action that will impact their data or experience in a potentially negative way, such as deleting files or contacts. This alert dialog has a red (negative) button to highlight the destructive action.
Error variant#
Error alert dialogs communicate critical information about an issue that a user needs to acknowledge. This alert dialog has a warning icon to reinforce its importance.
Primary action label#
An alert 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 and dismiss the dialog.
Secondary action label#
An alert dialog can have a total of 3 buttons if the secondary outline button label is defined. If left undefined, the button won’t appear. The secondary outline button label communicates what the button will do with a short, actionable phrase to describe what will happen in the next step, if selected.
Cancel action label#
An alert dialog with a button that offers an option to go back and cancel the action will have a label of “Cancel,” by default.
Table of options#
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.
| Property | Values | Default value |
|---|---|---|
| title | text | – |
| description | text | – |
| variant | confirmation / information / warning / destructive / error | confirmation |
| primary action label | text | – |
| secondary action label | text If undefined, this button does not appear. | – |
| cancel action label | text If undefined, this button does not appear. | Cancel |
Behaviors#
Text overflow#
When the title and description text are too long for the available horizontal space, they wrap to form another line.
Button group overflow#
An alert dialog can have up to 3 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.
Usage guidelines#
Use alert dialogs sparingly#
Alert dialogs are interruptive, so they're best for displaying important information that users need to acknowledge before moving forward with a task or workflow. Use them only when absolutely necessary, not for low-signal notifications or excessive confirmations.
Don't nest alert dialogs#
Alert dialogs are meant to interrupt the experience until a resolution is reached, so there should only be one displayed at a time. Don't open an alert dialog from within another alert dialog. If the situation seems to require a sequence of decisions, look into using a different design altogether.
Content standards#
Writing for alert dialogs starts by determining the nature of the message. Each Spectrum alert dialog variant has its own communication goal and tone that work in partnership with its visual design.
| Alert dialog variant | Goal | Tone |
|---|---|---|
| Confirmation | Asking a user to confirm an action they want to take. | Instructive |
| Information | Sharing important information that a user needs to acknowledge. | Helpful |
| Warning | Sharing time-sensitive information that a user needs to consider, but won’t block them from proceeding. | Instructive to helpful |
| Destructive | Telling a user that if they are to proceed with an action they want to take, it may impact their data in a negative way. | Instructive |
| Error | Communicating critical information about an issue that a user needs to resolve before they can move forward with a task. | Supportive |
Writing the title#
All alert dialogs must have a title. The title communicates the upshot of the message, such as the eventual outcome or conclusion of an action. It should be as close as possible to a complete sentence (subject + verb). Don’t use punctuation at the end of the title.
Most alert dialog titles communicate the main effect of whatever a person is about to do. Titles ideally use the same or similar phrasing as the call-to-action that had led someone to the alert dialog in the first place.
The title of an error alert dialog communicates the result of the error. Don’t just state that an error has occurred.
Writing the description#
Alert dialog descriptions share any additional information or context that a person needs to know in order to make one of the decisions offered by the actions. Descriptions are written in complete sentences, and any error code is included in parentheses at the end of the last sentence.
Writing the actions#
Use a short phrase to succinctly describe the options for next steps. If possible, have the button label use the same language as the action mentioned in the alert dialog title (e.g., if a dialog's title is “Delete conversation,” its primary action button label would be “Delete”).
Make button labels specific and actionable#
For alert dialog buttons, make the labels as specific and actionable as possible. Even if someone were to only read the word or phrase on the button, they should be able to get a summary of the alert dialog’s entire message.
Avoid asking questions#
Questions in alert dialog titles — such as “Are you sure you want to quit?” or “Do you want to cancel?” — are redundant and undermine a user's agency in the decision they've already made by taking a previous action to get to the alert dialog. This phrasing also sets up for a yes/no set of actions, which can become confusing. Instead, reframe the message to focus on the outcome or effect.
Pair confirmation with distinct actions#
It’s OK to ask a question in an alert dialog's description to confirm if someone wants to go ahead with a choice that the system is making on their behalf. However, this should still be paired with distinct actions that show that a person has control over what happens next.
Internationalization#
RTL#
For RTL (right-to-left) languages, the layout of the alert dialog is mirrored. Texts are right-aligned and buttons are left-aligned.
Keyboard interactions#
| Key | Interaction |
|---|---|
| Tab | Moves focus to the next button inside the alert 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 alert dialog (first becomes last). If none of the buttons are selected, the focus is set on the last button. |
| Esc | Dismisses the alert dialog. This is equivalent to choosing “Cancel” or an “OK” confirmation. |
Changelog#
| Date | Number | Notes |
|---|---|---|
| Apr 06, 2022 | 7.0.0 |
|
| Feb 17, 2022 | 6.0.0 |
|
| Mar 29, 2021 | 5.2.0 |
|
| Feb 29, 2020 | 5.1.1 |
|
| Aug 22, 2019 | 5.1.0 |
|
| May 21, 2019 | 5.0.1 |
|
| Apr 20, 2019 | 5.0.0 |
|
Design checklist#
All interactive states
Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).
All color themes
Works properly across all four color themes (lightest, light, dark, darkest).
All platform scales
Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).
Accessible use of color
Color is not used as the only visual means of conveying information (WCAG 2.0 1.4.1).
Accessible contrast for text
Text has a contrast ratio of at least 4.5:1 for small text and at least 3:1 for large text (WCAG 2.0 1.4.3).
Accessible contrast for UI components
Visual information required to identify components and states (except inactive components) has a contrast ratio of at least 3:1 (WCAG 2.1 1.4.11).
Content design
UI language and information design considerations have been incorporated into component design.
Defined options
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)
Defined behaviors
Includes guidelines for keyboard focus, layout (wrapping, truncation, overflow), animation, interactions, etc.
Usage guidelines
Includes a list of dos and don'ts that highlight best practices and common mistakes.
Writing guidelines
Includes content standards or usage guidelines for how to write or format in-product content for the component.
Internationalization guidelines
Works properly across various locales and includes guidelines for bi-directionality (RTL).
Keyboard interactions
Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.
Design tokens
All design attributes (color, typography, layout, animation, etc.) are available as design tokens.
UI kit
Includes a downloadable XD file that shows multiple options, states, color themes, and platform scales.
Generated UI kit
Includes a downloadable XD file, generated by code using design tokens defined in Spectrum DNA, and shows multiple options, states, color themes, and platform scales.
In Spectrum for Adobe XD plugin
Component is included in the Spectrum for Adobe XD plugin.
Alert banner