WCAG 3.3.1: How to Fix Form Error Identification Issues

Last updated: 2026-03-22

Level A Understandable WCAG 3.3.1

What This Criterion Requires

WCAG 3.3.1 requires that 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. When a user submits a form with invalid data or fails to complete a required field, the system must clearly indicate which fields have errors and describe what is wrong in a way that is perceivable by all users, including those using assistive technologies. Error identification must go beyond visual indicators like red borders or color changes; the error must be described in text that is programmatically associated with the relevant form field. This means using aria-describedby to link error messages to their corresponding inputs, using aria-invalid to mark fields as having errors, and providing error text that explains what went wrong and ideally how to fix it. Error messages should appear near the erroneous field and should be announced by screen readers when the user encounters the field. An error summary at the top of the form that lists all errors with links to the affected fields is a recommended best practice for forms with multiple potential errors.

Why It Matters

When form validation fails and users cannot identify which fields have errors or understand what went wrong, they cannot correct their input and complete the form. Screen reader users cannot see red borders, exclamation icons, or color-based error indicators. Without programmatically associated text error messages, they have no way to know that an error exists, which field it applies to, or how to fix it. Users with cognitive disabilities benefit from clear, specific error descriptions rather than vague messages like 'invalid input.' Users with low vision who may not notice subtle color changes need prominent text-based error identification. Frustrating form experiences with unclear error messages lead to form abandonment, which impacts both users and business outcomes. Studies show that clear, specific, and well-placed error messages significantly improve form completion rates across all users. Proper error identification is not just an accessibility requirement but a fundamental usability principle that benefits every user who encounters a form validation issue.

Common Failures and How to Fix Them

Error indicated only by red border with no text message

A form field with an error is highlighted with a red border, but no text error message is provided to explain what is wrong. Screen reader users have no indication that an error exists, and color-blind users may not notice the red border.

Inaccessible 
<style>
  .error { border: 2px solid red; }
</style>
<form>
  <label for="email">Email</label>
  <input type="email" id="email" class="error" value="not-an-email">
  <button type="submit">Submit</button>
</form>
Accessible 
<form>
  <label for="email">Email</label>
  <input type="email" id="email" class="error" value="not-an-email"
         aria-invalid="true" aria-describedby="email-error">
  <span id="email-error" class="error-message" role="alert">
    Please enter a valid email address (e.g., [email protected]).
  </span>
  <button type="submit">Submit</button>
</form>

Generic error message without field identification

A form displays a generic error message like 'There were errors in the form' at the top of the page without identifying which specific fields have errors or what the errors are. Users must guess which fields need correction.

Inaccessible 
<form>
  <div class="alert alert-error">
    There were errors in your submission. Please try again.
  </div>
  <label for="name">Name</label>
  <input type="text" id="name">
  <label for="email">Email</label>
  <input type="email" id="email">
  <label for="phone">Phone</label>
  <input type="tel" id="phone">
  <button type="submit">Submit</button>
</form>
Accessible 
<form>
  <div class="alert alert-error" role="alert">
    <h2>Please fix the following errors:</h2>
    <ul>
      <li><a href="#name">Name: This field is required.</a></li>
      <li><a href="#email">Email: Please enter a valid email address.</a></li>
    </ul>
  </div>
  <label for="name">Name</label>
  <input type="text" id="name" aria-invalid="true" aria-describedby="name-error" required>
  <span id="name-error" class="error-message">This field is required.</span>
  <label for="email">Email</label>
  <input type="email" id="email" aria-invalid="true" aria-describedby="email-error">
  <span id="email-error" class="error-message">Please enter a valid email address.</span>
  <label for="phone">Phone</label>
  <input type="tel" id="phone">
  <button type="submit">Submit</button>
</form>

How to Test

  1. Submit forms with intentionally invalid or missing data and verify that each field with an error is identified with a visible text error message that describes the specific problem.
  2. Use a screen reader to navigate to fields with errors and verify that the error messages are announced, either through aria-describedby associations or role='alert' live regions.
  3. Check that error messages are not communicated solely through color changes, icons, or visual positioning but always include descriptive text.
  4. Verify that aria-invalid='true' is set on fields with errors so assistive technologies can identify invalid fields programmatically.

CMS-Specific Guidance

This criterion commonly causes issues on these platforms:

Further Reading

Related WCAG Criteria