Le label d’un champ désactivé n’est pas désactivé
C’est une erreur que je rencontre fréquemment : vouloir mettre un label en état « disabled » lorsqu’il accompagne un champ lui même « disabled ». No no José. No se Bueno !
Je ne vous lance pas la pierre, j’ai pu être tenté de le faire par le passé. Sauf que lorsque l’on travaille sur un Design System, chaque choix doit suivre une logique, certaines convictions sont remises en question, les standards et référentiels font foi, et après de nombreuses recherches, j’ai réalisé que je me trompais.
Un champ peut être désactivé, il n’y a aucun doute, mais qu’en est-il de son label ?
À cette question, on me répond souvent : « Mais Hugo, puisque l’utilisateur ne peut rien faire avec le champ, alors son label n’a pas besoin d’être lu, et d’un point de vue UX ça lui permet d’identifier les champs qui sont justement désactivés ».
C’est vrai que ça part d’une bonne intention et que la réflexion n’est pas mauvaise, mais c’est une erreur. Je ne vais pas vous donner mon avis subjectif sur la question, nous allons plutôt regarder ce qu’en dit le RGAA et le WHATWG.
Problème d’accessibilité
Depuis mon passage chez EDF, notamment aux côtés de Vincent PERRIER-PERRERY, il m’est impossible de concevoir la moindre interface sans chercher à être 100% raccord avec le RGAA. C’est une obligation légale pour certains de mes clients, en réalité ça devrait être une obligation morale pour tout designer.
Au delà de permettre la création d’interfaces inclusives, les règles d’accessibilité nous aident aussi à savoir ce que l’on peut (doit ?) faire ou non. Regardons le RGAA :
Critère 3.2 : « Dans chaque page web, le contraste entre la couleur du texte et la couleur de son arrière-plan est-il suffisamment élevé (hors cas particuliers) ? ».
Dans les cas particuliers on retrouve : « Le texte ou l’image de texte fait partie d’un élément d’interface sur lequel aucune action n’est possible (par exemple un bouton avec l’attribut disabled). ».Critère 3.3 : « Dans chaque page web, les couleurs utilisées dans les composants d’interface ou les éléments graphiques porteurs d’informations sont-elles suffisamment contrastées (hors cas particuliers) ? ».
Ici aussi, dans les cas particuliers : « Composant d’interface inactif (par exemple, un bouton avec un attribut disabled) sur lequel aucune action n’est possible ».
Ces critères ne s’appliquent donc pas à un composant d’interface comme un champ de formulaire qui peut être « disabled », ils font exception. Et c’est vrai qu’en toute logique on pourrait se dire : « Un label accompagne un champ, et ce champ est désactivé, alors le label l’est aussi, il ne répond pas lui non plus à ces critères ».
Et que dit le RGAA au sujet du label ? Rien du tout. Et ça n’est pas un oubli, un label n’est pas un composant d’interface, il ne permet pas à l’utilisateur de communiquer avec la machine. C’est une étiquette, un texte, il est donc traité comme tel et on se doit de respecter les règles d’accessibilité et de contraste comme tout autre label ou simple texte, il ne fait pas exception.
Un label HTML n’a pas d’attribut « disabled »
Et quand bien même il y aurait un doute sur le référentiel d’accessibilité ou que vous ne voudriez simplement pas le suivre, on peut aussi regarder du côté du WHATWG (Web Hypertexte Application Working Group) quels sont les attributs de l’élément <label>.
Documentation WHATWG du label, dans les attributs on retrouve :
Global attributes -> Comprenez tous les attributs que l’on retrouve par défaut sur chaque élément HTML (title, style, …)
for -> Associe le label à un contrôle de formulaire.
Et c’est tout ! Pas de « disabled » comme sur un contrôle.
Serait-ce un oubli du WHATWG ? Le meilleur Design System que vous trouverez et dont vous devez vous inspirer est celui du web natif (HTML & CSS). Il est incroyablement bien pensé et documenté. Chaque élément répond à une logique précise. Et même si vous faites du mobile natif, le référentiel du web reste votre meilleur guide sur les bonnes pratiques à suivre. Un label n’est pas désactivé, c’est le champ auquel il est rattaché qui l’est.
Et l’UX ?
Reste la question de l’UX, c’est vrai. On pourrait se dire que ces référentiels se trompent, qu’ils n’ont pas assez pensé à l’utilisateur qui aimerait identifier dans son formulaire les éléments désactivés. Que si le label d’un champ désactivé est affiché comme les autres alors il sera difficile pour lui de s’y retrouver.
Un champ désactivé EST une information pour votre utilisateur. Sinon il ne serait simplement pas affiché. Votre utilisateur doit donc quoi qu’il arrive pouvoir lire le label qui l’accompagne. Inutile de chercher à réinventer la roue, il n’y a aucun besoin réel à vouloir le rendre moins visible, seulement de mauvaises inspirations.
C’est aussi quelque chose que je vois fréquemment : Les designers s’inspirent beaucoup du travail des autres, et encore plus quand il s’agit de belles références. Gardez l’esprit critique, ne suivez pas toujours la masse, et servez-vous des référentiels comme argument pour ne pas faire leurs erreurs et vous démarquer.
Ce que vous pouvez faire
Si malgré tout cela votre souhait serait de pouvoir rendre différenciants ces labels dans vos formulaire tout en respectant les référentiels et standards, vous avez toujours ces possibilités :
Utiliser un contraste légèrement plus clair, mais qui respecte bien le minimum de ratio 4.5:1 entre le label et son fond. Pour l’avoir expérimenté, ça fonctionne bien sur les labels qui accompagnent une Checkbox ou un Radio Button dans un groupe. C’est léger et tous les utilisateurs ne verront pas ce détail, mais pour d’autres ça peut améliorer leur perception de ces éléments désactivés.
L’italic pourrait aussi aider. Je n’irais pas le conseiller, je préfère le garder pour les placeholders car ça aide à les différencier de la valeur d’un champ, mais ça reste une option qui respecte les référentiels.
Il n’y a donc plus de doute à avoir désormais quand vous concevrez vos champs de formulaire : chaque label doit rester accessible, en toute situation. Amusez-vous si vous le souhaitez avec leur style je ne saurais dire si c’est réellement une bonne idée, mais veillez à ce que ceux-ci suivent les règles d’accessibilité et les standards pour une meilleure inclusivité et moins de travail pour vos devs.
Si ce post vous a plu, n’oubliez pas de laisser un like et un petit commentaire, ça aidera à lui donner de la visibilité et je suis curieux que vous me partagiez votre expérience à ce sujet !