Placeholder est un attribut un peu maudit…
Déjà, pour respecter le rôle qui lui est dévolu dans HTML5, il ne doit pas être utilisé à la place d’une étiquette de champ bien balisée, comme par exemple un label.
Ensuite, pour être compatible avec l’accessibilité, il ne doit véhiculer à lui seul aucune information essentielle lors de la saisie. Il ne doit servir à donner aucune information relevant de l’étiquette du champ (caractère obligatoire, format de saisie, etc.).
Plus largement, pour ne pas être agaçant lors de la saisie, il ne doit évidemment pas avoir servi à afficher quelque-chose dont, en fait, vous pourriez avoir besoin en cours de saisie.
Prenons par exemple l’indication d’un champ obligatoire et imaginons que la classique astérisque serait dans le placeholder seulement. A priori, cela semble logique : l’utilisateur commence par voir que le champ est obligatoire, puis il attaque sa saisie en connaissance de cause. Mais en fait, non : quand on m’a soumis cette idée, mon premier réflexe a été (expérience vécue et aussi constatée ailleurs) : « mais moi, je commence à saisir machinalement dans le champ et puis, après, je me demande « au fait, c’était obligatoire, ça ? Parce que ça me casse les pieds de saisir cette info, en fait… Ah, c’était indiqué où déjà ? »
Il est tout simplement très risqué de préjuger de ce qui, pour l’utilisateur, va être utile ou pas au moment de la saisie. Il est donc beaucoup plus prudent de partir du principe que l’utilisateur, qui a souvent du mal avec les formulaires, va se poser des questions en cours de route. Fatalement au moment que vous n’aviez pas anticipé… Et donc, de ne pas se reposer sur le placeholder, d’une manière générale. Ce qui est à peu près conforme à sa définition formelle : il ne sert qu’à donner un exemple de saisie, accessoire, complémentaire aux informations essentielles données par l’étiquette qui sont, elles, disponibles en permanence.
Placeholder est bien un attribut un peu maudit : à l’affichage, il a l’air d’une solution formidable. Mais pour ne pas poser de problème, il ne doit en fait servir que quand il est quasiment inutile… 😉
6 commentaires sur “Placeholder, l’attribut maudit”
Les commentaires sont clos..
Bonjour Laurent,
Du coup, est-ce que d’un point de vue accessibilité, cette solution est meilleure pour véhiculer l’étiquette du champ en le faisant passer pour un placeholder ? http://codepen.io/chriscoyier/pen/C…
Il est vrai qu’on voit souvent des champs sans label, avec par exemple email et mot de passe.
Je suis tombé plusieurs fois sur des cas, lorsque le mot de passe n’est pas valide on me dit « le couple identifiant/mot de passe n’est pas bon ». Sauf que j’ai mis un mail, pas un identifiant/pseudo. Je me retrouve obligé de vider le champs pour relire le placeholder (ou lire le code source) et confirmer qu’il fallait bien un email ou un pseudo.
C’est toujours plus facile de penser « joli » plutôt que de penser « accessible ».
Une plaie du HTML, ce placeholder.
D’autant que d’un point de vue ergonomique, il fait souvent doublon avec les labels qui suffisent a exprimer les attentes d’un champ.
En fait, je le vois au mieux comme un attribut de confort. Dommage qu’il soit si mal utilisé ^^
@ Christophe : désolé pour la réponse un peu tardive.
Sans entrer dans le détail (on pourrait soulever le problème d’un affichage et d’un comportement déroutant par exemple pour l’utilisateur d’une loupe d’écran), pourquoi pas ?
Mais, plus généralement : pourquoi se retrouver quasiment obligé d’imposer une saisie dans une taille de caractères du coup réduite ? (il faut bien ménager de la place pour la saisie et l’étiquette là où ça n’a été prévu que pour la saisie). Est-ce vraiment un bénéfice pour l’utilisateur ?
Hum ? 😉
Bonjour,
Moi j’aime bien cette simulation du placeholder :http://codepen.io/soulrider911/pen/… 🙂
et je commence à la voir sur les sites.