Labels, placeholders et légendes : les fondations

Un formulaire sans labels correctement associés est inutilisable pour une partie des utilisateurs. Pas simplement difficile à utiliser, totalement inutilisable. L’utilisateur de lecteur d’écran arrive sur un champ, entend “zone de saisie”, et ne sait pas quoi y écrire.

C’est pourtant l’erreur la plus fréquente sur les formulaires : des champs identifiés visuellement par leur placeholder, sans label associé dans le code.

Ce que chaque mécanisme fait vraiment

Le <label> est la seule solution robuste

Le <label> est l’élément HTML natif pour nommer un champ de formulaire. Associé correctement à son champ via les attributs for et id, il crée un lien programmatique que les technologies d’assistance lisent, que les moteurs de recherche comprennent, et que le navigateur utilise pour agrandir la zone de clic.

<label for="email">Adresse email</label>
<input type="email" id="email" name="email">

Ce que ce code produit :

• NVDA annonce : “Adresse email, zone de saisie” au focus sur le champ
• Cliquer sur le texte “Adresse email” place le focus dans le champ, zone de clic élargie
• Les outils d’audit reconnaissent le champ comme correctement labellisé

L’association doit être explicite. La proximité visuelle entre un label et son champ ne suffit pas, un lecteur d’écran ne “voit” pas la mise en page. Seul le lien for/id dans le code crée l’association.

<!-- ✗ Proximité visuelle sans association — le lecteur d'écran ne voit pas le lien -->
<label>Votre nom</label>
<input type="text" name="nom">

<!-- ✓ Association explicite par for/id -->
<label for="nom">Votre nom</label>
<input type="text" id="nom" name="nom">

Le placeholder est une aide visuelle, pas un label

Le placeholder est le texte gris qui apparaît dans un champ vide et disparaît dès que l’utilisateur commence à saisir. Il est conçu pour donner un exemple de format ou une indication brève, pas pour remplacer un label.

<!-- ✓ Placeholder comme exemple de format, avec label -->
<label for="tel">Téléphone</label>
<input type="tel" id="tel" placeholder="ex. 02 98 XX XX XX">

<!-- ✗ Placeholder à la place du label — problème majeur -->
<input type="text" placeholder="Votre nom">

Trois problèmes du placeholder seul :

Il disparaît à la saisie. L’utilisateur qui remplit un formulaire long perd l’indication de chaque champ dès qu’il commence à saisir. Il doit vider le champ pour se rappeler ce qu’il devait y mettre.

Son contraste est souvent insuffisant. Par convention, les placeholders sont affichés en gris pâle, un style qui échoue fréquemment au seuil de contraste de 4,5:1 du critère 3.2.

Son support par les technologies d’assistance (AT) est inégal. Certains lecteurs d’écran lisent le placeholder comme label quand aucun label n’est associé. D’autres l’ignorent complètement. Ce comportement varie selon la version et la configuration, aucune garantie d’annonce correcte.

aria-label, le label invisible

aria-label permet de nommer un champ directement dans le code, sans texte visible à l’écran. Les AT l’annoncent comme un label ordinaire, mais il n’est pas visible pour les utilisateurs voyants.

<!-- Champ de recherche sans label visible — contexte suffisant -->
<input type="search" aria-label="Rechercher dans le site">

Quand l’utiliser : uniquement quand il n’est pas possible d’avoir un <label> visible, comme dans une barre de recherche dans le header, un champ dans un contexte où le label serait redondant avec un titre adjacent.

Quand ne pas l’utiliser : à la place d’un <label> visible. Un label visible est toujours préférable, car il aide tous les utilisateurs, pas seulement les AT.

Le piège aria-label vs texte visible (WCAG 2.5.3) : si un champ a à la fois un texte visible et un aria-label différent, les utilisateurs de commande vocale qui disent le texte visible ne déclenchent rien. L’aria-label doit toujours commencer par le texte visible.

<!-- ✗ aria-label différent du texte visible -->
<button aria-label="Valider et envoyer">Envoyer</button>
<!-- Commande vocale "cliquer Envoyer" : échoue -->

