WCAG 3.3.3 : Suggestion d’erreur

Ce que signifie cette règle

WCAG 3.3.3 Suggestion après une erreur est un critère de niveau AA relevant du principe Compréhensible. Il s’appuie directement sur 3.3.1 (Identification des erreurs), qui exige que les erreurs soient identifiées dans le texte. La Suggestion après une erreur va plus loin : lorsqu’une erreur de saisie est détectée automatiquement, l’interface doit également indiquer à l’utilisateur comment la corriger, à condition que cette suggestion ne compromette pas la sécurité ou l’objectif du contenu.

La distinction clé ici est celle entre identification de l’erreur et suggestion après une erreur. Dire à un utilisateur « Votre date de naissance n’est pas valide » relève de l’identification. Dire à un utilisateur « Votre date de naissance n’est pas valide — veuillez saisir une date au format JJ/MM/AAAA » est une suggestion. Les deux sont requis par leurs critères respectifs, mais la Suggestion après une erreur exige qu’un guidage correctif, exploitable, accompagne le message d’erreur partout où c’est possible.

Le critère s’applique chaque fois qu’une erreur de saisie est détectée automatiquement — c’est-à-dire lorsque la logique de validation côté client ou côté serveur détermine qu’une valeur saisie ou envoyée ne répond pas aux critères attendus. Il s’applique à tous les contrôles de formulaire : champs de texte, listes déroulantes, cases à cocher, boutons radio, sélecteurs de date, champs de téléversement de fichier et tout composant interactif qui collecte des données utilisateur.

Ce qui est considéré comme conforme : Le message d’erreur est présenté sous forme de texte (et pas uniquement par la couleur ou une icône), identifie clairement le champ en erreur et fournit des indications précises sur la manière de la corriger. Par exemple : « Le mot de passe doit comporter au moins 8 caractères et inclure une lettre majuscule » plutôt que simplement « Mot de passe invalide ». La suggestion doit apparaître à proximité du champ, être associée à celui-ci de manière programmatique (via aria-describedby ou similaire) et être perceptible par les technologies d’assistance.

Ce qui est considéré comme non conforme : Tout message d’erreur qui se contente d’indiquer qu’une erreur s’est produite sans expliquer ce qui ne va pas ni comment y remédier. Des messages génériques tels que « Erreur », « Saisie invalide » ou « Champ requis » sans contexte supplémentaire ne respectent pas ce critère. Les erreurs communiquées uniquement par une bordure rouge ou une icône d’avertissement, sans texte descriptif, échouent également.

Exceptions définies : Le critère inclut deux exceptions explicites où une suggestion n’est pas requise. Premièrement, si fournir la suggestion mettrait en péril la sécurité — par exemple, sur un formulaire de connexion où expliquer précisément pourquoi un mot de passe a échoué (mauvais mot de passe vs mauvais nom d’utilisateur) pourrait faciliter des attaques par force brute. Deuxièmement, si fournir la suggestion compromettrait l’objectif du contenu — par exemple, un quiz éducatif où révéler la bonne réponse annulerait l’objectif d’évaluation. Ces exceptions sont limitées et ne doivent pas être utilisées pour éviter l’exigence dans des formulaires standard.

Pourquoi c’est important

La Suggestion après une erreur existe parce que remplir des formulaires est l’une des activités les plus exigeantes sur le plan cognitif que les utilisateurs effectuent sur le web, et aussi l’une des plus lourdes de conséquences — des erreurs sur des formulaires de paiement, de demandes de prestations publiques, de formulaires médicaux d’admission ou de portails bancaires peuvent avoir des conséquences concrètes pour les utilisateurs qui ne comprennent pas ce qui s’est mal passé ni comment s’en remettre.

