Accessible form error messages: what to write and how to code them
How to make contact, booking and checkout form errors work for screen-reader, keyboard and colour-blind visitors: say what's wrong in words beside the field, don't rely on red alone, keep what people typed, and copyable HTML.
A red outline around a field tells some visitors something went wrong. It tells a colour-blind visitor very little, and a screen-reader user nothing at all. Form errors are where many small-business sites lose bookings and enquiries without knowing it: the visitor presses Send, nothing obvious happens, and they leave. Good error handling is mostly good writing plus a few attributes. Here's a 5-minute test and what to change.
The 5-minute error test
- Submit the form empty. Something should clearly happen, in text you can read, not only a shake or a colour change. (WCAG 3.3.1)
- Is each error in words beside its field? "Enter your phone number" next to the phone field, not just "There was an error" at the top or a red border. Red can back the message up, but not replace it. (WCAG 1.4.1)
- Does the message say how to fix it? "Enter an email address like [email protected]" beats "Invalid input". "Choose a date after today" beats "Date error". (WCAG 3.3.3)
- Were required fields marked before you started? The word "required" in the label, or a note explaining the asterisk, so people don't learn the rules by failing. (WCAG 3.3.2)
- Is what you typed still there? After an error, every other field should keep its value. Making people retype everything is a common reason they give up, and asking for the same details twice in one process is something WCAG 2.2 addresses. (WCAG 3.3.7)
- Can a screen reader find the errors? With a screen reader on (see our screen reader test), submit with an error. You should hear that there's a problem and, when you move to the field, what's wrong with it. A short summary at the top that links to each field, or moving focus to the first field with an error, both help. (WCAG 1.3.1, 2.4.3)
- Is success announced too? After a good submission, a "Thanks, we'll reply within one working day" message should appear in text and be announced, not only a green tick. (WCAG 4.1.3)
Words that work
- Say which field and what to do: "Enter your first name", "Enter a phone number with area code, like 918-555-0100".
- Be specific about formats only if you really need them. Better still, accept spaces, dashes and brackets in phone numbers rather than rejecting them.
- Don't blame the visitor ("You failed to...") and don't use codes ("Error 422").
- For payments, bookings with deposits or anything legal, let people review and correct details before the final step. (WCAG 3.3.4)
HTML you can copy
The error text sits next to the field and is linked to it with aria-describedby, and aria-invalid tells screen readers the field has a problem. Add both only when there is an error:
<label for="email">Email (required)</label> <input id="email" name="email" type="email" autocomplete="email" required aria-invalid="true" aria-describedby="email-error"> <p id="email-error" class="field-error"> Enter an email address like [email protected] </p>
An optional error summary at the top of the form, shown after a failed submit. Move focus to it so screen-reader and keyboard users land on it:
<div id="form-errors" tabindex="-1" role="alert">
<h2>Please fix 2 things before sending</h2>
<ul>
<li><a href="#email">Enter an email address like [email protected]</a></li>
<li><a href="#date">Choose a date after today</a></li>
</ul>
</div>And a success message that screen readers announce without moving focus:
<p role="status">Thanks, we got your message and will reply within one working day.</p>
Give error text a dark red that still meets 4.5:1 contrast on your background, or add an icon with the word "Error" so colour isn't the only signal. The W3C forms tutorial covers user notifications and validating input in more depth.
Common mistakes
- Red borders or red labels with no message.
- One vague message at the top ("Please check the form") that doesn't say which field.
- Errors shown as a pop-up that disappears after a few seconds.
- Placeholder text used as the instructions, which vanishes as people type. See accessible contact forms.
- Clearing the whole form after a mistake.
- Rejecting perfectly good input, such as phone numbers with spaces or names with apostrophes and hyphens.
- A CAPTCHA failure with no explanation. See login, one-time code and CAPTCHA fixes.
On Wix, Squarespace, Shopify or WordPress
Built-in form blocks and popular form plugins handle errors differently, and many only turn the field red or show a generic message. Test yours with the 7 checks above. Look in the form settings for custom error or validation messages and rewrite them to say what to do. Mark required fields with the word "required" in the label if the builder allows it. If a form tool can't show field-level errors in text, consider switching to one that can, and keep a phone number or email beside the form as a fallback. Our Wix, Squarespace, Shopify and WordPress guides cover each platform.
What an automated scan can and can't tell you
An automated scan, including ours, checks the page as it loads: missing labels, low-contrast text and broken ARIA. It usually doesn't submit your form, so it can't see your error messages, whether they're announced, whether they say how to fix the problem, or whether the form keeps what people typed. The 5-minute test above covers those. This page is general information, not legal advice.
Related: accessible contact forms, online booking widgets, checkout accessibility, screen reader test, colour contrast guide, keyboard navigation test.
Want the fixes written for you?
Start with a free homepage snapshot. The $149 Fix-Pack scans up to 10 pages and gives copy-paste fixes for your platform within 48 hours, with a 14-day refund promise. See a sample report first.
This is general technical guidance, not legal advice, and it does not certify compliance with the ADA or any law.
Related guides
- Accessible reviews, testimonials and star ratings: a 5-minute test and fixes
- WCAG 2.2 explained for small-business websites
- Squarespace accessibility fixes: alt text, contrast, forms and more
- Wix accessibility fixes: a practical checklist
This guide is general technical information, not legal advice. Following it does not certify ADA or any legal compliance. Automated checks find only part of accessibility barriers.
Check your own site
Run a free homepage snapshot to see your top 3 issues in about a minute, or order the $149 Fix-Pack for up to 10 pages with copy-paste fixes for your platform.