Formulaires accessibles : labels, erreurs et champs obligatoires

Associer une étiquette à chaque champ

Chaque champ de saisie doit avoir une étiquette explicite, liée au champ de façon programmatique afin que le lecteur d'écran l'annonce au moment de la saisie. Cette exigence relève des critères 1.3.1 et 4.1.2 de la WCAG, repris par le RGAA pour l'étiquetage des champs. Un texte placé visuellement à côté d'un champ ne suffit pas s'il n'est pas relié techniquement : l'association via l'attribut qui lie l'étiquette à l'identifiant du champ est ce qui rend le lien fiable. Évitez de remplacer l'étiquette par un simple texte d'aide à l'intérieur du champ, qui disparaît dès la saisie.

Indiquer clairement les champs obligatoires

Le critère 3.3.2 de la WCAG (niveau AA) demande des étiquettes et des instructions pertinentes, ce qui inclut de signaler les champs obligatoires. L'indication ne doit pas reposer uniquement sur la couleur, par exemple un libellé affiché en rouge, car elle serait invisible pour certaines personnes. Précisez le caractère obligatoire dans le texte de l'étiquette et exposez aussi cette information aux technologies d'assistance, via l'attribut ARIA dédié aux champs requis. L'astérisque visuelle doit être accompagnée d'une explication de sa signification.

Rédiger des messages d'erreur utiles

Le critère 3.3.1 de la WCAG (niveau A) exige que les erreurs de saisie soient identifiées et décrites en texte. Un message efficace nomme le champ concerné et indique comment corriger : il vaut mieux préciser que la date doit être au format jour, mois, année plutôt qu'afficher un simple champ invalide. L'erreur doit être visible, reliée au champ et restituée aux lecteurs d'écran, idéalement via une zone qui annonce automatiquement le message. Ne signalez jamais une erreur par la seule couleur du champ.

Utiliser ARIA avec parcimonie

Les attributs ARIA permettent de nommer des composants, d'annoncer des erreurs ou de signaler un champ obligatoire lorsque le HTML natif ne suffit pas. Mais ARIA mal employé peut aggraver la situation en masquant ou en dupliquant des informations. La règle est d'utiliser d'abord les éléments HTML natifs, qui sont accessibles par défaut, et de ne recourir à ARIA que pour combler un manque. Sur les formulaires complexes, ce sont précisément ces réglages ARIA que nous vérifions en priorité lors d'un audit.

Questions fréquentes

Le texte indicatif dans un champ peut-il remplacer l'étiquette ?

Non. Le texte d'aide affiché à l'intérieur d'un champ disparaît dès que l'utilisateur commence à saisir, ce qui prive de repère les personnes ayant des troubles cognitifs ou de mémoire, et il n'est pas toujours bien restitué par les lecteurs d'écran. Il peut compléter une étiquette, par exemple pour donner un format attendu, mais ne doit jamais s'y substituer. Chaque champ a besoin d'une étiquette persistante et correctement liée.

Comment signaler un champ obligatoire de façon accessible ?

Mentionnez l'obligation dans le texte de l'étiquette, par exemple en ajoutant le mot obligatoire, et exposez cette information aux technologies d'assistance avec l'attribut ARIA prévu pour les champs requis. Si vous utilisez une astérisque, expliquez sa signification en début de formulaire. L'essentiel est que l'information ne dépende ni de la seule couleur ni d'un symbole non explicité.

Où afficher les messages d'erreur dans un formulaire ?

Placez le message au plus près du champ concerné et reliez-le à ce champ pour que le lecteur d'écran l'annonce. Un récapitulatif des erreurs en haut du formulaire, avec des liens vers chaque champ fautif, aide aussi sur les formulaires longs. L'important est que l'erreur soit identifiée en texte, qu'elle décrive la correction attendue et qu'elle ne repose pas uniquement sur une couleur.

Faut-il forcément utiliser ARIA pour rendre un formulaire accessible ?

Pas systématiquement. Une grande partie de l'accessibilité d'un formulaire s'obtient avec du HTML natif correctement structuré : éléments de champ, étiquettes liées, regroupements logiques. ARIA devient utile pour les composants personnalisés ou pour annoncer dynamiquement des erreurs et des états. Utilisé sans nécessité, il introduit souvent plus de problèmes qu'il n'en résout.

Comment tester l'accessibilité de mes formulaires ?

Commencez par naviguer dans le formulaire uniquement au clavier, puis avec un lecteur d'écran, pour vérifier que chaque champ est annoncé avec son étiquette et que les erreurs sont restituées. Les outils automatiques repèrent les étiquettes manquantes mais ne valident pas la pertinence des messages ni le parcours complet. Un diagnostic gratuit donne une première vue d'ensemble, et un audit manuel confirme la conformité réelle à la WCAG 2.1 AA et au RGAA.