An accessible form error message does three things: it names the field that has a problem, it says in plain text what went wrong and how to fix it, and it’s connected to the field in code so a screen reader announces it. A red border with the word “Error” does none of those — and it’s quietly costing you the leads who hit your validation and gave up.
Most advice on this topic is written for developers. This post is for the business owner who owns the form: what good error messages look like, the exact copy to swap in, and a five-minute test you can run on your own contact form today.
Why your form’s error messages are costing you leads
The moment a validation error appears is the moment a lead decides whether to try again or leave. According to Baymard Institute’s running meta-analysis of 50 studies, the average cart abandonment rate is 70.22%, and 18% of US shoppers have abandoned an order because the checkout process was too long or complicated. Baymard estimates the average large e-commerce site can lift conversions by 35.26% through better checkout design alone.
Confusing error recovery is a big slice of “too complicated.” A visitor who sees “Invalid input” has to guess which field, guess the fix, and often re-type everything. Many guess wrong once and quit.
The accessibility picture is worse than most owners assume. WebAIM’s 2026 Million report, which analyzed the top one million home pages in February 2026, found that 33.1% of form inputs were not properly labeled. If a field has no accessible label, its error message has almost no chance of making sense to a screen reader user — the two failures compound.
This post covers only the validation step. For labels, field order, and structure, start with our accessible forms guide.
What makes a form error message accessible?
An accessible error message identifies the field, describes the problem in text, and tells the user how to fix it. That’s not a style preference — it’s the standard. WCAG 3.3.1 Error Identification (Level A) requires: “If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text” (W3C).
One level up, WCAG 3.3.3 Error Suggestion (Level AA) adds that when the fix is known, “the suggestions are provided to the user” — so “Enter a date in MM/DD/YYYY format,” not just “Invalid date” (W3C).
The W3C’s forms tutorial turns that into a concrete recipe. Every error message should:
- Reference the label of the form control, so the user recognizes which field it means.
- Describe the error concisely, in language anyone can understand.
- Say how to correct it, including any format requirements.
- Link to the field itself, so the user can jump straight to the fix.
Notice that none of this requires design flair. It requires the message to carry real information.
Why a red border alone fails — and who it fails
Marking the bad field red feels intuitive, but color is the one signal large groups of your visitors can’t rely on. WCAG 1.4.1 Use of Color (Level A) requires that “color is not used as the only visual means of conveying information” — and the W3C’s documented failure F81 is precisely “identifying required or error fields using color differences only” (W3C).
Who gets stranded by a color-only error? Color-blind visitors, who may see your red border as the same gray-brown as everything else — try your own form in our color blindness simulator. Screen reader users, because a border is pure decoration to assistive technology; nothing gets announced. And anyone on a dim phone screen in sunlight.
Deque’s guidance in The Anatomy of Accessible Forms: Error Messages is blunt about it: “Don’t use visual cues like color or icons alone to identify the form fields that have the errors.” Keep the red — it helps sighted users scan — but treat it as seasoning, never the meal. The meal is a text message next to the field.
Before and after: error copy that actually helps
Vague error text is the most fixable problem on this list, because it’s a copywriting job, not an engineering one. WebAIM’s form validation guidance uses the example “Course number must be a 3 digit number” — the message states the field, the problem, and the rule in one sentence. Here’s that principle applied to the copy we see most often on small-business forms:
| Field | Before (loses the lead) | After (recovers the lead) |
|---|---|---|
| ”Invalid input" | "Enter your email address in a format like name@example.com” | |
| Phone | ”Error" | "Phone number must be 10 digits, like 5551234567” |
| Name (required) | Red border, no text | ”Enter your first name” |
| Password | ”Password does not meet requirements" | "Password must be at least 8 characters and include a number” |
| Date | ”Invalid date" | "Enter the date as MM/DD/YYYY, like 07/03/2026” |
| Form summary | ”There were errors with your submission." | "There are 2 problems: 1. Enter your email address. 2. Enter your phone number.” (each linked to its field) |
Two rules make every “after” version work. First, never make the user guess the format — show it. Second, write like a person helping, not a system rejecting. “Enter your first name” reads as a nudge; “FIELD REQUIRED” reads as a slammed door.
One more recovery rule: when the page reloads with errors, the visitor’s correct entries must still be there. Wiping a completed form over one bad phone number is how you lose someone who was seconds from converting.
Where should error messages appear on the form?
Right next to the field, at the top of the form, or both — and “both” usually wins. WebAIM’s guidance describes the trade-off: a summary at the top (with focus moved to it) tells screen reader users immediately that something failed and lists everything at once, while inline messages sit exactly where the fix happens. Inline errors must be programmatically tied to their fields — via the label or aria-describedby — or a screen reader treats them as random floating text (WebAIM).
WebAIM frames the whole job as three steps: alert the user that errors exist, let them easily reach the fields that need fixing, and let them resubmit. Deque adds a detail most sites skip: update the page title to something like “Alert form has errors,” because the title is the first thing a screen reader speaks after a page reloads (Deque).
If you want to hear why this ordering matters, our walkthrough of the screen reader checkout experience plays out what a blind customer actually encounters when errors appear silently.
What do aria-invalid and aria-describedby actually do?
They’re the two attributes that turn a visible error into an announced one. Setting aria-invalid="true" on a field causes screen readers to identify the control as “invalid” or in need of attention, per WebAIM. Pointing aria-describedby at the error text’s ID makes the screen reader read that message whenever the user lands on the field.
Timing matters as much as markup. MDN’s aria-invalid documentation warns: “Do not set aria-invalid="true" on empty required elements until after the user attempts to submit the form. They may still be working on filling it out.” A form that shouts “invalid” at a half-typed email address is hostile to everyone.
You don’t need to write this code yourself — you need to recognize whether your form has it. Here’s the shape your developer should produce:
<label for="email">Email address</label>
<input type="email" id="email" aria-invalid="true" aria-describedby="email-error">
<p id="email-error">Enter your email address in a format like name@example.com</p>If your form was built by a page builder or plugin, there’s a decent chance none of this exists. That’s what the test below is for.
Test your own contact form in five minutes
You can catch most error-message failures without any technical skill. Open your contact form and run this script:
- Submit the form completely empty. Text messages should appear naming each required field. If all you get is red outlines — or nothing — you have a 1.4.1 and 3.3.1 problem.
- Squint, or view in grayscale. Most phones have a grayscale mode in accessibility settings. Can you still tell which fields failed? If the color was carrying all the meaning, you just experienced your color-blind visitors’ version of the form.
- Read each message aloud. Does it say which field, what’s wrong, and how to fix it? “Invalid input” fails all three.
- Fill everything correctly except one field, then submit. Did your correct answers survive, or did the form wipe them? Wiped data is a silent lead-killer.
- Try the whole recovery with only the keyboard. Tab to the field, fix it, resubmit. If you get lost, so will real visitors — the same technique from our 10-minute keyboard test.
Write down what failed and on which page. Even a three-line list turns “our form seems fine?” into a work order a developer can act on.
Fix the step where leads give up
Error handling is unglamorous, which is why it’s usually the least-tested part of a site — and one of the most common failures we find in real audits. The fixes are well understood: text messages tied to fields, no color-only signals, focus that moves to the problem, data that survives a reload. At Curbcut, wiring that markup correctly is standard scope in our manual remediation work, because a form that only works for users who never make mistakes doesn’t work.
Want to know whether your forms flag errors accessibly — before your next lead finds out the hard way? Start with a free scan.