Prepared Docs

Overview

Banner communicates site-wide or session-level state at the top of the application shell. Use it for outages, reconnections, maintenance windows, and product announcements that should remain visible while the condition persists. Unlike Callout, which lives inline in a page region, Banner spans the app header and competes for a single attention slot.

Connection lost. Please check your internet connection. Attempting to reconnect...

When to use

For global or session-level state

Use Banner when the message applies to the whole console, not a single pane or form. Connection loss, scheduled maintenance, and cross-product announcements belong here.

For degraded but non-blocking conditions

Warning banners communicate transient or degraded states where the user can keep working. Pair them with reconnection or refresh actions only when the user can meaningfully respond.

For recovery confirmations

After a sustained outage resolves, a short Success banner can confirm recovery. Sequence it after any lingering Warning banner and auto-dismiss it when the message is non-actionable.

When not to use

For inline section context

Use Callout when the message qualifies a specific table, form, or workflow region.

For transient toast feedback

Use Snackbar for save confirmations, background sync notices, and other disposable outcomes that should not occupy the header.

For blocking decisions

Use Modal when the user must deliberately confirm or resolve a problem before continuing.

Types

BannerType maps to semantic intent. Use the lightest variant that still communicates urgency.

Info

Neutral announcements such as webinars, release notes, or product updates.

Warning

Important but non-actionable or transient degraded states. Example: reconnecting after a sustained websocket disconnect. Do not use error styling for reconnect churn.

Critical

User-actionable problems that require dismissal or a clear resolution path. Never auto-dismiss Critical banners.

Success

Resolution or recovery confirmations. Safe to auto-dismiss when the banner has no CTA.

Marketing

Promotional content with optional registration or learn-more actions.

Rule: never auto-dismiss banners that include a ctaButton or use BannerType.Critical.

Auto-dismiss

Non-actionable Success banners may auto-dismiss using content-aware timing:

Base perception buffer plus per-word reading time
Clamped between 3 and 10 seconds
Pauses while hovered or focused (WCAG 2.2.1 timing adjustable)

Actionable banners and Critical banners must remain until the user dismisses them or the underlying condition resolves.

Connection lost → restored pattern

For websocket or network recovery:

Show a yellow Warning banner after a sustained disconnect threshold.
Keep the warning visible for a minimum display time after reconnect so users can read it.
After the warning hides on reconnect, show a green Success recovery banner.
Apply a cooldown so recovery banners do not spam during reconnect churn.
Let the recovery banner auto-dismiss with pause-on-hover/focus.

Composition

Icon: optional leading SVG that reinforces intent.
Title: short declarative phrase.
Description: optional supporting line for reconnect or maintenance detail.
CTA: optional primary action such as refresh or learn more.
Dismiss: optional close control with tracking and accessible title text.

Accessibility

Root element uses role="alert" with a localized aria-label.
Dismiss buttons require an accessible title.
Auto-dismiss timers must pause on hover and focus.
Do not rely on color alone; pair variant, icon, and title wording.

Badge / Accessibility

Banner / Accessibility

Overview

When to use

For global or session-level state

For degraded but non-blocking conditions

For recovery confirmations

When not to use

For inline section context

For transient toast feedback

For blocking decisions

Connection lost → restored pattern

Composition

Accessibility

Overview

Connection lost. Please check your internet connection. Attempting to reconnect...

When to use

For global or session-level state

Use Banner when the message applies to the whole console, not a single pane or form. Connection loss, scheduled maintenance, and cross-product announcements belong here.

For degraded but non-blocking conditions

Warning banners communicate transient or degraded states where the user can keep working. Pair them with reconnection or refresh actions only when the user can meaningfully respond.

For recovery confirmations

After a sustained outage resolves, a short Success banner can confirm recovery. Sequence it after any lingering Warning banner and auto-dismiss it when the message is non-actionable.

When not to use

For inline section context

Use Callout when the message qualifies a specific table, form, or workflow region.

For transient toast feedback

Use Snackbar for save confirmations, background sync notices, and other disposable outcomes that should not occupy the header.

For blocking decisions

Use Modal when the user must deliberately confirm or resolve a problem before continuing.

Types

BannerType maps to semantic intent. Use the lightest variant that still communicates urgency.

Info

Neutral announcements such as webinars, release notes, or product updates.

Warning

Important but non-actionable or transient degraded states. Example: reconnecting after a sustained websocket disconnect. Do not use error styling for reconnect churn.

Critical

User-actionable problems that require dismissal or a clear resolution path. Never auto-dismiss Critical banners.

Success

Resolution or recovery confirmations. Safe to auto-dismiss when the banner has no CTA.

Marketing

Promotional content with optional registration or learn-more actions.

Rule: never auto-dismiss banners that include a ctaButton or use BannerType.Critical.

Auto-dismiss

Non-actionable Success banners may auto-dismiss using content-aware timing:

Base perception buffer plus per-word reading time
Clamped between 3 and 10 seconds
Pauses while hovered or focused (WCAG 2.2.1 timing adjustable)

Actionable banners and Critical banners must remain until the user dismisses them or the underlying condition resolves.

Connection lost → restored pattern

For websocket or network recovery:

Show a yellow Warning banner after a sustained disconnect threshold.
Keep the warning visible for a minimum display time after reconnect so users can read it.
After the warning hides on reconnect, show a green Success recovery banner.
Apply a cooldown so recovery banners do not spam during reconnect churn.
Let the recovery banner auto-dismiss with pause-on-hover/focus.