Components menu
  2. components
  3. feedback indicators
  4. banner

Banner

Informs merchants about important changes or persistent conditions. Use this component if you need to communicate to merchants in a prominent way. Banners are placed at the top of the page or section they apply to, and below the page or section header.

Examples

  • Use to convey general information or actions that aren’t critical. For example, you might show a banner that asks for merchant feedback.
  • Default banners contain lower priority information and should always be dismissible.
Drag to resize example

Props

action
DisableableAction & LoadableAction
Action for banner
children
React.ReactNode
The child elements to render in the banner.
icon
string | FunctionComponent
Icon to display in the banner. Use only major, duotone icons
secondaryAction
Action
Action | Displays a secondary action
status
"success" | "info" | "warning" | "critical"
Sets the status of the banner.
stopAnnouncements
boolean
Disables screen reader announcements when changing the content of the banner
title
string
Title content for the banner.
onDismiss
() => void
Callback when banner is dismissed

Accessibility

Banners provide context and assist workflows for merchants with disabilities.

  • Critical and warning banners have a role=”alert” and are announced by assistive technologies when they appear.
  • All other banners have a role=”status” and are read after any critical announcements.
  • All banners have an aria-live attribute and are announced by assistive technologies when their content is updated. These announcements can be disabled by using the prop stopAnnouncements.
  • Banners use aria-describedby to describe their purpose to assistive technologies when they’re announced or receive focus. If a banner has a title, then the title content is used for the aria-describedby. If the banner doesn’t have a title, then all of the banner content is used for the aria-describedby.
  • Banner containers have a tabindex=”0” and display a visible keyboard focus indicator. Because of this, merchants can discover banners while tabbing through forms or other interactions, and developers can programmatically move focus to banners.
  • Banners use a combination of icons and colors to show their meaning and level of importance to merchants.

Error notifications in forms

Critical banners

When merchants submit long or complex forms with errors, use a critical banner to summarize what went wrong. Place the banner at the top of the form and move focus to the banner when the form is submitted. This allows all merchants to move through the form in a logical order to correct the issues.

Inline errors

Always include inline error messages for specific form fields so that merchants know what to do in context as they correct their mistakes.

To learn about creating helpful and accessible error message text, see the guidelines for error messages.

Do

  • Put banners close in context to the problem they’re referring to
  • Give banners with a lot of information a clear title that summarizes their content
  • Move focus to banners if they’re relevant to the merchant’s current workflow and need to be addressed immediately

Don’t

  • Move focus to banners if they appear on page load, or outside the merchant’s current workflow
  • Use warning or critical (role=”alert”) banners to convey information that the merchant doesn’t need to address immediately

Default banners

  • Use to convey general information or actions that aren’t critical. For example, you might show a banner that asks for merchant feedback.
  • Default banners contain lower priority information and should always be dismissible.

Default banner for Android

Banner with footer call-to-action

Use when you want merchants to take an action after reading the banner.

Banner with footer call-to-action for Android

Informational banners

Use to update merchants about a change or give them advice.

Informational banner for Android

Success banner

  • Default to using toasts for success messages, unless the feedback is delayed, persistent, or has a call to action
  • Include next steps if applicable

Success banner for Android

Warning banners

  • Use to display information that needs attention or that merchants need to take action on
  • Seeing these banners can be stressful for merchants so be cautious about using them

Warning banner for Android

Critical banners

  • Use to communicate problems that have to be resolved immediately for merchants to complete a task
  • For example, you will show this banner for orders with high fraud risk
  • Seeing these banners can be stressful for merchants so be cautious about using them

Critical banner for Android

Accessibility

See Material Design and development documentation about accessibility for Android:

Default banners

  • Use to convey general information or actions that aren’t critical. For example, you might show a banner that asks for merchant feedback.
  • Default banners contain lower priority information and should always be dismissible.

Default banner for iOS

