Grilla

Critère RGAA 11.1 : étiquettes de formulaire en code

Publié le

Le critère 11.1 du RGAA 4.1.2 demande que chaque champ de formulaire ait une étiquette. Le test 11.1.1 accepte cinq techniques : un <label> avec for, un aria-labelledby, un aria-label, un title, ou un bouton adjacent complété par un nom accessible. Le placeholder n'en fait pas partie. Cette fiche montre chaque technique en code, les erreurs qui font échouer le critère et la façon de le tester.

Source : critère 11.1 sur le site officiel du RGAA.

Ce que vérifie le critère 11.1

L'intitulé officiel

Le référentiel pose une seule question : « Chaque champ de formulaire a-t-il une étiquette ? »

Ce qu'est un champ de formulaire pour le RGAA

Le glossaire du RGAA donne une liste fermée : les input de saisie (text, password, search, email, number, tel, url) et textarea, les sélections (checkbox, radio, date, range, color, time, month, week, datetime-local, select, datalist, optgroup, option), input type="file", output, progress, meter, et les rôles WAI-ARIA progressbar, slider, spinbutton, textbox, listbox, searchbox, combobox, option, checkbox, radio et switch.

Le glossaire exclut les input de type submit, reset, hidden, image et button, l'élément button et role="button". Les boutons relèvent du critère 11.9, qui vérifie la pertinence de leur intitulé.

11.1, 11.2 et 11.4

Le 11.1 vérifie qu'une étiquette existe et qu'elle est reliée au champ par une technique reconnue. Il ne juge pas le texte. La pertinence relève du critère 11.2 : « Chaque étiquette associée à un champ de formulaire est-elle pertinente (hors cas particuliers) ? » La proximité visuelle entre l'étiquette et son champ relève du critère 11.4.

Les trois tests officiels, expliqués

Test 11.1.1 : les cinq conditions acceptées

Le test demande que chaque champ vérifie au moins une de ces conditions, citées mot pour mot :

  1. « Le champ de formulaire possède un attribut WAI-ARIA aria-labelledby référençant un passage de texte identifié » ;
  2. « Le champ de formulaire possède un attribut WAI-ARIA aria-label » ;
  3. « Une balise <label> ayant un attribut for est associée au champ de formulaire » ;
  4. « Le champ de formulaire possède un attribut title » ;
  5. « Un bouton adjacent au champ de formulaire lui fournit une étiquette visible et un élément <label> visuellement caché ou un attribut WAI-ARIA aria-label, aria-labelledby ou title lui fournit un nom accessible. »

Test 11.1.2 : la liaison for et id

Quand un champ est associé à un <label> avec for, deux conditions s'ajoutent : le champ possède un attribut id, et la valeur de for est égale à cette valeur d'id.

Test 11.1.3 : l'étiquette qui n'est pas visible

Ce test vise les champs dont l'étiquette n'est pas visible ou pas à proximité (contenu masqué, aria-label), ou n'est pas accolée au champ (aria-labelledby). Chacun doit alors vérifier une de ces conditions :

  • un attribut title « dont le contenu permet de comprendre la nature de la saisie attendue » ;
  • un passage de texte accolé au champ qui devient visible à la prise de focus ;
  • un passage de texte visible accolé au champ.

Le glossaire définit « accolés » ainsi : l'étiquette et son champ doivent être « visuellement proches de manière à ce que la relation entre les deux ne puisse pas prêter à confusion ». Ce test demande donc un jugement humain sur la page affichée.

Les cinq façons d'étiqueter un champ, en code

Les extraits suivants sont rédigés pour cette fiche, sur le modèle des exemples des techniques W3C citées. Ils illustrent chaque condition du test 11.1.1 et n'ont pas été testés avec un lecteur d'écran.

<label> avec for et id

C'est la technique à privilégier. La technique W3C H44 en note un avantage : cliquer sur l'étiquette active le champ, la zone cliquable est donc plus grande.

<label for="email">Adresse e-mail</label>
<input type="email" id="email" name="email" autocomplete="email">