Handicaps cognitifs : Les personnes dyslexiques, avec TDAH, troubles d’apprentissage ou une littératie limitée peuvent avoir du mal à décoder des messages d’erreur vagues et à les relier au champ spécifique ou au format requis. Sans suggestion corrective claire, elles peuvent abandonner complètement le formulaire ou soumettre des informations incorrectes. Selon l’Organisation mondiale de la Santé, environ 1 personne sur 6 dans le monde — plus de 1,3 milliard — vit avec une forme de handicap, et les handicaps cognitifs comptent parmi les catégories les plus répandues mais les moins prises en compte.

Personnes aveugles ou malvoyantes : Les utilisateurs de lecteurs d’écran dépendent entièrement des descriptions textuelles pour comprendre les erreurs de validation. Lorsqu’un message d’erreur se contente d’indiquer « Invalide » sans fournir de suggestion, l’utilisateur n’a aucun moyen de déterminer ce que « invalide » signifie pour ce champ. Il ne peut pas jeter un coup d’œil aux libellés adjacents, au texte indicatif (placeholder) ou aux indices visuels de formatage pour déduire le format attendu. Une suggestion claire, associée de manière programmatique au champ via aria-describedby, est le seul canal d’information fiable.

Personnes avec handicap moteur : Les utilisateurs qui s’appuient sur un accès par contacteur, le contrôle vocal ou des dispositifs d’entrée alternatifs fournissent un effort physique important lorsqu’ils remplissent des formulaires. Devoir revenir sur un formulaire après un envoi échoué — sans comprendre ce qui doit être modifié — impose un coût disproportionné. Des suggestions claires réduisent la charge de ressaisie et le nombre de cycles d’envoi échoués.

Personnes non natives dans la langue et personnes âgées : Les utilisateurs qui ne maîtrisent pas la langue du formulaire, ou qui ont moins d’expérience des conventions du web, bénéficient également fortement de suggestions correctives explicites. Un message comme « Saisissez votre numéro de téléphone sans espaces ni tirets, par ex. 05321234567 » supprime l’ambiguïté pour des utilisateurs qui, autrement, ne parviendraient peut-être jamais à terminer le formulaire.

Scénario réel : Imaginez un citoyen turc demandant une aide sociale via un portail de e-gouvernement. La demande exige un numéro d’identité TR (TC Kimlik Numarası), un format spécifique à 11 chiffres. Si l’utilisateur saisit 10 chiffres et ne reçoit que le message « TC Kimlik Numarası hatalı » (le numéro d’identité TC est incorrect), une personne avec handicap cognitif, une personne âgée ou un utilisateur de lecteur d’écran peut ne pas savoir si le numéro est trop court, contient un caractère invalide ou présente un problème de formatage. Ajouter « TC Kimlik Numarası 11 haneli olmalıdır, örneğin: 12345678901 » (le numéro d’identité TC doit comporter 11 chiffres, par ex. 12345678901) lève immédiatement l’ambiguïté et permet à l’utilisateur de se corriger lui-même.

Avantages en matière d’ergonomie et de conversion : Au-delà de l’accessibilité, l’abandon de formulaire est un indicateur métier critique. Les recherches montrent de manière constante que des messages d’erreur peu clairs comptent parmi les principales raisons pour lesquelles les utilisateurs abandonnent les parcours de paiement en ligne et d’inscription. Des suggestions d’erreur spécifiques et actionnables réduisent les taux d’abandon de formulaire et améliorent les taux de complétion pour tous les utilisateurs — ce qui fait de ce critère un argument commercial fort en plus d’une exigence d’accessibilité.

Règles Axe-core associées

WCAG 3.3.3 nécessite des tests manuels, car les outils automatisés ne peuvent pas évaluer la qualité ou l’exhaustivité du texte des messages d’erreur. Un analyseur automatisé peut détecter qu’un message d’erreur existe et qu’il est associé de manière programmatique à un champ de formulaire, mais il ne peut pas déterminer si le message fournit réellement une suggestion corrective utile. Il faut un jugement humain pour évaluer si le texte est spécifique, actionnable et suffisant pour guider l’utilisateur vers une saisie valide.

