Adobe Logo

Spectrum

Version 5.0.0

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.

This is an example of the Spectrum Toast component, with an icon and text and divider and a close button. It's green which is the positive semantic color.

Table of contents#

Anatomy#

Illustration of the anatomy of a Toast component which includes an icon, text, blue (info) background color, a button, a divider, and a close button.

Options#

Key example of neutral toast. Text, All documents in this folder have been archived.

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.

Key example of neutral variant toast. Text, Button.xd archived.

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.

Key example of informative variant toast. Text, An update is available.

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.

Key example of positive variant of toast. Text, Copied to clipboard.

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.

Key example of negative variant toast. Text, Unable to delete file.

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.

Examples of four toasts that include an action. Neutral toast text, Button.xd archived. Button label, Undo. Positive toast text, Analysis complete. Button label, View. Informative toast text, An update is available. Button label, Update. Negative toast text, 2 assets missing. Button label, Show.

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.

PropertyValuesDefault 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#

PriorityToast VariantAuto-dismissBehavior
1Actionable, ErrorNoOverrides when lower-priority toast is triggered. If toast of same priority is visible, placed next in queue.
2ErrorOptionalOverrides 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.
3Actionable, SuccessNoIs 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.
4Actionable, InformativeNoIs 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.
5Actionable, NeutralNoIs 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.
6SuccessOptionalIf 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.
7InformativeOptionalIf 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.
8NeutralOptionalIf 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#

Examples of Toast components with overflowing text. Both include a close button, one also includes an icon and and actionable button.

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.

Example of a properly implemented Toast that displays a simple message confirming a file upload is complete.
An example of a Dialog used to display a simple file upload confirmation. This message is better suited to a Toast implementation.

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).

Example of proper toast placement at the bottom center of the UI.

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.

An example of a Toast placed properly in a mobile UI, such that it does not obscure the navigation bar at the bottom of the screen.
Example of an improperly placed Toast in a mobile UI, which has obscured the navigation bar at the bottom of the screen.

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).

An example of a Toast with properly implemented, concise text that reads 'File archived'.
An example of an improperly implemented Toast with a message that is not concise, which reads "This file has been archived".

Don’t display more than one action#

Actionable toasts should only have one button, in the form of a quiet over background button.

Example of a properly implemented actionable Toast that contains only one action.
Example of an improperly implemented actionable Toast that contains two actions.

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.

Example of an improperly implemented Toast that contains a 'Dismiss' action, which is redundant to the 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.

Example of improperly implemented Toasts that have been displayed at the same time.

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.

Example of a well implemented Toast that bundles notification of 4 uploads into a single message, reducing the frequency with which the user is interrupted.
Example of incorrectly implemented Toast notifications, where multiple messages have been displayed at once, distracting the user.

Internationalization#

An example of the Toast component in RTL configuration with a mirrored layout.

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#

KeyInteraction
TabPlaces the focus on the next interactive element, which is either a button or a close icon.
Shift + TabPlaces the focus on the previous interactive element, which is either a button or a close icon.
Space or EnterIf focus is on the close button, dismisses the toast.
If focus is on the button, executes the button action.
EscDismisses 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#

DateNumberNotes
Apr 19, 20195.0.0
  • This component is now individually versioned (individual versions of existing components start at 5.0.0)
  • Added RTL (right-to-left) guidelines

Design checklist#

N/A

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.

Generated UI kit

Includes a downloadable XD file that has been generated by code and shows multiple variations, states, color themes, and scales.

Design tokens

All design attributes (color, typography, layout, animation, etc.) are included in Spectrum DNA.