Normes · WCAG 2.2

SC 3.3.3 Niveau AA WCAG 2.0

Suggestion d'erreur

Lorsqu'une erreur de saisie est détectée et qu'une correction est connue du système, celui-ci doit proposer une suggestion à l'utilisateur — sauf si cela compromet la sécurité ou invalide l'objet de la saisie.

Ce que le critère demande

Lorsqu’une saisie de formulaire est invalide et que le système dispose de suffisamment d’informations pour proposer une correction, il doit la communiquer. « La date doit être au format JJ/MM/AAAA — vouliez-vous dire 17/04/2026 ? » est préférable à un simple « Date invalide ». Si le système connaît des valeurs valides (par exemple la valeur la plus proche, une liste de pays autorisés), il doit les présenter.

Le critère comporte des exceptions explicites : ne pas divulguer d’informations qui compromettraient la sécurité (ne pas suggérer un nom d’utilisateur lorsque l’échec réel est un mauvais mot de passe) et ne pas proposer de corrections qui neutraliseraient l’objet de la saisie (ne pas auto-corriger un CAPTCHA).

Comment satisfaire ce critère

  • Pour les erreurs de format, afficher le format attendu et idéalement reformater la saisie de l’utilisateur comme suggestion : « Essayez 01-23-45-67-89 ».
  • Pour les adresses e-mail mal saisies, proposer « Vouliez-vous dire utilisateur@gmail.com ? » lorsque le domaine saisi est proche d’un domaine connu.
  • Pour les codes postaux invalides, suggérer la correspondance la plus proche ou afficher le format valide pour le pays sélectionné.
  • Pour les règles de mot de passe, lister quelle règle spécifique n’est pas satisfaite : « Le mot de passe doit contenir un chiffre — essayez d’en ajouter un ».
  • Pour les nombres hors plage, indiquer la plage autorisée et proposer la valeur valide la plus proche.
  • Ne pas appliquer les suggestions automatiquement et silencieusement — laisser l’utilisateur les accepter ou les ignorer.

Erreurs courantes

  • Messages génériques « Saisie invalide » sans aucune indication sur ce à quoi ressemble une saisie valide.
  • Champs de mot de passe indiquant « Le mot de passe ne respecte pas les exigences » sans préciser quelle règle n’est pas satisfaite.
  • Formulaires d’adresse rejetant un code postal sans indiquer le format attendu pour le pays sélectionné.
  • Validateurs d’e-mail qui échouent silencieusement sur « utilisateur@gmail.com » sans suggérer la probable faute de frappe.

Pourquoi c’est important

Les suggestions d’erreur font la différence entre un utilisateur qui corrige une erreur en trois secondes et un utilisateur qui abandonne le formulaire. Pour les utilisateurs ayant des troubles cognitifs, une dyslexie ou des difficultés motrices, la charge cognitive liée à la compréhension d’un vague message « Invalide » constitue la barrière réelle — pas la faute de frappe elle-même.

Associer 3.3.3 avec 3.3.1 et 3.3.2 : identifier ce qui ne va pas, suggérer comment le corriger, et libeller le champ clairement dès le départ pour rendre l’erreur moins probable.