Pour une case à cocher ou un bouton radio, l'étiquette se place après le champ, comme dans les exemples de H44 :

<input type="checkbox" id="cgu" name="cgu">
<label for="cgu">J'accepte les conditions d'utilisation</label>

aria-labelledby vers un texte identifié

Utile quand le texte d'étiquette est déjà dans la page, ou se compose de plusieurs morceaux.

<p id="nb-jours-lbl">Nombre de jours avant le rappel</p>
<input type="number" id="nb-jours" aria-labelledby="nb-jours-lbl">

La technique ARIA16 montre une concaténation : le nom est formé de l'étiquette, de la valeur du champ et d'un texte qui suit.

<label id="l1" for="f3">Me prévenir</label>
<select id="f3" name="delai" aria-labelledby="l1 f3 l2">
  <option value="1">1</option>
  <option value="2">2</option>
</select>
<span id="l2">jours avant</span>

Le glossaire du RGAA ajoute deux notes : un tabindex="-1" est recommandé sur les passages de texte non interactifs « pour assurer une compatibilité maximum avec les agents utilisateurs, notamment Internet Explorer 11 », et les références ne doivent être ni récursives (A référence B qui référence A) ni traversantes (A référence B qui référence C).

aria-label

Réservé aux cas où aucun texte visible n'est possible.

<input type="search" id="q" name="q" aria-label="Rechercher dans la documentation">
<button type="submit">Rechercher</button>

Deux limites. Le glossaire précise que « l'attribut aria-label ne peut pas être utilisé pour indiquer le caractère obligatoire d'un champ ». Et l'étiquette n'étant pas visible, le test 11.1.3 s'applique : il faut un title explicite, un texte accolé visible, ou un texte qui apparaît au focus.

title

La technique W3C H65 le présente comme une solution quand l'élément label ne peut pas être utilisé, par exemple une liste qui restreint la portée d'une recherche.

<label for="terme">Rechercher :</label>
<input type="text" id="terme" name="terme">
<select id="portee" name="portee" title="Rechercher dans">
  <option value="tout">Tout le site</option>
  <option value="docs">La documentation</option>
</select>

Le glossaire ajoute que, si title et placeholder sont présents sur le même champ, « ils doivent être identiques ».

Le bouton adjacent

La cinquième condition couvre le motif courant d'un champ de recherche suivi de son bouton. Le bouton visible sert d'étiquette visible ; un <label> masqué ou un attribut ARIA fournit le nom accessible.

<label for="q2" class="sr-only">Rechercher sur le site</label>
<input type="search" id="q2" name="q">
<button type="submit">Rechercher</button>

sr-only est un nom de classe d'exemple : il désigne la classe de masquage accessible du projet, pas un attribut standard.

Ce qui fait échouer le critère 11.1

Le placeholder seul

<!-- Aucune des cinq conditions du test 11.1.1 -->
<input type="email" name="email" placeholder="Votre e-mail">

L'attribut placeholder ne figure pas parmi les conditions du test 11.1.1. Le glossaire du RGAA ne le mentionne qu'à propos de title : il « est susceptible d'être restitué à la place de l'attribut title », d'où l'exigence de contenus identiques quand les deux coexistent. Le W3C, dans Understanding 2.5.3, rapporte que la norme HTML indique que l'attribut placeholder ne doit pas être utilisé comme alternative à un label. Correction : ajouter un <label for> visible.

Le texte posé à côté, sans liaison

<!-- Le texte n'est relié à aucun champ -->
Code postal : <input type="text" name="cp">
<label>Ville</label> <input type="text" name="ville">

Ces deux cas sont décrits par l'échec W3C F68. Correction : <label for="cp"> et id="cp".

Cas voisin, le <label> qui entoure le champ sans attribut for. La condition du test 11.1.1 mentionne « Une balise <label> ayant un attribut for ». En lecture stricte, ajoutez donc for et id, même quand le <label> entoure le champ ; l'interprétation est à confirmer avec votre auditeur.

Le for qui ne pointe sur rien

<!-- Test 11.1.2 invalidé : for="mail", id="email" -->
<label for="mail">Adresse e-mail</label>
<input type="email" id="email" name="email">

