RGAA 11.10 — Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente ?

Erreurs de saisie non identifiées

Le problème

Les erreurs de saisie non identifiées surviennent lorsqu'un formulaire détecte une erreur de saisie mais ne l'indique pas clairement à l'utilisateur. Le critère RGAA 11.10 (correspondant au WCAG 3.3.1, niveau A) exige que si une erreur de saisie est automatiquement détectée, l'élément en erreur soit identifié et l'erreur soit décrite textuellement à l'utilisateur.

Les violations les plus courantes incluent : signaler une erreur uniquement par un changement de couleur (bordure rouge) sans message textuel, afficher un message d'erreur générique (« Le formulaire contient des erreurs ») sans identifier les champs concernés, et ne pas associer programmatiquement le message d'erreur au champ via aria-describedby ou aria-errormessage.

Sur de nombreux sites, la seule indication d'erreur est un changement visuel (couleur de bordure, icône) qui n'est pas perceptible par les utilisateurs de lecteurs d'écran ni par les personnes daltoniennes. Sans message textuel associé au champ, l'utilisateur ne sait ni quel champ est en erreur, ni quelle est la nature de l'erreur.

Impact sur les utilisateurs

Pour les utilisateurs de lecteurs d'écran, une erreur signalée uniquement par la couleur est invisible. Ils soumettent le formulaire, reçoivent un message d'erreur générique (ou aucun), et doivent parcourir chaque champ un par un pour deviner lequel pose problème. C'est une source majeure de frustration et d'abandon de formulaire.

Les personnes daltoniennes (8% des hommes) ne distinguent pas une bordure rouge d'une bordure normale. Sans message textuel, l'erreur leur est invisible. Les personnes ayant des troubles cognitifs ont besoin de messages d'erreur clairs et spécifiques pour comprendre ce qui est attendu.

Dans les formulaires critiques (inscription, paiement, déclaration administrative), des erreurs non identifiées empêchent les utilisateurs d'accomplir des démarches essentielles. C'est à la fois un problème d'accessibilité et un problème d'utilisabilité qui affecte le taux de conversion.

Votre site a-t-il ce problème ?

106 critères RGAA analysés en 5 minutes par notre IA.

Testez votre site gratuitement

Exemple de code

Avant (non conforme)

<!-- Erreur signalée uniquement par la couleur -->
<input type="email" class="border-red-500" value="abc">
<!-- Pas de message d'erreur textuel -->

<!-- Message d'erreur générique -->
<div class="error">
  Le formulaire contient des erreurs.
</div>

<!-- Message d'erreur non associé au champ -->
<label for="tel">Téléphone</label>
<input type="tel" id="tel">
<span class="error">Format invalide</span>

Après (conforme)

<!-- Erreur avec message textuel associé -->
<label for="email">Email</label>
<input type="email" id="email" value="abc"
  aria-invalid="true"
  aria-describedby="email-error">
<span id="email-error" class="error" role="alert">
  Veuillez saisir une adresse email valide (ex. nom@domaine.fr)
</span>

<!-- Message d'erreur spécifique et associé -->
<label for="tel">Téléphone</label>
<input type="tel" id="tel"
  aria-invalid="true"
  aria-describedby="tel-error">
<span id="tel-error" class="error" role="alert">
  Le numéro de téléphone doit contenir 10 chiffres
</span>

Comment Scrutia détecte ce problème

Scrutia simule la soumission de formulaires avec des données invalides et vérifie que chaque champ en erreur est identifié avec aria-invalid="true", qu'un message d'erreur textuel est affiché, et que ce message est associé programmatiquement au champ via aria-describedby ou aria-errormessage. Il signale les erreurs signalées uniquement par la couleur et les messages d'erreur génériques non associés aux champs.

Questions fréquentes

Peut-on utiliser la couleur rouge pour signaler les erreurs ?

Oui, mais la couleur ne doit pas être le seul moyen de signalement. Vous devez également ajouter un message textuel, une icône ou un autre indicateur visuel. La couleur seule exclut les personnes daltoniennes et les utilisateurs de lecteurs d'écran.

Comment associer un message d'erreur à un champ ?

Utilisez aria-describedby sur le champ avec l'id du message d'erreur. Le lecteur d'écran annoncera le message d'erreur en même temps que le champ. Ajoutez aussi aria-invalid="true" sur le champ en erreur.

Quand faut-il afficher les messages d'erreur ?

Idéalement, les erreurs doivent être signalées dès que l'utilisateur quitte un champ (validation en temps réel) et confirmées lors de la soumission du formulaire. Le focus doit être placé sur le premier champ en erreur après soumission.

Faut-il lister toutes les erreurs en haut du formulaire ?

C'est une bonne pratique complémentaire : un résumé des erreurs en haut du formulaire avec des liens vers chaque champ concerné. Mais cela ne dispense pas d'afficher aussi les messages d'erreur à côté de chaque champ.

Votre site a-t-il ce problème ?

Scrutia audite votre site sur 106 critères RGAA en 5 minutes. Navigation clavier, composants ARIA, focus visible, contrastes, et bien plus.

Lancer un audit gratuit