A visitor fills in your contact form, hits send, and nothing seems to happen. Maybe a thin red outline appears somewhere, or a tiny sentence pops up that says "Invalid input." They do not know which field is wrong, what the form expected, or whether their message was delivered. Most people close the tab rather than solve that puzzle.
Good contact form error messages are not decoration. They are the final instruction that decides whether a lead becomes a real enquiry or disappears. This guide shows small business owners and marketers how to write actionable, accessible errors on an existing HTML form, with plain-language copy patterns, ARIA wiring, and a short manual test you can run in ten minutes.
Why error wording and placement decide whether a visitor resubmits
An error is feedback. When the browser blocks a submission, the visitor needs three things almost instantly: which field failed, why it failed, and what to do next. If any of those is missing, they start guessing, and guessing feels like work.
HTML already gives you a baseline. The browser will block submission and show its own message when a required field is empty or an type="email" value is malformed, according to Mozilla's guide to client-side form validation. That default is better than nothing, but it is generic, it is often announced only visually, and its wording cannot be tailored to your business. Your job is to make the feedback specific and calm rather than alarming.
Placement matters just as much. An error banner at the top of the page is easy to miss if the visitor is already scrolled to the message field at the bottom. Pair a summary at the top with a message directly beside the failing field, and you cover both the "I missed it" and the "I am here" cases.
The four jobs of a good error message
Every inline error should do four jobs in one short sentence or two.
- Name the field. "Email address" is clearer than "Field 3."
- Explain the problem in plain language. Say what the form expected, not what the visitor did wrong.
- Say how to fix it. Give a concrete action: "Add the part after the @ symbol."
- Stay announced. The message must be programmatically tied to the input so assistive technology reads it, not just sighted users.
Keep the tone neutral and helpful. "We need your email so we can reply" is better than "Error! Invalid entry." Avoid blame, uppercase shouting, and exclamation marks. Your error copy is customer service in miniature.
Plain-language copy patterns with before and after examples
Here is a practical set you can adapt for the four fields most contact forms have. Notice that each "after" version identifies the field, the problem, and the fix.
- Name field — Before: "Invalid input." After: "Please enter your name so we know who to reply to."
- Email field — Before: "Bad email." After: "That email address looks incomplete. Check for a missing @ or a typo after the dot."
- Phone field — Before: "Error." After: "Phone numbers need at least 7 digits. You can include spaces or dashes."
- Message field — Before: "Too long." After: "Your message is over our 1,000-character limit. Please shorten it and try again."
A useful rule: if the visitor cannot act on the sentence, rewrite it. "This field is required" is technically true but vague; "Please add a short message so we know how to help" is actionable and human.
Also avoid over-validating. Mozilla's validation guide warns not to require data you do not need, and notes that length constraints are only reported for values the user actually typed. If a phone number is optional, do not block submission over a format you can fix later.
Don't rely on color alone: visible text, icons and inline placement
A red border tells a sighted visitor something is wrong, but it does not say what, and it communicates nothing to someone who cannot distinguish red from green. WCAG requires that error identification not depend on color alone. Always pair the visual cue with text.
A healthy pattern is:
- A short text message directly below the field.
- An icon paired with the text, not instead of it.
- A field outline or background tint as a secondary cue.
- A summary near the submit button or top of the form that lists every problem and links to each field.
Keep the summary short. If three fields fail, say "3 fields need attention" and list them, rather than repeating every sentence twice. Duplicated messages become noisy for screen reader users who hear both the summary and the inline text.
Connecting errors to fields with ARIA
Wiring errors properly is what makes them accessible. Three attributes do most of the work:
aria-invalid="true"marks the field as currently invalid.aria-describedby="email-error"points the input at the id of its error message, so the message is read when the field receives focus.- A summary container with
role="alert"or a moved focus target announces failures at the point of submission.
A minimal pattern looks like this:
<label for="email">Email address</label>
<input id="email" name="email" type="email" required
aria-invalid="true" aria-describedby="email-error">
<p id="email-error" class="field-error">
That email address looks incomplete. Check for a missing @ or a typo after the dot.
</p>
When the value becomes valid, remove aria-invalid or set it to false, and hide or clear the message. Leaving stale error text in place is a common bug: the visitor fixes the field and still sees a warning.
For the summary, place it near the top of the form and move focus to it after a failed submit so keyboard and screen reader users land on the explanation instead of hunting for it.
Where validation should run: blur, submit, and the server
Timing affects frustration. Validating every keystroke on an email field flags half-typed addresses as errors, which feels hostile. A workable rhythm is:
- On blur: check a field after the visitor leaves it, and show an inline message if it is clearly wrong.
- On submit: re-check everything, show the summary, and move focus.
- On the server: always validate again, because client-side checks are easy to bypass.
That last point is not optional. Mozilla's validation article is explicit that client-side validation is a starting check and never an exhaustive security measure, because a malicious user can alter the request. The companion guide on how form data is sent to the server explains that the markup just configures an HTTP request; whatever endpoint receives it must still check and sanitise the data. Reach for robust HTML attributes first, then enhance with JavaScript where it genuinely helps.
If your form currently posts nowhere — a common side effect of AI-generated HTML — read our walkthrough on making an AI-generated HTML form actually work without a backend. It pairs well with this article because an error message is only useful if a successful submission also goes somewhere reliable.
A short manual test script
Once the copy and wiring are in place, test like a real visitor. Fifteen minutes is usually enough.
- Keyboard only: Tab through the form without a mouse. Submit it empty. Confirm focus lands on the summary, and that each error is reachable and readable.
- Screen reader announcement: With a screen reader running, focus the email field. Confirm the label and its error message are both read. Fix the value and confirm the error disappears.
- Error recovery: Correct one field at a time. Check that only the relevant message clears and the summary updates.
- Mobile zoom: On a phone, zoom to 200% and check the error text does not overlap the field or get clipped.
- Color independence: View the form in grayscale or with a color-blindness simulator. Every error must still be understandable from text and icons alone.
- Successful send: Submit a valid set of values, then confirm the data actually arrives where you expect.
Write down what failed and in which step. A short checklist like this catches most of the problems that make people give up.
Keeping an existing form in sync with the detected form widget
You do not need to rebuild your contact form to improve its errors. Fix the markup and copy first, then make sure the submission path still works.
WidgetJar's detected form widget connects an existing HTML form to the platform. In the panel you create and configure the widget, then install the embed script on your registered website domain. The form keeps its own fields, labels and error markup; the widget's job is to stay in sync with the submissions and states you have already built. If you want a broader look at how widgets are embedded without backend changes, our guide on embedding a widget without touching your backend walks through the architecture. For accessibility context and a wider checklist, see our overview of WCAG requirements for ADA website compliance.
Test after any change to labels, ids or error containers: renaming an input or an error id can silently break both aria-describedby and whatever is reading the form, so run the test script again before you call it done.
Start with the email field
You do not have to rewrite every message today. Start with the field that costs you the most leads — usually email — and apply the four jobs: name the field, explain the problem, say how to fix it, and connect it with aria-describedby and aria-invalid. Then run the keyboard and screen reader steps above.
When the copy is clear and the submission path is dependable, set up the detected form widget so your existing HTML form stays connected to WidgetJar while visitors get errors they can actually act on.