Accessible Error Messages: How to Design and Write Them

What makes an error message accessible

An accessible error message is:

• Written in text (icons and color can help, but not alone)

• Close to the element that failed

• Informative, so the user can fix the issue

• Associated with the failed element in the code

It’s also helpful to move focus to the form control that failed, especially after server-side validation, where users might not otherwise notice what has changed.

Write the message like a teammate, not a judge

Great, accessible error messages do two things:

1. Clearly describe the problem.

2. Suggest the fix (or the expected format).

More precision usually helps. “Only letters, not numbers” is clearer than a vague warning like “unusual characters.” Just keep it pragmatic; more precision can mean more message variants.

If you use error symbols (like an exclamation mark or an asterisk), don’t let the symbol carry the meaning by itself. Describe it in text for screen reader users, too.

Place it where people expect it

In-line errors are easiest to understand when they sit right next to the field to which they refer.

For “after submit” validation, it can also help to list errors at the top of the page, before the form, with a distinctive heading.

Each item in the list should:

• Reference the label of the related control

• Describe the error concisely and clearly

• Explain how to correct it (including format requirements)

• Include an in-page link to jump to the field

Make it work for screen readers and keyboards

Copy + placement aren’t enough. The code needs to connect the dots.

• Associate the message with the field.

• Mark invalid fields.

• Make sure updates are announced.

• Keep it keyboard-friendly.

Quick checklist for accessible error messages

• Text first: don’t rely on color or icons alone

• Nearby: keep the message close to the field

• Actionable: say what’s wrong and how to fix it

• Connected: use aria-describedby and (when invalid) aria-invalid="true"

• Announced: use role="alert" where appropriate

• Navigable: ensure keyboard access, and move focus to the first error after submit

If you get these basics right, accessible error messages stop being an accessibility checkbox and start feeling like a quiet UX upgrade that helps everyone complete the form with less friction.