Banner with footer call-to-action

Use when you want merchants to take an action after reading the banner.

Banner with footer call-to-action for iOS

Informational banners

Use to update merchants about a change or give them advice.

Informational banner for iOS

Success banner

  • Default to using toasts for success messages, unless the feedback is delayed, persistent, or has a call to action
  • Include next steps if applicable

Success banner for iOS

Warning banners

  • Use to display information that needs attention or that merchants need to take action on
  • Seeing these banners can be stressful for merchants so be cautious about using them

Warning banner for iOS

Critical banners

  • Use to communicate problems that have to be resolved immediately for merchants to complete a task
  • For example, you will show this banner for orders with high fraud risk
  • Seeing these banners can be stressful for merchants so be cautious about using them

Critical banner for iOS

Accessibility

See Apple’s Human Interface Guidelines and API documentation about accessibility for iOS:

Best practices

Banners should:

  • Be placed in the appropriate context:
    • Banners relevant to an entire page should be placed at the top of that page, below the page header. They should occupy the full width of the content area.
    • Banners related to a section of a page (like a card, popover, or modal) should be placed inside that section, below any section heading. These banners have less spacing and a pared-back design to fit within a content context.
    • Banners related to an element more specific than a section should be placed immediately above or below that element.
  • Focus on a single theme, piece of information, or required action to avoid overwhelming merchants.
  • Be dismissible unless they contain critical information or an important step merchants need to take.
  • Be concise and scannable—merchants shouldn’t need to spend a lot of time figuring out what they need to know and do.
  • Be limited to a few important calls to action with no more than one primary action.
  • Be used thoughtfully and sparingly for only the most important information.
  • Not be used as the primary entry point to information or actions merchants need on a regular basis.
  • Not be used for marketing information or upsell—use callout cards instead.
  • Use the default icon for success, info, warning and critical statuses. If the icon is changed, use only major, duotone icons.

Content guidelines

To learn about writing helpful and accessible error message text, see the guidelines for error messages.

Title

Banner titles should follow the content guidelines for headings and subheadings.

Body content

Body content should:

  • Be concise: keep content to 1 to 2 sentences where possible
  • Clarify the benefit of the main task
  • Be written in sentence case and use appropriate punctuation
  • Avoid repeating the heading
  • Explain how to resolve the issue, particularly for warning and critical banners

  • Your online store has a maximum of 20 themes. Delete unused themes to add more.

  • You have reached your theme limit. Your online store has reached its maximum of 20 themes. To add more themes, delete themes you’re no longer using.

Button and links

Buttons and links should be:

  • Clear and predictable: merchants should be able to anticipate what will happen when they click a button. Never deceive merchants by mislabeling a button.

  • Buy shipping label

  • Buy

  • Action-led: buttons should always lead with a strong verb that encourages action. To provide enough context to merchants use the {verb}+{noun} format on buttons except in the case of common actions like Save, Close, Cancel, or OK.

  • Activate Apple Pay

  • Try Apple Pay

  • Scannable: avoid unnecessary words and articles such as the, an, or a.

  • Add menu item

  • Add a menu item

Link text should:

  • Set the expectation of where merchants will be taken

  • Order #001

  • Order

  • Use consistent content to label navigation. For example, if a navigational link leads to a page called Orders, label the link Orders.

  • Payments

  • Finance section

Secondary body content

Body content should be:

  • Actionable: start sentences with imperative verbs when telling merchants what actions are available to them (especially something new). Don’t use permissive language like “you can”.

  • Get performance data for all your sales channels.

  • Now you can get performance data for all your sales channels.

  • Structured for merchant success: always put the most critical information first.
  • Clear: use the verb “need” to help merchants understand when they’re required to do something.

  • To buy a shipping label, you need to enter the total weight of your shipment, including packaging.

  • To buy a shipping label, you must enter the total weight of your shipment, including packaging.

Edit source on GitHub