Toast

Version 6.0.0

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

Example of the toast component, with an icon and text and divider and a close button. It's green which is the positive semantic color.
DateVersionSpectrumApr 06, 20226.0.0DownloadMar 29, 20215.0.1DownloadApr 20, 20195.0.0Download

Anatomy#

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

Options#

Key example of neutral toast. Text, All files archived.

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.

Key example of neutral variant toast. Text, Link copied.

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.

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

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

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 vision deficiency to discern the message tone. This is used to show an error or failure.

Examples of four toasts that include an action. Neutral toast text, All files 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 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.

PropertyValuesDefault Valuetexttext–variantneutral / informative / positive / negativeneutralaction labeltext
If undefined, this button does not appear.
–is auto-dismissibleyes / nono

Priority queue#

PriorityToast VariantAuto-dismissBehavior1Actionable, 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, positiveNoIs 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.6PositiveOptionalIf 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, 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.

do
Example of a properly implemented Toast that displays a simple message confirming a file upload is complete.
dont
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 center for both desktop and mobile platform scales to avoid disrupting the user experience.

For desktop applications, a toast should be placed 16 px away from the bottom 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 disrupts the user experience, its placement can be changed to bottom end, top end, or top center.

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

Don’t place mobile toasts over navigation#

On mobile apps, be mindful of important navigation bars at the bottom of the screen by placing toasts vertically above these components.

do
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.
dont
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.

do
Example of a properly implemented actionable Toast that contains only one action. Text, File archived. Button label, Undo.
dont
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.

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

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

do
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.
dont
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.

3 key examples of toasts with confirmation messages. First example, positive variant in green with a checkmark icon, text Copied to clipboard. Second example, positive variant in green with a checkmark icon, text Saved to Your work. Your work is formatted in bold because it is the name of an interface element. Third example, neutral variant in grey, text Item archived.

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.

2 key examples of toasts with error messages. Both examples in red, with warning icons. First example, text Payment failed, button label Update info. Second example, text 2 fonts missing, button label Show.

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.

do
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.
dont
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.

do
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.
dont
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.

do
Key example of the correct way to write a toast using generic language to communicate the message. Toast text, Item archived,
dont
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.

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

Changelog#

DateNumberNotesApr 06, 20226.0.0
  • Updated all colors to 6.0.0
Mar 29, 20215.0.1Apr 20, 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).

check

All color themes

Works properly across all four color themes (lightest, light, dark, darkest).

check

All platform scales

Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).

check

Accessible use of color

Color is not used as the only visual means of conveying information (WCAG 2.0 1.4.1).

check

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

check

Content design

UI language and information design considerations have been incorporated into component design.

check

Defined options

Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)

check

Defined behaviors

Includes guidelines for keyboard focus, layout (wrapping, truncation, overflow), animation, interactions, etc.

check

Usage guidelines

Includes a list of dos and don'ts that highlight best practices and common mistakes.

check

Writing guidelines

Includes content standards or usage guidelines for how to write or format in-product content for the component.

check

Internationalization guidelines

Works properly across various locales and includes guidelines for bi-directionality (RTL).

check

Keyboard interactions

Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.

check

Design tokens

All design attributes (color, typography, layout, animation, etc.) are available as design tokens.

check

UI kit

Includes a downloadable XD file that shows multiple options, states, color themes, and platform scales.

check

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.

check

In Spectrum for Adobe XD plugin

Component is included in the Spectrum for Adobe XD plugin.