Status Banner

On this page

Example

Designer guidance

Developer guidance

Content editor guidance

Accessibility 

Support

Designer Guidance

When to use

Use a status banner to communicate important system statuses, alerts, or feedback. For example:

• System status updates - Keep users informed about ongoing processes, such as error states, maintenance, or service disruptions.
• 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

Avoid using a status banner in the following situations:

• Non-critical information - If the message isn’t urgent, consider using inline text instead.
• Permanent information - Use inline content or a dedicated page element.
• Repeated or frequent alerts - These can reduce visibility and make it harder for users to notice genuinely important information.

How to use

• Use this component in a prominent position, preferably at the top of the relevant page or section they relate to.
• Use no more than one banner per page, or relevant section if the banner is being used in a subcomponent.
•  Do not place in a section that requires the user to scroll to view.
• For dynamic banners(e.g. live updates), ensure assistive technologies announce changes correctly.

Behaviour


• Status banners are persistent. 
• This component does not use animation or movement to attract attention, this can distract or overwhelm users. 
• This component should never obscure other key 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 ( icon → text → actions), 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.