Accessible Error Messages People Can Actually Recover From

The moment a form shows an error is the most dangerous moment in any transaction on the web. The user has already done the hard part. They decided to buy, or sign up, or apply. They filled in the fields. Then something went wrong, and now the whole thing hinges on a single question: can they figure out what to fix? If yes, you keep the customer. If no, they leave, and they don’t file a bug report on the way out. They just leave.

So it’s strange how little care error messages usually get. They’re written last, by whoever happens to be in the code that day, and tested never. And the standard failure mode is specific enough that I can describe it precisely. The user submits. The page repaints. Somewhere, a field border turns red. Maybe a small line of red text appears near the top. And the message, if there is one, says something like “Invalid input” or “An error occurred.”

Consider what this is like if you can’t see the page. A screen reader user submits the form and hears nothing. Nothing announced, no focus moved, no signal that anything happened at all. The error text was added to the page, but adding text to a page doesn’t make a screen reader say it. The user sits in silence wondering whether the form submitted, then rereads the whole page hunting for what changed. Many give up before they find it. The red border helps them not at all, and it also fails anyone with the common forms of color blindness, which is why the accessibility guidelines say color can’t be the only way you signal anything. Color is a highlight, not a message.

A recoverable error has to answer three questions, and I mean literally answer them in words. Which field is wrong. What’s wrong with it. What would make it right. “Invalid date” answers only the first, and only if the message is positioned where you can tell which field it belongs to. “Date must be in the form MM/DD/YYYY, for example 04/15/2026” answers all three. The difference in effort is one sentence. The difference in outcome is whether the user is debugging your form or just typing.

Then there’s the part developers skip because it’s invisible: the wiring. The error message needs to be programmatically attached to its field, not just floating nearby. In HTML that’s an aria-describedby attribute on the input pointing at the message’s id, plus aria-invalid on the field, so that when a screen reader user lands on the input they hear the field’s name and its error together. Visually the message might be obviously “next to” the field. To assistive tech, nearby means nothing. Proximity on screen is not a relationship in the document, and assistive tech only sees the document.

When the form is submitted and fails, something audible has to happen at that moment. The two workable patterns are simple. Either move keyboard focus to the first invalid field, so the user is dropped directly at the problem and hears its error, or show a summary at the top that announces itself, listing each error as a link that jumps to its field. Both are old, boring, proven patterns. Their obscurity isn’t a knowledge problem so much as a testing problem: nobody on the team ever submits the form with the screen off.

Two more mistakes deserve naming because they hurt everyone, not only assistive tech users. The first is clearing the form on error. Someone fills in twelve fields, one is wrong, and the page comes back empty. For a user with a motor impairment, for whom every field is real work, this is often the end of the transaction, but nobody enjoys it. Keep every valid value. The second is vague messages born of a real constraint: on a login form you genuinely shouldn’t reveal whether the email or the password was wrong. Fine. But that logic gets cargo-culted onto shipping forms and profile pages where there’s no attacker and no secret, just a user who typed a phone number with a space in it and is now being scolded in the abstract. Ask what the message is protecting. Usually the answer is nothing.

If you want to feel this instead of taking my word for it, do one test. Unplug your mouse, turn on the screen reader that shipped with your computer, and try to submit your own most important form with a deliberate mistake in it. Most people can’t recover from an error on their own website. It’s an uncomfortable experiment, which is exactly why it’s worth running. I built error handling checks into GazeSite because this failure hides in the one state of the page nobody screenshots: the form, mid-failure, with a real person on the other end trying to give you money. The happy path takes care of itself. The error path is where you find out whether the site was built for users or for demos.