Chaque étiquette associée à un champ de formulaire est-elle pertinente (hors cas particuliers) ?
Un utilisateur de lecteur d’écran arrive sur un formulaire et navigue de champ en champ. À chaque champ, le lecteur d’écran annonce l’étiquette. Si cette étiquette dit « Champ 1 » ou « Texte », l’utilisateur ne sait pas quoi saisir. Label présent ne veut pas dire label utile.
Six mécanismes d’étiquetage sont couverts : l’élément <label>, l’attribut title, les attributs WAI-ARIA aria-label et aria-labelledby, et le bouton adjacent. Pour chacun, la question est identique : le contenu de ce mécanisme décrit-il la fonction du champ avec suffisamment de précision pour que l’utilisateur sache ce qu’il doit y saisir ? Le critère 11.1 vérifie qu’une étiquette existe ; le critère 11.2 vérifie qu’elle est utile. Ce sont deux problèmes distincts.
Le test 11.2.5 couvre un cas souvent négligé : quand un champ a à la fois un libellé visible et une étiquette programmatique (aria-label, title, etc.), le texte programmatique doit contenir le libellé visible. Un utilisateur de reconnaissance vocale qui prononce « Prénom » pour activer le champ sera ignoré si le nom accessible contient autre chose. C’est le critère WCAG 2.5.3 (Label in Name) appliqué aux formulaires.
Une étiquette pertinente répond à une seule question : « qu’est-ce que je dois saisir ici ?». Pas plus, pas moins.
6 tests pour évaluer la pertinence des étiquettes de champs
Pertinence du contenu du <label>
- Repérez tous les champs de formulaire dont l’étiquette est un élément
<label>(associé viafor/idou par imbrication). - Pour chaque champ, lisez le contenu textuel du
<label>associé. - Vérifiez que ce contenu décrit clairement la fonction du champ.
- Un label générique comme « Saisir », « Champ », « Texte » ou un identifiant technique fait échouer le test.
✓ Test validé si tous les <label> présents sont pertinents.
Pertinence du contenu de l'attribut title
- Repérez tous les champs de formulaire dont l’étiquette est fournie via l’attribut
title(en l’absence de<label>visible). - Pour chaque champ, lisez la valeur de l’attribut
title. - Vérifiez que cette valeur décrit clairement la fonction du champ.
✓ Test validé si tous les attributs title utilisés comme étiquette sont pertinents.
Pertinence du contenu de l'attribut aria-label
- Repérez tous les champs de formulaire dont l’étiquette est fournie via
aria-label. - Pour chaque champ, lisez la valeur de l’attribut
aria-label. - Vérifiez que cette valeur décrit clairement la fonction du champ. Attention :
aria-labelécrase le<label>visible dans le calcul du nom accessible.
✓ Test validé si tous les attributs aria-label utilisés comme étiquette sont pertinents.
Pertinence du texte référencé par aria-labelledby
- Repérez tous les champs de formulaire dont l’étiquette est fournie via
aria-labelledby. - Pour chaque champ, identifiez le ou les éléments référencés par la valeur de
aria-labelledby(un ou plusieurs identifiants séparés par des espaces). - Concatenez le contenu textuel de ces éléments dans l’ordre des identifiants.
- Vérifiez que ce contenu décrit clairement la fonction du champ.
✓ Test validé si tous les passages référencés constituent une étiquette pertinente.
Nom accessible contenant l'intitulé visible
Ce test s’applique uniquement aux champs qui ont à la fois un libellé visible ET une étiquette programmatique (<label>, title, aria-label ou aria-labelledby).
- Repérez les champs dans cette situation.
- Pour chaque champ, identifiez le libellé visible (le texte affiché à l’écran que les voyants lisent).
- Vérifiez que l’étiquette programmatique contient ce libellé visible. Il peut y avoir du texte supplémentaire, mais le libellé visible doit s’y trouver.
Échec : libellé visible « Prénom », aria-label="Votre identité civile" (ne contient pas « Prénom »).
Réussite : libellé visible « Prénom », aria-label="Prénom (obligatoire)" (contient « Prénom »).
✓ Test validé si l’étiquette programmatique contient le libellé visible pour chaque champ concerné.
Pertinence du bouton adjacent comme étiquette visible
Ce test concerne les formulaires à champ unique où un bouton adjacent sert de libellé visible (ex. : barre de recherche avec un bouton « Rechercher »).
- Repérez les champs dont le libellé visible est fourni par un bouton adjacent.
- Pour chaque champ, lisez le contenu visible du bouton (texte ou alternative textuelle s’il contient une image).
- Vérifiez que ce contenu décrit clairement la fonction du champ. Un bouton « OK » ou « Valider » sans contexte fail.
✓ Test validé si le contenu visible du bouton adjacent est pertinent pour chaque champ concerné.
Exemples
❌ Non conforme : Labels génériques via <label>
<label for="f1">Champ 1</label>
<input type="text" id="f1" name="nom">
<label for="f2">Texte</label>
<input type="email" id="f2" name="email">Les labels « Champ 1 » et « Texte » ne renseignent pas l’utilisateur sur ce qu’il doit saisir. Un lecteur d’écran annonce « Champ 1, zone de saisie » : inutilisable. Ces labels passent le critère 11.1 (ils existent et sont associés) mais échouent le critère 11.2 (ils ne sont pas pertinents).
✅ Conforme : Labels descriptifs via <label>
<label for="nom">Nom de famille</label>
<input type="text" id="nom" name="nom">
<label for="email">Adresse e-mail</label>
<input type="email" id="email" name="email">Chaque label décrit précisément ce que l’utilisateur doit saisir. Le lecteur d’écran annonce « Nom de famille, zone de saisie » : l’utilisateur sait immédiatement quoi écrire. La distinction « Nom de famille » vs « Prénom » est aussi plus précise que le seul mot « Nom » dans les formulaires avec plusieurs champs de nom.
❌ Non conforme : Conflit entre libellé visible et aria-label (test 11.2.5)
<label for="prenom">Prénom</label>
<input type="text" id="prenom" name="prenom" aria-label="Votre identité civile">Le nom accessible du champ est « Votre identité civile » car aria-label écrase le <label> dans le calcul du nom accessible. Le libellé visible « Prénom » est absent du nom accessible. Un utilisateur de Dragon NaturallySpeaking qui dit « cliquez Prénom » n’obtiendra aucun résultat. C’est une violation de WCAG 2.5.3.
✅ Conforme : aria-label cohérent avec le libellé visible (test 11.2.5)
<label for="prenom">Prénom</label>
<input type="text" id="prenom" name="prenom" aria-label="Prénom (obligatoire)">L’aria-label contient le mot « Prénom », identique au libellé visible. La reconnaissance vocale fonctionne correctement. Précision : dans la plupart des cas, un <label> bien rédigé suffit et rend l’aria-label inutile. On l’ajoute seulement quand le nom accessible doit transporter plus d’informations que le libellé visible seul.
Astuces et pièges
⚠️ Confondre présence et pertinence : l’erreur la plus fréquente en audit
Les développeurs vérifient souvent que chaque champ a un label (critère 11.1) mais ne lisent jamais le contenu de ce label. Un formulaire généré automatiquement peut produire des labels « input_47 » ou « field » qui passent 11.1 et échouent 11.2. Lire chaque label à voix haute est le test le plus rapide.
⚠️ L’aria-label qui écrase silencieusement le label visible
Quand un champ a un <label> visible ET un aria-label, c’est l’aria-label qui devient le nom accessible : il écrase le label dans l’arbre d’accessibilité. Si les deux ne concordent pas, le test 11.2.5 échoue. Soit supprimer l’aria-label (le <label> suffit), soit s’assurer que l’aria-label contient mot pour mot le texte du libellé visible.
💡 La règle des 1 à 5 mots pour un label efficace
Un label pertinent décrit la fonction du champ en 1 à 5 mots. Au-delà, vérifiez s’il ne s’agit pas d’une instruction plutôt que d’un label. Les instructions complémentaires (format de date, exemples de valeur) appartiennent hors du label, dans un texte associé via aria-describedby, afin de ne pas alourdir le nom accessible annoncé à chaque focus.
⚠️ Bouton adjacent et formulaire de recherche (test 11.2.6)
Une barre de recherche avec un bouton « Rechercher » peut satisfaire le test 11.2.6 si le bouton est visuellement adjacent et son texte pertinent. Attention cependant : cela couvre uniquement le libellé visible. Le champ doit toujours avoir un nom accessible programmatique pour satisfaire le critère 11.1 (via aria-label, title ou un <label> masqué en sr-only). Les deux critères s’appliquent indépendamment.
⚠️ Les cas particuliers du critère 11.2
La mention « hors cas particuliers » renvoie aux situations définies dans la note officielle du RGAA : champs dont la pertinence de l’étiquette ne peut être évaluée qu’au regard du contexte immédiat, ou champs façonnés par un outil tiers sur lequel l’éditeur n’a aucune maîtrise technique. Ces exceptions restent strictement encadrées et doivent être documentées dans la déclaration d’accessibilité.
Questions fréquentes
Quelle est la différence entre le critère RGAA 11.1 et le critère 11.2 ?
Le critère 11.1 vérifie qu’une étiquette existe et est correctement associée au champ. Le critère 11.2 vérifie que son contenu est utile. Un champ peut avoir un <label> valide (11.1 conforme) dont le texte est « Champ obligatoire » (11.2 non conforme). Les deux critères s’évaluent indépendamment.
Comment auditer le test RGAA 11.2.5 rapidement en inspection de code ?
Repérez les champs ayant à la fois un texte visible sur la page et un nom accessible fourni par <label>, title, aria-label ou aria-labelledby. L’inspecteur d’accessibilité de Firefox (panneau « Accessibilité ») ou Includdy affiche le nom accessible calculé : comparez-le à l’intitulé visible. Le nom accessible doit contenir les mots de l’intitulé visible, hors ponctuation et différences de casse.
Comment interpréter la conformité d'un champ avec aria-label et <label> visible en RGAA ?
Non, à condition que le aria-label contienne l’intitulé visible. <label>Code postal</label> avec aria-label="Code postal, 5 chiffres" est conforme au test 11.2.5 car le nom accessible contient « Code postal ». En revanche, aria-label="Saisir le CP" serait non conforme. Quand un <label> visible existe et suffit, évitez d’ajouter un aria-label : le risque de désynchronisation n’en vaut pas la peine.
Quand le title constitue-t-il une étiquette pertinente au sens du critère RGAA 11.2 ?
Le title est validé par le test 11.2.2 si son contenu est pertinent. Mais le title n’est pas visible par défaut et ne satisfait pas les exigences de visibilité du critère 11.4. Pour un formulaire standard, un <label> visible est toujours préférable. Le title comme seule étiquette est acceptable uniquement dans les formulaires à champ unique (recherche, connexion) où le contexte visuel est suffisant.
Comment évaluer la pertinence d'une étiquette de champ dans un fieldset selon le RGAA ?
Le RGAA ne l’exige pas explicitement dans le critère 11.2. Dans un fieldset « Date de naissance », les étiquettes « Jour », « Mois » et « Année » sont pertinentes prîtes au contexte fourni par la légende. En pratique, vérifiez que la combinaison étiquette du champ et légende du groupe forme un ensemble intelligible pour l’utilisateur.