An error needs to say what is wrong, which field, and what to do, be reachable by keyboard, and be announced rather than only shown in red.

Three failures, and only one is visible

The message says nothing useful. Invalid input, please check your entry, or something went wrong. The reader knows they failed and not what to change.

The message is only visual. Red text appears beside a field. A screen reader user, who is not looking at the page, is given no indication that anything happened at all.

The message is unreachable. Submitting scrolls to the top, or does not move focus anywhere, so somebody navigating by keyboard has to hunt for what changed.

The first is a writing problem. The second and third are why forms that look fine are unusable for some people.

Wording that works

Three things in every message.

What is wrong, specifically. Not invalid, but the specific problem.

Which field, named, so the message stands alone if it is read out of context.

What to do, stated as an action rather than a rule.

So: enter a phone number with at least ten digits, rather than invalid phone number. And: choose a date in the future, rather than date error.

Naming the field matters more than it looks. Screen readers can list errors as a group, and a message reading please enter a valid value is useless in that list, while postal code must be six characters is actionable.

Tone

Neutral, and not apologetic or accusatory.

Avoid you failed to, you must, and anything implying the person did something stupid. They are trying to give you their money and the form is being difficult.

Avoid over-apologising too. Oops! Something went a bit wrong! is noise around a message that should be information.

State the problem and the fix. That is the whole tone.

Making it reachable

The technical half.

Associate the message with its field so a screen reader announces it when focus reaches that field, rather than leaving it as unconnected text nearby.

Mark the field as invalid so assistive technology knows, rather than relying on a red border.

Move focus deliberately after a failed submission, either to a summary at the top or to the first field with a problem. Doing nothing leaves the user where they were with no indication anything changed.

Announce dynamic errors that appear without a page reload, using a live region, or they are silent.

Summarise at the top for forms with several fields, with each item linking to its field. That gives an overview and a route.

Never colour alone

The one that catches everybody.

A red border, red text, or a red asterisk conveys nothing to somebody who cannot distinguish it. Colour is reinforcement, never the signal.

Which means every error needs text, and required fields need the word required rather than only a coloured mark. An icon helps as a second channel and is not a substitute for words either.

When to validate

A design decision with an accessibility consequence.

Validating on every keystroke shows errors while somebody is still typing, which is both irritating and noisy for a screen reader announcing changes constantly.

Validating when a field is left is generally better: the person has finished, the feedback is timely, and there is nothing to interrupt.

Validating only on submit is acceptable and asks the user to fix several things at once, which is where the summary earns its place.

What to avoid entirely: clearing the form on error, which is the single most hostile thing a form can do and still happens.

The prevention half

The best error message is the one that was not needed.

State the format before somebody types, not after they get it wrong. Accept formats people actually use, so a phone number with spaces or brackets is not rejected. Do not require a format you can normalise yourself.

Ask for less, since every field is a chance to fail.

And do not reject valid data because your pattern is too strict, which is a common failure with postal codes, names containing apostrophes or accents, and addresses that do not match an expected shape.

Testing it

  1. Submit the form empty and see what happens and where focus goes.
  2. Submit one bad field and read the message aloud out of context.
  3. Do it by keyboard only, and check you can reach every error.
  4. Turn the screen reader on and confirm errors are announced.
  5. Check nothing you typed was lost.

The broader form requirements this sits within are covered in accessible forms: the five things that matter most.


Frequently asked questions

What are the three failures?

A message that says nothing useful, a message that is only visual so screen reader users get nothing, and a message that is unreachable after submission.

What should an error message contain?

What is wrong specifically, which field by name, and what to do as an action. Naming the field matters because errors are frequently read as a list out of context.

What tone should errors use?

Neutral. Not accusatory, and not over-apologetic. State the problem and the fix.

How is an error made reachable?

Associate it with its field, mark the field invalid programmatically, move focus deliberately after submission, and announce dynamic errors through a live region.

Why is colour not enough?

A red border conveys nothing to somebody who cannot distinguish it. Every error needs text, and required fields need the word rather than only a coloured mark.

When should validation run?

Usually when a field is left rather than on every keystroke, which is noisy for screen readers. Never clear the form on error.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Form that rejects entries without saying why?

We rewrite the messages and check they are actually announced, which is usually where the silent failure is.

Start a Conversation