UX Patterns Guide
UI + UX Feedback, Status, And System State standard

Alert

Show a concise persistent alert in the current task context, choose urgency semantics from consequence, provide one direct next step or safe dismissal, and update or remove the alert when the condition resolves.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A current task has a time-sensitive warning, error, or important status change.
  • Users need immediate notice but should not be forced into a modal response.
  • The alert can be resolved, downgraded, or dismissed safely according to the underlying condition.

Avoid when

  • The message belongs beside one object, row, field, or local section.
  • The message can safely disappear after a few seconds.
  • The user must confirm, cancel, or choose before a high-consequence action proceeds.
  • A content region failed and needs a full recovery state.
  • The message applies across the site, product, account, or multiple sessions.
  • The update is routine, repeated, or low urgency.

Problem it prevents

Users need immediate notice of a time-sensitive task condition, but moving focus into a dialog or hiding the message in a transient notification would either over-interrupt the task or make the condition too easy to miss.

Pattern anatomy

What a strong implementation has to make clear

User need

A system, validation, connection, security, payment, save, or submission condition affects the user's current task now.

Pattern promise

Show a concise persistent alert in the current task context, choose urgency semantics from consequence, provide one direct next step or safe dismissal, and update or remove the alert when the condition resolves.

Required state

No-alert state with the task operating normally.

Recovery path

Users miss an urgent condition because the message auto-expires or appears far from the affected task.

Access contract

Use role alert for urgent dynamic text and avoid putting interactive controls inside the role-alert node itself.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A session alert appears above the active editor, says the session expires in 2 minutes, and offers Save draft while keeping the editor usable.
  • A connection alert stays near the workspace header and says changes are stored locally until the server reconnects.
  • Users can renew the session, save a draft, or inspect details without losing typed work.
  • When the connection returns, the alert downgrades to a success status and then can be dismissed safely.
Weak implementation

Vague, hidden, hard to recover from

  • A vague red strip says Warning with no object, consequence, or next step.
  • A payment hold alert opens as a modal with only OK even though no decision is needed.
  • The only warning that unsaved work will be lost disappears after five seconds.
  • A routine saved message interrupts screen reader output with assertive alert semantics on every keystroke.
UI guidance
  • Render an alert as a visible message in the current task area with a clear severity cue, short title, consequence-focused body, and one direct action or safe dismissal when appropriate.
  • Use assertive alert semantics only when an urgent message appears dynamically and needs immediate notice; use calmer status or region semantics for advisory, success, or already-visible page-load information.
UX guidance
  • Use alerts when the user must notice a time-sensitive condition that affects their current task, such as session expiry, lost connection, unsaved work risk, failed submission, or a security-sensitive hold.
  • Keep alerts tied to the current task outcome: name what changed, why it matters, what happens if the user does nothing, and which one next step resolves or clarifies the condition.
Implementation contract

What the implementation must handle

States

  • No-alert state with the task operating normally.
  • Urgent warning or error alert that appears dynamically and is announced without taking focus.
  • Advisory or success state that uses calmer status semantics rather than assertive alert semantics.
  • Actionable alert with one direct next step such as Save draft, Renew session, Retry sync, or Update payment.

Interaction

  • The alert appears close to the task area whose outcome it affects and before the controls users need next.
  • The alert title names the condition or affected process, not only the severity.
  • The body states the consequence and the most useful next step in one or two short sentences.
  • The alert does not steal focus, but its action and dismiss controls are reachable in normal tab order.

Accessibility

  • Use role alert for urgent dynamic text and avoid putting interactive controls inside the role-alert node itself.
  • Place actions adjacent to, but not inside, the asserted alert text when the alert needs controls.
  • Use status or region semantics for nonurgent messages and already-visible page-load content.
  • Do not move focus when the alert appears unless the user requested a detail route or a blocking response is required.

Review

  • Is the condition urgent enough to interrupt assistive technology output, or should it be a calmer status message?
  • Can users tell which current task, process, or page condition the alert affects?
  • Does the alert say what will happen if users do nothing?
  • Is one direct action enough, or does this need an error state, dialog, page, or panel?
Interactive lab

Inspect the states before you copy the pattern

Handle urgent current-task feedback

Switch alert severity, reveal details, dismiss a safe message, resolve the condition, and check that urgent updates announce without becoming a modal or toast.

Alert
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

No-alert state with the task operating normally.

Keyboard / Access

Alert appearance does not move focus away from the current task control.

Avoid Generating

Using a disappearing toast for warnings users must act on before continuing.
Evidence trail

Source-backed claims behind this guidance

U.S. Web Design System Alert Component

U.S. Web Design System - checked

USWDS describes alerts for system status and validation messages, with guidance for next steps, dismissibility, context, and ARIA role selection.

MDN ARIA Alert Role

MDN Web Docs - checked

MDN defines role alert as assertive live-region text for important time-sensitive messages and warns against overuse or required interaction.

Carbon Design System Notification

IBM Carbon Design System - checked

Carbon distinguishes notification types by placement, duration, interaction, and whether a message should persist or escalate.

Full agent/debug reference

