Erroneous Behavior: A Field Guide to Form Failures

There's a sentence that appears on more websites than it should:

"Invalid input."

Invalid in what way? The user is left to guess, and most of them won't bother. They'll abandon the form, and you'll never know why.

Form error messages are where UX, accessibility, and basic clarity tend to break down at the same time; and the costs are real. Abandoned applications, frustrated customers, screen reader users locked out of services they have a legal right to access. Consider this a field guide: a list of the common error messages you'll encounter on most websites, why they cause harm, and what to write instead.

Error messages you've definitely seen

If you've ever filled out a form online, you've more than likely met all of these in some way.

• "Please enter a valid email address." The user typed joe@gmail and forgot the .com. Your validator knows what's missing. The error message could too, but it doesn't say.

• "This field is required." On a form with seventeen fields, this message is functionally useless. Which field? The user has to scan the entire form to find out.

• "An error occurred." This is a status, not a message. It tells the user something happened without telling them what, where, or what to do next.

• "Password must contain at least one uppercase letter, one lowercase letter, one number, one special character (but not these specific special characters), be at least 12 characters but no more than 16, not contain your username, and not match any of your last 24 passwords." Worse: this message often appears only after the user submits, never beforehand as guidance.

• "Something went wrong." The most common error message on the internet. Also one of the least useful. It tells the user nothing about the problem and offers no path forward.

• A red asterisk and silence. The form sits there. The submit button does nothing. The user clicks again, reloads the page, loses everything they typed, and leaves. From the user's perspective, the site is broken.

Why this matters beyond UX

For a sighted keyboard user, a vague error message is frustrating. For a screen reader user, it can make a form genuinely impossible to complete. There are four common failure modes:

• The error appears, but the screen reader never announces it. A red message renders above the field. Visually, it's obvious. To a screen reader user who has already tabbed past that location, it doesn't exist. Without aria-live or role="alert", the error is silent.

• The error is announced, but it's not connected to the field. The screen reader reads "Email is invalid" somewhere on the page. When the user tabs back to the email field, the field itself reports nothing about being in an error state. They have to remember which field had the error and what was wrong with it. The fix is using aria-describedby linking the field to the error text.

• Errors are announced as a wall of text after submit. "Please correct the following errors: Email is invalid. Phone number is invalid. Postal code is invalid. State is required." This is technically WCAG-compliant. Functionally, it gives the user no way to navigate to a specific error and forces them to remember the entire list while scrolling back through the form.

• Color is doing all the work. The field border turns red. The label turns red. The asterisk gets a more aggressive shade of red. None of this is perceivable to users with low vision, color blindness, or who rely on a screen reader. A visual indicator without a programmatic one isn't an accessibility feature, it's decoration.

This isn't theoretical. Form errors are consistently among the most-cited issues in WCAG 2.1 AA audits and EAA complaints. The Dutch DigiToegankelijk reviews flag them constantly. Title II investigations reference them. If your form fails to communicate errors clearly to every user, you're excluding people from whatever service that form provides; increasingly, that's a compliance issue as well as a usability one.

Field marks of a healthy error message

Get this sequence right and most error messages write themselves.

What went wrong?

This is the part most error messages skip. They tell the user that something went wrong without saying what. "Invalid." "Failed." "Error." These are status labels, not explanations.

Naming the problem requires you to know what the problem actually is, which sounds obvious, but a surprising number of error messages are written by developers who can see the validation rule but never translate it back into plain language. If your validator knows the email is missing a domain, the error message should say so. If the field requires exactly 10 digits, say that. If the password failed because it matches a previous password, name that specifically rather than dumping the entire password policy.

The test: can the user, reading only the error message, explain in their own words what went wrong? If not, you haven't answered question one.

Where did it go wrong?

The error message must be locatable. On a form with two fields this is easy. On a form with twenty, "this field is required" forces the user to scan the entire form looking for the offender. By the time they find it, they've forgotten what they were trying to do.

Location works on two levels. Visually, the error needs to appear next to or directly below the field it describes — not stacked at the top of the form, not in a popup, not in a toast that disappears after three seconds. Programmatically, the error needs to be connected to the field with aria-describedby so screen readers announce it as part of the field, not as a disembodied sentence floating somewhere in the page.

When the user encounters the error, they should never have to ask "which one?"

What should the user do about it?

This is where most error messages stop just short of being useful. They identify the problem and locate it, but leave the user to figure out the fix on their own.

Telling someone "your password is too short" is better than "invalid password," but "your password is 8 characters — it needs to be at least 12" is better still. The first version states a fact. The second version gives the user a target. They know exactly how many more characters they need, and they can act on that without re-reading the password policy.

Sometimes the fix is obvious from the problem ("phone number is missing the area code" implies "add the area code"). Sometimes it isn't ("this card has expired" should be paired with "try a different card or update the expiration date"). When in doubt, spell it out.

Before-and-after examples

The pattern is consistent: specific, located, actionable. Each message reads as if it were written by one human for another, not as a status code translated into prose.

The technical checklist

The principles above are easier to apply when paired with the implementation details. The following is the short version of what every accessible form needs.

• Identify errors in text, not just color. Red borders are acceptable as a supplement. They are not a substitute. Every error needs a text label that names the problem in words.

• Connect the error to the field programmatically. Use aria-describedby on the input, pointing to the ID of the error message. When a screen reader user focuses the field, they should hear the field name, any instructions, and the error.

• Mark invalid fields as invalid. Use aria-invalid="true" on the input when it's in an error state. This tells assistive technology that this specific field has a problem.

• Announce errors when they appear. For errors that surface after submit or async validation, use role="alert" or aria-live="polite" so screen readers announce them as they appear, without the user having to hunt for them.

• On submit, send focus to the first error. A summary at the top of the form is helpful, but it's not enough. Move keyboard focus to the first invalid field, or to a focusable error summary that links to each invalid field. This is often the difference between a form that takes 30 seconds to correct and one that takes five minutes.

• Validate at the right time. Inline validation works well for things you can check in real time, like password strength or email format. It works poorly for things you can't, like server-side checks or cross-field validation. Don't tell someone their email is invalid the moment they type the first character. Let them finish.

• Preserve what they typed. A form that clears its fields on error is a form that won't be completed twice. This is especially true for long-form inputs like feedback or application text.

A small mindset shift

Most error messages are written from the system's perspective. Invalid. Required. Failed. These are status codes presented as sentences.

Better error messages are written from the user's perspective. They assume the user is a person doing their best, who has hit a snag and would like to get unstuck. They don't assign blame, and they don't make the user feel like they failed a test.

The shift is small but it changes the experience entirely:

• "You entered an invalid date" → "We need the date in DD-MM-YYYY format"

• "Phone number is invalid" → "Please include the area code"

• "This action cannot be completed" → "This card has expired. Try a different one?"

• "Forbidden" → "You'll need to log in again, your session timed out"

The form is not a quiz the user is failing. It's a tool you're providing, and the error messages are part of the conversation.

The two-question test

Before any error message is implemented, read it out loud and ask: Would I say this to a person standing in front of me? If I did, would they know what to do next?

If the answer to either question is no, rewrite it. If the answer to both is yes, it's likely doing its job.

The next time you're auditing a form, your own or someone else's, start with the error states. They're usually where the problems are hiding.