Spectrum
Toast
Toasts display brief, temporary notifications. They are noticeable but do not disrupt the user experience and do not require an action to be taken.
Table of contents#
Anatomy#
Options#
Text#
Toasts must include text to communicate a message. The text should be written as concisely as possible while still being clear about what has happened or is happening. It’s acceptable to use short phrases for toasts that are communicating confirmation and error messages, but informative toasts should use complete sentences.
Neutral variant#
The neutral variant is the default variant for toasts. It is gray and does not have an icon. This is used when the message is neutral in tone or when its semantics do not fit in any of the other variants.
Informative variant#
The informative toast uses the informative semantic color (blue) and has an info icon to help those with color blindness discern the message tone. Similar to the call to action button, this should be used when the message should call extra attention compared to the neutral variant.
Positive variant#
The positive toast uses the positive semantic color (green) and has a checkmark icon to help those with color blindness discern the message tone. This can be used to inform the user of a successful operation.
Negative variant#
The negative toast uses the negative semantic color (red) and has an alert icon to help those with color blindness to discern the message tone. This can be used to show an error or failure.
Action#
A toast can have up to one button (a quiet over background button). This should be kept concise and only used when there’s an actionable item related to the toast text.
Auto-dismissible#
By default, a toast will dismiss when the user clicks the “x” close button. A toast also has the option to auto-dismiss. Be sure to set a minimum of 5 seconds so users have ample time to read the toast message. If an actionable toast is set to auto-dismiss, make sure that the action is still accessible elsewhere in the application.
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 |
|---|---|---|
| text | text | – |
| variant | neutral / informative / positive / negative | neutral |
| action label | text If undefined, this button does not show up. | – |
| is auto-dismissible | yes / no | no |
Priority queue#
| Priority | Toast Variant | Auto-dismiss | Behavior |
|---|---|---|---|
| 1 | Actionable, Error | No | Overrides when lower-priority toast is triggered. If toast of same priority is visible, placed next in queue. |
| 2 | Error | Optional | Overrides when lower-priority toast is triggered. If toast of same priority is visible, placed next in queue. Can be pushed back in queue by higher priority toast. |
| 3 | Actionable, Success | No | Is placed in queue at third-level priority. If toast of same priority is visible, placed next in queue. Can be pushed back in queue by higher priority toast. |
| 4 | Actionable, Informative | No | Is placed in queue at fourth-level priority. If toast of same priority is visible, placed next in queue. Can be pushed back in queue by higher priority toast. |
| 5 | Actionable, Neutral | No | Is placed in queue at fifth-level priority. If toast of same priority is visible, placed next in queue. Can be pushed back in queue by higher priority toast. |
| 6 | Success | Optional | If auto-dismiss, do not show if other toast is present on screen. Otherwise place in queue at sixth-level priority. If toast of same priority is visible, placed next in queue. Can be replaced by higher priority toast. |
| 7 | Informative | Optional | If auto-dismiss, do not show if other toast is present on screen. Otherwise place in queue at seventh-level priority. If toast of same priority is visible, placed next in queue. Can be replaced by higher priority toast. |
| 8 | Neutral | Optional | If auto-dismiss, do not show if other toast is present on screen. Otherwise place in queue at eighth-level priority. If toast of same priority is visible, placed next in queue. Can be replaced by higher priority toast. |
Behaviors#
Text overflow#
When the text is too long for the available horizontal space, it wraps to form another line. In actionable toasts, this means the button moves below the text prior to text wrapping.
Usage guidelines#
Toast or dialog?#
Toasts should only be used for confirmations, simple notifications, and low-priority alerts that do not need to completely interrupt the user experience. Dialogs are ideal when a situation requires the user’s attention, either for displaying important information or prompting for a response.
Placement#
Toasts are displayed at the bottom of the screen. By default, a toast is placed in the bottom center of the application, 16 px away from the bottom of the viewport. In mobile applications, a toast is placed 16px above the bottom toolbar. In smaller viewports, a toast is never larger than the viewport width (with 8px left and right margins).
Don’t place mobile toasts over navigation#
On mobile applications, be mindful of important navigation bars at the bottom of the screen by placing toasts vertically above these components.
Be concise#
Toasts are only meant for short, non-disruptive notifications, so keep the text concise. Most of the time, toasts will be sentence fragments and therefore should not be punctuated. In the rare occasion where complete sentences are necessary, use a terminal punctuation (period).
Don’t display more than one action#
Actionable toasts should only have one button, in the form of a quiet over background button.
Don't include a redundant action#
Actionable toasts should not have a button with a redundant action. For example, “dismiss” would be redundant because all toasts already have a close button.
Multiple toasts#
Do not display multiple toasts at the same time. When toasts are consecutively or simultaneously triggered, their display and behavior should follow a priority queue.
Too many toasts#
Be mindful of how often you trigger toasts. Even though they are not as disruptive as dialogs, they still interrupt a user’s attention. Frequent interruptions interfere with usability, especially for people with visual and cognitive disabilities (see WCAG Success Criterion 2.2.4 Interruptions).
Also, products should allow users to turn off all types of alerts when necessary. This allows users who are blind or have low vision to keep their “viewing” focus on the content they are currently reading.
Internationalization#
RTL#
For RTL (right-to-left) languages, the layout of the toast is mirrored. The icon is right-aligned and the close button is left-aligned. If the toast is actionable, the button placement is also inverted and appears on the left side.
Keyboard interactions#
| Key | Interaction |
|---|---|
| Tab | Places the focus on the next interactive element, which is either a button or a close icon. |
| Shift + Tab | Places the focus on the previous interactive element, which is either a button or a close icon. |
| Space or Enter | If focus is on the close button, dismisses the toast. If focus is on the button, executes the button action. |
| Esc | Dismisses the toast. This is equivalent to selecting the close icon. |
When keyboard focus is placed on buttons in a toast, any auto-dismiss behavior should be paused in order to meet WCAG Guideline 2.2 Enough Time.
Changelog#
| Date | Number | Notes |
|---|---|---|
| Apr 20, 2019 | 5.0.0 |
|
Design checklist#
All interactive states
Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).
Multiple options
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)
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).
Defined behaviors
Includes guidelines for layout (wrapping, truncation, overflow), animation, interactions, etc.
Usage guidelines
Includes a list of dos and don’ts that highlight best practices and common mistakes.
Accessible contrast
Follows WCAG 2.0 standards for contrast (AA).
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 included in Spectrum DNA.
Generated UI kit
Includes a downloadable XD file that has been generated by code and shows multiple variations, states, color themes, and scales.
In Spectrum for Adobe XD plugin
Component is included in the Spectrum for Adobe XD plugin.
Dialog