Accessible error messages: The complete guide

The hidden cost of unhelpful errors

You have probably seen it: a form that tells you “Invalid input” after you’ve carefully typed your phone number. A checkout process that marks a field red but offers no explanation. An error message that uses cryptic codes understood only by the developer who wrote it at 11pm on a Friday.

These aren’t minor UX inconveniences. For the 1.3 billion people worldwide who live with some form of disability, poorly crafted error messages can make a digital product completely unusable. For screen reader users, an error message that only changes color is invisible. For users with cognitive disabilities, a vague one-liner like “Something went wrong” is paralysing. For someone relying on voice control, a form error that steals focus unpredictably breaks the entire workflow.

Accessible error messages are not about adding ARIA attributes as an afterthought. They require intentional language, appropriate DOM structure, visual and non-visual signalling, and a deep respect for the diversity of your users. This guide walks through every dimension of getting them right — from WCAG criteria to copywriting principles to live code patterns.

What the standard actually demands

WCAG 2.2, published in October 2023, is the current benchmark for web accessibility and the reference point for most legal frameworks — including the EU Web Accessibility Directive, the UK Equality Act, and the US ADA. Several success criteria apply directly to error messages. Understanding the letter of each one is essential before you can go beyond them.

What makes a good error message

A well-formed error message has four non-negotiable components. Each one serves a distinct purpose — remove any one of them, and you degrade the experience for some portion of your users.

The language framework: Six rules for error copy

Error messages are a form of UX writing. They are not log output. They are not developer notes. They are human communication under stress — written for someone who just failed at something and needs to succeed.

Real Error Messages: Before & After

The gap between an inaccessible and an accessible error message is often just a few words and two attributes. These comparisons show exactly what changes — and why each change matters.

Required field validation

Format validation (date)

Password validation

Server / system error

Error patterns & when to use them

Different error scenarios call for different interaction patterns. Choosing the wrong container or announcement mechanism is one of the most common accessibility failures in forms.

The dual-layer approach for multi-field forms

For forms with three or more fields, a single pattern is insufficient. The Government Digital Service (GDS) and the ARIA Authoring Practices Guide both recommend a dual-layer system: an error summary at the top of the form, plus inline error messages beside each affected field.

Code patterns that work

Understanding the theory is half the battle. Below are production-ready patterns for the most common scenarios, annotated with the WCAG criteria each attribute satisfies.

Inline field validation

<!-- The label is always present and always linked -->
<div class="field-group">
  <label for="email">
    Email address
    <span class="required-indicator" aria-label="required"> *</span>
  </label>

  <input
    type="email"
    id="email"
    name="email"
    autocomplete="email"
    aria-required="true"
    aria-invalid="true"     <!-- set when invalid -->
    aria-describedby="email-hint email-error"
  />

  <!-- Hint text always shown (WCAG 3.3.2) -->
  <p id="email-hint" class="field-hint">
    We'll send your confirmation here.
  </p>

  <!-- Error message (shown only on error) -->
  <p
    id="email-error"
    class="field-error"
    role="alert"
    aria-live="assertive"
  >
    <!-- inject error text here -->
    Enter a complete email address — for example, [email protected]
  </p>
</div>

Error summary (multi-field forms)

<!-- Inject this above the form on submission, then focus #error-summary -->
<div
  id="error-summary"
  role="alert"
  aria-labelledby="error-summary-title"
  tabindex="-1"   <!-- allows programmatic focus -->
  class="error-summary"
>
  <h2 id="error-summary-title">
    There are 2 errors. Fix these to continue.
  </h2>
  <ul>
    <li><a href="#email">Email address: enter a complete email</a></li>
    <li><a href="#dob">Date of birth: use DD/MM/YYYY format</a></li>
  </ul>
</div>

<!-- JavaScript: move focus to summary after injection -->
<script>
  const summary = document.getElementById('error-summary');
  summary.focus(); // fires after DOM update
</script>

Dynamic / AJAX errors (no page reload)

When errors are returned asynchronously — from an API call, for example — you can’t rely on page load to surface them. The ARIA live region pattern is essential here.

// Set up the live region once on page load (empty, hidden)
// <div id="live-error" role="alert" aria-live="assertive" aria-atomic="true"></div>

async function submitForm(data) {
  try {
    const res = await fetch('/api/save', { method: 'POST', body: data });
    if (!res.ok) throw new Error(await res.text());
    announceStatus('Your changes have been saved.', 'polite');
  } catch (err) {
    announceStatus(
      'We couldn\'t save your changes. Try again or contact support.',
      'assertive'
    );
  }
}

function announceStatus(message, urgency = 'polite') {
  const region = document.getElementById('live-error');
  region.setAttribute('aria-live', urgency);
  // Clear first to re-trigger announcement if same message
  region.textContent = '';
  requestAnimationFrame(() => {
    region.textContent = message;
  });
}

The error accessibility audit checklist

Use this checklist during design review, code review, and QA. It covers all Level A and Level AA WCAG 2.2 criteria relevant to error states.

Visual & content

Programmatic & AT

Focus & keyboard

How we got here: A brief timeline

Error messages as a mirror of your product’s values

The error message is one of the most revealing moments in any digital experience. It arrives precisely when a user is under stress — when they’ve made a mistake, or when something beyond their control has gone wrong. What you do in that moment says everything about how seriously you take inclusion.

A red border with no text is not an error message. A code dump is not an error message. A vague “something went wrong” is not an error message. An accessible error message is a piece of clear, kind, actionable human communication that works for everyone — including the 26% of users who experience some form of disability, the 15% who rely on keyboard navigation, and the 100% of users who will encounter an error at some point.

The good news is that accessible error messages require very little extra effort when incorporated from the beginning. The ARIA attributes are minimal. The copy guidelines are clear. The patterns are well-established. What they require is intention — a deliberate decision to test with assistive technologies, to write for humans instead of systems, and to treat every failure state as an opportunity to earn trust.

At AIOPSGROUP, a valantic company, we build digital products that work for everyone. Accessibility engineering is embedded in our design system, our code reviews, and our QA process — not bolted on at the end. If your team needs help auditing, implementing, or building an accessible design system from the ground up, we’d be glad to help.