Form validation error messages associated with fields and describe how to fix the error

When form validation fails, screen reader users must know three things: that an error occurred, which field is affected, and how to correct it. Displaying a red border or showing text only visually is invisible to AT. Without aria-invalid and aria-describedby wiring the error message to the input, screen reader users hear only the field name repeated—no indication that anything is wrong. WCAG 2.2 SC 3.3.1 (Level A) requires errors to be identified in text, and SC 3.3.3 (Level AA) requires suggestions for correction. Section 508 2018 Refresh 502.3.6 covers form field associations. Every form submission failure that goes unannounced to screen reader users silently breaks a user journey.

Wire error messages to their inputs using aria-invalid and aria-describedby, and use role="alert" or aria-live="polite" to announce errors on insertion. In your form components:

const [emailError, setEmailError] = useState('');

<div>
  <label htmlFor="email">Email address</label>
  <input
    id="email"
    type="email"
    aria-invalid={emailError ? 'true' : 'false'}
    aria-describedby={emailError ? 'email-error' : undefined}
  />
  {emailError && (
    <div id="email-error" role="alert" className="error-text">
      {emailError}
    </div>
  )}
</div>

Error messages must be actionable—"Email must contain an @ symbol" not "Invalid email". Set focus to the first errored field after submission to orient keyboard users.