Sur l’audit d’un formulaire de demande de devis, le symptôme sautait aux yeux d’un auditeur voyant : après soumission, deux champs obligatoires non remplis affichaient une bordure rouge vif. Pratique et lisible — pour qui distingue le rouge du gris par ailleurs neutre du champ. Aucun texte n’accompagnait cette bordure, aucune icône, aucun message annoncé aux technologies d’assistance. Pour un utilisateur daltonien ou pour quiconque utilise un lecteur d’écran, le formulaire semblait simplement avoir échoué à s’envoyer, sans qu’aucune cause ne soit identifiable.
Ce défaut correspond très précisément à un critère du RGAA (le référentiel général d’amélioration de l’accessibilité) et des WCAG : ne jamais utiliser la couleur comme unique moyen de transmettre une information. La couleur peut renforcer un message, elle ne peut jamais le remplacer.
Pourquoi c’est un problème, précisément
Trois populations distinctes sont pénalisées par ce choix, pour des raisons différentes :
- Les personnes daltoniennes, qui représentent une part non négligeable de la population masculine, peuvent ne pas distinguer le rouge d’erreur de la bordure grise neutre, selon le type de daltonisme.
- Les utilisateurs de lecteurs d’écran ne perçoivent aucune couleur : sans texte ni attribut ARIA, le champ en erreur reste indiscernable d’un champ valide lors de la lecture du formulaire.
- Les utilisateurs sur écran monochrome, en mode contraste élevé forcé du système, ou avec une luminosité d’écran très faible peuvent aussi perdre cette distinction purement chromatique.
Le code fautif
.champ-erreur {
border: 2px solid red;
}<input type="email" name="email" class="champ-erreur">Rien dans ce balisage n’indique à une technologie d’assistance que ce champ pose problème : pas d’attribut aria-invalid, pas de message associé, pas même un changement de libellé. Le champ est syntaxiquement identique à un champ valide.
Le correctif complet
<label for="email">Adresse e-mail</label>
<input type="email" id="email" name="email" class="champ-erreur"
aria-invalid="true" aria-describedby="email-erreur">
<p id="email-erreur" class="message-erreur">
<strong>Erreur :</strong> l'adresse e-mail saisie n'est pas valide, vérifiez le format (exemple : nom@domaine.fr).
</p>.message-erreur {
color: #b3261e;
}
.message-erreur::before {
content: "⚠ ";
}
.champ-erreur {
border: 2px solid #b3261e;
}Trois ajouts transforment ce champ : aria-invalid="true" signale l’état d’erreur à l’API d’accessibilité, aria-describedby relie explicitement le champ à son message d’erreur (annoncé automatiquement à la prise de focus par la plupart des lecteurs d’écran), et le texte du message décrit précisément quoi corriger plutôt que de se contenter d’un vague « champ invalide ».
Ce qui distingue un bon message d’erreur d’un mauvais
| Mauvais message | Bon message |
|---|---|
| « Erreur » | « L’adresse e-mail saisie n’est pas valide, vérifiez le format » |
| « Champ requis » | « Le numéro de téléphone est obligatoire pour vous recontacter » |
| « Format incorrect » | « Le code postal doit contenir 5 chiffres (exemple : 75001) » |
Le résumé des erreurs en haut de formulaire
Sur un formulaire à plusieurs champs, ajouter un résumé listant l’ensemble des erreurs en haut du formulaire, avec des liens directs vers chaque champ fautif, complète utilement les messages individuels. Ce résumé, placé dans une région role="alert" ou ciblée par le focus juste après la soumission ratée, permet à un utilisateur de lecteur d’écran de connaître d’emblée l’étendue du problème avant de parcourir chaque champ un par un.
Quoi faire à l’avenir
Avant de valider visuellement un état d’erreur de formulaire, la question à se poser systématiquement : si je retire toute couleur de cette maquette, est-ce que l’information reste compréhensible ? Si la réponse est non, il manque un texte, une icône ou un attribut, pas seulement une nuance de rouge plus vive.
