Banner is a system-generated alert related to the overall experience of the product.
Overview
Banner is one of three types of notifications available in Odyssey. Banners let users know important messages related to their overall experience on the website. They can be purely informational messages or critical errors to act upon.
Anatomy
- Icon: The icon represents the severity of the notification and is supported by the background color.
- Description: Text content that provides details.
- Close button (optional): An affordance can be included to dismiss a banner.
- Action (optional): A link that will let the user address the notification or navigate to a dialog or page to see more details.
Demo
Open the component in Figma.
When to use
Use banners for these scenarios:
- When you have system-wide informational, warning, or error messages that require user attention.
- When you need an alert displayed according to the system settings (this could be a single view, a time period, or until an action is completed).
When not to use
Use another type of alert for scenarios when you need the information displayed for a different amount of time, or in a different location, or based on a user’s action.
Use a callout instead:
- When you need an alert to remain until an issue is fixed.
- When you need the alert to be in context of a specific area.
Use a toast instead:
- For transient feedback based on user action.
- For non-critical actions.
- To immediately confirm a user’s action.
Similar components
Behaviors
Placement
A banner is located at the top of the page.
Size
A banner takes up the full width of the page.
Dismissal
A banner will remain until the issue has been fixed or the message is no longer relevant.
A close affordance can also be included to let the user dismiss it on their own.
Status
Banner status signifies the purpose of the message. The banner background color and icon are different depending on the severity.
Accessibility
Odyssey components are designed and built to meet accessibility requirements out of the box. So, designers and engineers can focus on any accessibility concerns unique to their problem areas.
Our components meet WCAG 2.2 AA criteria and WAI-ARIA guidelines to provide a usable and accessible experience to everyone.
Content guidelines
Banners communicate a single important, succinct message and provide actions for users to become more informed or resolve the issue.
Description
- Start with the key actionable information.
- Use simple, clear words that match the severity of the banner status.
- Be concise: keep content to one sentence, ~80 characters maximum.
- Explain how to resolve the issue, particularly for warning and error banners.
- Start sentences with verbs when explaining what actions are available.
- Use full sentences.
- Use appropriate punctuation, including periods, commas, or semicolons.
- Write in sentence case (capitalize the first word and proper nouns only).
Link (optional)
-
Include a strong verb that encourages action.
Use the verb + noun format except in the case of common actions like Save, Close, Cancel, or OK. - Clearly explain the banner’s action.
- Keep link text to one to three words.
- Don’t use punctuation, with the exception of a question mark if absolutely necessary.
- See link.
Content accessibility
Icons and colors
-
Don’t change banner icons, colors, or text colors.
Banners use colors to provide consistent semantic meaning and communicate a level of visual importance for users. Each is designed to meet contrast requirements for accessibility.
However, color only supports banners' messages because it’s not conveyed by assistive technologies.
Description
- Use appropriate vocabulary and tone to clearly explain the severity of the banner message for users who can’t recognize certain colors.
-
No additional content is needed for accessibility tags or labels.
All banner content is automatically included in the aria-describedby to describe its purpose to assistive technologies when announced or receive focus.
Examples
Info
Warning
Error
