Status Banner

On this page

Anatomy

Designer guidance

Developer guidance

Content editor guidance

Accessibility 

Support

Anatomy

Designer Guidance

When to use

Use a status banner to communicate important messages about system status, user actions, or events that require attention, for example :

sklenflksnef ksenlfknseklfn lksenflskenfl lesknflsken lkenfslkenflsk lsenflskenklfsnelkf lkesnflkenflsknefklsnflkn slkenfslkenflsk aljwdnjndwjkla alwdnaljwndlanwldakjnlwd lawjndlanwdl  lwnrkjwn3krjnw kwj3rkjwn3jr 

• System status updates - Keep users informed about ongoing processes, such as maintenance, service disruptions, or system issues.
• Success messages - Confirm when users successfully complete an action, like submitting a form or finishing a task.
• Warnings - Alert users to potential issues that require attention, but don’t block progress.
• Errors - Notify users about critical issues that need immediate attention or correction.
• Information - Provide updates or guidance to help a user navigate a system or feature.

When not to use

Do not use a status banner in the following situations:

• Non-critical information - If the message isn’t important or time sensitive, use inline text instead.
• Permanent information - Use inline content or a dedicated page element for information that does not change.
• Repeated or frequent alerts - These reduce impact and may overwhelm users .

How to use

• Place the Banner in a prominent location, preferably at the top of the relevant page or section.
• Ensure the banner is visible without scrolling
• Use only one banner per page (or contained section if the banner is being used in a subcomponent.)
• Ensure dynamic banners (e.g. live updates) are announced correctly by assistive technologies.

Behaviour


• Status banners are persistent. 
• Do not use animation or movement. 
• The banner must never obscure content.
• Dynamic updates (e.g. new system messages) should be announced to assistive technology using the appropriate ARIA role (status or alert).

Options

This component is available in the following variants :

• Information - for contextual guidance.
• Warning - for potential issues or upcoming actions users should be aware of.
• Alert - For errors and other critical issues that need immediate user attention.

Developer Guidance

Best practices

• Enable full keyboard navigation.
• Ensure proper focus order, and avoid trapping focus within the banner.
• If a banner is removed dynamically, return focus to a meaningful location.
• Ensure screen readers can interpret structure, behaviour and state correctly.
• Use the appropriate ARIA role:
  • role="status" for non critical information.
  • role="alert" for urgent or critical information.

Content Editor Guidance

Best practices

• Keep banner text short and clear, aim for a single sentence or two at most.
• Front-load key information, start with the most important detail so users can grasp the message quickly.
• Include an actionable next step if appropriate.
• Use plain language, avoid jargon, acronyms, or overly technical terms.

Accessibility

A fully accessible banner must use the correct semantic roles (status or alert) so assistive technologies announce messages appropriately. It must provide sufficient colour contrast for text and icons, and never rely on colour alone to convey meaning. 

All interactions (links, actions, dismiss button) must be keyboard operable, with a visible focus indicator and adequate target size. 

Content should appear in a logical DOM order, reflow correctly on small screens, and remain readable with user-adjusted text spacing.

WCAG Success Criteria

• 1.3.2 Meaningful Sequence (Level A) 
  Ensure DOM order matches the visual order, so keyboard/screen-reader users encounter content logically.
• 1.4.10 Reflow (Level AA)
  On narrow viewports the banner reflows without loss of information or functionality (no horizontal scrolling).
• 2.1.2 No Keyboard Trap (Level A)
  Focus can enter and leave the banner; dismissing does not trap or strand focus.