Gestion des erreurs de formulaire : WCAG 3.3.1 à 3.3.4

Identifier l'erreur (3.3.1) : champ en cause + description textuelle

Le critère 3.3.1 (niveau A) impose que toute erreur de saisie automatiquement détectée soit identifiée et décrite en texte. L'erreur ne doit jamais être signalée uniquement par un changement de couleur (critère 1.4.1) ni par un effet visuel non verbal. Le message doit préciser : quel champ est en cause (nom explicite), pourquoi l'erreur survient (format email invalide) et, si possible, comment la corriger (suggestion concrète).

Étiquettes et instructions (3.3.2) : labels persistants

Le critère 3.3.2 (niveau A) demande que des étiquettes ou des instructions pertinentes soient fournies. Règle d'or : ne jamais utiliser l'attribut placeholder seul comme label. Le placeholder disparaît lors de la saisie, ce qui prive les utilisateurs de tout repère. Utilisez toujours un élément label associé via l'attribut for à l'identifiant du champ, ou via l'imbrication directe (label > input). Pour les instructions de format, utilisez aria-describedby.

Suggérer une correction (3.3.3) : aider l'utilisateur

Le critère 3.3.3 (niveau AA) exige de proposer une suggestion de correction si l'erreur est détectable programmatiquement. Ne dites pas seulement Date invalide : dites Date invalide. Veuillez utiliser le format JJ/MM/AAAA (exemple : 25/12/2024). Cela réduit drastiquement la charge cognitive et limite les itérations frustrantes, surtout pour les personnes ayant un handicap cognitif ou visuel.

Prévention des erreurs pour données sensibles (3.3.4)

Le critère 3.3.4 (niveau AA) concerne les transactions financières ou les engagements légaux : paiement, souscription à un contrat, validation de conditions générales. Offrez un récapitulatif avant validation finale, permettez la modification ou la réversibilité des données saisies, et affichez la politique de mot de passe AVANT la saisie (longueur, caractères attendus) plutôt qu'après une erreur. Cette approche prévient les erreurs humaines sur des données engageantes.

Mise en œuvre technique : aria-invalid, aria-describedby, regions live

Trois implémentations cumulatives. Sur le champ en erreur : aria-invalid=true (informe le lecteur d'écran de l'état invalide sans dépendre du code couleur). Sur l'input : aria-describedby pointant vers l'identifiant du message d'erreur, pour que la synthèse annonce l'erreur à la lecture. Pour les erreurs situées en bas d'un long formulaire : placez le message dans une région role=alert ou aria-live=polite, pour annoncer vocalement sans déplacer le focus. Préférez polite à assertive : cette dernière interrompt brutalement la lecture en cours.

Pièges fréquents à éviter

Quatre pièges revenants dans nos audits. Premier : signal par la couleur uniquement (contour rouge sans icône ni texte), échec critère 1.4.1. Deuxième : message d'erreur éloigné du champ, invisible pour le lecteur d'écran qui le parcourt séquentiellement. Troisième : utilisation abusive d'aria-live=assertive, qui coupe la parole de l'utilisateur. Quatrième : réinitialisation du formulaire après erreur, qui efface toute la saisie d'un seul coup — un échec grave d'UX comme d'accessibilité.

Questions fréquentes

Différence entre 3.3.1 et 3.3.3 ?

Le critère 3.3.1 (niveau A) identifie le fait qu'il y a une erreur et laquelle. Le critère 3.3.3 (niveau AA) va plus loin en aidant l'utilisateur à savoir comment la corriger. Les deux sont cumulables : annoncer l'erreur est le minimum, suggérer la correction est l'attendu pour AA.

Comment annoncer vocalement l'erreur d'un champ en bas du formulaire ?

Utilisez aria-describedby sur l'input pour pointer vers le message d'erreur. Quand le champ reçoit le focus, le lecteur d'écran lit le label puis l'état (invalide) puis le message. Pour une annonce sans déplacer le focus, utilisez une région role=alert ou aria-live=polite en haut du formulaire.

Le placeholder peut-il servir de label ?

Non. Placeholder n'est pas un label technique et disparaît lors de la saisie. C'est une violation du critère 3.3.2. Le placeholder peut compléter un label (par exemple pour illustrer un format), mais ne doit jamais s'y substituer.

Comment rendre un champ obligatoire ?

Utilisez l'attribut HTML required. Pour l'accessibilité, ajoutez une mention textuelle dans le label (Champ obligatoire ou Obligatoire :) ou via aria-required. Une astérisque visuelle doit être accompagnée d'une légende (par exemple * = obligatoire) au début du formulaire.

Quel aria-live utiliser ?

Préférez aria-live=polite pour la majorité des annonces : le lecteur d'écran attend une pause de l'utilisateur. Réservez aria-live=assertive aux messages critiques bloquants (panne serveur, déconnexion). Une utilisation trop fréquente de assertive devient intrusive.

L'EAA privé impose-t-elle des critères sur le paiement ?

Depuis le 28 juin 2025, l'EAA rend obligatoire le niveau WCAG 2.1 AA pour les services numériques privés. Le critère 3.3.4 impose spécifiquement un récapitulatif avant validation pour les données financières ou contractuelles. La DGCCRF peut sanctionner de 7 500 € à 15 000 € en cas de manquement.