Dans chaque formulaire, le contrôle de saisie est-il accompagné, si nécessaire, de suggestions facilitant la correction des erreurs de saisie ?
Un message « Adresse e-mail invalide » ne suffit pas. L’utilisateur sait qu’il a fait une erreur — il ne sait pas comment la corriger. Ce critère exige d’aller plus loin : quand une erreur de saisie est détectée, le message doit indiquer ce qui était attendu.
Deux niveaux de suggestion sont évalués. Test 11.11.1 : le message précise le type ou le format attendu. Pour une date, « Format attendu : JJ/MM/AAAA ». Pour un mot de passe, les règles de composition. Pour un numéro de téléphone, la structure acceptée. Test 11.11.2 : le message fournit un exemple concret de valeur valide. « Exemple : [email protected] » après une erreur sur un champ email.
Le critère s’applique « si nécessaire », ce qui crée une exception explicite pour les cas où la suggestion compromettrait la sécurité ou la finalité du contrôle : champ mot de passe actuel, code anti-spam, réponse à une question secrète. Hors ces cas, l’absence de suggestion est une non-conformité ferme.
Les deux tests sont indépendants. Un message peut valider l’un et échouer l’autre.
2 tests pour confirmer qu'une suggestion de correction accompagne chaque erreur
Suggestion du type ou format attendu dans le message d'erreur
- Déclenchez toutes les erreurs de validation du formulaire (soumission avec des données délibérément incorrectes pour chaque champ validé).
- Pour chaque message d’erreur affiché, vérifiez qu’il indique le type ou le format de donnée attendu :
- Champ date → le format est mentionné (JJ/MM/AAAA, YYYY-MM-DD…)
- Champ mot de passe → les règles de composition sont listées (longueur, caractères requis)
- Champ numérique → la plage ou l’unité est précisée
- Si chaque message d’erreur inclut cette information sur le type ou le format attendu, le test est validé.
Exemple de valeur valide dans le message d'erreur
- Déclenchez toutes les erreurs de validation du formulaire.
- Pour chaque message d’erreur affiché, vérifiez qu’il propose un exemple concret de valeur valide :
- Champ email → « Exemple : [email protected] »
- Champ date → « Exemple : 25/03/2026 »
- Champ code postal → « Exemple : 75001 »
- Si chaque message d’erreur inclut un exemple de valeur valide, le test est validé.
Exemples
❌ Non conforme : Message d’erreur sans suggestion de correction
<label for="email">Adresse e-mail</label>
<input type="email" id="email"
aria-describedby="email-error"
aria-invalid="true">
<p id="email-error" role="alert">
L’adresse e-mail saisie est incorrecte.
</p>Le message signale l’erreur mais n’indique ni le format attendu ni un exemple valide. L’utilisateur — notamment une personne peu familière avec la syntaxe des adresses email, ou souffrant de troubles cognitifs — ne sait pas quoi corriger. Les deux tests 11.11.1 et 11.11.2 échouent.
✅ Conforme : Message d’erreur avec format attendu et exemple concret
<label for="email">Adresse e-mail</label>
<input type="email" id="email"
aria-describedby="email-error"
aria-invalid="true">
<p id="email-error" role="alert">
L’adresse e-mail saisie est incorrecte.
Format attendu : [email protected].
Exemple : [email protected]
</p>Le message indique le format attendu (test 11.11.1 validé) et fournit un exemple de valeur valide (test 11.11.2 validé). L’utilisateur comprend immédiatement ce qu’il doit corriger, sans avoir à deviner la syntaxe. Le message est vocalisé automatiquement par les lecteurs d’écran grâce à aria-describedby et role="alert".
✅ Conforme : Champ mot de passe : règles listées sans révéler la valeur
<label for="mdp-new">Nouveau mot de passe</label>
<input type="password" id="mdp-new"
aria-describedby="mdp-error"
aria-invalid="true">
<p id="mdp-error" role="alert">
Le mot de passe ne respecte pas les critères requis.
Il doit contenir au moins 8 caractères, une majuscule,
un chiffre et un caractère spécial (!, @, #, $…).
</p>Pour un nouveau mot de passe, lister les règles de composition répond au test 11.11.1. Donner des exemples de caractères spéciaux répond au test 11.11.2. La sécurité n’est pas compromise : on décrit le format attendu, pas la valeur correcte.
Astuces et pièges
⚠️ Le message générique « valeur incorrecte »
C’est l’erreur la plus fréquente en audit. Le message signale le problème mais ne dit pas comment le corriger. Pour RGAA 11.11, signaler l’erreur ne suffit pas : il faut suggérer la correction. Le critère 11.10 couvre la détection de l’erreur ; le critère 11.11 couvre ce qu’on fait après.
⚠️ L’exception sécurité : mot de passe actuel et codes uniques
La mention « si nécessaire » exclut les cas où une suggestion affaiblirait la sécurité. Un champ « mot de passe actuel » incorrect ne doit pas suggérer la valeur attendue. Un code à usage unique (OTP) non plus. En revanche, un champ « nouveau mot de passe » doit lister les règles de composition : c’est une suggestion de format, pas une révélation.
💡 Les deux tests s’évaluent indépendamment
« Format attendu : JJ/MM/AAAA » valide 11.11.1 mais pas 11.11.2 (pas d’exemple concret). « Exemple : 25/03/2026 » valide 11.11.2 mais peut échouer 11.11.1 si le format n’est pas explicité. Un bon message inclut les deux : le format et un exemple.
⚠️ Le placeholder comme substitut de suggestion
Un placeholder disparaît dès que l’utilisateur commence à saisir. Au moment où le message d’erreur s’affiche, le placeholder est masqué par la valeur erronée. La suggestion doit être dans le message d’erreur lui-même ou dans un élément persistant lié au champ via aria-describedby.
⚠️ Validation serveur après rechargement complet de page
Quand une erreur est renvoyée par le serveur avec rechargement de page, le contexte visuel change. L’utilisateur ne voit plus les indications de format affichées avant la soumission. Le message d’erreur doit répéter les suggestions, même si elles étaient présentes initialement sous le champ.
Questions fréquentes
Quels types de champs de formulaire sont concernés par le critère RGAA 11.11 ?
Il s’applique uniquement aux champs pour lesquels un message d’erreur est effectivement affiché. Si votre formulaire ne valide que l’email et la date, seuls ces deux messages sont évalués. Un champ sans validation possible n’est pas concerné.
Comment auditer le critère RGAA 11.11 sur les suggestions de correction en pratique ?
Soumettez le formulaire avec des valeurs délibérément incorrectes pour chaque champ validé. Lisez chaque message d’erreur : mentionne-t-il le format ou le type attendu (11.11.1) ? Donne-t-il un exemple de valeur valide (11.11.2) ? Si l’un des deux manque, le test correspondant échoue. Testez également avec un lecteur d’écran pour vérifier que les suggestions sont bien vocalisées au moment de l’erreur.
Où placer une suggestion de correction selon le critère RGAA 11.11 ?
Oui, à condition qu’elle reste visible et accessible après la soumission du formulaire. Mais c’est risqué : si la page défile ou si l’utilisateur est renvoyé en haut, la suggestion peut échapper à sa vue. Placer la suggestion directement dans le message d’erreur, lié au champ via aria-describedby, est la solution la plus sûre.
Comment proposer une suggestion de correction RGAA 11.11 pour un champ acceptant plusieurs formats ?
Listez les formats acceptés et donnez un exemple pour chacun. « Formats acceptés : 06 12 34 56 78 ou +33612345678. » Si la liste est longue, privilégiez le format le plus courant comme exemple principal et mentionnez l’existence des autres. L’objectif est que l’utilisateur comprenne comment corriger sa saisie.
Quelle est la différence entre les critères RGAA 11.10 et 11.11 ?
Le critère 11.10 porte sur la détection et la communication de l’erreur : l’utilisateur est informé qu’une erreur existe. Le critère 11.11 porte sur la correction : l’utilisateur sait comment corriger. Un message « Champ obligatoire » peut valider 11.10 mais ne dit rien sur le format attendu — il ne touche pas à 11.11, qui ne s’applique qu’aux erreurs de format ou de valeur invalide.