Formulaires : comment concevoir des étiquettes (labels) accessibles ?

Chaque champ doit avoir un nom accessible

Souvent appelée « label », l’étiquette d’un champ de saisie indique le type de donnée attendu par ce champ. C’est littéralement la notice d’utilisation de ce champ.

Sans elle, l’internaute ne peut remplir le formulaire correctement. C’est pourquoi il est essentiel que le type d’information attendu par chaque champ de saisie soit communiqué de manière accessible.

Les personnes aveugles ou malvoyantes ont besoin que l’étiquette soit restituée par la technologie d’assistance dont elles se servent pour lire le contenu numérique.

Par exemple, leur lecteur d’écran doit annoncer le nom du champ, pour qu’elles comprennent le type d’information à saisir dedans.

Dans ce cas, c’est le nom accessible du champ qui va être utilisé, c’est-à-dire le nom « technique » du champ, tel qu’il est défini dans le code source.

Il en est de même pour les commandes vocales dont se servent certaines personnes ayant un handicap moteur : en déplaçant, à la voix, le focus sur le champ « Prénom », la concordance entre ce qui a été vocalisé et le nom accessible doit s’effectuer.

Pour satisfaire ces différents besoins, le nom accessible doit absolument contenir l’intitulé visible du champ ; autrement, l’impact pour l’accessibilité serait très grave, pouvant aller jusqu’à rendre le formulaire inutilisable.

Si l’essentiel des précautions à prendre pour fournir un nom accessible à un champ de formulaire relèvent du code, cela a néanmoins plusieurs impacts sur la conception éditoriale, fonctionnelle et graphique de vos étiquettes de champs.

L’étiquette doit être visible

Le terme « étiquette visible » désigne le nom du champ de formulaire qui s’affiche à l’écran.

En effet, les personnes qui voient le formulaire ont besoin que cette information soit visible pour savoir ce qu’elles doivent saisir dans chaque champ.

Le cas le plus courant consiste à afficher un texte concis à proximité du champ, c’est ce qu’on appelle le « label » ou l’étiquette.

Précision sur l’étiquette des listes déroulantes

Une liste de choix (balise HTML select) est un champ de formulaire comme un autre, c’est-à-dire qu’elle aussi doit avoir une étiquette visible.

C’est une mauvaise pratique encore trop courante de considérer que la première option de la liste de choix peut constituer l’étiquette car, techniquement ce n’est pas le cas.

En effet, dès que l’utilisatrice sélectionne une option, la liste n’a plus d’étiquette visible. Si ce champ n’est pas doté d’une étiquette visible en bonne et due forme, cela constitue une non-conformité au RGAA.

Cas particulier : que faire quand il n’y a pas d’étiquette visible ?

Imaginez un champ de formulaire, sans étiquette visible, mais accompagné d’un bouton assez explicite permettant a priori aux personnes qui voient l’écran de déduire la fonction de ce champ dénué d’étiquette :

Ici, la fonction du champ est indiquée par le bouton de soumission du formulaire. Ce dernier représente une loupe, ce qui est assez explicite pour les personnes qui la perçoivent, par exemple dans le contexte d’un en-tête de site. Plus communément, il pourrait aussi s’agir également d’un bouton intitulé « Rechercher ».

Le problème, c’est que ce bouton en forme de loupe ne suffit pas aux personnes qui utilisent des technologies d’assistance comme un lecteur d’écran, et cela même en présence d’un placeholder.

En effet, chaque champ de formulaire doit avoir un nom accessible ; dans ce cas précis, nous vous recommandons d’utiliser un attribut title pertinent. Cet intitulé sera à spécifier dans vos maquettes afin que les équipes techniques puissent l’intégrer correctement.

Les dangers du placeholder

Le placeholder est un texte qui apparaît par défaut quand le champ est vide. Il est souvent utilisé pour fournir un exemple de saisie. Cependant, utiliser un placeholder n’est pas sans risque.

Le premier impact est que le placeholder n’est pas pris en compte par les technologies d’assistance (certaines le font, mais l’algorithme de calcul du nom accessible décrit par le RGAA, c’est-à-dire le nom qui sera restitué par les technologies d’assistance ne le prend pas en compte).

Ce qui signifie que si le placeholder est utilisé comme seul moyen de fournir l’étiquette du champ ou encore le format attendu, celui-ci risque tout simplement de ne pas être restitué.

Problèmes posés par le placeholder pour l’accessibilité

Voici le résumé des problèmes majeurs du placeholder en termes d’accessibilité :

