To use BcBanner in a view, import it as usual:

import { BcBanner } from '@bugcrowd/bc-elements'

The Banner component’s markup is simple for the default state.

It becomes more complex when using the “Info”, “Warning” or “Error” variants as they are ARIA live regions.

The <BcBanner> React component automatically handles the ARIA attributes. See the React section.

Error variant HTML example

Here’s an example of the Banner’s more complex markup using the Error variant to demo the ARIA live region.

Note: the ARIA markup differs slightly again for the “Warning” and Info” variants.

<div class="bc-banner bc-banner--error" role="alert" aria-live="assertive">
  <span data-testid="bc-icons" class="bc-icons bc-icons--error-icon bc-icons--parent-color bc-icons--lg bc-banner__icon">
    <!-- SVG <BcIcons /> from spritesheet goes here. -->
  </span>
  <div class="bc-banner__message">
    <div class="bc-banner__copy">
      <div class="bc-banner__title">
        <h2>A global error has occurred.</h2>
      </div>
      <div class="bc-banner__description">
        <p>
          The sample was prevented from being inserted into the spectrum
          anaylzer to prevent a critical resonance cascade. You can override
          this in your <a href="/">Settings</a>.
        </p>
      </div>
    </div>
    <div class="bc-banner__actions">
      <!-- Actions such as more buttons or links go here (optional). -->
    </div>
  </div>
</div>

The default Banner is for static, yet important status information that should be shown on all pages, for example: to inform users they are accessing a restricted-access area.

The 3 Banner variants are all for status updates, that is live, more explit and/or ephemeral updates where the Banner is spawned due to some event or condition:

Info Banners

Use to tell users about globally-significant events or conditions, similar to the default banner, but for ephemeral events.

Warning Banners

Use to warn the user about possible danger or to caution them about something.

Error Banners

Use to alert the user that something has gone critically wrong and will degrade their experience.

The error message should, if possible, tell the user the cause of the problem, especially if their manual intervention is required.

Guidance for using Banners

What qualifies being important enough for a Banner?

Only use Banners for globally-significant events or conditions.

Only use “Warning” and “Error” Banners for actual globally-significant issues.

Do not use Banners for any form errors.

Multiple Banners

Avoid over-using too many Banners on a single page as it may overwhelm users.

When using multiple Banners do not spawn multiple Banners in quick succession because it may not allow a screen reader to finish reading out previous Banners’ content.

Closing Banners

By default Banners must only be closed or dismissed manually through user action, e.g. through a simple “Close” button.

Never automatically close Banners without giving users a global setting to turn auto-closing off, prior to encountering them, e.g. in user settings. See Timing adjustable auto-closing Banners below.

Writing good Banners

Banner content should be clear, accurate and easy to understand.

Use our Tone & Language guidance.

Follow the Design guidance and use semantic markup for the Banner’s title, copy, and links or actions.

Banner ARIA live region

The default Banner functions as simple page header content, statically persistent across all pages that state is relevant to.

However the Banner’s 3 variants all function as ARIA live regions to ensure these state updates are announced to screen readers and other assitive technologies (AT).

Beware that warning and error Banners will interrupt any screen reader readout with the Banner’s content.

The <BcBanner> React component automatically handles the ARIA attributes. See the React section on this page.

Timing adjustable auto-closing Banners

Avoid auto-closing or dismissing Banners as at least the 1st of the following provisions must be made:

• Turn off: The user is allowed to turn off the time limit before encountering it; or
• Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
• Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, “press the space bar”), and the user is allowed to extend the time limit at least ten times; or
• Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
• Essential Exception: The time limit is essential and extending it would invalidate the activity; or
• 20 Hour Exception: The time limit is longer than 20 hours.

Citation: WCAG SC 2.2.1: Timing Adjustable.

Users expect to informed about significant site- or application-wide notices and status updates.

The visual row-like “banner” layout makes it easy to place inside the page Header.

The Info, Warning, and Error variants use background-color to aid in visually signifying Banner type.

The visual and DOM order placement makes the Banner the logical position for the page’s global ARIA live regions.

The default Banner is not an ARIA live region as it would duplicate the “Info” variant. The default Banner should therefore be used for persistent messages in the page Header, rather than ones that have more explicit or ephemeral causes.

We do not auto-close Banners because global status messages must by default persist long enough for as many users to them. We may optionally give users a user setting to close/dismiss some variants automatically in the future.

In the Design System

• Toast
• Page alerts
• Primary Header

Further reading

• MDN: Using ARIA
• MDN: ARIA live regions
• Sara Soueidan: Accessible notifications with ARIA Live Regions (Part 2)