Chaque champ de vos formulaires possède-t-il une étiquette visible en permanence — pas uniquement un texte d'exemple qui disparaît à la saisie ?
Critère officiel 11.1 — Chaque champ de formulaire a-t-il une étiquette ?
Pourquoi c'est important
Le texte d'exemple (placeholder) qui apparaît dans un champ vide disparaît dès que l'utilisateur commence à taper. Une personne âgée, stressée ou ayant des troubles cognitifs peut oublier ce qu'elle devait saisir avant même d'avoir fini de le remplir — sans aucune indication visible pour se remémorer.
Exemples concrets
Ce qui est conforme
Le formulaire d'inscription aux activités périscolaires affiche l'étiquette « Prénom de l'enfant » en permanence au-dessus du champ de saisie. Elle reste visible avant, pendant et après la saisie. Le champ contient en plus un texte d'exemple en gris clair à titre indicatif.
Ce qui pose problème
Le même formulaire affiche « Prénom de l'enfant » uniquement à l'intérieur du champ, en gris. Dès que la personne commence à taper, ce texte disparaît. Une personne âgée qui saisit lentement ne sait plus si elle est dans le champ du prénom ou du nom.
Comment agir
Dans WordPress, si vous utilisez un plugin de formulaire (Contact Form 7, Gravity Forms, WPForms), assurez-vous que chaque champ possède une étiquette affichée au-dessus ou à côté du champ — pas seulement un placeholder. La plupart des plugins proposent un champ « Étiquette » distinct du « Texte d'exemple » : utilisez les deux, jamais l'un en lieu de l'autre.
Règles clés
- Méthode 1 (recommandée) : <label for="id-du-champ"> avec l'attribut id correspondant sur <input>.
- Méthode 2 : <label> englobant directement le <input> (label implicite).
- aria-label ou aria-labelledby sont des alternatives valides mais le label visible doit être cohérent avec le nom accessible (critère 11.2 + 2.5.3).
- Le placeholder n'est pas un label — il peut compléter un label mais jamais le remplacer.
- Pour les groupes de champs liés (radio, checkbox) : utiliser <fieldset> + <legend> (critères 11.5 et 11.6).
- Le label doit rester visible en permanence — même quand le champ est rempli ou actif.
Erreurs fréquentes
- Placeholder seul utilisé comme étiquette (disparaît à la saisie, contraste souvent insuffisant)
- Label visuellement présent mais non lié programmatiquement au champ (for/id manquant ou non correspondant)
- aria-label sur le champ mais son contenu ne correspond pas au label visible (violation 2.5.3)
- Label commun pour plusieurs champs distincts
- Bouton submit sans intitulé explicite (critère 11.9)
- Champs générés dynamiquement sans label associé (frequent avec les form builders CMS)
- Label vide (<label></label> ou <label for='id'></label>) qui écrase le title : l'attribut title est ignoré car <label> a la priorité dans la hiérarchie de calcul du nom accessible, laissant le champ sans nom accessible | Utilisation de title seul comme étiquette, approche non fiable, beaucoup de technologies d'assistance(AT) ne traitent pas title comme un label valide
Exemples de code
placeholder seul
✗ Non conforme<input type="email" placeholder="Votre adresse e-mail">Le placeholder disparaît à la saisie. Un utilisateur qui vérifie ses saisies perd la référence. Les AT l'annoncent mais de façon incohérente selon les navigateurs.
label associé avec for/id
✓ Conforme<label for="email">Adresse e-mail</label>
<input
type="email"
id="email"
name="email"
autocomplete="email"
placeholder="ex. : prenom@domaine.fr"
>Le label est visible en permanence. L'association for/id est explicite. Le placeholder est un exemple de format, pas le label — il complète sans remplacer.
label visuellement lié mais non associé
✗ Non conforme<p>Votre message</p>
<textarea name="message"></textarea>Visuellement, le <p> fait office d'étiquette. Programmatiquement, il n'y a aucune relation entre le texte et le champ. Le lecteur d'écran annoncera le textarea sans nom.
label visuellement lié mais non associé
✓ Conforme<label for="message">Votre message</label>
<textarea id="message" name="message"></textarea>La relation programmatique est établie via for/id. Le lecteur d'écran annoncera « Votre message, zone de texte ».
label implicite (englobant)
✓ Conforme<label>
Accepter les conditions d'utilisation
<input type="checkbox" name="cgu">
</label>Le label implicite (englobant) est valide. L'association est programmatique même sans for/id.
aria-label incohérent avec le label visible
✗ Non conforme<label for="search">Recherche</label>
<input
type="search"
id="search"
aria-label="Barre de recherche principale"
>Le label visible dit 'Recherche' mais aria-label dit 'Barre de recherche principale'. Pour les utilisateurs de commande vocale, dire 'Recherche' n'activera pas le champ. Violation de 2.5.3.
aria-label cohérent avec le label visible
✓ Conforme<!-- Si on veut enrichir le nom accessible sans changer le label visible -->
<label for="search">Recherche</label>
<input
type="search"
id="search"
aria-label="Recherche dans le catalogue"
>
<!-- Mieux : aria-describedby pour les infos supplémentaires -->
<label for="search2">Recherche</label>
<input
type="search"
id="search2"
aria-describedby="search-hint"
>
<p id="search-hint" class="text-sm">Recherchez par titre, auteur ou ISBN</p>Si le label visible doit rester court, utiliser aria-describedby pour les informations complémentaires plutôt qu'aria-label qui remplace le nom accessible.
Référence WCAG : 1.3.1, 2.4.6, 3.3.2, 4.1.2