<!-- ✓ aria-label commence par le texte visible -->
<button aria-label="Envoyer le formulaire de contact">Envoyer</button>
<!-- Commande vocale "cliquer Envoyer" : fonctionne -->

aria-labelledby permet de référencer un texte existant

aria-labelledby permet de désigner un élément déjà présent dans la page comme label d’un champ. Utile quand le label visuel n’est pas un <label> HTML.

<!-- Un titre sert de label à un champ de recherche -->
<h2 id="titre-recherche">Rechercher un document</h2>
<input type="search" aria-labelledby="titre-recherche">

<!-- Label composé de plusieurs éléments -->
<span id="col-montant">Montant</span>
<span id="col-eur">en euros</span>
<input type="number" aria-labelledby="col-montant col-eur">
<!-- NVDA annonce : "Montant en euros, zone de saisie" -->

Scénarios concrets d’impact

Scénario 1 : Le formulaire de contact sans labels

Le site d’une commune propose un formulaire de contact avec trois champs : Nom, Email, Message. Visuellement, les placeholders “Votre nom”, “Votre adresse email”, “Votre message” sont clairs. Dans le code, pas de <label>.

Fatou utilise NVDA pour ses démarches administratives. Elle arrive sur le formulaire. NVDA annonce : “zone de saisie”. Puis : “zone de saisie”. Puis : “zone de saisie”.

Elle ne sait pas dans quel ordre saisir les informations, ni ce qui est attendu dans chaque champ. Elle abandonne le formulaire.

Scénario 2 : Le label visible qui n’est pas associé

Un formulaire d’inscription affiche “Prénom” au-dessus de son champ. Visuellement, l’association est évidente. Dans le code, le <label> n’a pas d’attribut for, et l’<input> n’a pas d’id.

<!-- ✗ Association visuelle sans lien programmatique -->
<label>Prénom</label>
<input type="text" name="prenom">

NVDA annonce : “zone de saisie”, le label existe dans le DOM mais n’est pas associé au champ. Même conséquence qu’une absence de label.

Correction minimale :

<label for="prenom">Prénom</label>
<input type="text" id="prenom" name="prenom">

Scénario 3 : Le placeholder comme seul label, visible par les voyants

Un formulaire de don en ligne utilise des placeholders élaborés : “Montant du don (minimum 5 €)”, “Votre prénom”, “Votre email pour le reçu fiscal”. Ces placeholders disparaissent dès la saisie.

Un utilisateur âgé avec des troubles de mémorisation commence à remplir. Il saisit son montant, passe au champ suivant, le premier placeholder a disparu, il ne se souvient plus s’il a mis 50 € ou 500 €. Il doit effacer pour vérifier.

Le problème touche ici un utilisateur voyant, pas seulement les utilisateurs de lecteurs d’écran.

La règle de priorité

Quand plusieurs mécanismes sont disponibles, les utiliser dans cet ordre de priorité :

1. <label> visible associé par for/id : toujours la première option
2. <label> visible avec input imbriqué : valide, moins robuste sur certains AT anciens
3. aria-labelledby : si un texte existant dans la page peut servir de label
4. aria-label : si aucun texte visible n’est disponible ou pertinent
5. title : dernier recours, support AT inégal, à éviter

Le placeholder ne figure pas dans cette liste, il n’est jamais un substitut acceptable à un label.

Ce que le RGAA exige

Critère 11.1 : Chaque champ de formulaire a-t-il une étiquette ?

Chaque <input>, <select>, <textarea> doit avoir un label associé programmatiquement par <label for>, aria-label, aria-labelledby, ou title. La proximité visuelle seule ne suffit pas.

Critère 11.2 : Chaque étiquette associée à un champ de formulaire est-elle pertinente ?

Le label doit décrire clairement ce qui est attendu dans le champ. “Champ 1”, “Zone de saisie”, “Input”, ces valeurs existent dans le code mais ne sont pas pertinentes. Le label doit permettre à l’utilisateur de comprendre ce qu’il doit saisir, sans voir le reste de la page.