presentation form · Feedback and notices
Banner
A prominent page-level message region that persists while a condition, announcement, or required awareness remains relevant.
Decisive boundary
Do not confuse a visual banner message with the ARIA banner landmark for site-level header content.
Definition and intent
What is a Banner UI pattern?
Use the behavior, not the silhouette
A prominent page-level message region that persists while a condition, announcement, or required awareness remains relevant. The term is used here as a presentation form that describes placement or motion without deciding every semantic behavior. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Keep a broad condition or announcement visible across the relevant page scope. A good implementation preserves that job while making the trigger, open state, close path, and responsive behavior observable to users.
Know when the label is wrong
The fastest way to identify a pattern is often to reject the nearest alternative. For Banner, the boundary is: Do not confuse a visual banner message with the ARIA banner landmark for site-level header content.
Do not implement it as Toast for short event feedback and Notification for a personal message history. If those requirements describe the real task better, use the related pattern page or the full Feedback and notices comparison before writing code.
Decision process
Decide before choosing a component
Record these requirements in plain language. A library component name is not a substitute for the contract.
Confirm the user job
Keep a broad condition or announcement visible across the relevant page scope.
Define opening and closing
Page load, application state, or a relevant system condition. Optional close or automatic removal when the condition resolves.
Specify access behavior
Does not steal focus; actions enter normal focus order. Links, actions, and close controls are keyboard operable.
Reject the near miss
Toast for short event feedback and Notification for a personal message history.
Behavior contract
What must survive the build
- trigger
- Page load, application state, or a relevant system condition.
- dismissal
- Optional close or automatic removal when the condition resolves.
- modality
- Non-modal.
- focus
- Does not steal focus; actions enter normal focus order.
- keyboard
- Links, actions, and close controls are keyboard operable.
- interactive
- May contain one or two clear actions related to the message.
- persistence
- Persists while the page-level condition matters.
- placement
- Prominent horizontal region near the top of the relevant scope.
- mobile
- Wrap content without covering navigation or consuming the full viewport.
Failure modes
Common wrong builds
- Auto-dismissing a condition that still applies.
- Using the banner landmark role for a message.
- Stacking several banners until content disappears.
Observable checks
Verify the result
- The scope is clear.
- The message remains while the condition applies.
- Actions are keyboard reachable.
- It does not steal focus.
- Mobile content remains visible below it.
Coding-agent handoff
Implementation brief template
Pattern: Banner Purpose: Keep a broad condition or announcement visible across the relevant page scope. Trigger: Page load, application state, or a relevant system condition. Dismissal behavior: Optional close or automatic removal when the condition resolves. Modality: Non-modal. Focus behavior: Does not steal focus; actions enter normal focus order. Keyboard behavior: Links, actions, and close controls are keyboard operable. Interactive content: May contain one or two clear actions related to the message. Placement: Prominent horizontal region near the top of the relevant scope. Mobile behavior: Wrap content without covering navigation or consuming the full viewport. Do not implement as: Toast for short event feedback and Notification for a personal message history. Acceptance checks: - The scope is clear. - The message remains while the condition applies. - Actions are keyboard reachable. - It does not steal focus. - Mobile content remains visible below it.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Banner UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Banner in web UI?
A prominent page-level message region that persists while a condition, announcement, or required awareness remains relevant. In this reference set it is a presentation form that describes placement or motion without deciding every semantic behavior.
When should I use a Banner?
Keep a broad condition or announcement visible across the relevant page scope. The decisive boundary to confirm is this: Do not confuse a visual banner message with the ARIA banner landmark for site-level header content.
What keyboard and focus behavior does a Banner need?
Links, actions, and close controls are keyboard operable. Does not steal focus; actions enter normal focus order. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Banner behave on mobile?
Wrap content without covering navigation or consuming the full viewport. Its modality is a separate requirement: Non-modal.
How do I verify a Banner implementation?
Start with observable checks: The scope is clear. The message remains while the condition applies. Actions are keyboard reachable. Then verify the remaining checks and compare the result with the linked source guidance.