Error Handling and Recovery in UX Design

Every user makes errors. They mistype, miss required fields, click the wrong button, lose their connection mid-task. How a product handles these moments defines its usability more than any other single factor. For users with disabilities — cognitive impairments that affect memory, motor impairments that cause accidental clicks, vision loss that makes field requirements hard to detect — poor error handling turns minor mistakes into abandoned sessions.

WCAG Requirements for Error Handling

Four success criteria in WCAG 2.2 directly address error handling:

Criterion	Level	Requirement
3.3.1 Error Identification	A	When an error is detected, identify the item in error and describe it in text.
3.3.3 Error Suggestion	AA	When an error is detected and a suggestion can be made, provide it — unless it compromises security.
3.3.4 Error Prevention (Legal, Financial, Data)	AA	For submissions that cause legal, financial, or data-modification consequences: allow review, confirmation, or reversal.
3.3.6 Error Prevention (All)	AAA	Extend 3.3.4 to all form submissions.

Principles of Accessible Error Handling

Identify the Error Clearly

“Something went wrong” is not an error message. Neither is a red border with no text. Accessible error messages must:

State what went wrong in plain language (“The email address format is invalid”).
State where the error is (which field, which step, which section).
State how to fix it (“Enter an email address like [email protected]”).

Make Errors Perceivable

Use text, not just color. A red border alone is invisible to colorblind users and completely absent for screen reader users. See color contrast standards for visual requirements.
Announce errors to screen readers using aria-live="assertive" for summary messages and aria-describedby to link error text to specific fields.
Mark fields in error with aria-invalid="true" so assistive technology can communicate the state.
Move focus to the error summary or the first field in error when the user submits a form with errors.

Prevent Errors Before They Happen

Prevention is better than recovery:

Input constraints: Use appropriate input types (type="email", type="tel", type="number") so keyboards and validation help users enter correct data.
Format hints: Show the expected format near the field (not just in the placeholder): “Date format: MM/DD/YYYY.”
Confirm destructive actions: Before deleting data, canceling a subscription, or submitting a legal document, show a confirmation dialog.
Autosave: Prevent data loss from accidental navigation, session timeout, or browser crash.

Support Recovery

When errors do occur:

Preserve user input. Never clear form fields after a validation error. The user has already done the work; do not make them repeat it. This aligns with WCAG 2.2 SC 3.3.7 (Redundant Entry) — do not force users to re-enter information they have already provided.
Provide undo. For actions with consequences (delete, send, publish), offer an undo window rather than only a confirmation dialog before the action.
Allow back navigation. In multi-step flows, let users return to previous steps with their data intact.

Error Message Patterns

Inline Field Errors

Place the error message immediately below (or beside) the field. Link it programmatically:

<label for="email">Email address</label>
<input type="email" id="email" aria-describedby="email-error" aria-invalid="true">
<span id="email-error" role="alert">Enter a valid email address (e.g., [email protected])</span>

Error Summary

For forms with multiple errors, provide a summary at the top of the form with links to each field in error:

<div role="alert" aria-labelledby="error-heading">
  <h2 id="error-heading">2 errors found</h2>
  <ul>
    <li><a href="#email">Email address is required</a></li>
    <li><a href="#password">Password must be at least 8 characters</a></li>
  </ul>
</div>

Move focus to this summary on form submission so keyboard and screen reader users encounter it immediately.

Toast / Snackbar Notifications

For non-form errors (network failure, save failure, rate limiting), toast notifications work when they:

Use role="alert" or aria-live="assertive" so screen readers announce them.
Persist long enough for the user to read them (minimum 6-8 seconds, or until manually dismissed).
Include an action to retry or resolve the issue.
Do not stack or overlap other critical content.

Error Handling in Dynamic Interfaces

Single-page applications and real-time interfaces introduce additional challenges:

Async errors (failed API calls) must be surfaced to all users, not silently swallowed in console logs.
Optimistic UI that reverts on failure must clearly explain what was undone and why.
Session timeouts should warn users before expiration and save their data. WCAG SC 2.2.1 (Timing Adjustable) requires that users can extend, turn off, or adjust time limits.

For managing focus during these dynamic updates, see focus management in SPAs.

Key Takeaways

Error messages must identify the field, describe the problem in text, and suggest a fix.
Never rely on color alone to indicate errors — use text and ARIA attributes.
Prevent errors with input constraints, format hints, confirmation dialogs, and autosave.
Preserve user input after errors and provide undo for destructive actions.
Move focus to error summaries or the first field in error on form submission.

Next Steps

Apply error patterns to accessible forms and e-commerce checkout flows.
Reduce the likelihood of errors through cognitive load reduction in your interface design.

Sources

WCAG 2.2 SC 3.3.1 Error Identification — The Level A requirement for identifying errors in text.
W3C WAI Forms Tutorial: Validation — Patterns for accessible form error messages.
WebAIM: Usable and Accessible Form Validation — Practical error handling implementation.
Deque University Error Handling — Accessibility checklist for form validation.

Error handling requirements referenced from WCAG 2.2 Success Criteria 3.3.1, 3.3.3, 3.3.4, 3.3.6, and 3.3.7. Patterns adapted from W3C WAI form tutorials and Deque accessibility guidelines.