WCAG 3.3.1 : Identification des erreurs

Ce que signifie cette règle

WCAG 3.3.1 Identification des erreurs est un critère de succès de niveau A relevant du principe Compréhensible. Il stipule : « Si une erreur de saisie est détectée automatiquement, l’élément en erreur est identifié et l’erreur est décrite à l’utilisateur sous forme de texte. » Concrètement, chaque fois que votre site web ou votre application valide automatiquement la saisie utilisateur — que ce soit à l’envoi du formulaire, à la perte de focus d’un champ ou en temps réel — deux choses doivent se produire si une erreur est détectée : le champ ou le contrôle spécifique qui contient l’erreur doit être clairement identifié, et la nature de l’erreur doit être communiquée à l’aide d’un contenu textuel réel (et non uniquement par la couleur, une icône ou un son).

Ce critère s’applique à toute situation où des données sont collectées auprès des utilisateurs et où une validation se produit automatiquement. Cela inclut les éléments de formulaire HTML tels que <input>, <select>, <textarea>, ainsi que les composants interactifs personnalisés construits avec ARIA. Il couvre la validation côté client déclenchée par JavaScript, la validation native du navigateur utilisant des attributs comme required, pattern, minlength et type, ainsi que les résultats de validation côté serveur rendus après un rechargement de page ou injectés dynamiquement dans le DOM.

Un succès exige que : (1) chaque champ en erreur soit associé de manière programmatique à un message d’erreur — généralement via aria-describedby ou aria-errormessage — afin que les technologies d’assistance puissent l’annoncer ; (2) le message d’erreur soit en texte clair visible dans l’interface (et non masqué aux utilisateurs voyants) ; et (3) le texte décrive clairement ce qui s’est mal passé, et pas seulement qu’un problème s’est produit. Par exemple, « L’adresse e-mail est obligatoire » est une description d’erreur valide, tandis que l’affichage d’une simple bordure rouge ou d’une icône d’exclamation sans alternative textuelle constitue un échec.

Un échec se produit lorsque : les erreurs sont indiquées uniquement par des changements de couleur (bordure rouge sans texte), les erreurs sont annoncées uniquement via role="alert" sans identification du champ concerné, le texte du message d’erreur est vide ou générique (par exemple « Saisie invalide »), ou lorsque des messages d’erreur existent dans le DOM mais ne sont pas reliés de manière programmatique au champ correspondant, de sorte que les lecteurs d’écran ne peuvent pas les associer.

WCAG 3.3.1 ne s’applique pas lorsqu’aucune détection automatique n’a lieu — par exemple, si un formulaire est soumis et que le serveur se contente de recharger la page sans aucune indication de ce qui s’est mal passé, il s’agit d’un problème d’ergonomie distinct mais qui sort du strict périmètre de ce critère. En revanche, si votre système effectue une détection automatique (ce qui est pratiquement le cas de tous les formulaires modernes), le critère s’applique pleinement. Aucun cas d’exception n’est défini dans le critère lui-même pour des types de saisie ou des cas d’usage spécifiques.

Pourquoi c’est important

L’identification des erreurs affecte directement de manière significative plusieurs groupes de personnes handicapées. Pour les utilisateurs aveugles ou malvoyants qui s’appuient sur des lecteurs d’écran tels que NVDA, JAWS ou VoiceOver, une bordure rouge ou une icône d’avertissement ne communique rien. Si un message d’erreur n’est pas présent sous forme de texte réel et n’est pas associé de manière programmatique au champ en erreur, le lecteur d’écran ne l’annoncera pas, et l’utilisateur pourra soumettre un formulaire à plusieurs reprises sans comprendre pourquoi il échoue. Selon l’Organisation mondiale de la Santé, environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, et des millions d’entre elles s’appuient quotidiennement sur des technologies d’assistance pour interagir avec le contenu web.

Pour les utilisateurs ayant des troubles cognitifs — y compris la dyslexie, le trouble du déficit de l’attention et les troubles de la mémoire — des messages d’erreur vagues comme « Un problème est survenu » créent des obstacles importants. Ces utilisateurs bénéficient énormément de messages d’erreur précis et descriptifs qui indiquent exactement quel champ doit être corrigé et quel format ou quelle valeur est attendu(e). Par exemple, au lieu de « Date invalide », un message tel que « La date de naissance doit être au format JJ/MM/AAAA » est beaucoup plus exploitable.

