Skip to main content

Making form error messages clear and accessible

Published: •4 min read•navable Team
FormsError messagesScreen readersARIAWCAG

You submit a form. Error messages appear beside two fields. How does someone using a screen reader find out that submission failed and which entries need correcting?

You can move focus deliberately or announce a message while focus stays in place. The choice depends on the form and the route back to the fields. Test the interaction through correction and resubmission.

What should an error explain?

“Invalid entry” leaves the affected field unclear. “Enter your email address, such as name@example.org” identifies the field and suggests a correction. WCAG distinguishes error identification, 3.3.1, from error suggestion, 3.3.3.

The field still needs its visible label. The forms guide covers labels, hints and associated error descriptions. This article follows the interaction after an action causes an error to appear.

An error summary provides a route back

Consider a contact form with name and email fields. Both are empty when submitted. A summary above the fields lists both errors and links to the corresponding inputs.

In our prepared teaching example, the summary receives focus after an unsuccessful submission. Tab reaches the first error link; Enter moves focus to its field. Once you enter your name, only the email error remains. The name you entered is preserved.

Try it: focus on the error summary

Submit the form empty, then correct the fields. Use fictional details. Nothing is sent or stored.

Enable JavaScript to try this example. The article explains the interaction in text.

Try it: focus on the error summary
After an invalid submission, the summary receives focus. Follow an error link to its field and correct the entry. Reset affects only this example.

An excerpt for this kind of summary:

<div id="errors" role="group" aria-labelledby="errors-title" tabindex="-1">
  <p id="errors-title">Please correct your entries</p>
  <ul>
    <li><a href="#email">Enter your email address.</a></li>
  </ul>
</div>

The application needs to reveal the summary after validation and move focus to it. Check that the link focuses the intended input. The excerpt alone does not implement that behavior.

GOV.UK documents an error summary with field links and focus management. It is a specific design-system pattern. WCAG does not prescribe that same summary for every form.

A live region announces a change without moving focus

In the second example, focus stays on the submit button. An existing notification region receives the text “2 errors. Enter your name. Enter your email address.” Error descriptions also appear beside the inputs.

Try it: a live region with stationary focus

Submit the form empty, then correct the fields. Use fictional details. Nothing is sent or stored.

Enable JavaScript to try this example. The article explains the interaction in text.

Try it: a live region with stationary focus

The notification region updates after submission. The example does not move focus. Shift+Tab takes you from the submit button back to the fields.
<p id="feedback" role="status" aria-atomic="true"></p>

The application inserts the message after validation. W3C technique ARIA19 describes live-region error notification. Our role="status" example is a candidate to test rather than a requirement for every error.

WCAG 4.1.3, Status Messages, addresses information presented without a focus change. Plan how users will reach the affected fields afterwards. Hearing a notification is one part of correcting the form.

When does repetition become distracting?

A submission notification and an error description heard when returning to a field can serve different purposes. Test the interaction to find out whether an additional, distracting duplicate announcement occurs.

Focus management and an alert role can also coexist: GOV.UK's example combines them. A blanket ban on role="alert" alongside aria-describedby would therefore be misleading. WAI-ARIA defines aria-describedby as an association with a description; that association does not guarantee specific speech for every dynamic update.

Try the initial submission, an unchanged second submission and correction of one field. Record what you hear and where focus goes. Inspecting the browser's accessibility tree does not establish what a screen reader spoke.

Check your form through correction

  1. Submit it empty. Can you tell that submission failed?
  2. Reach the affected inputs with the keyboard. Are the field, error and correction clear?
  3. Submit the same entries again. Is the feedback still perceptible?
  4. Correct one field. Are other values preserved and obsolete error states removed?
  5. Submit valid entries. Is completion clearly confirmed?

Repeat the sequence with a screen reader and scan the reached states separately. Use the website-testing guide to select other states for your test plan.

Further reading and sources