6 mauvaises façons d’utiliser la balise label pour un champ de formulaire
Qu’est-ce qu’un <label> ?
Le <label> permet d’associer un intitulé à un champ de formulaire (<input>, <select>, <textarea>…).
Cette association est essentielle pour les personnes aveugles ou fortement malvoyantes qui utilisent un lecteur d’écran, mais aussi pour les personnes ayant des troubles moteurs (elle agrandit la zone cliquable du champ).
Voici un exemple simple :
<label for="email">Adresse e-mail</label>
<input type="email" id="email">
Pourtant, lors des audits de conformité au RGAA ou RAWeb, le <label> est très souvent mal utilisé, voire complètement absent.
Voici les erreurs les plus courantes.
1 : L’oubli pur et simple
C’est l’erreur la plus basique mais aussi une des plus fréquentes.
Adresse e-mail
<input type="email" id="email">
Sans <label> associé, les technologies d’assistance peuvent :
- Ne rien annoncer du tout.
- Ou lire un intitulé générique et inutile comme « champ de saisie ».
À retenir : tout champ de formulaire doit avoir un label associé, sans exception.
2 : Casser l’association avec le for / id
Parfois le <label> existe mais il n’est associé à rien, à cause d’une faute de frappe ou d’un id dupliqué ailleurs sur la page.
<label for="mail">Adresse e-mail</label>
<input type="email" id="email">
Ici, for="mail" ne correspond à aucun id="mail" : le lien est rompu. Le lecteur d’écran annoncera le champ sans son intitulé.
<label for="email">Adresse e-mail</label>
<input type="email" id="email">
À retenir : le for et l’id doivent être identiques, uniques dans la page, et vérifiés après chaque modification du code.
3 : Un label trop vague, coupé de son contexte
Un intitulé peut être présent et pourtant inutile une fois lu hors contexte visuel.
<label for="champ1">Nom</label>
<input type="text" id="champ1">
<label for="champ2">Nom</label>
<input type="text" id="champ2">
Un lecteur d’écran énoncera deux fois « Nom », sans qu’on sache lequel concerne la personne facturée et lequel concerne le destinataire.
<label for="nom-facturation">Nom (facturation)</label>
<input type="text" id="nom-facturation">
<label for="nom-livraison">Nom (destinataire de la livraison)</label>
<input type="text" id="nom-livraison">
À retenir : un label doit rester compréhensible même sorti de son environnement visuel.
4 : Utiliser un placeholder à la place d’un <label>
Une erreur très répandue consiste à se dire qu’un placeholder suffit.
<input type="search" placeholder="Nom complet">
Problème : ici, rien n’indique à un lecteur d’écran à quoi correspond ce champ. Le placeholder disparaît dès que l’utilisateur commence à saisir du texte, et son support par les lecteurs d’écran est inégal. Une personne qui perd le fil (interruption, trouble de la mémoire de travail) ne sait plus ce qui était demandé.
<label for="nom">Nom complet</label>
<input type="text" id="nom" placeholder="Jean Dupont">
À retenir : le placeholder est un complément (un exemple de format), jamais un substitut au <label>.
5 : Multiplier les intitulés qui se contredisent
Un piège classique : empiler <label>, aria-label et aria-labelledby sur un même champ, en espérant que cela soit d’avantage accessible.
<label for="tel">Téléphone</label>
<input type="tel" id="tel" aria-label="Numéro de portable">
Quand plusieurs sources de nommage coexistent, l’ordre de priorité du navigateur peut ignorer le <label> visible au profit de l’aria-label, créant un décalage entre ce que voit une personne voyante et ce qu’entend une personne aveugle.
Cela peut également créer des problématiques pour les reconnaissances vocales qui cibleront aussi l’aria-label et non l’intitulé visible.
<label for="tel">Téléphone</label>
<input type="tel" id="tel">
À retenir : un seul mécanisme de nommage à la fois, sauf besoin réellement justifié.
6 : Ne pas distinguer label visible et label accessible
Un champ de recherche ne possède parfois aucun texte, seulement une icône. Dans cet exemple l’icône n’est qu’une image de fond CSS, invisible pour les technologies d’assistance.

<input type="search" class="champ-recherche">
.champ-recherche {
background: url("loupe.svg");
}
Pour y remédier, une solution consiste à masquer un <label> grâce à CSS.
Attention cependant, n’utilisez pas display:none ou visibility:hidden pour « faire disparaître » le texte car ces propriétés CSS retirent aussi l’élément de l’arbre d’accessibilité. Le label disparaît donc pour tout le monde, y compris pour le lecteur d’écran.
À la place, utiliser une classe CSS qui permet la restitution uniquement à certaines technologies d’assistance (dont les lecteurs d’écran) :
.visually-hidden {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border-width: 0;
}
Cette technique masque le texte visuellement tout en le laissant accessible aux technologies d’assistance.
<label for="recherche" class="visually-hidden">Rechercher sur le site</label>
<input type="search" class="champ-recherche">
À retenir : un champ dont le seul repère visuel est une icône a quand même besoin d’un label accessible, masqué avec une technique adaptée.
Conclusion : comment bien utiliser le <label> ?
Comme souvent en accessibilité, la règle est « simple » mais demande de la rigueur.
Priorités à respecter :
- Associer un
<label>à chaque champ de formulaire. - Vérifier que
foretidcorrespondent bien. - Garder les intitulés compréhensibles hors contexte.
- Masquer un label visuellement sans le retirer de l’arbre d’accessibilité.
- Éviter les mécanismes de nommage multiples et contradictoires.
Et surtout : penser à l’utilisateur final.
Article publié par
Élisa GrederConsultante experte en accessibilité numérique & Responsable communication


