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. 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). How we choose 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
Project settings
Inline feedback: the result stays next to the action and does not move focus.
Implementation
- Say what happened and what the user can do next. Put field errors next to their inputs rather than only in a notification.
- 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.
- Reserve role="alert" for important, time-sensitive updates. It announces the message without moving keyboard focus.
- 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.
- 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?