When Your Error Messages Lock Out Users

The moment the form breaks

Picture this: a blind user fills in a checkout form, submits it, and hears nothing useful from their screen reader. No announcement. No explanation. The page has visually flagged five validation errors in red, but the user has no idea. They hit submit again. And again. Eventually they leave.

This isn’t a fringe scenario. Inaccessible error handling is one of the most common barriers we find in real audits, and it’s one that tends to frustrate users at the worst possible moment — when they’re trying to complete a transaction or submit something important.

The good news is that fixing it is largely a matter of knowing what “good” looks like. The failures are almost always the same few patterns.

Why error messages are hard for assistive technology users

Sighted mouse users tend to notice validation errors immediately — the red border, the warning icon, the text appearing beneath the field. But users who rely on screen readers, keyboard navigation, or voice control face a fundamentally different experience.

When a form is submitted and errors appear:

• Screen reader users may not hear anything unless focus moves to the error or a live region announces it
• Keyboard users need to be able to reach each error message from the keyboard and understand which field it belongs to
• Voice control users need to address fields by a visible, accurate label — if the label is wrong or missing, they’re stuck

None of this happens automatically. You have to build it.

The WCAG criteria that apply

Four success criteria in WCAG 2.2 cover error handling directly:

3.3.1 Error Identification (Level A) — If an error is detected automatically, the item in error is identified and described to the user in text. You cannot convey errors through color alone.

3.3.2 Labels or Instructions (Level A) — Inputs that require a specific format must make that requirement clear before or during input, not only after submission fails.

3.3.3 Error Suggestion (Level AA) — If an error is detected and suggestions for correction are known, provide them. “Invalid date” is not enough. “Enter the date in DD/MM/YYYY format” is.

3.3.4 Error Prevention (Level AA) — For submissions that are consequential (financial transactions, legal agreements), give users the ability to review, correct, and confirm before the action is permanent.

There is also 4.1.3 Status Messages (Level AA), which covers dynamically injected messages that don’t receive focus — these must be announced by assistive technology using role="status" or role="alert".

What an accessible error message actually needs

Getting error messages right requires attention to four distinct layers:

1. The programmatic connection

Every error message must be tied to its field using aria-describedby. This tells screen readers to announce the error text when the field receives focus.

<!-- Before: error text exists visually but is invisible to screen readers -->
<label for="email">Email</label>
<input type="email" id="email" class="error">
<p class="error-text">Enter a valid email address.</p>

<!-- After: programmatic association via aria-describedby -->
<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-describedby="email-err"
  aria-invalid="true"
>
<p id="email-err" class="error-text">Enter a valid email address.</p>

The aria-invalid="true" attribute signals that the field is currently invalid, which most screen readers announce when focus lands on it.

2. Focus management after submission

When a form submits and errors are present, focus must move somewhere useful. The two most common patterns:

• Move focus to an error summary at the top of the form that lists all errors with links to the relevant fields
• Move focus to the first field in error

If focus stays on the submit button or nowhere at all, screen reader users have to discover the errors themselves by navigating through the form — if they even know errors exist.

// After validation fails, move focus to the error summary
const summary = document.getElementById('error-summary');
summary.setAttribute('tabindex', '-1');
summary.focus();

3. Live region announcements for dynamic errors

For errors that appear as the user types (inline real-time validation), use ARIA live regions so the message is announced without requiring focus to move.

<p role="alert" aria-live="assertive" id="password-err">
  Password must be at least 8 characters.
</p>

Use role="alert" / aria-live="assertive" for errors that need immediate attention. Use role="status" / aria-live="polite" for less urgent feedback that can wait for the user to pause.

4. The error message itself

The language matters. Accessible error messages are:

• Specific: say what’s wrong, not just that something is wrong
• Actionable: tell the user exactly what to do to fix it
• Polite: avoid blaming language like “you entered an invalid value”

Inaccessible	Accessible
”Invalid input"	"Email address must include an @ symbol, e.g. name@example.com"
"Error"	"Date must be in DD/MM/YYYY format"
"Required field"	"Full name is required"
"Password invalid"	"Password must be at least 8 characters and include one number”

Patterns for different error scenarios

Inline field errors

The most common pattern. An error message appears directly below its associated field. Works well for simple forms. Requires aria-describedby and aria-invalid to be announced correctly.

Error summary banners

For long forms with multiple errors, place a summary at the top listing all issues as links that jump to the relevant field. Move focus here after a failed submission. This is the pattern used by GOV.UK and widely recommended for complex forms.

Toast notifications

Short-lived messages that appear at the edge of the screen are among the most inaccessible patterns in common use. They disappear before screen reader users can reach them, they’re often not announced at all, and they give no recovery path. Avoid using toasts for errors. If you do use them, pair them with a persistent error state on the form itself.

System errors

When something goes wrong on the server side, tell the user in plain language what happened and what they can do next. “Something went wrong” with no further guidance leaves users stranded.

<div role="alert" aria-live="assertive">
  <p>We couldn't save your changes due to a network error.
  Please check your connection and try again.</p>
</div>

The testing checklist

After implementing error handling, verify these manually — automated tools will not catch most of them:

• Submitting an empty required form moves focus to an error summary or the first field in error
• Each error message is linked to its field via aria-describedby
• Fields in error have aria-invalid="true"
• Error messages are announced when focus lands on the affected field
• Real-time validation uses live regions
• Error messages use specific, actionable language — not just “invalid”
• Color is not the only way errors are indicated (icon or text label alongside the red)
• The error can be tab-navigated to from the keyboard
• Focus order after submission is logical and does not jump unpredictably
• Toast messages are paired with a persistent error state

Why automated tools miss most of this

An automated scanner can check whether aria-describedby points to an existing element and whether aria-invalid is present. It cannot check whether focus moves correctly after submission, whether error text is accurate, or whether a toast notification vanishes before it can be read. Our manual accessibility audits include form-specific testing with real assistive technology — the only reliable way to verify error handling actually works end to end.

If you’re unsure where your forms stand, run a free scan to surface the automatable issues first, then take it from there.