Banner

Accessibility and usability expectations

Banners are designed with visual prominence so that they are emphasised and noticed by sighted users. To provide an equitable experience for screen reader users, banners should be easily discoverable by appearing in the heading hierarchy and landmarks of the page.

The type of banner message (critical, warning, success, info and upsell) must not be conveyed through colour alone. An icon is used to convey the type of banner message to colour blind users. A text description is used for screen reader users, either in the banner heading, or the accessible name of the banner's landmark or the icon.

The banner's icon, text content and border must meets minimum contrast requirements to help users with low vision see the banner.

The banner must be responsive, with all content remaining visible and readable with no horizontal scrolling, when the page is zoomed or viewed at a width equivalent to 320 CSS pixels.

If a banner contains links or buttons, they must have have a descriptive label and meets the minimum target size of 24 by 24 CSS pixels.

When a banner is dismissed, focus must not be lost, focus must move to a useful place in the page so that keyboard users can easily continue their journey.

When a banner dynamically appears in a page, the new content needs to be immediately obvious to all users, and when it contains action controls should be easily reachable with a keyboard. When the banner contains essential information focus must moves to the banner. When the banner contains non-essential information and moving focus to the banner would be disruptive, the content must be automatically announced by screen readers by using a live region.

Built-in accessibility features

The banner is rendered as a <section> landmark region, with an accessible name that indicates the type of banner, and contains an <h2> heading that by default indicates the type of banner. The heading text can be visually hidden and over-ridden with different text. The landmark and heading enable screen reader users to easily discover the banner and know what type of message it contains.

The type of banner is conveyed by an icon, in addition to colour, so that color blind users know what type of message it contains.

The icon is decorative for screen reader users and has aria-hidden="true" applied to hide it from the accessibility tree.

The banner's icon, text content, action link and button and border colour meets minimum contrast requirements for all variants.

The dismiss button has a recognisable close icon and descriptive accessible name.

The action controls and dismiss button meet the minimum target size of 24 by 24 CSS pixels.

The banner is responsive, adjusting to the available space, with all content remaining visible and readable with no horizontal scrolling.

Implementation requirements

If a banner contains an action control you must provide a sufficiently descriptive label.

When using a live region, ensure that they are implemented correctly so they can be announced by all screen readers and browser combinations. See Why are my live regions not working? for further information.

Feedback Banners

Banners that are used to communicate feedback require extra accessibility considerations to ensure they are immediately perceived by assistive technology users.

Consider using either a live region announcement or focus management technique:

• Live region announcements: can be used to announce the new content to screen reader users. This is the preferred method for non-critical information (though exceptions apply, such in scenarios where focus loss needs to be handled).
• Focus management: involves shifting a user's focus directly to the new Banner. This method is disruptive when used inappropriately, but is extremely helpful in scenarios where we need to guide the user towards an action.

Here are some questions to consider when deciding which method to use:

Will the user be blocked if they miss the Banner?

If a user is blocked from proceeding if they miss the Banner, moving focus is usually preferred over a live region announcement.

A prime example of this is an error banner that appears after a form validation, such as interactive error summary. Moving focus directly into the error banner allows all users (including screen reader users, zoom magnification users, and sighted keyboard users), to immediately perceive the feedback and take the necessary action to resolve the issue.

If the banner communicates non-critical information (e.g. a success banner) that wouldn't block a user if missed, a live region announcement is sufficient.

Does the Banner contain an action?

If the Banner contains an action, placing focus on the newly shown Banner may be preferred over a live region announcement, especially if the action helps unblock/guide a user within a current flow. This ensures the user can immediately interact with the action without having to manually locate it.

Where is a user's focus when the banner appears?

If a user triggers an action that results in the element that they were were on being removed from the DOM (that isn't a result of a page navigation), then focus management is required. For example, let's say that a user activates a Save button successfully, and the section of the page they were on gets replaced by new content. The removal of the Save button from the DOM will result in the user's focus getting lost.

Focus loss is disorienting, especially when some assistive technology users are unexpectedly taken back to the top of the page after performing an action. This is a WCAG 2.4.3 Focus Order issue.

If the Banner appears as part of the new content on the page after a user experiences focus loss, then it may be an appropriate focus target. This does not apply to scenarios where the user is navigated to a completely new route.

Still unsure?

Many scenarios are nuanced, and can be tricky to figure out the appropriate path forward for. These benefit from additional feedback from assistive technology users.

If you're unsure about which technique is appropriate for your use case, please reach out to the Accessibility team who can help find a path forward.

How to test the component

Integration tests

• If a banner contains an action control it has a sufficiently descriptive label
• If a banner is dynamically added to a page without a page reload, focus is either moved to the banner or the banner content is automatically announced by screen readers through the use of a correctly implemented live region. When a banner contains essential content focus is moved to it.

Component tests

• The banner component is exposed as a section landmark with a name appropriate for its variant type
• The banner has a default heading that matches the variant type
• The banner heading can be visually hidden and remains in the accessibility tree
• The banner heading text can be overridden and the landmark's name remains the default value
• The banner icon is appropriate for the variant type
• The banner icon has aria-hidden="true" and is hidden from the accessibility tree
• The banner's icon, text content, action link, and button and border colour meet minimum contrast requirements, for all variants
• The dismiss button uses the close icon and has a descriptive accessible name
• The action controls and dismiss button meet the minimum target size of 24x24 CSS pixels
• The banner is responsive, adjusting to the available space, with all content remaining visible and readable with no horizontal scrolling