Les utilisateurs ayant des déficiences motrices qui naviguent au clavier ou à l’aide de dispositifs de commande dépensent un effort considérable pour parcourir un formulaire. Lorsqu’une erreur est floue ou non identifiée, ils doivent retraverser l’ensemble du formulaire pour trouver le problème, ce qui augmente fortement le coût cognitif et physique de la complétion du formulaire. Une identification claire des erreurs permet à ces utilisateurs d’accéder directement au champ problématique.

Considérez ce scénario réel : un citoyen turc tente de s’inscrire sur un portail de e-services gouvernementaux pour demander une prestation de handicap. Le formulaire exige un numéro d’identification national dans un format spécifique. L’utilisateur, qui est aveugle, saisit son numéro d’identification. À la soumission, le formulaire se recharge avec des champs surlignés en rouge mais sans texte d’erreur associé. Le lecteur d’écran n’annonce que les libellés des champs à nouveau — l’utilisateur n’a aucune idée de ce qui s’est mal passé ni quel champ pose problème. Il abandonne complètement la procédure, perdant l’accès à un service public essentiel. C’est précisément la situation que WCAG 3.3.1 est conçu pour éviter.

Au-delà de l’accessibilité, une identification claire des erreurs améliore les taux de conversion et l’ergonomie pour tous les utilisateurs. Les études en recherche UX montrent de manière constante que des messages d’erreur descriptifs en ligne réduisent l’abandon de formulaires. D’un point de vue SEO, de meilleurs signaux d’engagement utilisateur — notamment un temps passé sur le site plus long et des formulaires complétés avec succès — influencent positivement le classement dans les moteurs de recherche au fil du temps.

Règles axe-core associées

WCAG 3.3.1 nécessite un test manuel pour une vérification complète. En effet, les outils automatisés peuvent détecter la présence ou l’absence de schémas structurels (tels que aria-describedby ou aria-errormessage), mais ils ne peuvent pas évaluer si le contenu textuel d’un message d’erreur est pertinent, exact ou suffisant pour aider l’utilisateur à comprendre et corriger l’erreur. Un outil automatisé voit qu’un élément role="alert" existe ; il ne peut pas juger si le message « Erreur à la ligne 4 » décrit de manière adéquate un échec de validation pour un utilisateur de lecteur d’écran.

• aria-required-attr : Cette règle axe-core vérifie que les éléments avec certains rôles ARIA possèdent tous les attributs ARIA requis. Bien qu’il ne s’agisse pas exclusivement d’une règle d’identification des erreurs, elle est pertinente car un champ de formulaire en état d’erreur qui utilise role="textbox" ou similaire sans les attributs requis peut ne pas transmettre correctement l’état aux technologies d’assistance, compromettant ainsi la communication de l’erreur.
• aria-valid-attr-value : Cette règle signale les cas où des attributs ARIA font référence à des ID qui n’existent pas dans le DOM. Par exemple, si un champ utilise aria-describedby="email-error" mais qu’aucun élément avec id="email-error" n’existe, l’association est rompue et le message d’erreur ne sera pas lu par les lecteurs d’écran. Il s’agit d’un schéma d’échec courant pour 3.3.1.
• Exigence d’évaluation manuelle : Les testeurs doivent déclencher manuellement des erreurs de validation puis utiliser un lecteur d’écran pour confirmer que : le champ en erreur est identifié par son nom ou son libellé, la description de l’erreur est annoncée, le message est pertinent et exploitable, et l’erreur n’est pas communiquée uniquement par des moyens non textuels. Les analyses automatisées ne peuvent pas simuler des séquences d’interaction utilisateur ni évaluer la qualité sémantique du texte des messages, ce qui rend le jugement humain indispensable pour ce critère.

Comment tester

