# Toast, banner, or inline message?

[Website version](https://patterns.alexanderclaes.com/patterns/toast-or-banner/)

Updated 30 October 2026

Match the message's placement and persistence to its importance and scope.

## Sources take different approaches

GOV.UK recommends main-page content for information directly relevant to the current task and documents success banners with focus behavior on page load. This guide gives broader placement advice and describes in-page status announcements without moving focus. Those are different contexts, not interchangeable instructions.

**Preferred starting point:** [GOV.UK · Notification banner guidance](https://design-system.service.gov.uk/components/notification-banner/). Start with GOV.UK for choosing the notification placement. Apply WCAG status-message requirements when feedback updates without a change of context; do not assume an ARIA role itself moves focus.

Compare: [W3C · Status messages (WCAG 4.1.3)](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html). [How we choose sources](https://patterns.alexanderclaes.com/about/#sources).

## Recommendation

Prefer inline feedback for local actions. Use a persistent banner for page- or service-wide information, and a toast when missing it will not block the task.

## Problem

I need to tell the user something changed.

## Choose inline feedback, a banner, or a toast

- Inline feedback explains a field error or the result of a local action.
- A banner communicates an ongoing issue that affects the page or service.
- A toast confirms a low-risk action whose result remains discoverable elsewhere.

## Notification patterns to avoid

- A disappearing toast containing the only explanation of a serious failure.
- Interrupting the whole page for an ordinary successful save.

## Example

[View the example on the website](https://patterns.alexanderclaes.com/patterns/toast-or-banner/#example).

## Implementation

1. Say what happened and what the user can do next. Put field errors next to their inputs rather than only in a notification.
2. Expose dynamic status messages to assistive technology without moving focus. For routine updates, put role="status" on an existing container before updating its text; this provides polite announcements.
3. Reserve role="alert" for important, time-sensitive updates. It announces the message without moving keyboard focus.
4. For timed toasts, keep the same information and actions available elsewhere, or meet WCAG’s timing-adjustment rules. An arbitrary longer timeout is not enough.
5. Choose semantics separately from appearance. ARIA role="banner" identifies the site header landmark, not a notification banner.

## Tradeoffs

Toasts save space but are easy to miss. Persistent banners remain available but can still be overlooked. Inline feedback gives the clearest context for a local action; avoid stacking messages that compete with the task.

## Verification

With keyboard and screen reader, is new feedback announced without moving focus? If a message disappears, can the user still find its information and perform the same actions?

## References

- [W3C · Status messages (WCAG 4.1.3)](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html)
- [W3C · Implementing role="status"](https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA22)
- [W3C · Timing adjustable (WCAG 2.2.1)](https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html)
- [W3C · The banner landmark role](https://www.w3.org/TR/wai-aria-1.2/#banner)
- [GOV.UK · Notification banner guidance](https://design-system.service.gov.uk/components/notification-banner/)

## Related patterns

- [What should an error message say?](https://patterns.alexanderclaes.com/patterns/error-recovery.md)
- [Spinner, skeleton, or progress bar?](https://patterns.alexanderclaes.com/patterns/loading-states.md)