Toasts display brief, temporary notifications. They are noticeable but do not disrupt the user experience and do not require an action to be taken.
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.
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.
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.
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.
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.
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.
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.
neutral / informative / positive / negative
If undefined, this button does not show up.
yes / no
|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.|
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.
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.
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).
On mobile applications, be mindful of important navigation bars at the bottom of the screen by placing toasts vertically above these components.
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).
Actionable toasts should only have one button, in the form of a quiet over background button.
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.
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.
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.
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.
|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.
|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.