In each form, is input validation accompanied, where necessary, by suggestions that make it easier to correct input errors?
A message such as "Invalid email address" is not enough. The user knows they made an error — they don't know how to fix it. This criterion requires going further: when an input error is detected, the message must indicate what was expected.
Two levels of suggestion are evaluated. Test 11.11.1: the message specifies the expected type or format. For a date, "Expected format: DD/MM/YYYY". For a password, the composition rules. For a phone number, the accepted structure. Test 11.11.2: the message provides a concrete example of a valid value. "Example: [email protected]" after an error on an email field.
The criterion applies "if necessary", which creates an explicit exception for cases where the suggestion would compromise security or the purpose of the control: current password field, anti-spam code, answer to a secret question. Outside these cases, the absence of a suggestion is a firm non-compliance.
The two tests are independent. A message may pass one and fail the other.
2 tests to confirm that a correction suggestion accompanies each error
Suggestion of expected type or format in error message
- Trigger all form validation errors (submit with deliberately incorrect data for each validated field).
- For each error message displayed, verify that it indicates the expected data type or format:
- Date field → the format is mentioned (DD/MM/YYYY, YYYY-MM-DD…)
- Password field → composition rules are listed (length, required characters)
- Numeric field → the range or unit is specified
- If each error message includes this information about the expected type or format, the test is passed.
Example of valid value in error message
- Trigger all form validation errors.
- For each error message displayed, verify that it provides a concrete example of a valid value:
- Email field → "Example: [email protected]"
- Date field → "Example: 25/03/2026"
- Postal code field → "Example: 75001"
- If each error message includes an example of a valid value, the test is passed.
Examples
❌ Non-compliant : Error message without correction suggestion
<label for="email">Email address</label>
<input type="email" id="email"
aria-describedby="email-error"
aria-invalid="true">
<p id="email-error" role="alert">
The email address entered is incorrect.
</p>The message signals the error but indicates neither the expected format nor a valid example. The user — especially someone unfamiliar with email syntax, or suffering from cognitive disorders — does not know what to correct. Both tests 11.11.1 and 11.11.2 fail.
✅ Compliant : Error message with expected format and concrete example
<label for="email">Email address</label>
<input type="email" id="email"
aria-describedby="email-error"
aria-invalid="true">
<p id="email-error" role="alert">
The email address entered is incorrect.
Expected format: [email protected].
Example: [email protected]
</p>The message indicates the expected format (test 11.11.1 passed) and provides an example of a valid value (test 11.11.2 passed). The user immediately understands what they need to correct, without having to guess the syntax. The message is automatically spoken by screen readers thanks to aria-describedby and role="alert".
✅ Compliant : Password field: rules listed without revealing the value
<label for="mdp-new">New password</label>
<input type="password" id="mdp-new"
aria-describedby="mdp-error"
aria-invalid="true">
<p id="mdp-error" role="alert">
The password does not meet the required criteria.
It must contain at least 8 characters, one uppercase letter,
one digit, and one special character (!, @, #, $…).
</p>For a new password, listing composition rules addresses test 11.11.1. Giving examples of special characters addresses test 11.11.2. Security is not compromised: we describe the expected format, not the correct value.
Tips and pitfalls
⚠️ The generic "incorrect value" message
This is the most common error in audits. The message signals the problem but does not say how to fix it. For RGAA 11.11, signaling the error is not enough: you must suggest the correction. Criterion 11.10 covers error detection; criterion 11.11 covers what you do after.
⚠️ The security exception: current password and unique codes
The mention "if necessary" excludes cases where a suggestion would weaken security. An incorrect "current password" field must not suggest the expected value. Neither should a one-time code (OTP). On the other hand, a "new password" field must list composition rules: this is a format suggestion, not a revelation.
💡 The two tests are evaluated independently
"Expected format: DD/MM/YYYY" passes 11.11.1 but not 11.11.2 (no concrete example). "Example: 25/03/2026" passes 11.11.2 but may fail 11.11.1 if the format is not made explicit. A good message includes both: the format and an example.
⚠️ The placeholder as a substitute for suggestion
A placeholder disappears as soon as the user starts typing. When the error message is displayed, the placeholder is hidden by the incorrect value. The suggestion must be in the error message itself or in a persistent element linked to the field via aria-describedby.
⚠️ Server-side validation after full page reload
When an error is returned by the server with a page reload, the visual context changes. The user no longer sees the format hints displayed before submission. The error message must repeat the suggestions, even if they were present initially under the field.
Frequently asked questions
Which types of form fields are covered by RGAA criterion 11.11?
It applies only to fields for which an error message is actually displayed. If your form only validates email and date, only these two messages are evaluated. A field with no possible validation is not affected.
How do I audit RGAA criterion 11.11 on correction suggestions in practice?
Submit the form with deliberately incorrect values for each validated field. Read each error message: does it mention the expected format or type (11.11.1)? Does it give an example of a valid value (11.11.2)? If one of the two is missing, the corresponding test fails. Also test with a screen reader to verify that suggestions are properly spoken when the error occurs.
Where should a correction suggestion be placed according to RGAA criterion 11.11?
Yes, as long as it remains visible and accessible after form submission. But this is risky: if the page scrolls or if the user is sent to the top, the suggestion may escape their view. Placing the suggestion directly in the error message, linked to the field via aria-describedby, is the safest solution.
How do I provide a correction suggestion for a field that accepts multiple formats according to RGAA 11.11?
List the accepted formats and provide an example for each. "Accepted formats: 06 12 34 56 78 or +33612345678." If the list is long, prioritize the most common format as the main example and mention the existence of the others. The goal is for the user to understand how to correct their input.
What is the difference between RGAA criteria 11.10 and 11.11?
Criterion 11.10 covers error detection and communication: the user is informed that an error exists. Criterion 11.11 covers correction: the user knows how to fix it. A message "Required field" may pass 11.10 but says nothing about the expected format — it does not address 11.11, which only applies to format errors or invalid value errors.