RGAA 11.11 — Dans chaque formulaire, le contrôle de saisie est-il accompagné, si nécessaire, de suggestions facilitant la correction des erreurs de saisie ?

Pas de suggestion de correction

Le problème

L'absence de suggestions de correction se produit lorsqu'un formulaire signale une erreur mais ne propose pas d'indication sur la façon de la corriger. Le critère RGAA 11.11 (correspondant au WCAG 3.3.3, niveau AA) exige que si une erreur est détectée et que des suggestions de correction sont possibles, elles soient fournies à l'utilisateur.

Les exemples typiques incluent : un champ email qui affiche « Email invalide » sans indiquer le format attendu, un champ de mot de passe qui dit « Mot de passe trop faible » sans préciser les critères requis, un champ de date qui affiche « Date invalide » sans montrer le format attendu (JJ/MM/AAAA), et un champ numérique qui dit « Valeur hors limites » sans préciser la plage acceptée.

Le simple fait de signaler qu'une erreur existe (critère 11.10) ne suffit pas. L'utilisateur doit savoir comment corriger son erreur. Un message comme « Format attendu : JJ/MM/AAAA » ou « Le mot de passe doit contenir au moins 8 caractères, une majuscule et un chiffre » est une suggestion de correction concrète et actionnable.

Impact sur les utilisateurs

Pour les personnes ayant des troubles cognitifs ou de la mémoire, un message d'erreur sans suggestion de correction est une impasse. Dire « Email invalide » ne les aide pas à comprendre ce qui manque. Ont-ils oublié le @? Le point ? Le nom de domaine ? La suggestion « Veuillez saisir une adresse au format nom@domaine.fr » résout immédiatement le problème.

Les personnes âgées peu familières avec les conventions web (formats de date, exigences de mot de passe) sont particulièrement affectées. Sans indication claire, elles multiplient les tentatives infructueuses et finissent par abandonner.

Les utilisateurs de lecteurs d'écran bénéficient aussi de suggestions claires car ils ne peuvent pas voir les indices visuels (placeholders, exemples dans la mise en page) que les utilisateurs voyants peuvent utiliser pour deviner le format attendu.

Votre site a-t-il ce problème ?

106 critères RGAA analysés en 5 minutes par notre IA.

Testez votre site gratuitement

Exemple de code

Avant (non conforme)
<!-- Pas de suggestion de correction -->
<label for="email">Email</label>
<input type="email" id="email" aria-invalid="true"
  aria-describedby="email-err">
<span id="email-err">Email invalide</span>

<label for="mdp">Mot de passe</label>
<input type="password" id="mdp" aria-invalid="true"
  aria-describedby="mdp-err">
<span id="mdp-err">Mot de passe trop faible</span>

<label for="date">Date de naissance</label>
<input type="text" id="date" aria-invalid="true"
  aria-describedby="date-err">
<span id="date-err">Date invalide</span>
Après (conforme)
<!-- Avec suggestions de correction -->
<label for="email">Email</label>
<input type="email" id="email" aria-invalid="true"
  aria-describedby="email-err"
  autocomplete="email">
<span id="email-err" role="alert">
  Veuillez saisir une adresse email valide, par exemple nom@domaine.fr
</span>

<label for="mdp">Mot de passe</label>
<input type="password" id="mdp" aria-invalid="true"
  aria-describedby="mdp-err">
<span id="mdp-err" role="alert">
  Le mot de passe doit contenir au moins 8 caractères,
  dont une majuscule, une minuscule et un chiffre
</span>

<label for="date">Date de naissance</label>
<input type="text" id="date" aria-invalid="true"
  aria-describedby="date-err"
  placeholder="JJ/MM/AAAA">
<span id="date-err" role="alert">
  Veuillez saisir la date au format JJ/MM/AAAA, par exemple 15/03/1990
</span>

Comment Scrutia détecte ce problème

Scrutia analyse les messages d'erreur de chaque formulaire et vérifie qu'ils contiennent des suggestions de correction concrètes (format attendu, plage de valeurs, exemple). Il identifie les messages d'erreur génériques (« invalide », « erreur ») qui ne fournissent pas d'indication sur la façon de corriger l'erreur. Le rapport propose des messages d'erreur améliorés avec des suggestions spécifiques.

Questions fréquentes

Quelle est la différence entre le RGAA 11.10 et le 11.11 ?
Le 11.10 (WCAG 3.3.1, niveau A) exige que les erreurs soient identifiées et décrites. Le 11.11 (WCAG 3.3.3, niveau AA) exige en plus que des suggestions de correction soient fournies quand c'est possible. Le 11.10 est « dites ce qui ne va pas », le 11.11 est « dites comment corriger ».
Les suggestions doivent-elles être dans le message d'erreur ?
Elles peuvent être dans le message d'erreur lui-même ou à proximité immédiate du champ (texte d'aide, placeholder, instruction au-dessus du champ). L'essentiel est qu'elles soient programmatiquement associées au champ et accessibles au moment de la correction.
Comment gérer les suggestions pour les mots de passe ?
Affichez les critères de validation en temps réel (au moins 8 caractères, une majuscule...) avec une indication visuelle de ceux qui sont satisfaits et ceux qui ne le sont pas. Utilisez aria-live pour annoncer les changements aux lecteurs d'écran.
Faut-il toujours fournir un exemple ?
Quand le format attendu n'est pas évident (date, numéro de téléphone, code postal), un exemple concret est la suggestion la plus efficace. Pour les champs plus simples (nom, ville), une indication du problème (« Ce champ ne peut pas être vide ») peut suffire.

Votre site a-t-il ce problème ?

Scrutia audite votre site sur 106 critères RGAA en 5 minutes. Navigation clavier, composants ARIA, focus visible, contrastes, et bien plus.

Lancer un audit gratuit