Blog · Getting forms right
Error Messages That Actually Help
Error messages are often the only thing your form ever says to a visitor. What a useful error says, where it goes on the page, when it should appear, and how to make sure everyone can perceive it.
'Invalid input' tells the visitor nothing
Somewhere in your form's code, a check just ran. It knows which field failed, which rule was broken, and usually what the visitor meant. Then the form shows the visitor 'Invalid input.' Or a red border with no words at all. Or the classic: 'An error occurred.'
Now the visitor has to work out the problem alone. They reread each field, guess at rules nobody stated, and maybe discover by trial and error that the phone field rejects parentheses. Every round of guessing loses you some of the people doing it.
The ones who give up don't complain about your validation. They leave, and your analytics record another abandoned form with no explanation.
The frustrating part is that better error text is close to free. The form already knows what went wrong. Someone just has to write the message.
A useful error answers three questions
A useful error says which field, what's wrong, and what a correct answer looks like: 'Phone number: this needs an area code, like 555-012-3456.' A message that answers all three lets the visitor fix the mistake in one try. Anything less leaves the missing part to the visitor's patience.
Tone matters too. Making a mistake on your form is different from doing something wrong. 'Please enter a valid email address' reads like a citation. 'We need an email like name@example.org to reply to you' explains why you are asking. The best error messages read like a colleague pointing at the line that needs another look.
Some errors aren't the visitor's fault at all: the server failed, the connection dropped, something broke on your end. Those messages should say so: 'Something went wrong on our end. Your message is still here; please try again.' The worst thing a form can do is blame the visitor for its own failure.
Put the error next to the field
Put each error message directly beside the field it's about. The visitor is already looking there, and the explanation sits right next to the thing they need to fix. A red banner at the top saying 'there were 3 errors,' with the errors themselves below the fold, is alarming and unhelpful at the same time.
Long forms need one more thing: a summary at the top listing each problem, with each item linking to its field. This is in addition to the messages beside each field. It's for the visitor who submits from the bottom of a long page when the problems are scattered above. Move focus to the summary when it appears, so the visitor reads it first.
The rule from earlier in this series still applies: an error must never cost the visitor their work. A form that clears the message field because of a typo in the phone field has thrown away the visitor's work over a small mistake.
When to show the error
Timing matters. A form that validates on every keystroke complains about answers people haven't finished typing. The email address is 'invalid' the whole time it's being typed, which is technically true and completely useless.
A calmer pattern checks when the visitor leaves a field, which is when their answer should be complete, and again at submit to catch anything skipped. Once a field has been marked wrong, switch to checking as they type. That way the error disappears the moment it's fixed instead of lingering until the next submit.
Errors everyone can perceive
A meaningful share of your visitors will never see your red. A color-blind visitor may see the error border as just another border, and a screen reader user doesn't see it at all. Color can highlight an error, but the error itself needs words.
Attach those words to the field in the markup, so assistive technology announces the problem when the field gets focus. If an error exists only as a color, part of your audience never learns about it.
This matters most for the organizations this series keeps in mind: public institutions. Their forms are often the legally required way to reach a service, and their accessibility obligations are binding.
Compliance is only part of it. The people who most need a clear error message are disproportionately the people public-sector forms exist to serve: older, less confident online, using borrowed devices, or reading in a second language.
Next in this series: tap targets and mobile keyboards, and why the phone in your visitor's hand is the strictest test your form will face.