WCAG 3.3.1 Error Identification: How to Make Form Errors Clear and Accessible

WCAG 3.3.1 Error Identification: what the success criterion requires

WCAG 3.3.1, from WCAG 2.1 Level A, says that when an input error is detected the item in error must be identified and described to the user in text. That applies to any form or interactive control where validation finds a problem after submission or during data entry. This rule ensures people who use assistive technology can find which field failed and why.

Where and when it applies

This criterion applies to client and server side validation, single-field checks, and multi-field submissions. If a page detects an error automatically or after a user submits, you must present a clear text identification of which control is in error. If the page is rebuilt on the server, the returned HTML must still identify and describe the error in text.

Core techniques that meet WCAG 3.3.1

Use these proven techniques together. One alone is usually not enough.

• Provide a visible, text error message near the field. Keep it concise and specific.
• Associate the error message with the control for assistive technology. Use aria-describedby pointing to the message or ensure the message is part of the form markup that references the input.
• Mark the control as invalid with aria-invalid=“true” or the HTML5 invalid state so assistive tech can convey the state.
• If you announce errors dynamically, use an ARIA live region or role=“alert” so screen readers receive the message when it appears.
• For returned server pages, include an error summary at the top with links or anchors to the problematic fields and clear text descriptions for each linked item.

Practical step-by-step pattern (server and client)

1. Detect the error server-side or client-side after validation.
2. Render a short, clear text message tied to the field. Example: “Email address is missing the @ sign.”
3. Ensure the message is reachable by assistive tech: add id to the message and set aria-describedby on the input to that id.
4. Set aria-invalid=“true” on the input so screen readers announce the invalid state.
5. If multiple errors exist, include an error summary at the top that links to each input. Move keyboard focus to that summary on submit so keyboard and screen reader users hear the list first.
6. When the user fixes an error, remove the message and clear aria-invalid or update the aria-describedby reference accordingly.

Decision framework: inline text, live feedback, or summary?

Choose one of these approaches based on form length and user flow.

• Short forms with one or two fields: inline text next to each field is enough.
• Long forms or multi-step flows: provide both an error summary and inline messages so users can get the big picture and navigate to each field.
• Live inline validation during typing: use cautiously. If you validate while the user types, announce errors via a live region and avoid moving focus away from the field.

Common mistakes and how to avoid them

• Relying only on colour. Colour can show a problem visually but does not meet the text requirement. Always include text that names the error.
• Using placeholder text as the only label. Placeholders are not a replacement for labels or error descriptions.
• Showing an error visually but not in the DOM. If an assistive device cannot read the message, the user loses the information.
• Announcing errors but not linking them to the input. A live announcement without a persistent textual association makes recovery harder.
• Moving focus unexpectedly. Send focus to an error summary or the first invalid field only when helpful and predictable.

Screen reader behaviour and reliable announcements

Different screen readers and browsers announce changes differently. Follow these rules to get consistent behaviour.

• Use an inline text message with an id and reference it with aria-describedby. This creates a persistent connection that most screen readers use when the control receives focus.
• For immediate announcements after submission, move focus to an error summary with keyboard focusable link targets. This ensures screen readers read the summary first.
• If you use live regions, choose an appropriate politeness setting. For important errors use an assertive live region or role=“alert”. For less urgent helper messages use polite live regions.

Accessible examples: real-world scenarios

Scenario: password confirmation does not match. Apply this sequence.

1. After submit, detect mismatch server-side or client-side.
2. Show inline message next to the confirmation field: “Passwords do not match.”
3. Give the message an id and add aria-describedby to the confirmation input and set aria-invalid=“true”.
4. If the form has multiple fields, add an error summary at the top with a link to the confirmation field and move focus there when the form reloads.

Testing checklist

• Keyboard only: submit the form and tab through provided links. Focus should reach the error summary or the invalid field.
• Screen reader: verify the error summary is read or announced and that inline messages are associated with fields when focused.
• Colour-blind / high contrast: hide colour to confirm the message text still identifies the error.
• HTML-only: disable JavaScript to ensure server-side errors still render as text and link to inputs.

When to consult related success criteria

WCAG 3.3.1 covers identification and text description for errors. For related guidance look at:

• WCAG 3.3.3 Error Suggestion, which addresses offering corrections when possible.
• WCAG 3.3.2 Labels or Instructions, which covers clear labels and instructions that reduce errors.

Quick compliance checklist (practical)

• Each error message is text, concise, and specific.
• Each message is programmatically associated with the field (aria-describedby or linked markup).
• Invalid inputs have aria-invalid=“true” when appropriate.
• Long forms include an error summary with links and focus management.
• Messages persist in the DOM when visible and are removed or updated when fixed.
• Manual testing includes keyboard, screen reader, and no-JS checks.

Final notes

Meeting WCAG 3.3.1 is about clarity and programmatic association. Use clear text, bind messages to controls, and make sure assistive technologies can discover and announce the error. Where you can offer corrections, also check WCAG 3.3.3 for the higher level requirement to suggest fixes.