When to Tell Someone They Got It Wrong

Most conversations about form errors focus on the message: what it says and where it appears. Those matter. But there's an earlier question that gets far less attention, which is when the message should appear at all.

Get the timing wrong in one direction and the form nags people before they've had a chance to finish. Get it wrong in the other and they find out about five problems at once, after they thought they were done.

Too early

The most common mistake we see is validating on every keystroke. Someone clicks into the email field, types the first letter, and a red message appears telling them their email address is invalid. Of course it is. They haven't finished typing it.

This feels like being corrected mid-sentence. It makes people anxious, and on a small screen the error message often pushes the layout around while they type. The form is technically being helpful and practically being rude.

Too late

The opposite approach waits until the submit button is pressed, then checks everything. If there are problems, the page reloads or scrolls to the top with a list of errors. The visitor has to find each field, work out what's wrong and fix it, sometimes after their other answers have been cleared.

This was the standard for years, and it still shows up on plenty of sites. It's a big part of why people dread long forms.

The approach we use

Our default sits between the two. We check a field when the person leaves it, which is the point where they've told us they think they've finished. If the email is missing an @, they find out as they move to the next field, while the mistake is fresh and easy to fix.

Once a field has shown an error, we switch to checking it as they type. That way, the error disappears the moment the problem is fixed, rather than waiting for them to leave the field again. Being strict before someone has made a mistake is nagging; being quick to confirm they've fixed one is reassuring.

We still check everything when the form is submitted, because people skip fields. When that happens, we move focus to the first field with a problem and show each error next to its field, not in a list at the top.

Some checks need to wait

Certain checks can't happen instantly. Whether a username is taken, whether a discount code is valid or whether an address exists may need a request to a server. For those, we show that a check is happening, and we only run it once the person has paused or left the field, so we're not firing off requests for every letter.

Preventing errors in the first place

The best error is one that never happens. Clear labels and hints prevent many mistakes. So does accepting input in more than one format. A phone number with spaces, a postcode in lower case or a card number with dashes should all be accepted and tidied up behind the scenes rather than rejected.

We also avoid making fields stricter than they need to be. Rules about names, in particular, tend to reject real people whose names don't fit someone's assumptions.

Writing the message

When an error does appear, it says what went wrong and how to fix it, in plain language. "Enter an email address, like name@example.com" is more useful than "Invalid input". The wording is part of our content writing work, not something left to a developer's placeholder.

Making errors visible to everyone

Errors need more than a red colour, because not everyone can see red clearly. We add an icon and text, and we make sure screen readers announce the error when it appears. The field itself is marked as invalid so assistive technology knows which one needs attention.

Good validation is mostly about respect: letting people finish, then helping quickly when something is wrong. If your forms feel more like an argument than a conversation, let's talk.