Le test 11.1.2 échoue aussi quand l'id est absent. La technique H44 rappelle en outre que l'id doit être unique dans la page : vérifiez les composants dupliqués.

aria-labelledby vers un id inexistant

<!-- Aucun élément id="tel-label" dans la page -->
<input type="tel" id="tel" aria-labelledby="tel-label">

La condition exige un « passage de texte identifié ». Si l'id cité n'existe pas, le champ n'a pas d'étiquette.

L'étiquette masquée sans texte visible

<!-- Test 11.1.3 : nom accessible présent, mais rien de visible -->
<input type="text" id="code" aria-label="Code de réduction">

Le champ satisfait le test 11.1.1, mais ni title, ni texte accolé visible, ni texte visible au focus. Le test 11.1.3 n'est pas validé.

Le champ en plusieurs morceaux

Un numéro de téléphone ou une date en trois champs pose deux problèmes documentés par le W3C : une seule étiquette pour plusieurs champs, ou reliée au premier seulement (F86), et une ponctuation lue comme étiquette : F86 note que certaines technologies d'assistance lisent la ponctuation comme l'identification des champs, et F82 traite le cas sous l'angle du 3.3.2. Chaque sous-champ doit avoir son propre nom, et le groupe une légende :

<fieldset>
  <legend>Téléphone</legend>
  <input type="tel" id="tel-ind" name="tel-ind" title="Indicatif pays" autocomplete="tel-country-code">
  <input type="tel" id="tel-num" name="tel-num" title="Numéro" autocomplete="tel-national">
</fieldset>

Le regroupement relève des critères 11.5 et 11.6. Les title restent soumis au test 11.1.3.

Le composant personnalisé sans nom

Un div role="combobox" ou role="textbox" est un champ de formulaire au sens du glossaire. aria-labelledby ou aria-label lui donnent un nom, comme le montre la technique ARIA14.

<span id="ville-lbl">Ville</span>
<div role="combobox" aria-labelledby="ville-lbl" aria-expanded="false" tabindex="0"></div>

Plusieurs étiquettes sur un même champ : laquelle est lue ?

Le glossaire du RGAA fixe un ordre strict pour le calcul du nom accessible : aria-labelledby, sinon aria-label, sinon <label>, sinon title. Il précise que « cet ordre doit être utilisé pour l'évaluation de la pertinence de l'étiquette (critère 11.2) ».

Conséquence directe : un aria-label ajouté « par sécurité » remplace le <label> visible.

<!-- Nom lu : "Saisissez votre identité", pas "Nom" -->
<label for="n">Nom</label>
<input type="text" id="n" aria-label="Saisissez votre identité">

Le test 11.2.5 demande que, s'il est présent, le contenu de l'aria-label contienne « au moins l'intitulé visible ». Le critère WCAG 2.5.3 (Étiquette dans le nom) va dans le même sens : Understanding 2.5.3 explique que les personnes qui utilisent la commande vocale se servent des intitulés visibles dans leurs commandes. Correction la plus simple : retirer l'aria-label.

Tester le critère 11.1

À la main

  1. Lister les champs de la page avec les outils de développement, en suivant la liste du glossaire, rôles ARIA compris.
  2. Lire le nom accessible de chaque champ dans l'arbre d'accessibilité du navigateur. La procédure de l'échec F68 demande un nom accessible ni vide ni composé seulement d'espaces.
  3. Vérifier les liaisons : chaque for correspond à un id unique, chaque aria-labelledby vise un élément existant.
  4. Pour chaque étiquette masquée, chercher le title, le texte accolé visible ou le texte qui apparaît au focus exigé par le test 11.1.3, et décider s'il permet de comprendre la saisie attendue.

Un outil automatique repère un champ dont le nom accessible est vide. Il ne peut pas décider seul si un texte accolé « permet de comprendre la nature de la saisie attendue » : ce jugement, comme la pertinence évaluée au 11.2, revient à l'auditeur.

Tester avec Grilla

Cette section décrit uniquement ce qu'indiquent les pages publiques de Grilla.