Problem Context

  • A system, validation, connection, security, payment, save, or submission condition affects the user's current task now.
  • The message is more urgent than routine status but does not require the user to answer a modal decision.
  • The affected scope is the current page, workspace, step, or task flow rather than one table row, one input value, or the whole product.
  • Users can understand the situation from a short title and body, with optional detail routed elsewhere.

Selection Rules

  • Choose alert when a time-sensitive warning, error, or important status change must be noticed immediately without moving focus.
  • Use inline message instead when the message belongs directly beside one visible object, row, card, panel, or form section.
  • Use toast notification instead when the message can expire safely and does not need to remain in the task layout.
  • Use confirmation dialog instead when the user must explicitly choose before a consequential action proceeds.
  • Use error state instead when an expected content region failed and needs retry, fallback, support, or preserved-task recovery.
  • Use banner or site alert instead when the message applies across the product, service, account, or multiple pages.
  • Use role alert only for dynamically updated urgent text, and use status or region for less urgent messages.
  • Allow dismissal only when the underlying condition is resolved, recoverable elsewhere, or purely informational.

Required States

  • No-alert state with the task operating normally.
  • Urgent warning or error alert that appears dynamically and is announced without taking focus.
  • Advisory or success state that uses calmer status semantics rather than assertive alert semantics.
  • Actionable alert with one direct next step such as Save draft, Renew session, Retry sync, or Update payment.
  • Detail-revealed state for a short consequence explanation without expanding into a full recovery workflow.
  • Dismissed state when hiding the alert is safe.
  • Resolved state where the alert updates, downgrades, or disappears when the condition changes.
  • Escalated state where the condition moves to inline message, error state, banner, notification center, or confirmation dialog.

Interaction Contract

  • The alert appears close to the task area whose outcome it affects and before the controls users need next.
  • The alert title names the condition or affected process, not only the severity.
  • The body states the consequence and the most useful next step in one or two short sentences.
  • The alert does not steal focus, but its action and dismiss controls are reachable in normal tab order.
  • Urgent dynamic text is announced with alert semantics; advisory updates use status or region semantics.
  • Dismissal does not hide an unresolved critical condition with no alternate route.
  • When the condition resolves, the alert is removed, converted to lower-urgency status, or replaced by the correct recovery surface.

Implementation Checklist

  • Classify the condition by urgency, affected scope, user consequence, and whether a user response is required.
  • Place the alert in the current task region, not in a detached corner or global header unless the scope truly spans the product.
  • Write a title that names the issue, such as Session expires soon or Connection lost.
  • Write body text that explains what will happen and what the user can do next.
  • Limit actions to one direct command or one detail route; move multi-step recovery into a dedicated flow.
  • Choose role alert for urgent dynamic text, role status for lower-urgency status, and alertdialog when closure or response is required.
  • Do not create several assertive alerts at once; queue, merge, or prioritize them by consequence.
  • Test repeated alerts, dismissal, resolved state, screen reader announcement, keyboard reachability, zoom, and narrow layouts.

Common Generated-UI Mistakes

  • Using a disappearing toast for warnings users must act on before continuing.
  • Using a modal dialog for a message that only needs immediate notice and one optional next step.
  • Using alert semantics for routine success messages, progress ticks, or page-load content.
  • Putting product-wide maintenance or outage messages inside one task alert.
  • Showing several assertive alerts at the same time.
  • Writing severity-only copy such as Error or Attention without consequence or action.
  • Letting users dismiss a critical unresolved condition with no way to rediscover it.

Critique Questions

  • Is the condition urgent enough to interrupt assistive technology output, or should it be a calmer status message?
  • Can users tell which current task, process, or page condition the alert affects?
  • Does the alert say what will happen if users do nothing?
  • Is one direct action enough, or does this need an error state, dialog, page, or panel?
  • Can the alert be dismissed safely, and how can users rediscover unresolved conditions?
  • What happens when the condition resolves, repeats, or coexists with another warning?
Accessibility
  • Use role alert for urgent dynamic text and avoid putting interactive controls inside the role-alert node itself.
  • Place actions adjacent to, but not inside, the asserted alert text when the alert needs controls.
  • Use status or region semantics for nonurgent messages and already-visible page-load content.
  • Do not move focus when the alert appears unless the user requested a detail route or a blocking response is required.
  • Do not rely on color, icon, or severity label alone; include visible text that names the condition.
  • Avoid multiple simultaneous assertive alerts and provide a clear reading order for title, consequence, and next step.
Keyboard Behavior
  • Alert appearance does not move focus away from the current task control.
  • The first alert action appears after the alert text in normal tab order.
  • A dismiss control, when present, has an accessible name that includes the alert subject.
  • After dismissal, focus stays on the dismiss control's logical successor or returns to the invoking control when the user opened alert details.
  • If the alert opens a detail page, panel, or dialog, that destination follows the keyboard contract of that surface.
Variants
  • Error alert
  • Warning alert
  • Information alert
  • Success alert
  • Actionable alert
  • Dismissible alert
  • Connection alert
  • Session-expiry alert
  • Validation alert

Verification

Last verified: