Toasts display brief, temporary notifications. They're meant to be noticed without disrupting a user's experience or requiring an action to be taken.
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.
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.
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.
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.
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.
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.
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.
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 appear.
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, 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.|
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.
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.
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.
On mobile apps, be mindful of important navigation bars at the bottom of the screen by placing toasts vertically above these components.
Actionable toasts should only have one button, in the form of a static white, secondary outline button.
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.
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.
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.
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.
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.
For an informational message (informative variant), write in a complete sentence following the formula of subject + verb phrase + optional additional information.
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.
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.
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.
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.
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.
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.
|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.|
|Apr 06, 2022||6.0.0|
|Mar 29, 2021||5.0.1|
|Apr 20, 2019||5.0.0|
Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).
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).
Color is not used as the only visual means of conveying information (WCAG 2.0 1.4.1).
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).
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).
UI language and information design considerations have been incorporated into component design.
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)
Includes guidelines for keyboard focus, layout (wrapping, truncation, overflow), animation, interactions, etc.
Includes a list of dos and don'ts that highlight best practices and common mistakes.
Includes content standards or usage guidelines for how to write or format in-product content for the component.
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.
All design attributes (color, typography, layout, animation, etc.) are available as design tokens.
Includes a downloadable XD file that shows multiple options, states, color themes, and platform scales.
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.
Component is included in the Spectrum for Adobe XD plugin.