Chaque champ de formulaire doit avoir un libellé, qu’il soit visible ou non

Publié le 15 janvier 2024

À retenir

⚠️ L’absence de libellés pour les champs d’entrée des formulaires est l’un des problèmes d’accessibilité les plus courants sur le web
Les libellés sont nécessaires pour que les lecteurs d’écran et les autres appareils d’assistance puissent identifier correctement les éléments d’un formulaire
Les designers devraient annoter leurs designs pour s’assurer que leurs collègues et d’autres intervenants puissent savoir qu’il y a du travail à effectuer, même s’il n’y a pas de résultat visuel
Pour corriger ce type de problème, une collaboration entre designers et rédacteurs est nécessaire

Cet article fait partie d’une série sur les micro-interactions avec les interfaces utilisateur et la manière dont elles affectent l’expérience utilisateur.

This article is also available in English.

Sans s’en rendre compte, la plupart des activités que les utilisateurs effectuent sur un site web consiste à remplir des formulaires. Cependant, ces formulaires n’ont pas besoin d’être linéaires ni d’être remplis de cases à cocher.

Chaque fois que des utilisateurs saisissent des données dans un champ ou qu’ils font un choix parmi un groupe d’options, ils interagissent avec un formulaire. Comme je l’ai défini dans un autre article, les formulaires sont essentiellement une interface permettant de recueillir des informations de la part des utilisateurs et de faire suivre ces informations envoyer à un autre système.

Tout comme pour les boutons, les utilisateurs de lecteurs d’écran ont besoin d’éléments correctement libellés pour pouvoir interagir avec les formulaires. Par contre, lors de la conception de formulaires, cette partie est souvent oubliée.

Voyons quelques modèles de design de composants de formulaires afin d’identifier les cas où ces omissions se produisent et de déterminer comment améliorer ces designs.

Cet article est une introduction pour porter à l’attention des créateurs de contenu — rédacteurs, concepteurs, développeurs et, également, gestionnaires de projets de toutes sortes — la nécessité de libeller les éléments de formulaire.

Consultez la section « Références et lectures additionnelles » pour des liens vers des articles de fond sur le sujet.

Exemples

Champs d’entrée de texte

Un champ d'entrée de courriel et un champ d'entrée de mot de passe — Un champ d’entrée de courriel et un champ d’entrée de mot de passe

Le champ d’entrée de texte, qu’il s’agisse de texte visible ou masqué, doit avoir un libellé. L’exemple ci-dessus montre deux champs texte avec chacun un libellé visible.

Un formulaire d'inscription avec un titre, un paragraphe de lorem ipsum, un champ d'entrée de texte sans libellé et un bouton «S'inscrire». — Exemple d’un champ d’entrée de texte sans libellé visible

L’exemple ci-dessus est un exemple que vu fréquemment : un formulaire contenant un seul champ d’entrée de texte et un bouton pour soumettre le formulaire. Grâce au contexte et au paragraphe, les utilisateurs voyants peuvent déduire ce qu’ils doivent saisir dans ce champ.

Un formulaire d'inscription avec un titre, un paragraphe de lorem ipsum, un champ d'entrée de texte annoté pour indiquer le libellé — Exemple d’un champ d’entrée de texte sans libellé visible, mais annoté pour indiquer le libellé

Contrairement aux utilisateurs voyants, les utilisateurs malvoyants et les utilisateurs de lecteurs d’écran ne consultent pas nécessairement le contenu d’une page web de manière linéaire. Ils peuvent naviguer grâce à une liste de points de repère (landmarks) et de composants sans contexte. Dans ce type de navigation, le paragraphe qui aide les utilisateurs voyants n’est pas lié au formulaire, et le contexte est perdu.

Les utilisateurs de lecteurs d’écran dépendent du fait que chaque élément du formulaire doit être correctement libellé dans le code pour comprendre leur utilisation.

Un bon moyen pour les designers d’identifier un libellé qui n’est pas visible est d’ajouter une annotation dans leurs designs. Il existe de nombreux moyens et outils pour ce faire, mais comment créer ces annotation n’est pas le sujet de cet article.

Ces annotations servent à indiquer clairement aux rédacteurs qu’ils doivent envisager de créer un libellé et aux développeurs qu’ils doivent s’assurer d’implémenter le libellé dans le code. Le fait de disposer d’une trace visuelle de ces annotations aide également les gestionnaires de projet à mieux comprendre qu’ils doivent allouer du temps à la réalisation de ce travail.

Groupes de boutons radio

Un formulaire avec un champ de texte, un groupe de boutons radio sans libellé et un bouton pour soumettre le formulaire — Exemple de groupe de boutons radio sans libellé visible

Les groupes de boutons radio sont généralement bien compris par les voyants et ne nécessitent pas toujours un libellé visible.

Un formulaire avec un champ de texte, un groupe de boutons radio, une annotation pour le libellé et un bouton pour soumettre le formulaire — Exemple d’un groupe de boutons radio sans libellé visible, mais annoté pour indiquer le libellé