• Pour les personnes déficientes visuelles (aveugles ou malvoyantes) : il n’est pas restitué de manière homogène par tous les lecteurs d’écran ;
• Pour les personnes malvoyantes : le style par défaut du placeholder n’est pas suffisamment contrasté. Bien que cela puisse être corrigé avec des styles CSS, avoir un placeholder avec un contraste correct risque paradoxalement de ne plus permettre de différencier le texte du placeholder du texte saisi par l’utilisateur. Celui-ci pourrait donc penser que le champ est déjà rempli ;
• Pour les personnes ayant un handicap intellectuel ou cognitif : un placeholder présentant un rapport de contraste élevé risque d’être difficilement distinguable du texte saisi, ce qui peut représenter un obstacle ;
• Pour les personnes ayant un trouble de la mémoire ou de la compréhension : le placeholder disparaît dès que l’utilisateur commence à saisir du contenu, ce qui le prive d’une aide précieuse.
• Si le placeholder est la seule étiquette visible, cela constitue une non-conformité au RGAA (même si les contrastes sont conformes).

Bonnes pratiques de conception avec le placeholder

Pour toutes ces raisons, n’utilisez pas uniquement un placeholder pour communiquer une aide à la saisie : demandez aussi à l’équipe technique de fournir la même information dans le nom accessible du champ.

Dans le doute, une méthode accessible sûre consiste à indiquer l’aide à la saisie dans l’étiquette du champ elle-même, plutôt que dans un placeholder :

Le placeholder peut néanmoins être utilisé pour doubler la consigne, le format ou l’exemple de saisie.

Mais, si vous l’utilisez, assurez-vous de :

• corriger son contraste ;
• demander à l’équipe technique de transmettre l’information contenue dans le placeholder par une autre méthode accessible (par exemple : attributs title ou aria-label, texte masqué hors écran, etc.).

Ayez néanmoins conscience que cela ne résoudra pas tous les problèmes d’accessibilité posés par le placeholder : par exemple, le fait que le placeholder finisse par disparaître pourra continuer à poser des problèmes aux personnes ayant des troubles de la mémoire, de l’attention, ou à des personnes ayant un handicap intellectuel, pour qui les aides à la saisie sont absolument indispensables.

Ne perdez pas non plus de vue que l’attribut title va certes afficher une infobulle au survol, mais rares sont les navigateurs à l’afficher aussi au focus, ce qui pose en soi aussi un problème d’accessibilité pour les personnes qui naviguent sans souris (notamment des personnes ayant un handicap moteur).

La conclusion de cette parenthèse sur le placeholder est qu’il n’y a pas plus simple et plus accessible que de donner toutes les informations nécessaires dans l’étiquette visible.

L’étiquette doit être accolée au champ

Par ailleurs, l’étiquette doit être accolée au champ (critère 11.4 du RGAA).

Cette notion de proximité n’est pas spécifiquement exprimée : c’est-à-dire qu’il n’y a pas de distance exacte en pixel à respecter.

L’étiquette peut être située à gauche, au dessus, à droite ou en-dessous du champ pour certains composants d’interface. La pertinence de la disposition peut dépendre de la nature du champ, par exemple les cases à cocher, les boutons radio, les « switch », et d’autres cas encore où une autre position serait légitime.

L’absence d’étiquette à proximité d’un champ va rendre le formulaire compliqué à utiliser et à comprendre pour les personnes utilisant une loupe d’écran et/ou le zoom de leur navigateur : elles ne pourraient pas afficher l’intitulé et le champ en même temps.

L’étiquette doit être pertinente

Enfin, du côté du guidage (UX writing), l’étiquette doit être pertinente (critère 11.2 du RGAA), c’est-à-dire qu’elle doit :

• être concise ;
• être précise.

En plus d’être pertinentes, les étiquettes qui se répètent doivent être constantes (critère 11.3 du RGAA).

Par exemple, ne demandez pas « l’adresse électronique » dans le formulaire d’abonnement à votre newsletter, et « le courriel » dans le formulaire de contact.

Conclusion de la première partie

Les étiquettes de champs sont un élément essentiel d’un formulaire web.

Les erreurs d’accessibilité peuvent être nombreuses, même sur les interfaces les plus simples. C’est pourquoi le RGAA exige que les étiquettes de champ respectent plusieurs règle. Chaque étiquette doit être :

• visible ;
• accolée au champ qu’elle décrit ;
• pertinente ;
• contenue dans le nom accessible.

Attention aussi à certaines pratiques de design en vogue : ce n’est pas parce qu’elles sont répandues, qu’elles sont forcément conformes au RGAA, comme l’exemple du placeholder le démontre.

Si vous concevez des formulaires plus complexes, prenez le temps d’échanger en amont avec l’équipe technique chargée de leur développement : ainsi, vous vous assurerez d’avoir toutes les spécifications nécessaires pour concevoir des composants accessibles.

Car nous le verrons dans le prochain article de cette série : l’intégration technique des étiquettes requiert autant d’attention que leur conception.