skip to content

In a design system's feedback components, how should severity levels map to visual treatment and to polite or assertive announcements?

level: middleimportance: should knowfreq 45%

answer

  1. info, success, warning, error
  2. icon and words, not colour alone
  3. results politely, urgency assertively
  4. never steal focus
  5. assertive is a scarce resource

basics

~10 s

Each severity gets a text label or icon plus colour, never colour alone. Success and information are announced politely; only messages that need immediate attention are assertive, and no feedback message moves focus.

solid answer

~40 s

Many systems define four severities — **info, success, warning, error** — and each gets a consistent colour, an icon and often a word ('Error:'), so severity never depends on colour alone (WCAG 2.2 1.4.1 Use of Color, Level A), and an icon that carries meaning keeps 3:1 contrast under 1.4.11 Non-text Contrast (Level AA). For announcements the system maps severity to **politeness**: confirmations and results are **polite** status messages, read at the next pause; warnings and errors that need attention now are **assertive** alerts, read immediately. The WCAG techniques for 4.1.3 Status Messages pair success messages with a polite status announcement and errors with an assertive alert in the same way. Assertive is kept scarce, because it interrupts whatever is being read. And no feedback message moves focus: that turns it into a dialog.

go deeper

for a junior

Recall the four common severities and that each needs an icon or word as well as colour.

for a middle

Explain polite versus assertive in terms of interruption, which severities map to which, and why no feedback message moves focus.

for a senior

Diagnose an app that interrupts screen-reader users constantly or never announces errors, and fix it by building the mapping into the components.

for a principal

Decide how many severities the system supports and who may override the announcement mapping, weighing flexibility against predictability.

## Severity as a system vocabulary A **severity level** tells the user how much a message matters. Design systems usually settle on a small, fixed set so every product uses the same scale: | Severity | Meaning | Streaming-service example | |---|---|---| | **Info** | Neutral news | 'New episodes every Friday' | | **Success** | An action completed | 'Download complete' | | **Warning** | Something may go wrong or needs attention soon | 'Your plan ends in 3 days' | | **Error** | Something failed and needs action | 'Playback failed — check your connection' | Some systems add a separate **critical** level for outages or security events; a fifth level is worth adding only if it changes behaviour, not just colour. ## Visual treatment: redundant cues Each severity is carried by **more than one cue**: - **Colour** from the system's functional status palette. - An **icon** with a distinct shape per severity — a check, a triangle, a circle with a cross — so it reads without colour. - Often a **text prefix** ('Warning:') or a heading, which also reaches screen-reader users. This matters because WCAG 2.2 **1.4.1 Use of Color** (Level A) forbids colour as the only visual means of conveying information, and a severity icon that users need to understand the message must keep at least **3:1** contrast against its background under **1.4.11 Non-text Contrast** (Level AA). The message text itself falls under the ordinary text contrast rule. ## Announcements: polite or assertive A feedback message that appears without moving focus must still reach screen-reader users. WCAG 2.2 **4.1.3 Status Messages** (Level AA) requires that status messages can be presented by assistive technology **without receiving focus**. WAI-ARIA gives two urgencies: - **Polite** — updates are presented at the next graceful opportunity, such as the end of the current sentence. WAI-ARIA's status role implies it. - **Assertive** — updates have the highest priority and are presented immediately, interrupting. WAI-ARIA's alert role implies it. The understanding document for 4.1.3 pairs **success and result messages** with a status role and **warnings and errors** with an alert role or a live region. A design system turns that into a mapping on its feedback components: 1. **Info** and **success**: polite. 2. **Warning**: polite by default; assertive only if the user must act before continuing. 3. **Error** that blocks the current task: assertive. 4. **Error** in a background process the user is not waiting on: polite, often shown as an inline alert or banner. The mapping should be built into the components so teams choose a severity, not an announcement mode. ## Why assertive is scarce An assertive announcement **interrupts** whatever the screen reader is saying. Used for every 'Saved', it turns the interface into a stream of interruptions; the Authoring Practices alert page notes that frequent interruptions make WCAG 2.2.4 Interruptions harder to meet. Keep assertive for messages where waiting would cost the user something. ## What no feedback message does - It does **not move focus**. The Authoring Practices alert page is explicit that alerts must not affect keyboard focus; a message that takes focus is an alert dialog, a different component. - It does not rely on being present at page load to be announced. The same page notes that screen readers do not announce alerts already present before the page finishes loading, so a banner rendered on load is found by reading, not by announcement. ## Example: a playback error on the web player A viewer using a screen reader starts an episode on a streaming service's web player; the stream fails. The system shows an error inline alert over the player with an icon, the word 'Error' and 'Playback failed — check your connection, then try again', and announces it assertively because the viewer is waiting on playback. A minute later a download completes in the background: a success toast, announced politely, so it does not cut across the episode's audio description. ## Common mistakes - Severity shown only by background colour. - Every message announced assertively 'to be safe'. - Errors that move focus into the message, pulling users out of their task. - Each team choosing its own severity colours and icons. - A warning styled like an error, which teaches users to ignore the error styling. On native mobile platforms the same model holds: each platform's accessibility layer offers a way to announce a message without moving focus and a way to mark some announcements as more urgent, so the system's severity-to-urgency mapping is written once in the spec and implemented on each platform.

  • Why build the severity-to-announcement mapping into the components instead of letting teams choose?
    Teams pick a severity easily but choose politeness inconsistently, and the usual failure is everything assertive. Deriving the announcement from severity gives one predictable behaviour across the product and leaves an explicit override for the rare exception, which reviewers can then question.
  • A banner is rendered when the page loads. Will a screen reader announce it?
    Often not: the Authoring Practices alert page notes that screen readers do not announce alerts present before the page finishes loading. Put the banner early in the reading order with a clear heading or label so it is found immediately, and announce only changes that happen after load.

saying these in an interview costs you the question

  • Colour alone is enough to tell an error from a success message.
  • Every message should be assertive so screen-reader users never miss it.
  • An error message should move focus to itself so it is read.
  • Politeness only matters for web; native apps announce everything the same way.
  • Adding more severity levels always makes messages clearer.