Formulaire
Un formulaire est un ensemble de champs et de boutons qui permettent à un utilisateur de transmettre des données sur un site web. Pour être accessible, chaque champ doit porter une étiquette reliée dans le code, les contrôles liés doivent être regroupés dans un fieldset, et les erreurs signalées en texte. Le RGAA y consacre 13 critères, sa thématique la plus fournie.
Connexion, inscription, paiement, recherche. Chaque fois qu'un site demande une information, un formulaire entre en jeu. C'est aussi là que l'accessibilité déraille le plus souvent : le WebAIM Million 2025 recense plus de 1,7 million de champs sans étiquette correcte sur un million de pages analysées.
#Trois piliers d'un formulaire accessible
Le tutoriel Formulaires du W3C WAI résume les exigences en trois axes.
Étiqueter chaque champ. Chaque <input>, <select> ou <textarea> a besoin d'un <label> relié par for et id. Le placeholder ne compte pas : il disparaît dès la saisie et n'est pas annoncé de manière fiable par tous les lecteurs d'écran.
Regrouper les contrôles liés. Un ensemble de boutons radio ou de cases à cocher partageant la même question se place dans un <fieldset> avec un <legend>. Sans ce regroupement, un lecteur d'écran annonce chaque option sans contexte.
<fieldset>
<legend>Mode de livraison</legend>
<label><input type="radio" name="livraison" value="standard"> Standard</label>
<label><input type="radio" name="livraison" value="express"> Express</label>
</fieldset>Décrire les erreurs en texte. Quand la saisie échoue, chaque champ en erreur doit recevoir un message visible, relié via aria-describedby. Le critère WCAG 3.3.1 l'exige au niveau A. Une bordure rouge seule est invisible aux lecteurs d'écran et indistincte pour les daltoniens.
#Ce que le RGAA vérifie
La thématique 11 du RGAA couvre les formulaires en 13 critères. Les plus fréquemment échoués :
- 11.1 : chaque champ a une étiquette reliée
- 11.5 : les champs de même nature sont regroupés (
<fieldset>) - 11.10 : les champs obligatoires et le format attendu sont signalés avant la saisie
- 11.11 : les erreurs sont identifiées et des suggestions de correction sont proposées
13 critères pour une seule thématique. Aucune autre catégorie du RGAA n'en compte autant.
#Le piège que personne ne mentionne
Les lecteurs d'écran passent en « mode formulaire » à l'intérieur d'un <form>. Dans ce mode, ils ne lisent que les éléments de formulaire : <input>, <select>, <textarea>, <legend> et <label>. Un paragraphe d'aide placé entre deux champs sans être relié par aria-describedby ? Invisible.
Un formulaire de recherche à un seul champ semble trop simple pour poser problème. Les exigences sont pourtant les mêmes : une étiquette (visible ou via aria-label), un bouton de soumission explicite. La technique H32 du W3C rappelle qu'un formulaire sans bouton retire à l'utilisateur le contrôle du moment où l'action se déclenche.
<label for="recherche">Recherche</label>
<input id="recherche" type="search">
<button type="submit">Rechercher</button>Trois lignes. Zéro excuse.
#En résumé
Étiquetez chaque champ avec <label>. Regroupez les contrôles liés dans <fieldset>. Décrivez les erreurs en texte, pas en couleur. Reliez vos instructions aux champs avec aria-describedby, sinon les lecteurs d'écran les ignoreront.