Banner

Anatomy

import {Banner} from '@staffbase/design';

<Banner>
  <Banner.Close />
</Banner>

Examples

Variants

Sizes

Layouts

API reference

Banner

Close

Banner.Close accepts all native <button> props.

Accessibility

As notification

If you’re using the banner as a notification to announce the outcome of something the user has just done, add role="alert" to the component so assistive technologies announce the message immediately.

Semantic HTML

If you’re putting multiple elements inside the banner, use semantic HTML — for example h2 for the heading, p for the content, and button or a for the CTA.

When to use

• Show page-level status, feedback, or policy messages that must stay visible while users continue their current task.
• Choose this pattern when users need immediate clarity about a current state, such as a successful save, a warning, or a blocking error.
• Surface non-blocking guidance that supports the current flow without forcing users into a modal decision.
• Communicate system-level notices that affect the current page, workspace, or audience, such as visibility, policy, or permission context.
• Follow the Accessible notifications pattern when deciding whether a banner is the right notification pattern for the situation.

When not to use

• Don’t use a Banner to ask users to confirm destructive or high-risk actions — use AlertDialog instead.
• Don’t use a Banner for lightweight contextual content anchored to a trigger — use Popover instead.
• Don’t use a Banner for short hover or focus help text — use Tooltip instead.
• Don’t use a Banner to label the status of a single item in a list or table row — use Pill instead.
• Don’t use a Banner as the primary surface for form controls and multi-step input — use Card instead.

How to use

Structure

• Start with the key message first so users can understand the state in one scan.
• Keep banner content concise and self-contained, then move detailed explanation or workflows to surrounding page content.
• Place the close action at the end of the banner content so it stays predictable across variants and layouts.
• Use semantic content when you include multiple elements, such as a heading plus supporting body text.

Variants

• Use info for neutral guidance or contextual information without success or error semantics.
• Use success only after a user action completes successfully.
• Use warning for states that need attention soon but do not block progress yet.
• Use critical for errors, failures, or blocked states that require immediate action.
• Don’t choose variants for visual preference alone; always map them to message severity.

Size and layout

• Use size="sm" by default for compact, inline page communication with 12px body text.
• Use size="md" when the message needs more visual prominence with 14px text and increased padding.
• Use layout="standalone" when the banner sits inside another surface and should keep rounded corners.
• Use layout="bleed" when the banner must span the full available width with no border radius.

Accessibility

• Use role="alert" only for urgent updates that must be announced immediately by assistive technologies.
• Use a neutral live-region role such as status for non-urgent updates that should be announced without urgency.
• Add a specific aria-label to Banner.Close so screen reader users understand the close action.
• Don’t rely on color alone to communicate meaning; include explicit text that describes the state.

Content and UX copy

• Write one clear message that describes the current state and the next required action, if any.
• Keep language concise and concrete, and use terminology already present in the surrounding UI.
• Use sentence case for message text, and reserve title-style emphasis for optional inline headings only.
• Don’t stack multiple unrelated messages in one banner; use separate banners or page sections instead.