Un placeholder ne remplace pas un label. Voilà. C’est tout. Je n’ai rien d’autre à ajouter. C’est une déclaration évidente. Et pourtant, j’ai l’impression de visiter de plus en plus de sites qui ont la manie d’utiliser un placeholder en guise de label. Voici quelques exemples aperçus récemment (et ce sont pourtant des gens biens qui ont fait ces sites).
En avril dernier, Roger Johansson résumait très bien le problème d’ergonomie lié à une telle présentation de formulaire :
La description de l’attribut placeholder dans la spécification HTML5 est très claire :
« L’attribut placeholder ne doit pas être utilisé en tant qu’alternative à un label. »
Pourquoi pas ? C’est assez évident. Puisque chaque texte dans l’attribut placeholder est visible uniquement lorsque le champ est vide, une fois que vous avez commencé à écrire quelque chose (ou si une valeur est pré-remplie par le serveur), votre indication a disparu. Vous voulez revenir en arrière et changer quelque chose ? Vous avez intérêt à vous souvenir de ce que le faux label en placeholder disait avant que vous ne commenciez à écrire, sous peine de devoir vider le champ pour voir le label apparaître à nouveau. Et, comme je le disais avant, dans certains navigateurs, le simple fait de placer le focus sur le champ suffit à faire disparaître le placeholder. Ne pas savoir ce que vous êtes censé indiquer dans un champ, ce n’est… pas très bien.
Au delà de ce problème d’utilisabilité, il y a aussi un problème clair d’accessibilité lorsque le champ texte ne propose pas d’alternative autre que le placeholder. Chris Coyier abordait brièvement le sujet dans l’un de ses articles :
C’est tentant d’utiliser un texte en placeholder en remplacement d’un label (en particulier maintenant que certains navigateurs laissent afficher le texte jusqu’à ce qu’on commence à écrire), mais n’utilisez pas de « display:none » et ne supprimez pas les labels. J’ai récemment entendu l’histoire navrante d’une aveugle qui essayait de s’inscrire à l’université, dont le formulaire d’inscription n’avait pas de label. Elle n’avait alors aucune idée de ce qu’il fallait mettre dans les champs. Donc si vous utilisez un texte en placeholder en remplacement d’un label, utilisez une technique accessible pour masquer les labels.
Voici une liste des pour et des contre l’utilisation d’un placeholder en guise de label.
Pour :
- C’est joli, et on gagne de la place.
Contre :
- Ça diminue l’ergonomie de votre site. Même avec quelques champs, vos formulaires sont plus difficiles à utiliser. Et c’est encore pire sur mobile, où la suppression du texte d’un champs pour faire réapparaître son faux label est une tâche complexe.
- Ça réduit l’interopérabilité de votre site. Oui, ça fonctionne bien sur les machines à l’heure à laquelle vous avez développé votre site. Et oui, vous avez mis un polyfill de placeholder pour les vieux navigateurs. Mais rien ne vous garantit que ça ne fonctionnera encore sur les machines de demain, puisque ce n’est pas fait pour ça à la base.
- Ça détruit l’accessibilité de votre page. Sauf si vous prenez le temps de mettre en place une solution fiable et accessible (note : masquer les labels pour les utilisateurs qui ont JavaScript activés n’est pas une solution fiable et accessible). J’ai une astuce pour vous : une solution existe en HTML, et ça s’appelle un label.
- Ça a un impact sur le temps d’intégration, et donc le coût de votre projet.
A moins que vous ne détestiez votre métier et que vous ne détestiez les gens qui utilisent votre site web, n’utilisez pas de placeholder en remplacement d’un label.
nicolas, le
Il y a deux aspects en fait : un visuel et un technique.
Visuellement, le seul problème à mettre un label dans le champs (sans considérer la technique utilisée pour mettre le texte à l’intérieur), c’est si le texte disparait dès que le champs est en focus. Il me semble que les dernières implémentations de placeholder corrigent ce problème et ne masquent rien tant que le visiteur n’a pas commencé à écrire.
Techniquement par contre, en effet, on ne peut pas se passer des label, que l’on mette des placeholder ou non. Mais c’est presque indépendant du fait que le label soit affiché ou non dans le champs, c’est juste un style comme un autre. Il faudrait simplement réfléchir à la meilleure pratique pour mettre le label dans le champs et non à l’extérieur (que ce soit en déplaçant physiquement le label, en le masquant accessiblement puis en dupliquant son contenu dans le placeholder, ou autre, je ne sais pas encore).
Mélusine, le
Je suis intégratrice et j’ai déjà eu à intégrer des maquettes avec des formulaires de contact n’utilisant que des placeholder… Il faudrait que les graphistes changent leurs manière de faire les formulaires (tout comme mettre en forme les select et autres checkbox).
Comme dit Nicolas au dessus, il faudrait sinon essayé d’autres méthodes pour déplacer les labels…
Olivier Nourry (@OlivierNourry), le
Bonjour,
Très bonne analyse et synthèse, je plussoie allègrement.
Il y a deux autres arguments d’accessibilité/utilisabilité pour favoriser le label pur et simple, affiché à coté ou au-dessus du champ comme il devrait l’être.
D’abord, le label étant cliquable et permettant une prise de focus, le fait d’avoir un label visible, de bonne taille, agrandit la zone de clic. Ce qui est toujours appréciable pour les gens qui ont une faible dextérité (tremblement, coordination, utilisation de joystick ou autres).
Ensuite, si le label est visible, on peut l’atteindre facilement en faisant un ctrl+F, en saisissant une partie du texte du label, en naviguant dans la liste des occurrences, puis en faisant Echap une fois le label atteint. Au tab suivant, le curseur est sur le champ. Ça parait compliqué dit comme ça, mais c’est à comparer à la situation où il faut atteindre un champ précis dans une page avec 200 liens et 28 champs (site banal), juste avec tab et shift+tab. Si le label est masqué et/ou lorsque le champ a déjà été modifié, cette stratégie est mise en échec.
Donc restons simple: label visible, et voilà.
Thomas, le
Je te rajoute un super exemple : http://www.net-entreprises.fr/
Le formulaire de login n’a pas de label, juste des placeholders.
Mais les mieux, c’est qu’il n’y a pas de traitement spécifique pour le mot de passe… Donc le placeholder « mot de passe » devient « •••••••••••• » :)
iManu, le
Concernant l’accessibilité c’est évident. J’ajouterai que le label est fait pour indiquer quoi saisir dans le champs (email, téléphone, …), alors que le placeholder servira plutôt à indiquer comment saisir la donnée (boite@hebergeur.tld, 10 chiffres, …).
hk_, le
Quid des labels dans les inputs directement (visuellement, ça donne un placeholder qu’on peut styliser, dans le code il y a bien un , il est juste placé dans le via CSS), à la Dropbox ?
Xorax, le
Et bien je vais fonner un avis plus mitigé. Certes le placeholder n’est pas le top de l’accessibilité, mais qu’est ce qu’il simplifie l’intégration! Prenons un site multi-langue, avec donc des labels qui peuvent varier en largeur: vous allez devoir faire pas mal de concessions sur votre design pour éviter de devoir configurer la largeur de ces labels pour chaque langue, ou alors vous mettez une table, à défaut de pouvoir faire autrement.
Je ne suis pas un intégrateur, donc ni mon niveau ni mon enthousiasme dans le CSS ne sont bien élevé, mais j’ai déjà chercher suffisamment longtemps une solution propre, sans succès.
remi en alternance, le
Quelle est compliquée cette question, j’ai pour ma part utilisé uniquement des placeholder dans le dernier site que j’ai intégré… J’ai effectivement écrit un petit script pour que celui marche sur IE, mais je me suis posé des questions au niveau accessibilité.
Et je tombe sur votre article et deux autres en Anglais qui donnent des pistes pour faire une variante du placeholder mais accessible
– http://mentalized.net/journal/2010/08/05/dont_use_placeholder_text_as_labels/
– http://www.pardot.com/help/faqs/best-practices/placeholders-and-labels
STPo, le
Merci d’avoir cité mon site en exemple !
Alors pour ma défense, tout d’abord je plaide coupable.
Oui supprimer un label c’est mal, oui pour l’accessibilité c’est mieux qu’il soit là, etc. etc. Je sais ça depuis des années et j’ai pesté comme toi contre ceux qui le faisaient.
Maintenant concernant mon site :
– Mon site est un laboratoire, et ce n’est pas SEULEMENT un laboratoire CSS/accessibilité mais également un laboratoire design. J’ai expliqué dans le billet de blog qui parlait de ma refonte que j’avais fait un pari ergonomique osé sur les formulaires. J’assume pleinement ce parti pris et cette prise de risque, elle fait partie de ce que je voulais tenter ici et je ne l’aurais pas fait sur un site dont je ne suis pas pleinement responsable.
– L’absence de label visible n’est probablement pas le plus déroutant dans mes formulaires : reposer sur des placeholders seuls est risqué en terme de compréhension brute, car les miens sont justement… des placeholders (des « exemples ») et pas des labels injectés dans des champs comme on le voit souvent (« votre nom »). J’avais à cœur de ne pas détourner la fonction de son but premier, et de fait j’ai bien réfléchi pour trouver des intitulés qui soient suffisamment parlants (et mixtes). Je voulais voir si ça fonctionnait sur ma cible (des power-users geeks plutôt aguerris) et le fait est que oui, ça fonctionne.
Cela dit, j’ai prévu aussi des garde-fous parce que j’ai essayé de bien faire malgré le fait que je savais que c’était pas bien :
– Le fallback JS pour les vieux navigateurs a un comportement malin (en cas de champ validé vide, il retourne la valeur du placeholder, pas un champ vide, on retrouve donc le contexte).
– Le label est bien là, il est juste masqué. Je sais que pour l’accessibilité ça ne remplace pas un label visible, mais ça peut limiter la casse (en cas de CSS qui pète par exemple).
– Chaque champ de formulaire possède un attribut title qui re-précise sa nature, au survol dessus il est très facile (pour ma cible, les geeks aguerris donc) de retrouver le contexte ainsi. Et il me semble que les synthèses vocales sont capables de lire ces attributs, ou du moins certaines, ce qui limite encore la casse question accessibilité.
Vivien, le
Bonjour,
« – Le label est bien là, il est juste masqué. Je sais que pour l’accessibilité ça ne remplace pas un label visible, mais ça peut limiter la casse (en cas de CSS qui pète par exemple). »
En effet, le display: none; joue bien son rôle « de ne pas afficher un élément », le label ne sera pas retranscrit par la synthèse vocale. Ce que vous pouvez faire en revanche, c’est de déplacer les labels comme ceci :
label {
position: absolute;
left: -10000px;
top: -10000px;
}
Ceux-ci ne seront pas visible à l’œil, mais retranscrit par les lecteurs d’écran (j’ai testé avec NDVA, ça fonctionne).
Il va de soit que rien ne vaut un label présent et bien visible :)
STPo, le
@Vivien
Tu as parfaitement raison, je ne sais pas pourquoi je ne l’avais pas fait, c’est comme ça que je fais d’habitude. C’est corrigé !
Lolu, le
@Vivien
Toujours avec l’idée qu’effectivement il vaut mieux un label visible, le text-indent à -5000px est-il également retranscrit ?
C’est une méthode qu’on utilise beaucoup suite aux contraintes graphiques mais sans réellement savoir comment ils sont interprétés.