• Revue manuelle — qualité du contenu du message d’erreur : Les testeurs doivent déclencher manuellement chaque condition de validation (soumettre un champ requis vide, saisir des données dans un format incorrect, dépasser les limites de caractères, etc.) et évaluer chaque message d’erreur résultant. Le testeur se demande : ce message indique-t-il à l’utilisateur non seulement qu’une erreur s’est produite, mais aussi précisément ce qu’il doit faire pour la corriger ? Si le message est générique (« Invalide », « Erreur », « Veuillez vérifier ce champ »), il ne respecte pas 3.3.3, même s’il est exposé de manière programmatique.
• Revue manuelle — association programmatique : Les testeurs doivent vérifier que le texte de suggestion après une erreur est lié de manière programmatique au champ de saisie concerné à l’aide de aria-describedby, de régions aria-live ou d’une association en ligne, afin que les lecteurs d’écran l’annoncent sans nécessiter de navigation supplémentaire. Cela recoupe partiellement des règles axe telles que label et aria-input-field-name, mais le texte de suggestion lui-même n’est pas vérifié par ces règles.
• Revue manuelle — validité de l’exception de sécurité : Les testeurs doivent vérifier que tout formulaire omettant des suggestions correctives pour des raisons de sécurité (par ex. formulaires de connexion) relève réellement de l’exception de sécurité, et que cette exception n’est pas utilisée pour éviter l’exigence sur des champs non sensibles.
• Partiellement automatisé — règle label : Bien que la règle label d’axe-core vérifie que les champs de formulaire ont des noms accessibles, elle ne vérifie pas si les messages d’erreur fournissent des suggestions correctives. Elle peut mettre en évidence des libellés manquants qui aggraveraient le problème de suggestion après une erreur, et corriger les problèmes de libellé est un prérequis pour une mise en œuvre efficace des suggestions après une erreur.

Comment tester

1. Base de référence par analyse automatisée : Exécutez axe DevTools ou Lighthouse sur la page contenant le formulaire. Notez toute violation existante liée aux libellés de formulaire, aux rôles ARIA ou à l’identification des erreurs (3.3.1). Celles-ci doivent être résolues en premier, car ce sont des prérequis pour une suggestion après une erreur efficace. Les analyses automatisées ne signaleront pas les suggestions manquantes — elles établissent uniquement la base structurelle.
2. Déclencher chaque condition de validation : Pour chaque champ de formulaire, déclenchez délibérément chaque état d’erreur possible : soumettez un champ requis vide, saisissez des données dans un format incorrect (mauvais format de date, e-mail invalide, mot de passe trop court, valeur non numérique dans un champ numérique) et dépassez les limites de caractères. Documentez chaque message d’erreur qui apparaît.
3. Évaluer la qualité des suggestions : Pour chaque message d’erreur, demandez-vous : (a) Identifie-t-il le champ spécifique ? (b) Explique-t-il ce qui ne va pas ? (c) Fournit-il des indications actionnables sur la manière de corriger la saisie ? Un message qui répond aux trois points respecte 3.3.3. Un message qui ne répond qu’au point (a) respecte 3.3.1 mais échoue à 3.3.3.
4. Tests avec lecteur d’écran NVDA + Firefox : Naviguez jusqu’au formulaire à l’aide de Tab. Saisissez une valeur invalide. Soumettez ou déplacez le focus. Écoutez ce que NVDA annonce. Vérifiez que le texte de suggestion après une erreur est lu automatiquement (via une région aria-live ou une gestion du focus vers l’erreur) sans que l’utilisateur ait à le chercher manuellement.
5. Tests avec lecteur d’écran VoiceOver + Safari (macOS/iOS) : Effectuez les mêmes étapes. Utilisez VO+Flèche droite pour lire le champ et sa description associée. Confirmez que le texte de suggestion est annoncé comme partie de la description accessible du champ, et pas seulement comme un texte voisin qui pourrait être ignoré.
6. Tests avec lecteur d’écran JAWS + Chrome : Après avoir soumis un formulaire comportant des erreurs, confirmez que JAWS lit la suggestion après une erreur soit via la gestion du focus (focus déplacé vers le récapitulatif des erreurs), soit via des mises à jour de région aria-live. Utilisez le curseur virtuel de JAWS pour naviguer jusqu’au champ et confirmez que la suggestion fait partie de la description du champ.
7. Navigation au clavier uniquement : Sans lecteur d’écran, naviguez dans le formulaire uniquement avec Tab, Maj+Tab et Entrée. Vérifiez que les suggestions après une erreur sont visibles dans la zone d’affichage, non cachées hors écran ni masquées par d’autres éléments, lorsque le champ reçoit le focus après un envoi échoué.
8. Vérifier les exceptions de sécurité : Pour les formulaires de connexion et d’authentification, confirmez que l’omission de suggestions spécifiques est intentionnelle et documentée, et que l’exception de sécurité est limitée au minimum de champs nécessaire.