Pour des raisons d’accessibilité, ces éléments doivent être accompagnés d’un libellé. En fait, un groupe de boutons radio est regroupé dans ce que l’on appelle un ensemble de champs (<fieldset>). Un ensemble de champs a un libellé : c’est ce qu’on appelle une légende (<legend>).

Comme pour les champs de texte, il est préférable de les identifier par des annotations dans les designs.

Notez qu’un bouton radio ne peut jamais être seul ; le libellé identifie donc toujours l’ensemble du groupe.

Groupes de cases à cocher

Les cases à cocher sont très similaires aux boutons radio, mais elles diffèrent principalement par le fait que si un seul bouton radio peut être sélectionné à la fois, en contrepartie, plusieurs cases à cocher peuvent être sélectionnées en même temps.

Dans ce cas également, le groupe a besoin d’un libellé, ce qui se fait de la même manière que pour les groupes de boutons radio : avec un <fieldset> et son <legend>.

Une seule case à cocher est un modèle de design acceptable. Dans ce cas, il ne sera pas nécessaire d’utiliser le modèle <fieldset> et <legend>, puisque le texte de la case à cocher est un libellé.

Menus déroulants

Un formulaire avec un menu déroulant sans libellé, un champ de texte et un bouton pour soumettre le formulaire — Exemple d’un menu déroulant sans libellé visible

L’utilisation de menus déroulants est un autre modèle de design qui permet aux utilisateurs de faire un choix à partir d’une liste d’options multiples.

Dans certains cas, les designers ont choisi d’utiliser la première option d’une liste de menus déroulants au lieu d’utiliser un libellé. Ce modèle de design peut poser des problèmes aux utilisateurs, car une fois qu’ils ont fait un choix, ils pourraient ne plus se souvenir du sujet de la liste. Cette confusion pourrait être plus grande pour les gens qui utilisent des appareils d’assistance, car ce modèle de design les oblige à parcourir toute la liste si le menu n’a pas de libellé.

Un formulaire avec un menu déroulant annoté pour indiquer le libellé, un champ de texte et un bouton pour soumettre le formulaire — Exemple de menu déroulant sans libellé visible, mais avec une annotation visible

Évitez à vos utilisateurs d’être désorientés : assurez-vous d’annoter vos designs et incluez un libellé pour les menus de sélection de vos formulaires, que ces libellés soient visibles ou non.

D’autres composants peuvent également nécessiter des libellés.

Ces quelques exemples ne constituent pas une liste exhaustive, mais ce sont ceux pour lesquels j’ai constaté le plus souvent l’absence de libellé dans les designs, dans les textes et dans le code.

Lorsque vous utilisez d’autres composants que ceux listés plus haut, ou que vous en créez de nouveaux pour vos designs, assurez-vous de vous renseigner sur les requis d’accessibilité pour le type de composant en question.

« Pourquoi les designers devraient-ils faire tout cela ? »

Lorsque l’on présente de meilleures pratiques à ses coéquipiers, il est fréquent de se heurter à de la résistance, parce que ces modèles de design détaillés peuvent en fait représenter du travail supplémentaire pour eux.

Les designers doivent veiller à documenter leur travail avec des mots également. Les artefacts de conception sont des outils qui permettent au designers de communiquer avec leurs collègues, et non pas des vérités évidentes à transmettre depuis une tour d’ivoire.

« Ne pourrais-je pas utiliser un texte de suggestion à la place ? »

Le texte de suggestion (placeholder text) est un texte à l’intérieur d’un champ, destiné à donner un aperçu de ce qui est attendu dans ce champ. Dès que l’utilisateur place son curseur sur le champ, le texte de suggestion disparaît, ce qui le rend inutile.

En plus, les lecteurs d’écran ne peuvent pas convertir le texte de suggestion en libellé.

Ce modèle de design témoigne de l’intention d’un designer voyant de sa mauvaise compréhension d’un composant pour le transformer en un autre. De nombreux articles recommandent d’éviter complètement le texte de suggestion.

« Je ne connais pas tous ces détails techniques »

Les designers ne devraient pas chercher à se soustraire à leurs obligations parce qu’ils ne savent pas comment procéder du premier coup. Le travail d’un designer n’est pas de décorer des wireframes ou des sites web, mais plutôt de s’assurer que les gens puissent interagir correctement avec des produits numériques.

Les designers devraient se réjouir de l’occasion qui leur est donnée d’apprendre plus de détails sur le travail qu’ils conçoivent. Il s’agit également d’une opportunité pour s’assurer de travailler en collaboration avec leurs collègues techniques.

« Ne serait-ce pas aux développeurs de le faire ? »

De nombreux problèmes d’accessibilité rencontrés dans le cadre d’un projet pourraient être évités dès la phase de conception. Se décharger simplement de la responsabilité sur d’autres coéquipiers est une autre échappatoire que les designers devraient éviter.

Comme illustré plus haut dans cet article, les annotations dans les designs améliorent la clarté de la compréhension pour les développeurs, mais aussi pour les rédacteurs et, dans une certaine mesure, pour les autres intervenants. Si le travail à effectuer est visible, davantage de collègues comprendront pourquoi le travail ne peut pas se terminer instantanément.

Références et lectures additionnelles

Mis à jour le 4 mars 2024