Spectrum

Version 6.0.0

Toast

Toasts display brief, temporary notifications. They're meant to be noticed without disrupting a user's experience or requiring an action to be taken.

Table of contents#

Anatomy
Options
Priority queue
Behaviors
Usage guidelines
Content standards
Internationalization
Keyboard interactions
Changelog
Design checklist

Anatomy#

Illustration of the component parts of a toast component, including its icon, text, blue (informative) background color, button, divider, and close button.

Options#

Text#

Toasts must include text to communicate a message. Write the text as concisely as possible while still being clear about what has happened or is happening. View the toast content standards for writing guidelines.

Neutral variant#

The neutral toast is the default variant. 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 vision deficiency discern the message tone. Similar to the accent 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 vision deficiency discern the message tone. This is used to inform about a successful action or completion of a task.

Negative variant#

The negative toast uses the negative semantic color (red) and has an alert icon to help those with color vision deficiency to discern the message tone. This is used to show an error or failure.

Action#

A toast can have up to one action: a static white, secondary, outline button. This label should be kept concise, and it should only be used when there’s a direct action available that is related to the toast text.

Auto-dismissible#

By default, a toast will dismiss when the user clicks the close button. A toast also has the option to auto-dismiss. Be sure to set a minimum of 5 seconds so that users can have time to read the toast message. If an actionable toast is set to auto-dismiss, make sure that the action is still available elsewhere in the app.

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 appear.	–
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, positive	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	Positive	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#

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, 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 for when a situation requires a 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 an alert dialog used to display a simple file upload confirmation. This message is better suited to a toast component.

Placement#

Toast position differs depending on platform scale. By default, a toast is placed at the bottom end for desktop scale and at the bottom center for mobile scale, to avoid disrupting the user experience.

For desktop applications, a toast should be placed 16 px away from the bottom and to the right of the viewport.

For mobile applications, a toast should be placed at the bottom center, 16 px above the bottom toolbar. In smaller viewports, a toast is never larger than the viewport width (with 8 px left and right margins).

If a toast isn’t noticeable or doesn't disrupt the user experience, its placement can be changed to bottom center, bottom end, top end, or top center.

4 examples of proper toast placement. First example, placement: bottom center. Toast is placed at the bottom center of the UI. Second example, placement: bottom end. Toast is placed at the bottom right of the UI. Third example, placement: top end. Toast is placed at the top right of the UI. Fourth example, placement: top end. Toast is placed at the top center of the UI.

On mobile apps, 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.

Don’t display more than one action#

Actionable toasts should only have one button, in the form of a static white, secondary outline button.

Example of a properly implemented actionable Toast that contains only one action. Text, File archived. Button label, Undo.

Example of an improperly implemented actionable Toast that contains two actions. Text, File archived. Buttons labels, Undo, Delete.

Don't include a redundant action#

Actionable toasts should not have a button with a redundant action. For example, including a “Dismiss” button 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#

Don't show 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're 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).

Products should allow for users to be able turn off all types of alerts. Doing this helps people who want to focus and minimize information that they may find non-essential.

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.

Content standards#

Writing for toasts depends on the nature of the message, whether it’s communicating confirmation, information, or an error. For all kinds of toasts, keep the text to fewer than 2 lines in English, since it will become longer when localized.

Confirmation#

For a confirmation message (neutral and positive variants), use a short past participle verb phrase: (optional) noun + verb ending in -ed + (optional) prepositional phrase with more information. If you refer to an interface element directly, put its name in bold text.

Informational#

For an informational message (informative variant), write in a complete sentence following the formula of subject + verb phrase + optional additional information.

2 key examples of toasts with informative messages. Both toasts in blue, with information icons. First example, text Photoshop has been updated to version 22.1.1. Second example, text A new version of Illustrator is available, button label Update.

Error#

For an error message (negative variant), use a short phrase — it can be a complete sentence or not — to describe what’s happening as succinctly as possible. Whenever possible, include an in-line action for a user to take so that they can readily address the issue explained in the message.

Write in sentence case with no period#

Like all in-product content at Adobe, toasts and their actions are written in sentence case. If the toast’s message is a single sentence, do not add a period to the end; this helps keep the text quicker to read and easier to parse.

Toasts should ideally only be a single sentence, but if you need to use two or more sentences to most accurately communicate the information, add a period to the end of each sentence.

Key example showing the correct way to format text in a toast using sentence case and no period. An informative toast in blue with an information icon, text A new version of Illustrator is available. Button label, Update.

Key example showing the incorrect way to format text a toast, with items in all-caps. An informative toast in blue with an information icon, text A NEW Version of Illustrator is Available. Button text, UPDATE. The words new and update are in all-caps and the rest of the sentence is in title case.

Use an instructive tone#

Toasts offer quick reference or context, so a user should be able to quickly read a message that’s brief and optimized for delivery. Use an instructive tone that presents the message in a concise and neutral way.

Because users are likely to see several toasts in quick succession, it’s not appropriate to use overly playful, encouraging, or celebratory language. Just convey the message, then get out of the way so that they can get back to the task at hand. Toasts are not appropriate for promotional messaging or upsells that show the benefit of doing or trying something.

Key example showing the correct way to use tone in a toast. An error toast with a warning icon, toast text, 2 fonts missing, button label, Show. The message is brief and neutral.

Key example showing the incorrect way to use tone in a toast. An error toast with a warning icon, toast text, 2 fonts are missing, but don’t worry because you can fix this! Button label, Fix it now. The message is too long and overly promotional.

Use generic language#

Whenever possible, use generic language in confirmation and error messages. This approach allows for better localization and it also reduces the need to write many different versions of toasts for similar use cases. It’s usually unnecessary to include specific filenames, usernames, or folders because a user can get that context from elsewhere in the UI.

Key example of the correct way to write a toast using generic language to communicate the message. Toast text, Item archived,

Key example of the incorrect way to write a toast using overly specific language to communicate the message. Toast text, Proposal.pdf archived to folder.

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#

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.

Key	Interaction
Tab	Places the focus on the next interactive element, which is either a button or a close button.
Shift + Tab	Places the focus on the previous interactive element, which is either a button or a close button.
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 button.

Changelog#

Date	Number	Notes
Apr 06, 2022	6.0.0	Updated all colors to 6.0.0
Mar 29, 2021	5.0.1	Updated font weight from bold to regular Updated line height to use component line height
Apr 20, 2019	5.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).

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

N/A

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.

In-line alert

Tooltip