Aller au contenu principal
Mynto

Brouillon non validé. Cette page est en noindex et n'apparaît pas dans le Codex public tant que son statut n'est pas passé à « Validé ».

AccessibiliteRGAA 11.10Niveau AAFormulaires

Contrôle de saisie non accessible (messages d'erreur de formulaire)

Quand un utilisateur soumet un formulaire avec une erreur, il doit savoir quel champ est en cause et comment corriger. Si ce retour n'est pas accessible, les personnes utilisant un lecteur d'écran tournent en rond. C'est ce que sanctionne le critère RGAA 11.10, niveau AA.

C'est quoi

Le critère RGAA 11.10, niveau AA, exige que le contrôle de saisie soit utilisé de manière pertinente. Il couvre l'ensemble de la chaîne de validation : signaler si un champ est obligatoire, préciser le format attendu avant la saisie, et identifier programmatiquement les erreurs après soumission.

Côté technologies d'assistance, deux exigences sont clés :

  • Le champ en erreur est identifié de façon programmatique : l'annonce du lecteur d'écran mentionne le champ en cause, pas seulement un message flottant quelque part sur la page. C'est le WCAG 3.3.1 (Identification des erreurs, niveau A).
  • Les indications données (format, contraintes) permettent de corriger. C'est le WCAG 3.3.2 (Étiquettes ou instructions, niveau A).

Le critère est de niveau AA dans le RGAA 4.1, conformément à la classification officielle du référentiel.

Qui est touché

  • Les personnes aveugles : si le message d'erreur apparaît visuellement mais n'est pas associé au champ ni annoncé, le lecteur d'écran ne le signale pas. L'utilisateur croit avoir tout rempli correctement.
  • Les personnes sourdes-aveugles utilisant une plage braille : même problème, le message doit être dans le flux du DOM et associé au champ.
  • Les personnes ayant des troubles cognitifs : un message vague ("Erreur de saisie") ne leur permet pas de comprendre ce qui est attendu.

Impact business

Un formulaire dont les erreurs ne sont pas accessibles est un formulaire que les utilisateurs de lecteur d'écran ne peuvent pas soumettre. L'impact est direct : inscription impossible, achat impossible, demande impossible.

Les formulaires de connexion, d'inscription et de commande sont les plus sensibles. Une erreur silencieuse y équivaut à une porte bloquée.

Sources des chiffres

Comment le détecter

  • Audit Mynto : le scan vérifie si les champs en erreur sont marqués avec aria-invalid="true" et si un message d'erreur leur est associé via aria-describedby.
  • Manuel : soumets un formulaire vide ou avec des données incorrectes. Écoute ce qu'annonce le lecteur d'écran. Si tu n'entends que la liste des champs sans mention des erreurs, le critère n'est pas respecté.
  • Inspecte le DOM : les messages d'erreur doivent exister dans le HTML (pas seulement créés par CSS) et être reliés au champ correspondant.

Comment corriger

Avant - HTML
<!-- Message d'erreur non associé au champ -->
<div class="erreur">Ce champ est obligatoire.</div>
<label for="email">E-mail</label>
<input type="email" id="email">
Après - HTML
<!-- Message d'erreur accessible, associé au champ -->
<label for="email">E-mail</label>
<input
  type="email"
  id="email"
  aria-invalid="true"
  aria-describedby="email-erreur"
>
<div id="email-erreur" role="alert">
  Ce champ est obligatoire. Format attendu : prenom@exemple.fr
</div>

Trois ajouts permettent de rendre un message d'erreur accessible :

  1. aria-invalid="true" sur le champ en erreur : annonce au lecteur d'écran que la saisie est invalide.
  2. aria-describedby="id-du-message" sur le champ : relie programmatiquement le message au champ.
  3. role="alert" sur le message : le fait annoncer automatiquement à l'apparition, sans que l'utilisateur ait à naviguer jusqu'à lui.

Sur WordPress, les plugins de formulaire modernes (Gravity Forms 2.5+, WPForms 1.8+) gèrent cela nativement. Vérifie que la version utilisée est à jour et que le thème n'écrase pas le HTML généré par le plugin.

Questions fréquentes

role="alert" suffit-il à signaler une erreur ?

Il suffit pour annoncer le message à son apparition. Mais il ne relie pas le message au champ. Combine role="alert" avec aria-invalid et aria-describedby pour une expérience complète.

Faut-il afficher tous les messages d'erreur en haut du formulaire ou à côté du champ ?

Les deux approches sont valides. Le plus important est que chaque message soit programmatiquement associé au champ concerné. Un résumé en haut du formulaire est utile en complément, pas en remplacement.

Comment tester sans lecteur d'écran ?

Inspecte le DOM après soumission : vérifie que aria-invalid="true" est bien posé sur les champs en erreur et que aria-describedby pointe vers un élément existant dans le HTML.

À lire aussi

Cette erreur est-elle sur ton site ?

Lance un audit Mynto gratuit. Tu sauras en quelques minutes si ton site est concerné, sur quelles pages, et avec quel impact.