1. Analyse automatisée avec axe DevTools ou Lighthouse : Exécutez une analyse axe DevTools sur la page contenant le formulaire avant et après avoir déclenché des erreurs de validation. Recherchez spécifiquement les violations liées à des références aria-describedby ou aria-errormessage rompues, à l’absence de régions role="alert" ou aria-live utilisées pour l’injection dynamique d’erreurs, et aux champs de formulaire dépourvus de libellés (ce qui empêche également une association correcte des erreurs). Dans Lighthouse, vérifiez l’audit Accessibilité pour les violations liées aux formulaires. Notez qu’un rapport automatisé sans erreur ne confirme pas la conformité à 3.3.1 — il ne fait qu’écarter certains échecs structurels.
2. Test manuel de navigation au clavier : En utilisant uniquement le clavier (Tab, Maj+Tab, Entrée, Espace), tentez de soumettre le formulaire avec des valeurs volontairement incorrectes ou manquantes. Vérifiez que : le focus se déplace vers ou à proximité du premier champ en erreur, chaque message d’erreur est visible dans la zone d’affichage, et que les messages d’erreur identifient le champ spécifique par son nom et décrivent le problème en texte clair.
3. Test avec lecteur d’écran NVDA + Firefox : Ouvrez le formulaire dans Firefox avec NVDA activé. Soumettez le formulaire avec des erreurs. Écoutez attentivement : NVDA annonce-t-il quel champ comporte une erreur ? La description de l’erreur est-elle lue à voix haute ? Placez le focus sur le champ erroné — NVDA lit-il le message d’erreur associé comme partie de la description accessible du champ ? Si vous utilisez des régions aria-live, vérifiez que l’annonce n’est ni retardée ni supprimée.
4. Test avec lecteur d’écran VoiceOver + Safari (macOS/iOS) : Répétez le même processus en utilisant VoiceOver sur Safari. Utilisez VO+Flèche droite pour lire le formulaire après la soumission. Confirmez que chaque champ en erreur inclut le texte d’erreur dans son nom ou sa description accessible. Sur iOS, testez à l’aide de la navigation tactile et des gestes de balayage.
5. Test avec lecteur d’écran JAWS + Chrome : Avec JAWS en cours d’exécution dans Chrome, soumettez le formulaire avec des erreurs. Utilisez le curseur virtuel JAWS pour naviguer jusqu’à chaque champ de formulaire en erreur. Confirmez que le texte du message d’erreur est inclus dans la lecture du champ par JAWS. Vérifiez également le comportement du mode formulaires de JAWS, car ce mode supprime certaines annonces de régions dynamiques.
6. Audit des indices de couleur et non textuels : Inspectez visuellement chaque état d’erreur. Supprimez ou désactivez temporairement le CSS (en utilisant les outils de développement du navigateur ou un bookmarklet) et confirmez que l’identification des erreurs est toujours présente sous forme de texte dans le DOM. Cela permet de vérifier que la communication des erreurs ne repose pas uniquement sur la couleur ou l’iconographie.
7. Vérification de l’injection dynamique : Pour les applications monopage ou les formulaires avec validation en temps réel, utilisez les outils de développement du navigateur pour inspecter le DOM après le déclenchement d’une erreur. Confirmez que l’élément de message d’erreur existe dans le DOM, contient un texte non vide et est référencé par le champ correspondant via aria-describedby ou aria-errormessage.

Comment corriger

Scénario 1 : Erreur indiquée uniquement par la couleur — Incorrect

<!-- Échec : bordure rouge ajoutée via une classe, aucun texte d’erreur associé -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' class='input-error'>
<!-- Le CSS définit border: 2px solid red sur .input-error -->
<!-- Aucun texte de message d’erreur n’est rendu dans le DOM -->

Scénario 1 : Erreur indiquée uniquement par la couleur — Correct

<!-- Succès : le texte d’erreur est présent, visible et lié au champ de saisie -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-describedby='email-error'
  aria-invalid='true'
>
<!-- aria-invalid signale l’état d’erreur aux technologies d’assistance -->
<!-- aria-describedby relie le champ à son message d’erreur par ID -->
<p id='email-error' role='alert'>
  Please enter a valid email address, for example: [email protected]
</p>

Scénario 2 : Résumé d’erreur générique sans identification des champs — Incorrect

<!-- Échec : un message récapitulatif existe mais n’identifie pas les champs en erreur -->
<div role='alert'>
  <p>There are errors in the form. Please correct them and try again.</p>
</div>
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' name='phone' class='is-invalid'>
<!-- Aucun message d’erreur par champ ; l’utilisateur ne peut pas déterminer quel champ a échoué -->

