Placeholder vs label : pourquoi un texte indicatif n'est pas un label, et la spec de champ à utiliser
Le texte gris dans un champ disparaît dès qu'on tape. Pourquoi un placeholder ne remplace pas un label, où placer les aides, la couleur de bordure qui passe, et la spec exacte à donner à votre développeur.
Un placeholder n'est pas un label. Il disparaît dès que l'on tape, et avec lui le seul indice sur l'utilité du champ. Mettez un vrai label au-dessus de chaque champ, les aides en dessous, une bordure visible autour, et réservez le placeholder à un exemple. Voici pourquoi, et la spec exacte.
Ce qui cloche quand le placeholder sert de label
Avant la saisie : l'air propre
✕ Après la saisie : c'était quoi ce champ ?
Le champ de gauche a l'air net, c'est pourquoi les designers l'aiment. Celui de droite est le même champ deux secondes plus tard. Le mot « E-mail » a disparu, la personne n'a plus de label à vérifier, et sur un long formulaire elle ne sait plus quelle réponse va dans quel champ.
C'est un problème de mémoire, pas de goût. La recherche de Nielsen Norman Group sur les placeholders dans les champs de formulaire a montré que le texte qui disparaît sollicite la mémoire à court terme et rend difficile la vérification des réponses avant l'envoi. Notre guide plus large sur les bonnes pratiques de design de formulaire couvre tout le formulaire ; ce papier creuse la décision qui cause le plus de problèmes.
Il y a un second problème. Le texte placeholder est gris par défaut, et ce gris est souvent trop pâle. Le gris courant #8E8E93 a un contraste d'environ 3,3 pour 1 sur blanc, sous les 4,5 pour 1 que les WCAG demandent pour du texte. Le seul indice que vous avez donné est donc aussi difficile à lire.
Correctif 1 : un vrai label, au-dessus du champ
✓ Label au-dessus : toujours là après la saisie
E-mail pro
✓ Placeholder uniquement comme exemple
Un label se place hors du champ, donc la saisie ne le touche jamais. Mettez-le au-dessus du champ, aligné à gauche, en 15 px semibold. Au-dessus vaut mieux qu'à côté car cela fonctionne à toutes les largeurs, téléphone compris, et l'œil descend le formulaire en ligne droite.
Ne cachez pas le label pour gagner de la place. Si un design n'a pas de place pour les labels, c'est le design qui a tort, pas la règle. Les labels flottants qui rétrécissent dans le coin au focus sont un compromis : ils gardent le label, mais ils sont petits, demandent un timing soigné et sont plus difficiles à rendre accessibles qu'un simple label au-dessus.
Un vrai label est aussi ce que les lecteurs d'écran annoncent. En HTML, reliez-le au champ pour que toucher le label donne le focus à l'input :
<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email"
placeholder="name@company.com" />
Correctif 2 : les aides vont sous le champ
Mot de passe
Au moins 8 caractères.
✓ Aide sous le champ : reste visible pendant la saisie
✕ Aide en placeholder : disparue dès la première touche
La chose la plus utile qu'un champ puisse dire, comme un format ou une règle, est ce dont on a besoin pendant la saisie. Elle ne peut donc pas vivre dans le placeholder, qui disparaît à la première frappe. Déplacez-la sous le champ, en 13 px dans un gris plus discret, où elle reste visible tout le temps.
Les erreurs utilisent le même emplacement. Quand quelque chose ne va pas, la ligne d'aide peut devenir le message d'erreur, ce qui garde la mise en page stable. Notre papier sur la couleur des messages d'erreur explique à quoi ce message doit ressembler.
Correctif 3 : une bordure que l'on voit
✕ Bordure #E5E5E5 : un fantôme
✓ Bordure #79747E : facile à repérer
Un champ est un contrôle, et un contrôle doit être repérable. La bordure gris fantôme à gauche est une favorite des fichiers de design, parce qu'elle paraît légère. Sur un vrai écran elle disparaît presque, et les gens ne savent pas où toucher.
La WCAG 1.4.11 demande que l'information visuelle nécessaire pour identifier un composant d'interface ait au moins 3 pour 1 de contraste avec la couleur voisine. #E5E5E5 sur blanc fait environ 1,3 pour 1, ce qui échoue. #79747E, la couleur d'outline de Material 3, fait environ 4,6 pour 1, ce qui passe confortablement. Utilisez 1,5 px pour que cela tienne aussi sur un écran de faible densité.
Notez la différence avec les séparateurs. Un gris clair comme #E5E5EA convient entre des lignes de liste, car un séparateur doit seulement être remarqué. Une bordure de champ doit être vue. Nous avons traité les gris de séparateurs et de surfaces dans la couleur de fond du mode clair.
Correctif 4 : demander le bon clavier
Un champ qui sait à quoi il sert peut ouvrir le clavier qui aide, sur iPhone comme sur Android. Un champ e-mail qui s'ouvre avec la touche @ prête économise une frappe et évite une faute à chaque caractère. En HTML, c'est un seul attribut :
| Champ | Type d'input | Ce que le téléphone ouvre |
|---|---|---|
type="email" | Clavier avec @ et . | |
| Téléphone | type="tel" | Pavé numérique |
| Site web | type="url" | Clavier avec / et .com |
| Carte ou code | inputmode="numeric" | Pavé numérique, sans spinner |
| Recherche | type="search" | Touche de recherche sur le clavier |
Associez cela à des valeurs autocomplete comme email et name, pour que le téléphone remplisse le champ lui-même.
La spec du champ
| Élément | Valeur |
|---|---|
| Label | Au-dessus du champ, 15 px, semibold |
| Champ | 48 px de haut, rayon de 12 px |
| Bordure | 1,5 px en #79747E |
| Texte | 16 px, jamais moins |
| Aide | Sous le champ, 13 px |
| Placeholder | Un exemple, ou rien |
Un texte de 16 px compte sur iPhone : Safari zoome sur la page quand on touche un champ au texte plus petit, ce qui ressemble à un bug.
.field label { font: 600 15px/1.3 system-ui; display: block; margin-bottom: 6px; }
.field input {
height: 48px;
padding: 0 14px;
font-size: 16px;
border: 1.5px solid #79747E;
border-radius: 12px;
}
.field input::placeholder { color: #8E8E93; }
.field .hint { font-size: 13px; margin-top: 6px; }
La hauteur de 48 px donne une cible tactile confortable, et le rayon de 12 px est un choix, pas une règle : alignez-vous sur votre système et gardez-le identique sur chaque champ.
FAQ
Dois-je utiliser un placeholder à la place d'un label ?
Non. Un placeholder disparaît quand on tape, et le champ perd son nom. Mettez un label visible au-dessus du champ et gardez le placeholder pour un exemple de format, ou laissez-le vide.
Le texte placeholder est-il accessible ?
Rarement par défaut. Il est souvent d'un gris clair à faible contraste, il disparaît à la saisie, et certains outils d'assistance ne le traitent pas comme un label. Un vrai label relié à l'input est le choix accessible.
Où placer le label : au-dessus ou dans le champ ?
Au-dessus, aligné à gauche. Cela marche à toutes les largeurs d'écran, reste visible pendant la saisie, et l'œil suit une ligne droite le long du formulaire.
Que mettre dans un placeholder ?
Un exemple de format, comme name@company.com, ou rien du tout. N'y mettez jamais l'instruction dont on a besoin pendant la saisie. Elle va dans une aide sous le champ.
De quelle couleur doit être la bordure d'un input ?
Assez foncée pour atteindre au moins 3 pour 1 contre la page, comme l'exige la WCAG 1.4.11. #79747E, la couleur d'outline de Material 3, fait environ 4,6 pour 1 sur blanc. Un #E5E5E5 pâle fait environ 1,3 pour 1 et échoue.
Les labels flottants règlent-ils le problème du placeholder ?
En partie. Ils gardent un label visible en le réduisant au-dessus du texte, mais la petite taille, l'animation et le travail d'accessibilité font d'un simple label au-dessus du champ le choix par défaut le plus sûr.
Sources
- Nielsen Norman Group, Placeholders in Form Fields Are Harmful (Katie Sherwin, 2014) : le texte placeholder disparaît à la saisie, sollicite la mémoire à court terme et rend les réponses difficiles à vérifier.
- WCAG 2.1, 1.4.11 Non-text Contrast (3 pour 1 pour les composants d'interface) et 1.4.3 Contrast (Minimum).
- Ratios sur blanc, calculés avec la formule de luminance relative des WCAG : #E5E5E5 1,26 pour 1, #79747E 4,55 pour 1, gris placeholder #8E8E93 3,26 pour 1. #79747E est l'Outline de Material 3 (NeutralVariant50), lu dans androidx Compose ColorLightTokens.
- MDN, l'élément input, attribut type :
type="email"affiche un clavier e-mail sur les téléphones. - Les tailles du tableau de spec (label 15 px, hauteur 48 px, rayon 12 px, aide 13 px) sont notre propre recommandation, pas une valeur de plateforme.
- D'abord publié sous forme de carrousel sur UX Brainy.
Want every form in your product to feel this easy to fill in? Our team designs and builds product UI with the field details decided once.
Get Started
