Les étiquettes de vos champs de formulaire décrivent-elles précisément ce qui est attendu ?
Critère officiel 11.2 — Chaque étiquette associée à un champ de formulaire est-elle pertinente (hors cas particuliers) ?
Pourquoi c'est important
Une étiquette vague comme « Nom » laisse le doute : faut-il saisir le nom de famille, le prénom, ou les deux ? Une étiquette imprécise multiplie les erreurs de saisie — particulièrement préjudiciables pour les personnes ayant des troubles cognitifs, de la mémoire, ou remplissant un formulaire administratif pour la première fois.
Exemples concrets
Ce qui est conforme
Le formulaire de demande d'acte d'état civil distingue « Nom de naissance (tel qu'il figure sur l'acte) » et « Prénom(s) dans l'ordre de l'état civil ». Chaque étiquette dit exactement ce qui est attendu et évite les erreurs de saisie.
Ce qui pose problème
Le même formulaire utilise uniquement « Nom » et « Prénom ». Des usagers saisissent leur nom marital au lieu du nom de naissance et reçoivent une réponse négative sans comprendre pourquoi leur demande a été rejetée.
Comment agir
Pour chaque champ, posez-vous la question : si l'utilisateur ne lit que l'étiquette, sait-il exactement quoi saisir ? Complétez les étiquettes vagues avec une indication entre parenthèses : « Date de naissance (JJ/MM/AAAA) », « Téléphone (numéro direct, sans espace) ». Transmettez ces intitulés précis à votre prestataire lors de la conception ou la mise à jour des formulaires.
Règles clés
- Le label doit décrire précisément ce que le champ attend : 'Adresse e-mail' plutôt que 'Email', 'Numéro de téléphone (format : 06 XX XX XX XX)' si le format est contraint.
- Le nom accessible (calculé par le navigateur via le <label>, aria-label ou aria-labelledby) doit contenir les mots du label visible — sinon violation de 2.5.3.
- Si plusieurs champs ont des fonctions similaires (téléphone principal, téléphone secondaire), les labels doivent les distinguer explicitement.
- Le format attendu peut être intégré au label ou précisé via aria-describedby sur le champ.
Erreurs fréquentes
- Labels génériques : 'Champ', 'Entrée', 'Info', 'Réponse'
- Label qui ne précise pas le format attendu quand il est ambigu ('Date' sans préciser jj/mm/aaaa)
- Label visible 'Prénom' mais aria-label='first-name' — violation de 2.5.3
- Même label pour deux champs différents dans le même formulaire
- Label pertinent mais tronqué visuellement par le design — le texte complet doit être accessible programmatiquement
Exemples de code
label générique
✗ Non conforme<label for="f1">Info :</label>
<input type="text" id="f1">'Info' ne dit pas à l'utilisateur ce qu'il doit saisir. Exemple réel de formulaire de contact mal rédigé.
label précis avec format
✓ Conforme<label for="telephone">
Numéro de téléphone
</label>
<input type="tel" id="telephone"
aria-describedby="tel-format"
autocomplete="tel">
<p id="tel-format" class="hint">
Format : 06 XX XX XX XX ou +33 6 XX XX XX XX
</p>Label clair. Le format attendu est fourni via aria-describedby — il complète le label sans l'alourdir. autocomplete="tel" facilite le remplissage automatique.
incohérence label visible / nom ARIA
✗ Non conforme<label for="fn">Prénom</label>
<input type="text" id="fn"
aria-label="first-name">Le label visible dit 'Prénom' mais aria-label écrase le nom accessible avec 'first-name'. Un utilisateur de commande vocale qui dit 'Prénom' n'activera pas le champ. Violation de 2.5.3.
nom ARIA cohérent avec le label visible
✓ Conforme<label for="fn">Prénom</label>
<input type="text" id="fn"
autocomplete="given-name">Le label for/id est suffisant. aria-label n'est pas nécessaire ici — il serait redondant et risquerait de créer une incohérence. autocomplete="given-name" pour la complétion automatique.
Référence WCAG : 2.4.6, 2.5.3, 3.3.2