Comment corriger

Message d’erreur générique — Incorrect

<!-- Error message provides no suggestion on how to fix the problem -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' aria-invalid='true' />
<span class='error'>Invalid email address.</span>

Message d’erreur générique — Correct

<!-- aria-describedby links the suggestion text to the input;
     the suggestion explains exactly what format is expected -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
/>
<span id='email-error' class='error' role='alert'>
  Please enter a valid email address in the format [email protected].
</span>

Validation de mot de passe sans indication de format — Incorrect

<!-- User is told the password is wrong but not why or how to fix it -->
<label for='password'>Create Password</label>
<input type='password' id='password' name='password' aria-invalid='true' />
<p class='error'>Password is not valid.</p>

Validation de mot de passe sans indication de format — Correct

<!-- The suggestion lists exactly what the password must contain,
     enabling the user to self-correct without guessing -->
<label for='password'>Create Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-invalid='true'
  aria-describedby='password-error'
/>
<span id='password-error' class='error' role='alert'>
  Password must be at least 8 characters and include at least one
  uppercase letter, one number, and one special character (e.g. !, @, #).
</span>

Champ de date avec erreur de format ambiguë — Incorrect

<!-- No indication of which date format is expected -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' name='dob' aria-invalid='true' />
<span class='error'>Date is incorrect.</span>

Champ de date avec erreur de format ambiguë — Correct

<!-- The suggestion states the required format and provides
     a concrete example, removing all ambiguity -->
<label for='dob'>Date of Birth</label>
<input
  type='text'
  id='dob'
  name='dob'
  aria-invalid='true'
  aria-describedby='dob-error'
  placeholder='DD/MM/YYYY'
/>
<span id='dob-error' class='error' role='alert'>
  Please enter your date of birth in DD/MM/YYYY format, for example
  15/03/1985.
</span>

Formulaire multi-champs avec récapitulatif d’erreurs côté serveur — Incorrect

<!-- Error summary exists but links do not associate suggestions
     with individual fields, and messages are vague -->
<div class='error-summary'>
  <p>Please correct the following errors:</p>
  <ul>
    <li>Name error</li>
    <li>Phone error</li>
  </ul>
</div>

Formulaire multi-champs avec récapitulatif d’erreurs côté serveur — Correct

<!-- Error summary includes linked, specific suggestions;
     each list item links to the relevant field;
     inline errors also appear adjacent to each field -->
<div class='error-summary' role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>There are 2 errors on this form</h2>
  <ul>
    <li>
      <a href='#full-name'>
        Full Name: Please enter your first and last name.
      </a>
    </li>
    <li>
      <a href='#phone'>
        Phone Number: Enter 10 digits without spaces, e.g. 05321234567.
      </a>
    </li>
  </ul>
</div>

<label for='full-name'>Full Name</label>
<input
  type='text'
  id='full-name'
  name='full-name'
  aria-invalid='true'
  aria-describedby='full-name-error'
/>
<span id='full-name-error' class='error'>
  Please enter your first and last name.
</span>

<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-invalid='true'
  aria-describedby='phone-error'
/>
<span id='phone-error' class='error'>
  Enter 10 digits without spaces or dashes, for example 05321234567.
</span>

Erreurs courantes

• Utiliser placeholder comme substitut aux suggestions après une erreur : Le texte indicatif (placeholder) disparaît dès que l’utilisateur commence à saisir et n’est pas annoncé de manière fiable par les lecteurs d’écran comme une erreur. Ne comptez jamais uniquement sur le texte indicatif pour communiquer le format requis après qu’une erreur s’est produite.
• Afficher les messages d’erreur uniquement dans une notification toast qui disparaît après quelques secondes : Les notifications transitoires ne sont pas perceptibles par tous les utilisateurs — les utilisateurs de lecteurs d’écran peuvent manquer l’annonce, et le message disparaît avant qu’un lecteur lent puisse le traiter. Les suggestions après une erreur doivent persister jusqu’à ce que l’erreur soit corrigée.
• Utiliser aria-invalid='true' sans aria-describedby pointant vers le texte de suggestion : Définir aria-invalid signale qu’un champ comporte une erreur, mais sans aria-describedby lié à l’élément de suggestion, les lecteurs d’écran ne liront pas le texte de suggestion lorsque le champ reçoit le focus.
• Fournir la suggestion uniquement dans le design visuel (par ex. une info-bulle au survol) et non dans le DOM : Les info-bulles accessibles uniquement au survol sont inaccessibles aux utilisateurs au clavier et aux utilisateurs de lecteurs d’écran. Le texte de suggestion doit être présent dans le DOM et associé de manière programmatique au champ.
• Utiliser uniquement la couleur ou l’iconographie pour indiquer quel champ comporte une erreur : Une bordure rouge ou une icône d’avertissement ne constitue pas une suggestion après une erreur. La suggestion doit être une description textuelle qui explique l’action corrective, et non un indicateur visuel.
• Rédiger des suggestions qui identifient le problème mais pas la solution : « Votre mot de passe est trop court » identifie l’erreur mais ne suggère pas de correction. « Votre mot de passe doit comporter au moins 8 caractères » fournit l’indication corrective nécessaire. Les deux parties sont requises pour la conformité à 3.3.3.
• Appliquer l’exception de sécurité de manière trop large : L’exception de sécurité s’applique de manière limitée aux situations où fournir une suggestion compromettrait réellement la sécurité — généralement restreinte aux champs d’authentification. Elle ne s’applique pas aux champs de formulaire standard comme les noms, adresses ou numéros de téléphone, où les erreurs génériques ne sont pas justifiées.
• Placer la suggestion après une erreur après le bouton d’envoi ou loin du champ : Les suggestions après une erreur doivent être visuellement et programmatiquement proches du champ qu’elles décrivent. Placer toutes les erreurs en bas d’un long formulaire, sans inclure également des suggestions en ligne à chaque champ, oblige les utilisateurs à faire des allers-retours et à se souvenir de quelle suggestion s’applique à quel champ.
• Ne pas déplacer le focus vers le récapitulatif des erreurs après un envoi côté serveur échoué : Lorsqu’une page se recharge après un envoi échoué, le focus revient généralement en haut de la page. Sans gestion programmatique du focus vers le récapitulatif des erreurs ou vers le premier champ en erreur, les utilisateurs de lecteurs d’écran doivent parcourir toute la page pour découvrir ce qui s’est mal passé.
• Utiliser un langage vague comme « Veuillez vérifier votre saisie » ou « Un problème est survenu » : Ces messages ne fournissent aucune information sur ce qui ne va pas ni sur la manière de corriger. Chaque suggestion après une erreur doit être spécifique au champ et à la règle de validation qui a été violée.

Lien avec la réglementation d’accessibilité de la Turquie

Le paysage de l’accessibilité en Turquie a considérablement progressé avec la Circulaire présidentielle 2025/10, publiée au Journal officiel n° 32933 le 21 juin 2025. Cette circulaire établit des exigences obligatoires d’accessibilité web et mobile alignées sur WCAG 2.2, avec une conformité de niveau AA requise pour les entités souhaitant obtenir le Erişilebilirlik Logosu (Logo d’accessibilité) délivré par le ministère de la Famille et des Services sociaux (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 3.3.3 Suggestion après une erreur, en tant que critère de niveau AA, relève du champ de cette exigence obligatoire. Toute entité concernée qui exploite des formulaires — pour l’inscription, le paiement, les demandes de service ou la gestion de compte — doit veiller à ce que ses messages d’erreur ne se contentent pas d’identifier les erreurs mais fournissent des suggestions correctives actionnables, comme décrit dans ce critère.

Les entités couvertes par la Circulaire présidentielle 2025/10 couvrent un large éventail de secteurs. Les institutions publiques et organismes gouvernementaux sont tenus de se conformer, ce qui signifie que tous les portails de e-gouvernement (par ex. services e-Devlet, portails municipaux, systèmes de demande de prestations) doivent proposer des mises en œuvre conformes de la suggestion après une erreur. Étant donné que de nombreux services publics exigent des citoyens qu’ils soumettent des données personnelles complexes — numéros d’identité, codes d’adresse, numéros fiscaux — des suggestions d’erreur claires sont particulièrement cruciales dans ce contexte.

Les banques et institutions financières sont concernées, y compris les plateformes de banque en ligne, les formulaires d’ouverture de compte d’investissement et les portails de demande de prêt. Ces formulaires collectent régulièrement des données sensibles et précisément formatées, et l’absence de suggestions correctives crée de véritables obstacles pour les clients handicapés ainsi qu’un risque juridique potentiel.

Les hôpitaux et prestataires de soins de santé doivent également se conformer, ce qui couvre les systèmes d’enregistrement des patients, les formulaires de prise de rendez-vous et les portails de demande de remboursement d’assurance. Les formulaires médicaux impliquent souvent des exigences de champ complexes (codes de diagnostic, numéros de police d’assurance, formats de date précis), ce qui rend les suggestions d’erreur claires particulièrement importantes pour les patients âgés et avec handicap cognitif.

Les entreprises de télécommunications comptant 200,000 abonnés ou plus sont concernées, englobant les portails clients des principaux opérateurs, les formulaires d’enregistrement de carte SIM et les interfaces de gestion de compte. Les plateformes de commerce électronique — y compris les parcours de paiement et d’inscription — doivent se conformer, ce qui rend la Suggestion après une erreur directement pertinente pour les formulaires de gestion de produit et de panier qui sont au cœur de leurs opérations commerciales.

Les agences de voyage, entreprises de transport privé et écoles privées autorisées par le ministère de l’Éducation nationale (MoNE) sont également dans le champ d’application. Les formulaires de réservation, de demande d’inscription et les interfaces de paiement exploités par ces entités doivent respecter les normes de niveau AA, y compris 3.3.3.

D’un point de vue pratique de conformité, les organisations visant l’Erişilebilirlik Logosu devraient considérer WCAG 3.3.3 comme un point d’audit clé lors de toute évaluation d’accessibilité. Des tests manuels de tous les flux de validation de formulaire — y compris les états d’erreur côté client et côté serveur — sont requis, et la documentation de la justification de l’exception de sécurité doit être conservée pour tout champ où des suggestions correctives sont intentionnellement omises. Le non-respect des exigences de niveau AA, y compris la Suggestion après une erreur, empêchera l’attribution du logo et peut exposer les entités concernées à des conséquences administratives au titre de la circulaire.