Alert banners show pressing and high-signal messages, such as system alerts. They're meant to be noticed and prompt users to take action.
Text is required for all alert banners. The message should be concise and, if applicable, describe the next step that a user can take.
An alert banner always has a semantic meaning and uses semantic colors. Only gray (neutral), blue (informative), and red (negative) are available as options.
An alert banner ideally provides a way for a user to address an issue in-line with an action. It can have both an icon-only close button and a button with a contextual action to take. There should never be more than one button with a contextual action in an alert banner.
An alert banner can include an icon-only close button to dismiss it.
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 / negative | neutral |
action label | text If undefined, this button does not appear. | – |
is dismissible | yes / no | no |
When the text is too long for the available horizontal space, it wraps to form another line. In actionable alert banners, the button moves below the text prior to text wrapping.
Whenever possible, add an in-line action button if there's a way for a user to quickly address the issue associated with an alert.
The close button is optional, depending on context. Consider adding one to let a user easily dismiss the alert.
Alert banners should be reserved only for high-signal, system-level alert messages, such as internet connection issues, expirations of subscriptions, or major changes.
For in-app notifications, lightweight confirmations of actions, or more promotional messaging, use a toast, badge, or other component.
Don’t use yellow or orange colors for errors because the contrast is not accessible.
If you need to show a “notice” message or other non-critical communication, use the gray (neutral) or blue (informative) semantic color options. Reserve the red (negative) option only for errors that directly interrupt or block a user’s experience — not for nice-to-know information.
Don't include more than one action in an alert banner. Having more than one action to choose from can be overwhelming, and it can become difficult for users to decide what to do next in such a small space.
Alert banners should appear at the top of a page, below the header.
Don't show multiple alert banners at the same time. If a new alert banner appears with a higher priority message, it should replace an existing alert banner of lesser importance until the higher priority one has been addressed.
Overlay an alert banner when it's expected to fade in and out without impacting the content underneath it, and when it's not hiding any important actions or information by being there. An alert banner should only overlay content if it is dismissible.
Push an alert banner when it's expected to stay in place, when it's not dismissible, or when no information should be hidden from the view.
If a user dismisses an alert banner without addressing an error that needs to be resolved, it should come back into view at the next possible occasion.
Never allow alert banners to time out. Since these are system-level messages, they should not dismiss on their own unless there is a change in the system that resolves an issue (e.g., regaining internet connectivity after losing it).
Do not include periods in alert banner messages that are short phrases or single sentences. This helps keep the text quicker to read and easier to parse.
If the message must be more than one sentence in order to convey the alert's information, use a period at the end of each sentence.
Keep an alert banner's message concise while still being clear, using either a short phrase or a complete sentence that describes what's happening and what someone needs to know.
Whenever possible, include an in-line action for a user to take so that they can readily address the issue explained in the message.
For RTL (right-to-left) languages, the layout of the alert banner is mirrored. The icon is right-aligned and the close button is left-aligned. If the alert banner is actionable, the button appears on the left side.
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 alert banner. If focus is on the button, executes the button action. |
Esc | Dismisses the alert banner if possible. This is equivalent to selecting the close button. |
Date | Number | Notes |
---|---|---|
Apr 06, 2022 | 3.0.0 |
|
Nov 10, 2020 | 2.0.1 |
|
May 22, 2020 | 2.0.0 |
|
Mar 13, 2020 | 1.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.