Form Validation and Error Messaging That Everyone Can Use

Forms are where websites earn their keep — signups, checkouts, bookings, contact requests. They're also where accessibility failures cost the most, because a visitor who can't recover from a form error doesn't browse away disappointed. They abandon a purchase.

The frustrating part is that most form accessibility problems aren't exotic. They're the same handful of patterns, repeated everywhere: errors nobody's screen reader announces, red borders as the only signal, and messages like "Invalid input" that explain nothing. All of them are fixable with patterns that also make forms measurably easier for everyone.

Here are the six that matter most.

Announce inline validation to screen readers

Inline validation — checking a field as the user fills it — is great UX, but only if everyone receives the feedback. A sighted user sees the red message appear next to the field. A screen reader user hears nothing unless you tell the browser to speak up.

The fixes are standard HTML and ARIA:

• Connect each error message to its field with aria-describedby, so the message is read when the field is focused.
• Set aria-invalid="true" on the field in error, so assistive technology announces its state.
• For messages that appear dynamically, use a live region (role="alert" or aria-live="assertive") so the announcement happens when the error appears — not just if the user happens to revisit the field.

One caution: don't validate aggressively on every keystroke. Announcing "invalid email" while someone is still typing their email is noise for everyone and genuinely disorienting with a screen reader. Validate when the user leaves the field or pauses, not mid-word.

Put an error summary at the top

When a form is submitted with errors, add a summary block at the top of the form: a heading like "There are 3 problems with your submission," followed by a list of the errors, each one a link that moves focus to the offending field.

Then move keyboard focus to that summary. This single pattern solves the worst failure mode of long forms — the user hits submit, the page reloads or re-renders, and nothing tells them what went wrong or where. Screen reader users get an immediate, navigable list; sighted users get an overview instead of scrolling to hunt for red text. It's the pattern government design systems converged on, and for good reason: it works.

Never rely on color alone

A red border is invisible to many people — those with color vision deficiencies, users of high-contrast modes, anyone on a bad screen in bright sunlight. Color can reinforce meaning, but it can't be the only carrier.

Pair the red border with at least one other signal: an error icon, bolded field label, and — always — a visible text message. If you removed all color from your form and could still find every error, you've done it right.

Mark required fields clearly

The classic pattern — a bare asterisk with a footnote somewhere — assumes users see the whole form at once. Better:

• Mark required fields with the word "required" in or near the label (visible to everyone, announced to screen readers), plus the required attribute so browsers and assistive tech treat it properly.
• If most fields are required, flip it: mark only the optional ones as "(optional)". Fewer marks, clearer form.
• State the convention once at the top of the form so nobody has to infer it.

Preserve what the user typed

Nothing drives abandonment like a form that punishes an error by wiping the user's work. For someone typing with a switch device, a screen reader, or a motor impairment, re-entering ten fields isn't an annoyance — it's often the end of the transaction.

On a validation failure, keep every valid field populated. Only the fields in error should need attention. This is invisible when done right and catastrophic when done wrong, which is why it's the pattern teams most often discover only after checking their analytics for checkout drop-off.

Write error messages in plain language

An error message has one job: tell the user what to do next. "Invalid input" fails that job. So does anything with a field name from your database in it.

Good error messages say what happened and how to fix it, in words a person would use: "Enter your phone number using digits only, like 5551234567." Specific, actionable, blame-free.

A before and after

Here's how these patterns compound. Take a typical event-registration form field:

Before: The email field gets a thin red border on submit. No message. The page scrolls back to the top, focus lands nowhere in particular, and the phone number the user already entered has been cleared. A screen reader announces nothing at all — as far as its user knows, the form simply refused to submit.

After: On submit, focus moves to a summary at the top: "There is 1 problem — Email address is missing an @ symbol." That line is a link; activating it moves focus straight to the email field, where the label now reads "Email address (required)," the field carries aria-invalid="true", and the message "Enter an email address like [email protected]" is tied to it with aria-describedby. Every other field still holds what the user typed.

Same form, same validation logic underneath. One version quietly loses registrations; the other recovers them.

Find your form issues before your visitors do

Most teams don't know which of these patterns their forms fail until someone abandons — or complains. An audit shows you where your forms fall short, and AllAccessible turns those findings into suggested fixes your team reviews and approves, one decision at a time.

Get started with AllAccessible and make your forms work for every visitor who's trying to say yes.