Chaque champ de formulaire a-t-il une étiquette ?
Un utilisateur de lecteur d’écran arrive sur votre formulaire de contact. Son logiciel annonce « champ de saisie, type texte ». Aucun nom. Il ne sait pas s’il doit saisir son prénom, son email ou son message. Sans étiquette accessible, le champ est inutilisable.
Chaque champ doit exposer un nom accessible : un texte que les technologies d’assistance peuvent lire pour identifier ce que l’utilisateur doit saisir. Le critère 11.1 accepte cinq méthodes : un <label> associé via for/id, un attribut aria-labelledby pointant vers un texte identifié dans la page, un attribut aria-label, un attribut title, ou un bouton adjacent visible accompagné d’un <label> masqué ou d’un attribut ARIA.
La méthode de référence reste le <label> visible relié par for/id correspondants. Elle bénéficie à tous les utilisateurs, agrandit la zone cliquable du champ, et satisfait les trois tests du critère. Réservez aria-label et title aux cas où l’espace visuel est contraint — barre de recherche, champ de quantité dans un tableau de commande.
Le placeholder n’est pas une étiquette. Il disparaît à la saisie, son contraste est insuffisant, et certains lecteurs d’écran ne le restituent pas. Un champ avec uniquement un placeholder échoue au critère 11.1.
3 tests pour s'assurer que chaque champ de formulaire possède une étiquette visible
Présence d'une étiquette accessible sur chaque champ
- Identifiez tous les champs de formulaire dans la page (
<input>,<textarea>,<select>, etc.). - Pour chaque champ, vérifiez qu’au moins une des conditions suivantes est remplie :
- Le champ possède un attribut
aria-labelledbydont la valeur correspond à l’idd’un élément présent dans la page. - Le champ possède un attribut
aria-labelnon vide. - Le champ est associé à un
<label>ayant un attributforrenseigné. - Le champ possède un attribut
title. - Un bouton adjacent fournit une étiquette visible, et un
<label>masqué ou un attributaria-label,aria-labelledbyoutitlefournit le nom accessible.
- Le champ possède un attribut
- Si au moins une condition est remplie pour ce champ, le test est validé. Si aucune ne l’est, le champ est non conforme.
Association <label> via attributs for/id
Ce test s’applique uniquement aux champs associés à un <label>.
- Vérifiez que le champ possède un attribut
id. - Vérifiez que la valeur de l’attribut
fordu<label>est identique à la valeur de l’attributiddu champ. - Si les deux conditions sont remplies, le test est validé. Un
idmanquant ou une valeurfordifférente de l’idrend le champ non conforme.
Titre ou texte visible pour étiquette non adjacente
Ce test s’applique aux champs dont l’étiquette n’est pas visible à l’écran ou n’est pas adjacente (étiquette masquée CSS, aria-label, aria-labelledby pointant vers un élément distant).
- Pour chaque champ concerné, vérifiez qu’au moins une des conditions est remplie :
- Le champ possède un attribut
titlequi décrit clairement la nature de la saisie attendue. - Un texte adjacent au champ devient visible à la prise de focus et décrit la saisie attendue.
- Un texte visible est accolé au champ et décrit la saisie attendue.
- Le champ possède un attribut
- Si au moins une condition est remplie, le test est validé.
Exemples
❌ Non conforme : Champ sans étiquette (placeholder seul)
<form>
<input type="text" name="email" placeholder="Votre adresse email">
<button type="submit">S’inscrire</button>
</form>Le champ ne possède ni <label>, ni aria-label, ni title, ni aria-labelledby. Le placeholder n’est pas reconnu comme étiquette par le RGAA. Un lecteur d’écran annonce « champ de saisie, type texte » sans aucun nom. L’utilisateur doit deviner ce qu’il faut saisir.
❌ Non conforme : <label> mal associé — for et id incohérents
<form>
<label for="nom">Nom complet</label>
<input type="text" id="full-name" name="name">
</form>L’attribut for="nom" ne correspond pas à id="full-name". L’association est rompue : le lecteur d’écran n’annonce pas l’étiquette au focus du champ. Le test 11.1.2 échoue. Cliquer sur le label n’active pas le champ non plus.
✅ Conforme : <label> explicite via for/id
<form>
<label for="email">Adresse email</label>
<input type="text" id="email" name="email">
<button type="submit">S’inscrire</button>
</form>Le <label> est relié au champ via for/id correspondants. Le lecteur d’écran annonce « Adresse email, champ de saisie ». La zone cliquable s’agrandit aussi : cliquer sur le label active le champ, ce qui aide les utilisateurs avec un contrôle moteur réduit.
✅ Conforme : Barre de recherche avec aria-label
<form role="search">
<input
type="search"
id="recherche"
name="q"
aria-label="Rechercher sur le site"
>
<button type="submit" aria-label="Lancer la recherche">
<svg aria-hidden="true" focusable="false" width="16" height="16">
<use href="#icon-search"></use>
</svg>
</button>
</form>Quand l’espace visuel ne permet pas d’afficher une étiquette, aria-label fournit le nom accessible. Le lecteur d’écran annonce « Rechercher sur le site, champ de recherche ». Cette technique est acceptable pour les formulaires à champ unique dont la fonction est évidente dans le contexte visuel.
Astuces et pièges
⚠️ Le placeholder n’est pas une étiquette
C’est l’erreur numéro un en audit. Le placeholder disparaît dès que l’utilisateur commence à saisir — impossible de relire l’instruction pour corriger une saisie. Plusieurs lecteurs d’écran ne le restituent pas du tout. Son contraste par défaut échoue par ailleurs le critère 3.2. Un champ avec uniquement un placeholder est non conforme au critère 11.1.
⚠️ Le <label> implicite échoue le test 11.1.2
Un <label> qui enveloppe son champ sans attribut for crée une association sémantique reconnue par la plupart des lecteurs d’écran. Mais le test 11.1.2 exige explicitement que le <label> possède un attribut for dont la valeur correspond à l’id du champ. En audit RGAA strict, un label implicite sans for/id échoue ce test, même s’il fonctionne techniquement dans les navigateurs modernes.
💡 Masquer une étiquette sans la supprimer
Pour les formulaires de connexion ou les barres de recherche contraintes, masquez visuellement le <label> avec une classe CSS sr-only (position absolute, overflow hidden, clip). Le champ reste conforme au critère 11.1, et le critère 11.4 (proximité visuelle) ne s’applique pas puisque l’étiquette n’est pas visible. Évitez display:none et visibility:hidden, qui masquent aussi aux lecteurs d’écran.
⚠️ aria-labelledby peut combiner plusieurs passages de texte
aria-labelledby accepte plusieurs identifiants séparés par des espaces : aria-labelledby="label-qte label-produit" produit « Quantité T-shirt bleu ». Utile dans les tableaux de commande où chaque ligne a un article et chaque colonne un libellé. Le nom accessible résulte de la concaténation des textes référencés, dans l’ordre des identifiants.
⚠️ Le title est valide mais à usage limité
title satisfait le critère 11.1, mais il n’est pas affiché par défaut et son accessibilité est faible sur mobile (pas d’infobulle au toucher). Sur les formulaires complexes, préférez aria-label ou un <label> visible. Réservez title aux cas où il sert simultanément d’infobulle pour les utilisateurs voyants et de nom accessible pour les lecteurs d’écran.
Questions fréquentes
Pourquoi le placeholder ne remplace pas une étiquette de champ RGAA ?
Non, jamais. Le placeholder n’est pas une étiquette au sens du RGAA 11.1. Il disparaît à la saisie, son contraste par défaut est insuffisant (critère 3.2), et certains lecteurs d’écran ne le lisent pas. Si vous ne pouvez pas afficher d’étiquette visible, utilisez aria-label ou un <label class="sr-only">. Le placeholder peut coexister avec une vraie étiquette pour illustrer un exemple de format attendu.
Quand utiliser un <label> implicite pour répondre au critère RGAA 11.1 ?
Techniquement, un label implicite fonctionne dans la plupart des lecteurs d’écran modernes. Mais le test 11.1.2 exige explicitement un <label> avec for correspondant à l’id du champ. En audit RGAA strict, un label implicite sans for/id échoue ce test. Utilisez toujours l’association explicite pour être conforme sans ambiguïté.
Comment vérifier qu'un champ de formulaire a un nom accessible selon le RGAA ?
Deux méthodes rapides : (1) ouvrez le panneau Accessibilité de votre navigateur (DevTools > Accessibilité) et vérifiez le champ « Nom » calculé pour chaque input — s’il est vide, le critère 11.1 échoue. (2) Naviguez au clavier avec NVDA ou VoiceOver : le lecteur d’écran doit annoncer le nom du champ à chaque prise de focus. Un champ annoncé sans nom est non conforme.
Comment utiliser aria-label pour étiqueter un <select> ou un <textarea> ?
Oui, aria-label fonctionne sur tous les éléments de formulaire interactifs, y compris <select> et <textarea>. Préférez toutefois le <label> visible relié par for/id : il profite à tous les utilisateurs — voyants, malvoyants, cognitifs — et répond aux critères 11.1 et 11.2 en même temps. aria-label reste réservé aux cas où afficher un label visible est techniquement impossible.
Quelle est la différence entre le critère 11.1 et le critère 11.2 ?
Le critère 11.1 vérifie la présence et l’association technique d’une étiquette, visible ou non. Le critère 11.2 vérifie que cette étiquette est pertinente, c’est-à-dire qu’elle décrit correctement la saisie attendue. Un champ peut avoir aria-label="champ1" et réussir le 11.1 tout en échouant le 11.2 parce que l’étiquette est incompréhensible hors contexte.