Accessible form errors: validation messages that help users recover

Immediate validation can interrupt users before they finish typing. Validate required and format rules on blur when the field contains a meaningful attempt, then validate the full form on submission. Clear an error as soon as the corrected value satisfies the rule so stale feedback does not remain.

Native constraints such as required, type="email", minlength, and autocomplete provide useful semantics and mobile keyboard hints. Custom messages can improve clarity, but they should build on those foundations instead of replacing the form with a collection of generic text boxes.

Set aria-invalid="true" only while the value is invalid and reference persistent help plus the current error through aria-describedby. Keep the message close to the field visually. Color can reinforce the state, but an icon, border treatment, and explicit text should carry the meaning together.

Write “Enter an email address in the format name@example.com” instead of “Invalid input.” The message should name the expected correction without blaming the user or exposing an internal validation rule they cannot act on.

                      <input id="email" type="email" aria-invalid="true" aria-describedby="email-help email-error">
<p id="email-error">Enter an email address in the format name@example.com.</p>
                    

When submission fails, place a concise summary before the form, focus its heading, and include links that move focus to each invalid field. This gives users a quick map without forcing them to hunt through a long checkout or account form.

Do not fire an assertive live-region announcement for every invalid field at once. A focused summary plus programmatically connected inline errors is usually calmer and more understandable. Reserve assertive announcements for urgent failures that would otherwise be missed.

• State the number of problems.
• Link each summary item to its field.
• Keep the original values and scroll position stable.

A validation test is incomplete if it stops after confirming an error appears. Correct the value, verify aria-invalid is removed, ensure the message disappears, and submit again. Repeat with keyboard navigation, browser autofill, pasted text, and server-returned errors.

Server validation remains authoritative even when client feedback is excellent. Return errors in the same field-level structure, avoid revealing whether sensitive accounts exist, and restore the user to the form with their non-sensitive entries intact.