La documentation pour lancer l'analyse automatique d'une page indique que la page est ouverte dans Chromium, puis que l'outil « classe le résultat sur les 106 critères ». Il extrait aussi un résumé de la page, champs compris, « pour la pré-analyse IA éventuelle ». L'outil signale ce qu'il détecte ; le rapport s'exporte en CSV, JSON ou PDF.

La page sur les critères que l'outil tranche seul détaille la règle de statut appliquée à chaque critère, et précise qu'« un verdict de l'auditeur […] remplace toujours ce résultat automatique ». Quand une pré-analyse a été faite, l'IA propose un verdict ; c'est l'auditeur qui décide. Cette étape a lieu dans l'audit guidé, qui affiche « chaque test du critère, avec la procédure de vérification publiée par la DINUM » : c'est là que l'on peut vérifier la pertinence des étiquettes dans l'audit guidé.

Un rapport d'audit réel, critère par critère, produit sur un site fictif, en donne une illustration. Dans la thématique Formulaires, le 11.2 y est affiché « À vérifier », avec une proposition de l'IA en attente de l'auditeur. Le 11.9 y est non conforme, ce qui rappelle que les boutons relèvent de ce critère et non du 11.1.

Pour les champs groupés, la page Outils décrit un générateur de groupe de champs avec fieldset et legend (critères 11.5 et 11.6).

Correspondance WCAG

Références affichées sous le critère 11.1 du RGAA 4.1.2, textes tirés de la traduction française autorisée des WCAG 2.1 :

WCAG 2.1 Niveau EN 301 549 V2.1.2
1.3.1 Information et relations A 9.1.3.1
2.4.6 En-têtes et étiquettes AA 9.2.4.6
3.3.2 Étiquettes ou instructions A 9.3.3.2
4.1.2 Nom, rôle et valeur A 9.4.1.2
Voisin : 2.5.3 Étiquette dans le nom (rattaché au test 11.2.5) A

Le 3.3.2 dit : « Des étiquettes sont présentées ou des instructions sont fournies quand un contenu requiert une saisie utilisateur. » Understanding 3.3.2 précise qu'un champ nommé par aria-label peut satisfaire le 4.1.2 et échouer pourtant au 3.3.2, si l'étiquette n'est pas présentée à tous les utilisateurs, et pas seulement à ceux qui utilisent une technologie d'assistance. La technique H44 l'écrit aussi : pour le 3.3.2, l'élément label doit être visible. C'est la logique du test 11.1.3.

Et le RGAA 5 ?

La page Méthode du site officiel indique que la version 5 du RGAA est en cours de rédaction, avec une publication prévue fin 2026, et que les travaux en cours « ne doivent en aucun cas être suspendus ou reportés ». Le numéro et le texte du critère seront à revérifier à la publication.

Questions fréquentes

Que demande le critère RGAA 11.1 ?

Que chaque champ de formulaire ait une étiquette. Le test 11.1.1 accepte cinq techniques : un <label> dont le for correspond à l'id du champ, un aria-labelledby vers un texte identifié, un aria-label, un title, ou un bouton adjacent qui sert d'étiquette visible, complété par un nom accessible. La pertinence du texte est vérifiée par le critère 11.2.

Un placeholder suffit-il comme étiquette de champ ?

Non. Le placeholder ne figure pas parmi les techniques du test 11.1.1. Le W3C rappelle que la norme HTML indique qu'il ne doit pas être utilisé comme alternative à un label. Si un champ porte à la fois title et placeholder, le glossaire du RGAA demande des contenus identiques.

Quelle étiquette est lue quand un champ en a plusieurs ?

Le glossaire fixe l'ordre : aria-labelledby, sinon aria-label, sinon <label>, sinon title. Un aria-label ajouté sur un champ qui a déjà un <label> visible le remplace. Pour le test 11.2.5 et le critère WCAG 2.5.3, ce nom doit contenir au moins l'intitulé visible.

Sources

Toutes consultées le 17 octobre 2026.

Information générale sur le RGAA 4.1.2, pas un avis juridique.

Un service Forge Digitale Solutions