All Guides

Accessibility

Fix Accessible Form Errors

By TC Timebomb, Moonvine

Tell users what went wrong and help them fix it.

What this covers: How to make form validation errors accessible to screen readers using aria-describedby, aria-live regions, and focus management — with code patterns for connecting errors to fields, announcing dynamic errors, and writing helpful error messages.

Who it’s for: Developers building or maintaining forms that need to be accessible, especially checkout flows and registration forms.

Key outcome: You’ll have accessible form error handling — errors linked to fields with aria-describedby, dynamically announced via aria-live, focus moved to the first error on submit, and clear messages that explain how to fix each problem.

Time to read: 4 minutes

Part of: Accessibility series

Jump to Quick Questions ↓

🔧 Skill Level: Developer required

Form accessibility requires HTML and JavaScript changes. Share this with your developer. For WordPress, Gravity Forms and WPForms have better built-in accessibility.

Show errors so everyone can understand them.

Accessible form errors tell users what went wrong and where—because a red border and silent form isn’t helping anyone.

Someone complained your checkout form doesn’t announce errors. When a screen reader user submits an invalid form, they need to hear what’s wrong. A red border around the email field means nothing when you can’t see.

This is where accessibility meets revenue. Forms that don’t announce errors have noticeably higher abandonment for users with disabilities. Screen reader users hit submit, nothing happens (from their perspective), and they leave. If your checkout flow silently fails for 7 million potential customers, you’re leaving money on the table and opening yourself to discrimination complaints.

What Accessible Errors Need

Error text is connected to the field (not just nearby visually)
Errors are announced when they appear
Focus moves to errors on submit
Errors explain how to fix the problem

The Pattern

1. Connect Error to Field


<input type="email" id="email" aria-describedby="email-error">
<span id="email-error">Please enter a valid email address</span>

aria-describedby links the error text to the input. Screen readers announce both.

2. Announce Dynamic Errors


<div aria-live="polite">
  <!-- Dynamic error messages here -->
</div>

aria-live="polite" tells screen readers to announce changes. “Polite” waits for a pause; “assertive” interrupts immediately.

3. Focus First Error on Submit


form.addEventListener('submit', (e) => {
  const firstError = form.querySelector('[aria-invalid="true"]');
  if (firstError) {
    e.preventDefault();
    firstError.focus();
  }
});

Error Message Quality

Bad errors tell you what’s wrong. Good errors tell you how to fix it.

Bad: “Invalid input” | Good: “Please enter a valid email address (e.g., name@example.com)”
Bad: “Error” | Good: “Password must be at least 8 characters”
Bad: “Required” | Good: “Please enter your phone number”

Error Summary Pattern

For forms with multiple errors, add a summary at the top:


<div role="alert">
  <p>There were 2 problems with your submission</p>
  <ul>
    <li><a href="#email">Email address is required</a></li>
    <li><a href="#password">Password must be 8+ characters</a></li>
  </ul>
</div>

role="alert" announces immediately. Links let users jump to each field.

Quick Checklist

Work through each item systematically.

Every error is linked to its field (aria-describedby)?
Invalid fields have aria-invalid="true"?
Errors are announced (aria-live or role="alert")?
Focus moves to first error on submit?
Error messages explain how to fix?

The Accessible Error Handling Checklist

Error messages are descriptive (not just “invalid”)
Errors are announced to screen readers
Error fields are visually highlighted
Form doesn’t clear valid data when errors occur

Sources

Accessible Form Error Questions Answered

What makes a form error accessible?

An accessible form error is programmatically associated with its field using aria-describedby, announced to screen readers via aria-live regions, and written in plain language that tells users exactly how to fix the problem. Visual color alone is never sufficient.

Should form errors appear on submit or in real-time?

Use inline validation (real-time) for format requirements like email and phone number. Use on-submit validation for fields that depend on each other or require server verification. Always move focus to the first error on submit so keyboard and screen reader users aren’t lost.

What WCAG criteria apply to form errors?

WCAG 2.1 Success Criteria 1.3.1 (Info and Relationships), 3.3.1 (Error Identification), 3.3.2 (Labels or Instructions), and 3.3.3 (Error Suggestion). Level A requires identifying errors; Level AA requires suggesting corrections. These are among the most commonly failed criteria in accessibility audits.

How do I test if my form errors work with screen readers?

Test with NVDA (free, Windows) or VoiceOver (built into macOS). Submit the form with empty required fields and verify the screen reader announces each error, which field it belongs to, and how to fix it. Also test with keyboard-only navigation to ensure focus moves to the error summary.

✓ Your Form Error Handling Is Accessible When

Error messages appear immediately next to the invalid field (not only at the top of the form)
Each error message is programmatically linked to its field via aria-describedby
Invalid fields are marked with aria-invalid=”true” so screen readers announce the error state
Focus moves to the first error field after form submission fails
Error messages use text descriptions (not color alone) — e.g., “Email is required” not just a red border

Test it: Submit every form empty with a screen reader active — each field should announce its label, its error message, and the required state, and focus should land on the first error.