WCAG 3.3.3 Error Suggestion: How to Give Useful Form Error Messages

WCAG 3.3.3 Error Suggestion: what the success criterion asks for

WCAG 3.3.3 Error Suggestion (WCAG 2.1, Level AA) says: when an input error is detected and suggestions for correction are known, those suggestions must be provided unless doing so would jeopardise security or the purpose of the content. This page shows what that means in practice and gives reusable text and implementation patterns for form error messages.

When you must provide suggestions

Provide suggestions whenever the application detects an input error and you can reasonably suggest a correction. For example, suggest a correct format for an email, a missing required field, or an acceptable value range for a number. Do not offer suggestions if doing so would reveal secure information or defeat the purpose of the form, such as showing a stored password or revealing private account details.

What makes a suggestion useful

A useful suggestion does four things. It says what went wrong. It says how to fix it. It shows an example of a valid value when helpful. It points to where the user must act.

Be specific and actionable

• Bad: “Invalid input.”
• Good: “Enter a UK phone number in this format: 07700 900123.”

Show valid values and examples

When format matters, show one or two brief examples and the allowed characters. For dates, give the expected order and a sample: “Use DD/MM/YYYY, for example 21/09/2026.”

Explain limits and units

Say the range and unit when relevant: “Enter a weight between 0.1 kg and 250 kg.” Avoid vague phrases like “too large”.

Avoid blame and jargon

Use neutral language. Do not imply the user made a mistake on purpose. Replace “You failed to” with “Please provide” or “Enter”.

Common scenarios and suggested messages

Field	Suggested message
Email	“Enter a valid email address, for example [email protected].”
Password (creation)	“Password must be 10–64 characters, include at least one letter and one digit.”
Date	“Use DD/MM/YYYY. For example 21/09/2026.”
Numeric range	“Enter a value between 1 and 100.”

Technical implementation notes

Link each error message to the input so screen reader users and keyboard users can find it. Use native controls and follow these attributes and behaviours.

Key attributes and ARIA

• Set aria-invalid=“true” on an input with an error.
• Use aria-describedby on the input to reference the error element id.
• For dynamic announcements, use an aria-live=“polite” region or role=“alert” depending on timing and priority.

Inline message pattern

Place the suggestion directly next to the field label or control. Keep messages short. Ensure focus management moves to the field with the error when the server returns a validation error.

Error summary pattern

When multiple errors appear after submission, include a summary at the top with links to each field. Each link should move keyboard focus to the input and place the cursor where correction is needed. Also update the inline message next to the field.

Examples of accessible text and markup (plain text examples)

Use these as templates. Replace words in square brackets with the real values.

• Email: “Please enter your email address in the format [email protected].”
• Phone: “Please enter a UK phone number, for example 07700 900123.”
• Password: “Password must be 10–64 characters and include at least one letter and one number.”
• Card number: “Enter a 16-digit card number with no spaces.”

Markup hint: mark the input with aria-describedby=“error-id” and add aria-invalid=“true” when invalid. Give the error element role=“alert” or aria-live=“polite” if it appears after the page loads.

When not to give a suggestion

Do not offer correction suggestions when doing so would reveal sensitive information or undermine authentication. For example, do not suggest corrections that reveal an existing user account or show parts of stored passwords. In those cases, give a neutral message such as “We cannot confirm this information. Check your entry and try again.”

Common mistakes to avoid

• Vague messages: avoid “Something went wrong.”
• Missing programmatic relationships: do not show messages without linking them to the input with aria-describedby.
• Focusing traps: do not move keyboard focus in a way that prevents users from correcting the field.
• Overlong text: keep suggestions under two lines on most viewports.

Testing checklist for WCAG 3.3.3

1. Trigger each error case manually and confirm a clear suggestion appears.
2. Verify screen reader announces the error and that aria-describedby or role=“alert” is used.
3. Check keyboard-only users can reach the error and move focus to the field from an error summary link.
4. Confirm suggestions do not reveal sensitive data or violate privacy policies.
5. Run an automated scan to find missing labels, missing aria-describedby, or unl inked error summaries, then verify manually.

Quick compliance checklist

• Do provide a specific, actionable suggestion for correct input.
• Do link messages to inputs with aria-describedby and set aria-invalid as needed.
• Do include examples or allowed formats where useful.
• Do not reveal secure or private information in suggestions.
• Do test with keyboard and a screen reader.

Further reading

Refer to the WCAG 2.1 success criteria for formal test steps and to your organisation’s privacy and security policies when deciding whether a suggestion might reveal sensitive data. For legal or procurement questions, consult your accessibility lead or legal team.