Comment associer un label accessible à chaque champ ?

Un formulaire de contact, une barre de recherche, une inscription à la newsletter… pour une personne qui utilise un lecteur d’écran, chaque champ sans étiquette est une case mystère : « zone de texte », sans savoir s’il faut y mettre son nom, son email ou son message. Associer un libellé clair à chaque champ rend vos formulaires utilisables par tous.

La règle : chaque champ a besoin d’un label

La règle WCAG 3.3.2 demande que chaque champ de formulaire ait une étiquette explicite (un « label »), pour que l’utilisateur sache quoi y saisir. Cela paraît évident visuellement ; le piège est que l’étiquette doit aussi être liée techniquement au champ, pour que les lecteurs d’écran fassent le lien.

Pourquoi un label visible ne suffit pas toujours

Un texte « Email » placé à côté d’un champ se voit à l’œil… mais un lecteur d’écran ne devine pas forcément qu’ils vont ensemble. Il faut une association explicite dans le code : l’étiquette (balise <label>) est reliée au champ. Ainsi, quand l’utilisateur arrive sur le champ, le lecteur d’écran annonce « Email, zone de texte » — et non un vague « zone de texte ».

Le piège du placeholder

Erreur très fréquente : se servir du texte d’exemple (le « placeholder » grisé dans le champ) en guise d’étiquette. Mauvaise idée : ce texte disparaît dès qu’on commence à taper, n’est pas toujours lu par les lecteurs d’écran, et son contraste est souvent trop faible. Le placeholder est un complément, jamais un remplacement du label.

Les champs concernés

Tous : nom, email, message d’un formulaire de contact, mais aussi la barre de recherche (souvent une icône loupe sans libellé), les cases à cocher, les menus déroulants. Partout où l’on attend une saisie ou un choix, un label clair doit accompagner le champ.

Bon pour l’accessibilité et pour vos conversions

Un formulaire clair n’aide pas que les personnes en situation de handicap : il rassure et guide tous vos visiteurs. Un formulaire confus fait abandonner ; un formulaire limpide se remplit jusqu’au bout. Pour un commerçant qui veut des prises de contact ou des inscriptions, soigner ses formulaires, c’est protéger ses conversions.

Pourquoi « parfois un coup de main »

Si vous construisez vos formulaires avec un outil visuel, le label est souvent géré automatiquement : vous n’avez qu’à le renseigner. Mais corriger un champ mal associé, ou une barre de recherche sans libellé intégrée au thème, peut nécessiter de toucher au code — d’où le « à votre portée, parfois avec un coup de main ».

Comment repérer et corriger

1. Limpi signale les champs de formulaire sans label associé.
2. Vérifiez que chaque champ a un libellé clair, lié au champ (pas seulement un placeholder).
3. Pour les cas techniques (barre de recherche, champ mal associé), faites ajouter le label ou un libellé accessible par un développeur.

Un champ sans label, c’est un tiroir sans étiquette : vous savez peut-être ce qu’il contient, mais celui qui ne voit pas reste devant, à hésiter.

Tester soi-même, sans outil

Vous pouvez vérifier vos formulaires en quelques minutes, sans rien installer. Premier test, au clavier seul : posez votre souris, et parcourez le formulaire avec la touche Tab. Chaque champ doit être atteignable dans un ordre logique, et l’élément actif doit être visiblement mis en évidence (un contour, un surlignage). Si vous « perdez » le focus ou ne savez plus où vous êtes, un utilisateur au clavier le perdra aussi. Second test, avec les oreilles : votre Mac intègre un lecteur d’écran gratuit (VoiceOver, activable dans les réglages d’accessibilité). Activez-le et parcourez votre formulaire : chaque champ doit être annoncé avec son libellé (« Email, zone de texte »), pas un vague « zone de texte ». Ces deux tests maison révèlent l’essentiel des problèmes, du point de vue réel des personnes concernées.

En résumé

La règle WCAG 3.3.2 impose un libellé explicite à chaque champ de formulaire, réellement associé au champ dans le code — sinon un lecteur d’écran annonce un vague « zone de texte ». Évitez d’utiliser le texte d’exemple (placeholder) en guise d’étiquette. Au-delà de l’accessibilité, des formulaires clairs protègent vos conversions. C’est à votre portée via votre outil de formulaire, parfois avec un coup de main pour les cas techniques.

Questions fréquentes

Que demande la règle WCAG 3.3.2 ?

Que chaque champ de formulaire ait une étiquette explicite, pour que l’utilisateur sache quoi y saisir.

Un texte visible à côté du champ suffit-il ?

Pas toujours : l’étiquette doit être associée techniquement au champ (balise label liée), sinon un lecteur d’écran ne fait pas le lien.

Puis-je utiliser le placeholder comme étiquette ?

Non. Le texte d’exemple disparaît dès qu’on tape, n’est pas toujours lu et manque de contraste. C’est un complément, pas un label.

Quels champs sont concernés ?

Tous : nom, email, message, mais aussi la barre de recherche, les cases à cocher et les menus déroulants.

Est-ce à ma portée ?

Souvent oui via votre outil de formulaire. Les cas techniques (barre de recherche du thème, champ mal associé) peuvent demander un coup de main.

Sources et références

1. W3C — Web Accessibility Initiative (WAI) — Comprendre le critère 3.3.2 : étiquettes ou instructions
2. MDN Web Docs (Mozilla) — L’élément <label>