Messages d'erreur et validation de formulaire accessibles
En bref — une erreur que tout le monde comprend et peut corriger
Un champ refusé à la validation est un moment critique : si la personne ne comprend pas ce qui ne va pas — parce que l'erreur n'est signalée que par une bordure rouge, parce que le message n'est jamais annoncé par le lecteur d'écran, ou parce qu'on ne sait pas quel champ corriger — elle abandonne, et la vente est perdue. L'European Accessibility Act (norme EN 301 549 / WCAG 2.1 AA), applicable au commerce électronique depuis le 28 juin 2025, impose des règles précises sur les erreurs. Les points clés :
- L'erreur est décrite en texte, pas seulement par une couleur (critère 3.3.1) ;
- Le message est associé au bon champ et le lecteur d'écran le lit (3.3.1 · 1.3.1) ;
- Une suggestion de correction est proposée quand c'est possible (3.3.3) ;
- Les erreurs sont annoncées dynamiquement sans recharger la page (4.1.3) ;
- Les champs obligatoires et le format attendu sont indiqués avant la saisie (3.3.2) ;
- Les actions coûteuses (paiement, commande) sont vérifiables et annulables (3.3.4).
La règle d'or : une erreur doit dire quel champ, quel problème et comment le corriger — en toutes lettres.
Le formulaire de paiement est l'endroit où l'on perd le plus de clients. Une carte refusée pour une raison invisible, un code postal jugé « invalide » sans qu'on sache pourquoi, un message d'erreur qui clignote en rouge mais que le lecteur d'écran n'annonce jamais : autant de raisons d'abandonner un panier. Bien gérer les erreurs n'est pas qu'une obligation légale — c'est l'un des leviers de conversion les plus rentables. Voici les six règles WCAG que l'EAA impose pour la validation et les messages d'erreur, et comment les vérifier.
Pourquoi les erreurs de formulaire sont décisives
Quand un formulaire renvoie une erreur, l'utilisateur doit comprendre trois choses immédiatement : quel champ pose problème, quel est le problème, et comment le corriger. Pour une personne voyante, une bordure rouge et un petit texte suffisent souvent. Mais une personne daltonienne ne perçoit pas le rouge ; une personne utilisant un lecteur d'écran ne « voit » rien apparaître à l'écran — si l'erreur n'est pas annoncée, elle reste persuadée que sa saisie était correcte et tourne en rond ; une personne ayant un trouble cognitif a besoin d'un message clair et d'une suggestion concrète.
L'EAA s'appuie sur l'EN 301 549, fondée sur les WCAG 2.1 niveau AA. Les erreurs relèvent d'une famille de critères « Assistance à la saisie » : 3.3.1 (Identification des erreurs), 3.3.2 (Étiquettes ou instructions), 3.3.3 (Suggestion après une erreur), 3.3.4 (Prévention des erreurs), complétés par 4.1.3 (Messages d'état) et 1.3.1 (Information et relations). Tous sont de niveau A ou AA, donc bel et bien exigés par l'EAA.
Les 6 règles pour une validation accessible
Dire quel champ et quel problème, pas seulement « en rouge »
Quand une saisie est refusée, le champ concerné doit être identifié en toutes lettres et le problème décrit en texte. La couleur seule (bordure ou fond rouge) ne suffit jamais : elle est invisible pour une personne daltonienne et muette pour un lecteur d'écran. Le message doit être précis — « Le code postal doit comporter 5 chiffres » plutôt qu'un vague « Champ invalide ».
Lien programmatique et focus sur le premier champ en erreur
Le message ne doit pas seulement être à côté du champ visuellement : il doit lui être relié dans le code, pour que le lecteur d'écran lise l'erreur en arrivant sur le champ. En pratique : aria-describedby pointe le texte du message, et aria-invalid="true" marque le champ comme erroné. Idéalement, le focus se place sur le premier champ en erreur après la soumission.
<input aria-invalid="true" aria-describedby="err-cp"> puis <p id="err-cp">Code postal : 5 chiffres attendus</p> ; le lecteur d'écran annonce l'erreur sur le champ.→ Voir aussi le tunnel de commande et les formulaires accessibles.
Indiquer le format ou la valeur attendue
Quand le système connaît la cause de l'erreur et qu'une correction est possible sans risque pour la sécurité, il doit la suggérer. Pour un format : rappeler la forme attendue (« date au format JJ/MM/AAAA »). Pour une valeur connue : proposer la bonne (« vouliez-vous dire gmail.com ? »). Cela transforme un mur en une étape franchissable.
Un message d'état lu sans recharger la page
Sur les formulaires modernes, la validation se fait souvent sans rechargement (en JavaScript). Le problème : un message qui apparaît visuellement n'est pas « entendu » par un lecteur d'écran si rien ne le lui signale. Il faut placer les erreurs dans une zone live (role="alert" ou aria-live="assertive" pour une erreur, aria-live="polite" pour un statut), ou afficher en haut un résumé des erreurs focusable, avec des liens vers chaque champ concerné.
role="alert".Mieux vaut prévenir l'erreur que la corriger
La meilleure erreur est celle qu'on évite. Indiquez avant la saisie quels champs sont obligatoires (mention « obligatoire » en texte, pas seulement un astérisque rouge ; required dans le code) et le format attendu lorsqu'il n'est pas évident (date, téléphone, numéro de carte). Ces instructions doivent rester visibles, pas disparaître comme un simple placeholder.
required.Prévenir les erreurs sur le paiement et la commande
Pour les opérations financières, juridiques ou qui modifient des données (paiement, validation de commande, suppression de compte), le critère 3.3.4 demande au moins l'une de ces protections : l'action est réversible, les données sont vérifiées et l'utilisateur peut les corriger, ou une confirmation explicite est demandée avant l'engagement. Cela évite les commandes passées par erreur et les litiges.
Récapitulatif des critères pour les erreurs et la validation
| Point à vérifier | Niveau | Critère WCAG |
|---|---|---|
| Erreur identifiée en texte, pas par la couleur seule | A | 3.3.1 · 1.4.1 |
| Message relié au champ (aria-describedby / aria-invalid) | A | 3.3.1 · 1.3.1 |
| Suggestion de correction quand c'est possible | AA | 3.3.3 |
| Erreurs annoncées dynamiquement (zone live / résumé) | AA | 4.1.3 |
| Champs obligatoires et format indiqués avant la saisie | A | 3.3.2 |
| Actions coûteuses vérifiables / annulables | AA | 3.3.4 |
aria-describedby, et marquez le champ aria-invalid="true". La couleur peut rester, mais comme renfort, jamais comme seul signal.
aria-live à votre place — ce sont des choix de développement propres à votre boutique. Rappel : la FTC américaine a sanctionné un éditeur d'overlay d'un million de dollars pour des allégations de conformité trompeuses. Voir pourquoi les overlays ne suffisent pas.Comment vérifier les erreurs de vos formulaires
Quelques tests rapides, à faire sur votre tunnel de commande et vos formulaires (compte, contact, newsletter) :
- Soumettez le formulaire vide ou avec de fausses valeurs : chaque erreur est-elle décrite en texte (et pas seulement par une couleur) ?
- Refaites le test au lecteur d'écran (NVDA, VoiceOver) : les erreurs sont-elles annoncées à la soumission, et associées au bon champ ?
- Naviguez au clavier : arrive-t-on facilement au premier champ en erreur ? Le résumé d'erreurs (s'il existe) est-il focusable ?
- Coupez la couleur (mode niveaux de gris) pour vérifier que rien ne repose uniquement sur le rouge.
- Vérifiez le paiement : y a-t-il un récapitulatif vérifiable avant l'engagement ?
Un scan automatique repère une partie des problèmes (champ sans étiquette, aria-invalid mal posé, contrôle non relié), mais l'annonce dynamique des erreurs et la qualité des messages se vérifient surtout au lecteur d'écran et au clavier. Notre rapport signale les manquements détectables automatiquement et l'ensemble des autres points WCAG.
→ Méthode complète : comment tester l'accessibilité de son site. Voir aussi la navigation au clavier et le contraste des couleurs.
Vérifiez l'accessibilité de votre boutique gratuitement
DeclareAccess analyse une page de votre site avec le moteur axe-core selon les WCAG 2.1 AA, repère les manquements (formulaires, contraste, structure, étiquettes…) et génère la déclaration d'accessibilité prête à publier — modèle français (RGAA), allemand (BFSG), italien ou espagnol. Gratuit, sans carte bancaire.
Rapport WCAG par e-mail sous 24 h ouvrées.
C'est noté. Votre client e-mail va s'ouvrir avec la demande pré-remplie — il vous suffit de l'envoyer.
Questions fréquentes
Puis-je signaler une erreur uniquement avec une bordure rouge ?
Non. Le critère 3.3.1 demande que l'erreur soit identifiée en texte, et le critère 1.4.1 interdit de transmettre une information par la couleur seule. Une bordure rouge est invisible pour une personne daltonienne et muette pour un lecteur d'écran. La couleur peut accompagner le message, mais il faut toujours un texte décrivant le champ concerné et le problème — idéalement avec une suggestion de correction.
Comment annoncer une erreur au lecteur d'écran sans recharger la page ?
Placez le message dans une zone live : role="alert" (ou aria-live="assertive") pour une erreur importante, aria-live="polite" pour un statut. Le lecteur d'écran lit alors le contenu dès qu'il apparaît. Pour un formulaire long, affichez aussi en haut un résumé des erreurs qui reçoit le focus après la soumission, avec un lien vers chaque champ à corriger. C'est l'objet du critère 4.1.3 (Messages d'état).
Le placeholder suffit-il pour indiquer le format attendu ?
Non. Le texte d'invite (placeholder) disparaît dès qu'on commence à taper, et son contraste est souvent trop faible. Il ne remplace ni l'étiquette du champ, ni les instructions de format. Affichez le format attendu dans une instruction visible et persistante sous l'étiquette (par exemple « format JJ/MM/AAAA »), conformément au critère 3.3.2.
Dois-je vraiment ajouter un récapitulatif avant le paiement ?
Pour les actions financières, juridiques ou qui modifient des données, le critère 3.3.4 exige au moins une protection : action réversible, données vérifiables et corrigeables, ou confirmation explicite. Un écran « Vérifiez votre commande » avant le paiement remplit cette exigence — et réduit au passage les erreurs d'adresse et les litiges. C'est à la fois une obligation et une bonne pratique de conversion.
La validation en temps réel (au fil de la frappe) est-elle obligatoire ?
Non, elle n'est pas obligatoire. Ce qui compte, c'est que l'erreur, quand elle apparaît, soit décrite en texte, reliée au champ et annoncée (critères 3.3.1, 3.3.3, 4.1.3). Si vous faites de la validation « en direct », évitez d'afficher une erreur avant que la personne ait fini de remplir le champ : un message qui change à chaque touche peut perturber, surtout au lecteur d'écran. Une validation à la sortie du champ ou à la soumission est souvent plus confortable.