Form validation errors are identified and explained

Form errors that appear only as a red border or generic 'Invalid' message leave screen reader users without actionable feedback — the element's invalid state is not announced, and there is nothing to explain what went wrong or how to fix it. WCAG 2.2 SC 3.3.1 (Error Identification) and SC 3.3.2 (Labels or Instructions) are both Level A requirements. Poor error UX also measurably increases form abandonment rates for all users.

Associate error messages with their inputs using aria-describedby and aria-invalid, and use role="alert" so the message is announced immediately.

const emailError = validate(email)

<div>
  <label htmlFor="email">Email address</label>
  <input
    id="email"
    type="email"
    aria-invalid={!!emailError}
    aria-describedby={emailError ? 'email-err' : undefined}
  />
  {emailError && (
    <p id="email-err" role="alert" className="text-sm text-red-600">
      {emailError}
      {/* Good: "Enter a valid email (e.g., name@example.com)" */}
      {/* Bad: "Invalid" */}
    </p>
  )}
</div>

Search for aria-describedby usage in forms — every input with possible validation errors should have one. Also check error string literals: any message under five words is likely too vague to satisfy WCAG 2.2 SC 3.3.2.