Error Messages That Announce: aria-describedby Done Right in Checkout

A shopper submits a checkout form, nothing happens, and the screen reader says nothing. The form has an error. The error is displayed in red text beside the field, and the screen reader user never hears it, because the error was never connected to the field, and the form never announced it.

The error has to reach the user through the channel they use

WCAG 3.3.1, Error Identification, at Level A, requires that if an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. Color alone is not identification. A red border is not a description. The error has to be text, and the text has to reach the user, which means it has to be announced, not just displayed.

The common failure is the error that appears visually and never reaches the assistive technology. The form validates on submit, the error text appears beside the field, and the screen reader user hears nothing, because the error was injected into the page without a live region and without a connection to the field. The user sits at a form that will not submit, with no idea why, and the only way to find out is to tab through every field and read each one, hoping to stumble on the error text. That is not an error message. It is a silent failure.

The fix has two parts, and both are required. First, connect the error to the field with aria-describedby, so the screen reader announces the error when the user reaches the field. Second, announce the error when it appears, either by putting it in a live region or by moving focus to an error summary on submit. The GOV.UK Design System error message guidance is the clearest statement of this: the error summary goes at the top of the form, it lists every error with a link to the field, and it receives focus on submit, so the user hears the errors before they start fixing them. The placeholder post is the companion failure: a field whose label disappears is a field whose error has nowhere to attach, and the two defects arrive together more often than not.

Inline errors and the summary do different jobs

The inline error tells the user what is wrong with this field. The summary tells the user how many errors there are and where they are. A form with only inline errors leaves the user hunting for them, field by field, with no count and no map. A form with only a summary leaves the user guessing which field to fix, because the summary names the error but the field does not show it. The form needs both, and the two have to agree: the summary links to the field, and the field shows the error the summary names.

The wording matters as much as the mechanism. An error that says Invalid input tells the user nothing. An error that says Enter a card number with 16 digits tells the user what to do. The error has to describe the problem in text, and the description has to be specific enough to act on. A red border plus an icon plus the words This field is required is identification. A red border alone is decoration, and it fails 3.3.1 the same way a red border failed it in the color alone post: the user who cannot see the color cannot see the error, and the error that cannot be seen is not an error message.

Put the error message in the field's description, not in its label. The accessible name stays short and stable, and the error is announced as the description when the user reaches the field. A label that changes on every error, Card number, then Card number, invalid, then Card number, required, is a label that confuses voice control and screen readers alike, because the name the user speaks is not the name the control has. The error belongs in aria-describedby, and the label belongs to the field, and the two stay separate.

The test that takes two minutes

Submit the checkout form with an empty required field, and listen. The screen reader should announce the error summary, the count, and the first error, and focus should be on the summary, not on the submit button. Tab to the field, and the error should be announced as the description. Fix the field, resubmit, and the next error should be announced the same way. If any of that is silent, the error message is not reaching the user, and the form is failing 3.3.1 while the visual design looks complete.

Test it with the keyboard alone, too, because the error summary has to be reachable and the links in it have to move focus to the field. A summary that cannot be tabbed to is a summary that does not exist for the keyboard user, and the keyboard user is the one who needs it most. The error message is the last thing a user hears before they abandon a purchase, and it is the cheapest thing on the page to fix. Connect it, announce it, and write it so the user knows what to do next.

Frequently asked questions

How do I make a screen reader announce a form error?

Connect the error to the field with aria-describedby, and put the error in the same live region the form already uses, or give the error summary the focus on submit. The announcement has to happen when the error appears, not when the user happens to tab to it.

Do I need inline errors and an error summary?

Both, and they do different jobs. The inline error tells the user what is wrong with this field. The summary tells the user how many errors there are and where they are. A form with only inline errors leaves the user hunting. A form with only a summary leaves the user guessing which field to fix.

Should the error message go in the label?

Put the error message in the label's description, not in the label itself. The accessible name stays short and stable, and the error is announced as the description. A label that changes on every error is a label that confuses voice control and screen readers alike.

Is a red border enough to identify an error?

Yes, and it is the rule that decides the wording. 3.3.1 requires errors to be identified in text, and color alone is not identification. An error that is only a red border fails, and an error that is red text plus an icon plus a message passes.