7.1. Utiliser la balise <label>
ainsi que les attributs for
et id
pour étiqueter les champs avec intitulé visible
Pour étiqueter les champs disposant d’un intitulé visible :
- Utiliser
<label>
pour baliser chaque intitulé. - Ajouter un attribut
for
dans chaque balise<label>
ainsi qu’un attributid
dans chaque champ. - Renseigner avec une valeur unique et identique les attributs
for
etid
de chaque couple intitulé/champ.
<label for="nom">Votre nom</label> <input type="text" id="nom" name="nom" autocomplete="family-name" />
<label for="pays">Votre pays</label> <select id="pays" name="pays" autocomplete="country-name"> <option value="belgique">Belgique</option> <option value="france">France</option> […] </select>
Remarque
Il est important de prévoir des intitulés identiques pour les champs dont la fonction est identique.
Par exemple, si plusieurs formulaires d’identification sont présents dans le site, ne pas utiliser l’intitulé « Identifiant » pour l’un et « Login » pour l’autre.
3 commentaires
-
Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.
Bonjour,
Beaucoup de plugins en WordPress génèrent le code suivant :
<label>Votre nom <input type="text" name="nom" /></label>
qui ne respecte pas les critères du RGAA puisque
for
etid
ne sont pas spécifiés. Mais si on écoute ce code avec NVDA, JAWS et VoiceOver, l’étiquette est vocalisée car le champ est dans la balise<label>
.
Le code de ces plugins est souvent figé sans possibilité propre de le modifier. C’est le cas du plugin ContactForm 7 pour les boutons radio et checkbox.
Est-ce que l’on peut le garder ainsi, en expliquant dans une page « accessibilité » par exemple que les étiquettes sont vocalisées malgré la non validation du critère 11.1 ?Qu’en pensez-vous ?
-
Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.
Bonjour Claire,
Merci pour ton commentaire.
Effectivement, le test 11.1.2 du RGAA impose que les balises
<label>
intègrent un attributfor
reprenant la valeur de l’attributid
de leur champ correspondant.Toutefois et sauf erreur de ma part, toutes les combinaisons « modernes » de lecteur d’écran / navigateur (celles de la base de référence du RGAA, entre-autres) restituent bien les labels implicites (champ de formulaire directement intégré au sein de la balise
<label>
). Même sans attributfor
.(De mémoire, à l’époque, les labels implicites sans attribut
for
posaient des problèmes de restitution seulement avec la combinaison Internet Explorer 6 / Jaws.)Par conséquent, je vois deux options pour ton cas de figure :
- Soit passer par un script JS de surcharge qui viendra ajouter au chargement de la page les attributs
for
correctement renseignés dans les balises<label>
. Mais je t’avoue que cette solution me paraît un peu lourde en vue de simplement valider un critère (pour de la conformité). - Soit, comme tu le mentionnes, indiquer ce léger manque dans une page « Accessibilité ». Perso, c’est ce que je ferais. ;)
Johan
- Soit passer par un script JS de surcharge qui viendra ajouter au chargement de la page les attributs
-
-
Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.
Excellent article! Je ne suis pas programmeur, mais j’ai parfaitement compris les explications. Merci.