Use warning text for a concise severe-consequence warning tied to an instruction or action; use alert for urgent current-task status, inline message for local object feedback, and error summary for submitted-form recovery.
Use warning text for a concise severe-consequence warning tied to an instruction or action; use alert for urgent current-task status, inline message for local object feedback, and error summary for submitted-form recovery.
Practice the judgment: Imagine this situation: A legal consequence is buried in ordinary hint text below the submit button, so users miss it before applying. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Warning text | Alert | Inline message | Error summary |
|---|---|---|---|---|
| UI or UX | UI + UX - Severe-consequence warning copy before an action | UI + UX - Urgent current-task status message | UI + UX - Contextual in-flow feedback | UI + UX - Form recovery summary |
| UI guidance | Render warning text as a short high-emphasis statement with a warning icon, visible or hidden warning label, and explicit consequence copy placed before the relevant action, declaration, or instruction. | 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. | Render the message inside the same row, card, panel, form section, or task region that it describes, with a clear tone, concise title, body text, and at most one local action or detail disclosure. | Render a top-of-form summary block with heading, linked error list, and matching field-level error messages. |
| UX guidance | Use warning text when users must understand a serious consequence before acting or failing to act, such as a fine, loss of access, permanent deletion, eligibility impact, or legal responsibility. | 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. | Use inline messages when users need contextual feedback while continuing nearby work, such as a row-level warning, section-level success, local policy note, or task-specific next step. | Move users from the summary to the exact field, group, or first invalid control that needs correction. |
| Good UI | Before Submit declaration, a warning with an exclamation icon says the user may be fined if they provide false information. | A session alert appears above the active editor, says the session expires in 2 minutes, and offers Save draft while keeping the editor usable. | An invoice row shows Missing billing contact directly beneath the affected customer with Add contact as the only action. | Top-of-form summary with a clear heading, linked error list, and matching inline field messages. |
| Bad UI | A red sentence says Important below the submit button after the user has already acted. | Users miss an urgent condition because the message auto-expires or appears far from the affected task. | A section message contains a full support workflow, several links, and unrelated settings controls. | Summary and field messages visually disconnected or contradictory. |
| Good UX | Users see the fine or eligibility consequence before checking the declaration and can pause to verify their answer. | When the connection returns, the alert downgrades to a success status and then can be dismissed safely. | A successful send message remains beside the invoice long enough to copy the generated reference. | After failed submit, focus or reading order makes the summary discoverable before users scan the form. |
| Bad UX | Users incur a penalty because the warning looked like ordinary hint text. | The only warning that unsaved work will be lost disappears after five seconds. | The message disappears like a toast even though users still need the invoice reference. | Only showing errors below the fold. |
| Best fit | A user must understand a serious consequence before taking or skipping an action. | A current task has a time-sensitive warning, error, or important status change. | A visible object or section has local status, warning, success, or next-step information. | Form submission can produce one or more errors. |
| Avoid when | The message is a dynamic task status that must be announced when it appears. | The message belongs beside one object, row, field, or local section. | The message is a one-field validation correction. | The message is a system failure, permission problem, or outage rather than a validation issue. |
| Required state | Before-action warning state placed immediately before the related control or declaration. | Advisory or success state that uses calmer status semantics rather than assertive alert semantics. | Informational inline message attached to the relevant object or section. | Failed-submit state with summary visible near the form heading. |
| Accessibility burden | Keep the warning in reading order before the control, declaration, or instruction it qualifies. | Use role alert for urgent dynamic text and avoid putting interactive controls inside the role-alert node itself. | Keep the message in the reading order near the context it describes. | Use a heading and alert behavior that makes the summary discoverable. |
| Common misuse | Using warning text for routine hints, explanations, or mild reminders. | Using a disappearing toast for warnings users must act on before continuing. | Using an inline message for a single field error that should be connected to that input. | Replacing field-level messages with only a top-level summary. |