A support ticket lands in the queue that makes no sense to the two people reading it. A customer insists they clicked submit on the signup form, that nothing happened, that the site is broken. The support agent pulls up the same form, fills it out the same way, and there it is: a bright red error message sitting right under the email field, plain as day. "Please enter a valid email address." How could anyone miss that?
The customer isn't lying, and the form isn't broken. The customer is a screen reader user, and that red error message was never announced to them at all. Their screen reader read the page top to bottom, hit submit, and then went completely silent, because nothing on that page told it an error had occurred. To them, the form simply swallowed their submission and did nothing. That is not a minor inconvenience. That is a task they could not complete.
The Stat: An estimated 7.6 million Americans age 18 and older reported having a visual disability in 2021 Census data, a population that includes many of the screen reader users who never hear a form's error message at all. (Source: American Foundation for the Blind, analysis of US Census Bureau (ACS) data)
The problem is bigger than one missing attribute
There is already a piece on this site about the one-line ARIA fix for error announcements, and if you only have time to do one thing today, go read that one first. It walks through the single aria-live region change that fixes the most common failure on its own.
This piece is about everything else. Because in practice, teams fix the live region and assume the problem is solved, only to find the same support tickets keep coming in. That is because "the error is invisible to screen readers" is not one bug. It is a family of five closely related bugs, and most forms have at least two or three of them stacked on top of each other.
Pattern one: color is doing all the talking
The most common failure is also the simplest to picture. A field turns red, maybe the border gets a red outline, and that is the entire signal. A sighted user glances at the field, sees red, and understands something is wrong even before reading a word.
A screen reader has no concept of "the border turned red." Color is a purely visual signal, and if color is the only thing that changed, nothing was communicated to anyone using assistive technology. The fix is to always pair color with real text that states what is wrong, positioned so it is programmatically associated with the field, not just floating nearby in the markup.
Pattern two: no live region, so nothing gets announced
Even when the error text exists on the page, if it appears without any mechanism to tell assistive technology "something changed, go read this now," a screen reader that already finished reading the page will never revisit it. This is the core issue behind the ticket at the top of this article, and it is exactly what an aria-live region (or a properly managed alert role) solves, as detailed in the W3C's guidance on status messages. Text that appears silently is, functionally, text that does not exist.
Pattern three: the asterisk is carrying too much weight
Marking required fields with a lone asterisk is everywhere, and it is a quiet accessibility failure of its own. A sighted user learns to associate the little symbol with "required" through visual convention. A screen reader will often read the asterisk as "star" with no further context, or skip it as punctuation entirely, depending on the field and the software. Required fields need the word "required" stated in text, or a proper aria-required attribute paired with visible text, not a symbol alone doing the explaining.
Pattern four: the toast that says its piece and disappears
Toast and snackbar notifications are popular because they feel unobtrusive. They slide in, announce a success or failure, and slide back out a few seconds later. That timing works fine for someone glancing at a screen. It works terribly for someone using a screen reader, because there is often a delay between the toast appearing and the assistive technology actually reaching and reading it. If the toast has already vanished by the time that happens, the message is gone, and the user never heard it at all. There is a full breakdown of this exact failure mode in the toast and snackbar accessibility piece on this site, including how long a message actually needs to stay put.
Pattern five: focus stays right where it was
The last pattern is subtle but devastating for usability. Someone submits a form with three fields wrong. The page updates, error text appears near each field, maybe even a live region announces "three errors found." But the user's keyboard focus never moves. They are still sitting on the submit button they just pressed, with no way to know where the first error actually lives short of tabbing through the entire form from scratch, field by field, hoping to bump into it.
Moving focus to the first invalid field (or to a summary of the errors at the top of the form) after a failed submission turns a scavenger hunt into a direct path. It is one of the highest-value, lowest-effort changes a team can make, and it pairs naturally with everything above it: the live region announces that something changed, the real text explains what, and the focus move gets the user there.
What this looks like fixed
A form that gets all five right does something like this on a failed submit: an aria-live polite region announces that errors were found and how many, focus moves to the first invalid field, that field's error text is real, programmatically associated language (not color alone), any required-field markers are spelled out in words, and if a toast is involved at all, it stays on screen long enough for assistive technology to actually reach it before disappearing.
None of these fixes require a redesign. They require a checklist, and a form review against that checklist before shipping. That is genuinely the fastest way to close this gap: pull up your highest-traffic form right now and walk it against these five patterns one at a time.
For the scale of who this affects, the population figures cited above come from AFB's research and statistics page, and it is worth sitting with those numbers for a moment. These are not edge cases. They are millions of people trying to complete the same signup, checkout, and support forms as everyone else, and running into a wall that was never visible to the team that built it.
If you want a second set of eyes on your forms specifically, a free audit is a fast, no-pressure way to find out exactly which of these five patterns are hiding in your own checkout or signup flow, before another confused support ticket lands in the queue.
Have questions about any of this, or want to talk through a specific form on your site? Reach a real person on the team at experts@wcag.world, or grab a free audit and get a concrete list back instead of a guess.