How to Fix Form Error Messages for WCAG Error Identification

What WCAG says about error messages

Several success criteria apply to forms, and they work together. The core three are about errors directly:

Others support them. 3.3.2 Labels or Instructions (A) requires labels and any format instructions up front. 1.4.1 (A) says colour must not be the only way information is shown, so a red border alone fails. 4.1.3 Status Messages (AA) requires messages such as 3 errors found to be announced without moving focus, if focus does not move. WCAG 2.2 adds 3.3.7 Redundant Entry (A), so a failed submission must not wipe the answers people already gave, and 3.3.8 Accessible Authentication (AA), which matters for login error handling.

In short: an accessible error is written in words, sits next to the field, is connected to the field in code, tells people how to fix it, and is announced or focused so that people who cannot see it still find it.

Why form errors fail WCAG

Most of these come from a theme or form plugin rather than from content, so one fix in the template repairs every form on the site.

How to test your form errors

Automated tools can catch missing labels, but they rarely trigger errors, so this test is manual. It takes ten minutes per form.

1. Submit the form empty. Write down what appears, where, and whether focus moved.
2. Fill in wrong values: an email without an @, a date in the wrong format, a phone number with letters. Submit again.
3. Check that your other answers are still there after the error.
4. Turn on NVDA (Windows) or VoiceOver (Mac, Cmd+F5) and repeat. After submitting, can you tell how many errors there are? When you Tab to a failed field, is the error read out with the label?
5. In Chrome DevTools, select a failed input and open the Accessibility pane. The computed properties should show Invalid user entry: true and the error text under Description.

You can also list every invalid field and its description from the console:

document.querySelectorAll('[aria-invalid="true"]').forEach(el => {
  const ids = (el.getAttribute('aria-describedby') || '').split(' ');
  const text = ids.map(id => document.getElementById(id)?.textContent.trim()).join(' | ');
  console.log(el.name, '=>', text || 'NO DESCRIPTION');
});

Any field printing NO DESCRIPTION has an error a screen reader user cannot hear.

The HTML and ARIA for an accessible error message

This pattern works in every current browser and screen reader. The label names the field, a hint gives the format before anyone makes a mistake, and the error is linked with aria-describedby:

<div class="field field--error">
  <label for="email">Email address</label>
  <p id="email-hint" class="hint">We will send your booking confirmation here</p>
  <p id="email-error" class="error-text">
    <span class="visually-hidden">Error:</span>
    Enter an email address in the correct format, like name@example.com
  </p>
  <input id="email" name="email" type="email" autocomplete="email"
    aria-describedby="email-hint email-error"
    aria-invalid="true">
</div>

• aria-invalid="true" makes screen readers say invalid with the field. Set it only after validation fails, never on page load, and remove it once the value is fixed.
• aria-describedby joins the hint and the error, so both are read after the label when the field is focused. Keep the visible label in the label element; do not move it into an aria-label.
• The hidden word Error: gives screen reader users the same signal the red styling gives sighted users.
• aria-errormessage exists for this purpose, but screen reader support is still uneven, so aria-describedby is the safer choice today.

Styling that does not rely on colour

.field--error input { border: 3px solid #b3261e; }
.field--error { border-left: 5px solid #b3261e; padding-left: 12px; }
.error-text { font-weight: 700; }
.error-text::before { content: "\26A0\FE0F  "; }

The thicker border, side bar, bold text and warning icon mean the error is still obvious without colour. The red still needs 3:1 contrast against the background for the border and 4.5:1 for the text; see fixing colour contrast.

Writing the message

Say what went wrong and how to fix it, in plain words. Compare Invalid date with Enter your date of birth as day, month and year, for example 27 3 1985. Avoid blame, technical codes and messages that only say a field is required when you could say Enter your postcode.

Error summaries, focus and live regions

On a long form, a list of errors at the top tells people how many problems there are and takes them straight to each field. After a failed submit, show the summary and move focus to it:

<div id="error-summary" class="error-summary" tabindex="-1" hidden>
  <h2>There is a problem</h2>
  <ul>
    <li><a href="#email">Enter an email address in the correct format</a></li>
    <li><a href="#phone">Enter a phone number, like 01632 960961</a></li>
  </ul>
</div>

form.addEventListener('submit', (e) => {
  const errors = validate(form);           // your own checks, returns [{id, message}]
  if (!errors.length) return;
  e.preventDefault();
  const list = summary.querySelector('ul');
  list.innerHTML = errors.map(er =>
    `<li><a href="#${er.id}">${er.message}</a></li>`).join('');
  summary.hidden = false;
  summary.focus();
  document.title = 'Error: ' + document.title.replace(/^Error: /, '');
});

Moving focus to the summary makes screen readers read it at once, so you do not also need role="alert"; using both can cause the summary to be read twice. If the page reloads with errors from the server, render the summary in the HTML and focus it on load. Prefixing the page title with Error: helps people who rely on the title to know a submit failed.

When to use a live region

Use a live region when you show a message without moving focus. A short form validated on submit can place a polite status message such as 2 errors found, please check the highlighted fields in an element with role="status". Do not announce errors as people type; validate when they leave a field or submit, otherwise every keystroke interrupts them.

Native HTML validation and custom error messages

Attributes such as required, type="email", pattern and min give you free validation, and browsers expose the invalid state to assistive technology. The weak point is the message bubble: its wording and timing are set by the browser, it disappears after a few seconds, it cannot be styled and it only shows one error at a time. You can change the wording with setCustomValidity:

const postcode = document.getElementById('postcode');
postcode.addEventListener('input', () => postcode.setCustomValidity(''));
postcode.addEventListener('invalid', () => {
  if (postcode.validity.valueMissing) {
    postcode.setCustomValidity('Enter your postcode');
  } else if (postcode.validity.patternMismatch) {
    postcode.setCustomValidity('Enter a postcode in the format AB1 2CD');
  }
});

Clear the custom message on every input, or the field stays invalid even after it is corrected. For full control, which most accessible forms need, add novalidate to the form. That stops the bubbles but keeps the validation API, so your script can read input.validity and write persistent messages using the markup above. For styling, the :user-invalid selector, now supported in current browsers, only matches after the user has interacted, which avoids showing errors on a fresh page. More patterns are in fixing form validation.

The fix, step by step

Edge cases worth knowing

• Login errors. Error Suggestion has a security exception, so the email or password is incorrect is fine. Do not block pasting into password fields, which would also fail 3.3.8 Accessible Authentication.
• Radio groups and checkboxes. Put the error inside the fieldset, after the legend, and link it with aria-describedby on the fieldset. Link the summary to the first option.
• Date fields split into three boxes. Mark only the boxes that are wrong as invalid, and say which part is wrong: Date of birth must include a year.
• Third-party forms. Embedded booking or payment forms are part of your page. Test their errors with a keyboard and screen reader, and raise faults with the supplier.
• Single page apps. In React or Vue, render the error element once and change its text, rather than mounting a new node, so screen readers notice. See accessibility in React.

Keeping form errors accessible

Build the field, hint, error and summary into one reusable component or theme partial, so every new form inherits them. Keep a short list of approved message wordings for common fields. Add the submit-empty test to your checklist for every new form, plugin update and checkout change, and include it in any review against WCAG requirements. For the labels themselves, see fixing form labels, and for broken ARIA attributes found by audits, fixing ARIA errors.