Scénario 2 : Résumé d’erreur générique sans identification des champs — Correct

<!-- Succès : le résumé liste les champs spécifiques en erreur, et chaque champ a un message d’erreur en ligne -->
<div role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>2 errors found. Please fix the following:</h2>
  <ul>
    <li><a href='#phone'>Phone Number: must contain only digits and be 10 characters long</a></li>
    <li><a href='#dob'>Date of Birth: required field — please enter your date of birth</a></li>
  </ul>
</div>
<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-describedby='phone-error'
  aria-invalid='true'
>
<!-- Message d’erreur en ligne lié via aria-describedby -->
<p id='phone-error'>Phone Number must contain only digits and be 10 characters long.</p>

Scénario 3 : Référence aria-describedby rompue — Incorrect

<!-- Échec : aria-describedby fait référence à un ID qui n’existe pas dans le DOM -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- L’élément avec id='username-msg' n’a jamais été rendu ou a été supprimé -->
<!-- Les lecteurs d’écran ne trouvent aucune cible et n’annoncent aucune description -->

Scénario 3 : Référence aria-describedby rompue — Correct

<!-- Succès : l’élément référencé existe dans le DOM avec un ID correspondant -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- L’élément avec l’ID correspondant est présent et contient un texte descriptif -->
<span id='username-msg'>
  Username must be between 4 and 20 characters and contain only letters and numbers.
</span>

Scénario 4 : Erreur de validation en temps réel injectée dynamiquement — Incorrect

<!-- Échec : erreur injectée dans le DOM mais non associée au champ ; aucune région dynamique -->
<label for='password'>Password</label>
<input type='password' id='password' name='password'>
<!-- Après la perte de focus, JavaScript ajoute cet élément, mais aucun aria-describedby sur le champ -->
<div class='error-text'>Password is too short.</div>

Scénario 4 : Erreur de validation en temps réel injectée dynamiquement — Correct

<!-- Succès : le conteneur d’erreur préexiste dans le DOM (vide), le champ y fait référence ; aria-live annonce les changements -->
<label for='password'>Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-describedby='password-error'
  aria-invalid='false'
>
<!-- Span vide présent au chargement de la page ; JavaScript renseigne le texte et définit aria-invalid='true' en cas d’erreur -->
<span id='password-error' aria-live='polite'></span>
<!-- JavaScript à la perte de focus : -->
<!-- document.getElementById('password-error').textContent = 'Password must be at least 8 characters.'; -->
<!-- document.getElementById('password').setAttribute('aria-invalid', 'true'); -->

Erreurs courantes

• Utiliser uniquement des changements de classe CSS (par exemple ajouter border-color: red) pour indiquer les erreurs sans texte correspondant dans le DOM. La couleur seule n’est pas perceptible par les utilisateurs aveugles ou daltoniens, et enfreint à la fois 3.3.1 et 1.4.1.
• Écrire aria-describedby sur le champ mais en pointant vers un ID rendu de manière conditionnelle ou supprimé du DOM lors de la réinitialisation de la validation. La référence rompue signifie que le lecteur d’écran ne trouve aucun contenu associé et que l’erreur est de fait invisible pour les utilisateurs de technologies d’assistance.
• Utiliser le texte de placeholder comme seul message d’erreur. Le texte d’espace réservé disparaît lorsque l’utilisateur commence à saisir, est souvent de faible contraste et n’est pas systématiquement annoncé par tous les lecteurs d’écran comme partie de la description du champ en cas d’erreur.
• Injecter des messages d’erreur dynamiquement dans le DOM sans s’assurer qu’ils sont associés à leur champ parent via aria-describedby. Un message d’erreur visuellement adjacent n’est pas automatiquement associé à un champ — le lien programmatique doit être explicite.
• Afficher un résumé d’erreurs au niveau de la page sans lier chaque élément du résumé au champ spécifique en erreur. Les utilisateurs de lecteurs d’écran ou de navigation au clavier doivent pouvoir passer directement de la description de l’erreur au champ qui nécessite une correction.
• Définir aria-invalid='true' sur un champ sans fournir de texte de message d’erreur. L’attribut aria-invalid signale qu’un champ est en état d’erreur mais ne décrit pas l’erreur — il doit être combiné avec un message descriptif.
• Fournir des messages d’erreur trop génériques, tels que « Saisie invalide » ou « Erreur dans le champ ». Ces descriptions n’expliquent pas ce qui ne va pas ni comment corriger le problème, ce qui ne satisfait pas l’exigence de description de 3.3.1 et rend la correction des erreurs inutilement difficile pour tous les utilisateurs.
• Supprimer les régions aria-live ou role='alert' des conteneurs d’erreur lors de la réinitialisation d’un formulaire, ce qui fait disparaître les conteneurs avant que les lecteurs d’écran aient fini d’annoncer leur contenu. Les annonces d’erreur peuvent être interrompues, laissant l’utilisateur dans l’ignorance du résultat de la validation.
• Se fier aux bulles de validation natives du navigateur (les info-bulles par défaut) sans personnalisation. Les interfaces de validation natives des navigateurs sont incohérentes d’un navigateur et d’une combinaison technologie d’assistance à l’autre, et ne répondent souvent pas aux exigences WCAG en matière d’identification et de description dans des scénarios de formulaires complexes.
• Placer les messages d’erreur visuellement loin de leurs champs associés — par exemple uniquement dans une boîte d’alerte en en-tête — sans fournir également des messages en ligne près de chaque champ. Les utilisateurs malvoyants qui agrandissent l’écran peuvent ne pas voir l’alerte en en-tête alors qu’ils sont focalisés sur la zone de saisie, et les utilisateurs au clavier doivent parcourir une grande distance pour lire l’erreur.

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

La Circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences obligatoires en matière d’accessibilité web pour un large éventail d’entités opérant en Turquie. La circulaire adopte WCAG 2.2 comme norme technique, rendant tous les critères de succès de niveau A — y compris WCAG 3.3.1 Identification des erreurs — légalement obligatoires pour les organisations concernées.

Le calendrier de conformité fixé par la circulaire est de un an pour les institutions publiques et de deux ans pour les entités du secteur privé à compter de la date de publication. Cela signifie que les institutions publiques doivent atteindre la conformité WCAG 2.2 niveau A d’ici juin 2026, et les entités couvertes du secteur privé d’ici juin 2027.

Les entités couvertes par la circulaire incluent un large éventail de services numériques turcs. Les institutions publiques — y compris tous les ministères de l’administration centrale, les municipalités, les universités publiques et les agences publiques — sont tenues de garantir l’accessibilité de leurs services numériques. Dans le secteur privé, la circulaire couvre les plateformes de commerce électronique, les banques et institutions financières, les hôpitaux et prestataires de soins de santé privés, les entreprises de télécommunications comptant 200,000 abonnés ou plus, les agences de voyage, les entreprises de transport privé et les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE).

Pour toutes ces entités, WCAG 3.3.1 est directement pertinent partout où des formulaires en ligne sont utilisés — ce qui, en pratique, signifie presque tous les points de contact numériques. Les formulaires de paiement du commerce électronique, les parcours d’ouverture de compte bancaire, les portails d’inscription des patients à l’hôpital, les formulaires de demande de prestations gouvernementales, les systèmes de réservation d’avion et de bus, et les pages d’inscription scolaire reposent tous sur la validation de formulaires. Si l’un de ces systèmes détecte automatiquement une erreur de saisie et ne parvient pas à identifier le champ ou à décrire l’erreur sous forme de texte, il est en violation directe des exigences de la circulaire.

Le non-respect de la circulaire peut exposer les entités concernées à un contrôle réglementaire, à un risque de réputation et à d’éventuelles sanctions à mesure que le cadre d’application de l’accessibilité numérique de la Turquie se renforce. Au-delà de la conformité juridique, le respect de 3.3.1 démontre un engagement envers une prestation de services inclusive — garantissant que tous les citoyens, y compris les quelque 8,5 millions de personnes handicapées en Turquie (selon les données de TÜİK), puissent accéder sans obstacles aux services essentiels en ligne. Les organisations opérant avec le framework SDK d’Accsible devraient donner la priorité à la fois à la conformité structurelle automatisée et à des tests manuels approfondis pour s’assurer que leur gestion des erreurs satisfait pleinement à ce critère fondamental.