An error that does not say what to fix is not a message

Why is a red border not enough?

A red border tells a sighted reader with normal color vision that something is wrong. It tells nobody else anything.

For a reader who cannot separate that red, the form simply refuses to submit for no visible reason.

Every error needs words. Color can reinforce them and must never carry them alone.

It is also the version most likely to be missed in testing, because whoever built the form can see the red perfectly well and the failure is invisible to them.

Say what and say why

Invalid input is not a message. It names no field and offers no correction.

Say which field, what is wrong, and what good looks like. Enter a phone number including the area code is actionable. Invalid phone is not.

Where a format is required, show an example rather than describing it in words.

Where several things could be wrong, say the most likely one. A message listing four possibilities helps nobody decide what to change.

• Name the field, not just the form
• Say what is wrong in plain words
• Say what a correct entry looks like
• Show an example where a format is required
• Use neutral wording, not blame
• Avoid codes and internal field names

Put it where the problem is

The message belongs immediately beside or below its field, connected in the markup so a screen reader reads it as part of that field.

A single message at the top saying some fields are incorrect leaves everybody hunting.

On a long form, do both: a summary at the top listing the problems as links, and a message at each field.

On a long form, do both: a summary at the top listing the problems as links, and a message at each field. Either alone leaves somebody hunting.

Announce the failure

When a submission fails, something has to tell a reader who is not looking at the screen. A message that silently appears is not noticed.

Move focus to the summary, or mark the region so it is announced. Either works and doing neither is the common case.

The same applies to success. Silence after pressing send makes people press again.

Test it by submitting a broken form with your eyes closed. If you cannot tell what happened, neither can anybody else.

Keep what they typed

A form that clears itself on an error is the cruellest pattern in this area, and it is still common on older sites.

Preserve every entry. The person has already done the work once and may have used voice input or a switch device to do it.

Return them to the first problem rather than the top of the page.

A form that clears itself is the cruellest pattern in this area, and it is worse for anybody using voice input or a switch device to enter text in the first place.

Validate at the right moment

Checking a field the instant somebody starts typing produces an error before they have finished, which reads as scolding.

Validate when they leave the field, or on submission. Then clear the message as soon as it is corrected.

Never validate a field the reader has not reached yet.

Tone

Plain and neutral. The reader made an ordinary mistake in a form you designed, and blame language makes people abandon.

Avoid technical wording that means nothing outside your system, such as codes or field names from a database.

Every page written by Website Builder Studio passes a check that runs before anything publishes, and forms here carry connected messages written in plain words. Reading your own errors aloud once is the test that finds the rest.

None of this is legal advice. It is the difference between a form somebody finishes and one they abandon at the last field.

Read your own errors aloud once. The wording that sounds reasonable in a specification often sounds like an accusation when a person hears it, which is covered more widely in accessible forms.