« Le texte d’un champ de formulaire ne doit pas se limiter à un texte indicatif (placeholder). » Cette exigence, formulée dans les référentiels d’accessibilité pour les formulaires, résume à elle seule l’antipattern le plus répandu sur les formulaires de contact des sites vitrines d’artisans : plombiers, électriciens, menuisiers, tous héritent souvent du même thème générique où chaque champ affiche un texte grisé du type « Votre nom » ou « Votre téléphone », sans aucune étiquette visible au-dessus.
Le problème n’est pas seulement esthétique. Il touche trois publics différents en même temps : les personnes malvoyantes qui ne distinguent pas un texte gris clair sur fond blanc, les personnes ayant des troubles de la mémoire de travail qui oublient ce qui était demandé dès que la saisie commence, et les utilisateurs de lecteurs d’écran pour lesquels un placeholder mal implémenté n’est parfois annoncé qu’une seule fois, sans rappel possible.
Ce qu’on voit sur le terrain
Le schéma se répète presque à l’identique sur des dizaines de sites de petits artisans construits à partir d’un même thème premium : un formulaire de trois ou quatre champs, chacun avec un placeholder mais aucun <label> associé. Le code ressemble typiquement à ceci :
<input type="text" name="nom" placeholder="Votre nom">
<input type="tel" name="telephone" placeholder="Votre téléphone">
<textarea name="message" placeholder="Votre message"></textarea>Visuellement, le formulaire paraît propre et minimaliste. C’est justement ce minimalisme qui pose problème : rien n’indique à quoi correspond un champ une fois qu’il contient déjà du texte, et le contraste du texte indicatif est souvent réglé bien en dessous du seuil requis pour un texte normal, car il est pensé comme un élément décoratif plutôt qu’informatif.
Pourquoi le placeholder échoue structurellement
Trois raisons techniques expliquent pourquoi le texte indicatif ne peut jamais remplacer une étiquette :
- Il disparaît dès la première frappe au clavier, alors qu’une étiquette reste visible en permanence ;
- Son contraste n’est soumis à aucune règle stricte dans les feuilles de style par défaut des navigateurs, contrairement au texte de contenu ;
- Son association avec le champ n’est pas garantie par la spécification HTML de la même manière qu’un
<label for="id">, ce qui rend son annonce par les lecteurs d’écran inconstante selon le navigateur et la technologie utilisée.
Un test simple révèle le problème en quelques secondes : effacer sa saisie sur un téléphone, se retourner, revenir cinq secondes plus tard face au formulaire déjà partiellement rempli. Sans étiquette visible, impossible de se souvenir de ce qui était demandé dans chaque champ.
Le correctif : deux options, un seul principe
Le principe reste toujours le même : une étiquette visible et associée au champ par un attribut for/id. Deux variantes existent selon la contrainte visuelle du design :
<label for="nom">Votre nom</label>
<input type="text" id="nom" name="nom">Quand le design impose visuellement l’absence d’étiquette au-dessus du champ, une classe utilitaire masque le texte visuellement tout en le conservant accessible aux technologies d’assistance :
.masque-visuellement {
position: absolute;
width: 1px;
height: 1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
}<label for="nom" class="masque-visuellement">Votre nom</label>
<input type="text" id="nom" name="nom" placeholder="Votre nom">Cette seconde version conserve le placeholder comme indice visuel complémentaire, tout en garantissant qu’une étiquette réelle existe pour tout le monde. Le point de vigilance : ne jamais utiliser display: none ou visibility: hidden pour masquer l’étiquette, ces deux propriétés la retirent aussi de l’arbre d’accessibilité, annulant tout l’intérêt de la manœuvre.
Un test rapide et fiable : si retirer le placeholder du code rend le formulaire incompréhensible, l’étiquette n’existe tout simplement pas.
Ce qu’il ne faut pas faire à la place
Certaines corrections rapides créent de nouveaux problèmes : ajouter un attribut title sur le champ ne constitue pas une étiquette fiable, car son annonce dépend du lecteur d’écran et du navigateur, et il n’apparaît généralement pas au survol tactile. De même, un texte placé juste au-dessus du champ sans lien programmatique (`for`/`id`) reste inutile pour une personne qui navigue au clavier sans repère visuel : rien ne garantit que ce texte soit associé au bon champ dans l’arbre d’accessibilité.
En résumé
Le placeholder reste un bon complément visuel pour donner un exemple de format attendu (« 06 12 34 56 78 »), jamais un substitut à l’étiquette. Sur les formulaires de contact d’artisans, corriger cet antipattern demande rarement plus de dix minutes par formulaire, pour un gain de compréhension immédiat et durable pour tous les visiteurs.
