Les étiquettes de formulaire

Une zone de texte à côté du mot « Email » n'est pas étiquetée tant que l'élément label ne lui est pas relié ; jusque-là, un lecteur d'écran peut se contenter de dire « texte modifiable ».

Chaque champ a besoin d'un nom

Quand le focus arrive sur un champ de formulaire, un lecteur d'écran annonce son étiquette, son type et son état : « Email, texte modifiable, obligatoire ». L'étiquette vient d'un élément label relié au champ. Il y a deux façons de les relier. Donne à l'input un id et à l'étiquette un for correspondant, ou place l'input à l'intérieur de l'étiquette. Dans les deux cas, cliquer sur le texte de l'étiquette place aussi le focus dans le champ, ce qui rend les petites cases à cocher et les boutons radio bien plus faciles à atteindre.

<label for="email">Email</label>
<input id="email" type="email" autocomplete="email">

<label>
  <input type="checkbox" name="news"> Send me the weekly menu
</label>

Le critère de succès 3.3.2 Étiquettes ou instructions des WCAG 2.2, de niveau A, demande des étiquettes ou des instructions dès qu'un contenu demande une saisie, et le critère 1.3.1 Information et relations demande que le lien entre étiquette et champ existe dans le code, pas seulement à l'écran. Un paragraphe qui se trouve au-dessus d'un input n'en est proche que visuellement ; rien n'indique aux technologies d'assistance que les deux vont ensemble.

Un texte indicatif n'est pas une étiquette

L'attribut placeholder affiche un texte indicatif gris dans un champ vide. On est tenté de l'utiliser à la place d'une étiquette, et beaucoup de formulaires d'inscription le font. Le problème, c'est qu'il disparaît dès qu'on tape : on ne peut plus vérifier à quoi servait le champ, et il est en général assez pâle pour échouer aux règles de contraste de l'unité précédente. Utilise une étiquette visible et, si tu veux, un placeholder avec une valeur d'exemple en plus.

Groupes, finalité et erreurs

Les boutons radio et les cases à cocher liées ont aussi besoin d'une étiquette de groupe. Entoure-les d'un fieldset et mets la question dans son legend : un lecteur d'écran dit alors « Size, groupe » avant « Small, bouton radio, 1 sur 3 ». Pour les données personnelles, l'attribut autocomplete indique au navigateur à quoi sert un champ, avec des noms du standard HTML comme name, email, tel, new-password et one-time-code. Le critère 1.3.5 Identifier la finalité des champs, de niveau AA, demande exactement cela, car cela permet aux navigateurs de remplir les champs et à certains outils d'afficher des icônes familières à côté.

Quand quelque chose ne va pas, dis-le avec des mots. Le critère 3.3.1 Identification des erreurs demande qu'une erreur de saisie soit identifiée et décrite à l'utilisateur sous forme de texte, et pas seulement en passant la bordure au rouge. Les WCAG 2.2 ont aussi ajouté le critère 3.3.7 Saisie redondante : une information qu'une personne a déjà saisie dans le même processus doit être remplie de nouveau pour elle ou proposée à la sélection, au lieu d'être tapée deux fois. Et le critère 3.3.8 Authentification accessible (minimum), de niveau AA, dit qu'une étape de connexion ne doit pas dépendre du fait de mémoriser ou de recopier quelque chose, sauf si une aide est disponible ; laisser les gestionnaires de mots de passe remplir le champ et autoriser le collage comptent tous deux comme une aide.

Dire ce qu'il faut avant que les gens commencent

Les instructions se placent avant les champs qu'elles décrivent, pas dans un message d'erreur après un échec. Si un mot de passe doit faire au moins 15 caractères, dis-le à côté de l'étiquette. Signale les champs obligatoires dans le texte de l'étiquette, par exemple avec le mot « obligatoire », et ajoute l'attribut required pour que le navigateur l'annonce aussi. Quand un message d'erreur apparaît, garde-le à côté de son champ et relie les deux avec aria-describedby pointant vers l'id du message ; le lecteur d'écran lit alors le message quand le champ reçoit le focus. Enfin, place le focus sur le premier champ en erreur, ou sur un récapitulatif des erreurs en haut, pour qu'un utilisateur du clavier ne reste pas au bas d'un long formulaire à se demander ce qui s'est passé.