Error Identification: Making Form Errors Clear and Actionable

Introduction

When users make mistakes filling out forms, they need clear information about what went wrong and how to fix it. WCAG 3.3.1 (Error Identification) requires that when errors are detected, the specific field with the error must be identified and the error described in text. This isn’t just an accessibility requirement—it’s essential for good user experience.

Forms with unclear error messages frustrate everyone. For users with disabilities, particularly those using screen readers or who have cognitive impairments, ambiguous error handling can make forms completely unusable.

What WCAG Requires

3.3.1 Error Identification (Level A)

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

This means:

• Errors must be described in text (not just color or icons)
• The specific field with the error must be identified
• Users must be able to find and understand what went wrong

3.3.3 Error Suggestion (Level AA)

If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user.

This means:

• When possible, provide specific guidance on how to fix the error
• Suggest correct formats (e.g., “Use format: MM/DD/YYYY”)
• Offer alternatives when appropriate

Who Benefits

User Type	Benefit
Screen reader users	Errors announced clearly, not just visual cues
Users with low vision	Text descriptions supplement color changes
Users with cognitive disabilities	Clear guidance on what needs fixing
Users with motor impairments	Can navigate directly to error fields
All users	Faster form completion with clear feedback

Common Error Handling Problems

1. Color-Only Errors

<!-- BAD: Only color indicates error -->
<input type="email" class="error-red-border">

<!-- GOOD: Text description with color -->
<input type="email" aria-describedby="email-error" aria-invalid="true">
<p id="email-error" class="error-text">
  Please enter a valid email address (e.g., [email protected])
</p>

2. Generic Error Messages

<!-- BAD: Unhelpful message -->
<p class="error">Invalid input</p>

<!-- GOOD: Specific, actionable message -->
<p id="phone-error" class="error">
  Phone number must be 10 digits. You entered 8 digits.
</p>

3. Errors Far from Fields

<!-- BAD: All errors at top with no field association -->
<div class="error-summary">
  <p>There were errors in your submission</p>
</div>

<!-- GOOD: Summary with links to fields + inline errors -->
<div class="error-summary" role="alert">
  <h2>Please fix 2 errors:</h2>
  <ul>
    <li><a href="#email">Email address is required</a></li>
    <li><a href="#phone">Phone number format is invalid</a></li>
  </ul>
</div>

4. Errors Not Announced to Screen Readers

<!-- BAD: Error appears but isn't announced -->
<span class="error">Required field</span>

<!-- GOOD: Live region announces error -->
<span class="error" role="alert" aria-live="assertive">
  Required field
</span>

Key Error Handling Patterns

Error Summary Pattern

Provide a summary of all errors at the top of the form, with links to each field:

<div class="error-summary" role="alert">
  <h2>There are 2 errors in this form</h2>
  <ul>
    <li><a href="#name">Name is required</a></li>
    <li><a href="#email">Email format is invalid</a></li>
  </ul>
</div>

Inline Error Pattern

Place error messages directly next to the field they describe:

<div class="form-group">
  <label for="email">Email Address</label>
  <input
    type="email"
    id="email"
    aria-describedby="email-error"
    aria-invalid="true"
  >
  <p id="email-error" class="error">
    Enter a valid email address (e.g., [email protected])
  </p>
</div>

Real-Time Validation

Validate as users type or when they leave a field, but avoid validating too aggressively:

• Do validate: On blur (when user leaves field)
• Do validate: On form submission
• Avoid: Validating while user is still typing
• Avoid: Showing errors for empty required fields before user interacts

Accessible Error Message Components

Visual Indicators

• Red border or background (but never color alone)
• Error icon (with alt text or aria-label)
• Clear error text near the field

Programmatic Requirements

• aria-invalid="true" on the field with an error
• aria-describedby linking field to error message
• role="alert" or aria-live="assertive" for dynamic errors
• Focus management (move focus to error summary or first error field)

Testing Error Identification

Quick Manual Test

1. Submit a form with intentional errors
2. Verify each error is described in text
3. Check that error messages identify which field has the error
4. Test with screen reader to ensure errors are announced
5. Verify keyboard users can navigate to error fields

What to Verify

• [ ] Errors are described in text (not just color/icons)
• [ ] Each error identifies which field has the problem
• [ ] Error suggestions provide helpful guidance when possible
• [ ] Screen readers announce errors when they appear
• [ ] Users can navigate from error summary to specific fields
• [ ] Focus is managed appropriately after form submission

Tools for Testing

• Screen reader: Test error announcement with NVDA, VoiceOver, or JAWS
• axe DevTools: Checks for missing error associations
• Keyboard testing: Verify focus moves to errors appropriately

Best Practices Summary

Do	Don’t
Describe errors in text	Rely only on color or icons
Identify specific field with error	Use vague “form has errors” messages
Provide correction suggestions	Just say “invalid input”
Use aria-invalid and aria-describedby	Leave errors unlinked to fields
Announce errors to screen readers	Show errors silently
Place errors near related fields	Put all errors far from fields

Related Articles

• Error Identification Implementation Guide - Detailed patterns
• ARIA Labels Guide - Accessible naming
• WCAG Compliance Hub - All accessibility evaluators

---

References

1. W3C - WCAG 2.2 SC 3.3.1 Error Identification
2. W3C - WCAG 2.2 SC 3.3.3 Error Suggestion
3. W3C - WAI Forms Tutorial - Validating Input
4. WebAIM - Accessible Form Validation