Input Validation

Input validation encompasses the mechanisms that help users fill out a form without errors: indicating required fields, specifying the expected format, and providing explicit error messages when input fails. Without these indicators, a screen reader user doesn't know what to fill in or what went wrong.

A user submits a contact form. The page reloads, a red border surrounds the email field. No text. A sighted user guesses the problem. Maybe. A screen reader user perceives nothing at all.

#Before, during, after

Input validation isn't just about error messages. The RGAA (criteria 11.10 and 11.11) distinguishes three moments:

Before input: signal required fields and the expected format. An asterisk alone isn't enough. The text "required" or the attribute aria-required="true" must accompany each relevant field.

During input: if real-time validation exists, it must be announced to assistive technologies via aria-live or a role="status".

After submission: each field in error is identified and the error described in text. This is the requirement of WCAG criterion 3.3.1 (level A). Criterion 3.3.3 (level AA) adds an obligation: if a correction suggestion exists, it must be offered. "The email address must contain an @" satisfies both criteria. "Invalid field" satisfies only the first.

#The technical trio

Three attributes suffice: aria-invalid, aria-describedby, and a visible text message.

<!-- ✅ Error identified and described -->
<label for="email">Email (required)</label>
<input id="email" type="email"
       aria-invalid="true"
       aria-describedby="email-error">
<p id="email-error" class="error">
  The email address must contain an @
</p>
 
<!-- ❌ Error invisible to screen readers -->
<input type="email" style="border-color: red">

The screen reader announces for the first field: "Email, required, invalid entry, The email address must contain an @". The second? Total silence.

Why aria-describedby rather than aria-errormessage? Adrian Roselli compared the two in detail: aria-describedby works in all tested browser and screen reader combinations. aria-errormessage remains poorly supported. The MDN documentation confirms this caution.

#Color alone is never enough

The red border is a useful visual cue. A color-blind person can't distinguish it from the default border. A screen reader user perceives it not at all. The W3C requires it: the error must be described in text, not merely signaled by a visual change.

#In summary

Signal required fields and expected format before input. Describe each error in text, linked to the field via aria-describedby. Never rely on color alone.