`placeholder` et accessibilité

Publié le 26 novembre 2015 par Équipe Atalan

L’attribut placeholder a le vent en poupe depuis quelque temps maintenant.

Malheureusement, il est souvent utilisé à mauvais escient : en remplacement d’une réelle étiquette de formulaire (balise <label>, par exemple) ou pour présenter des aides à la saisie importantes.

Dans cet article, je vous propose entre autres d’étudier ensemble :

Son principe et son comportement.
Dans quels cas il ne doit pas être utilisé et pour quelles raisons.
Dans quels cas il peut être utilisé.
Comment accentuer sa couleur (insuffisamment contrastée par défaut).
La technique du placeholder « simulé ».

Principe et comportements du `placeholder`

Le placeholder est un attribut permettant d’afficher du texte par défaut dans certains champs de formulaire.

Il peut par exemple s’intégrer dans les balises suivantes :

<input type="text" />.
<input type="email" />.
<textarea>.

Concrètement, il se présente sous cette forme :

Le texte du placeholder s’efface dès lors que l’utilisateur commence à saisir du contenu dans le champ en question.

Dans quels cas ne pas utiliser `placeholder` ?

En matière d’accessibilité et de manière générale, il est important de réserver cet attribut pour présenter des informations non nécessaires à la compréhension des données à saisir dans les champs de formulaire.

Autrement dit, les informations intégrées dans cet attribut ne doivent pas être indispensables.

Dans les faits, placeholder ne doit pas être utilisé :

En remplacement d’une réelle étiquette de formulaire (balise <label> ou attributs aria-labelledby, aria-label ou encore title).
Pour afficher des aides à la saisie nécessaires à la compréhension des données attendues.

Exemples d’usages incorrects

Dans cet exemple incorrect, l’attribut placeholder remplace une réelle étiquette de champs de formulaire.

Votre email
Dans ce mauvais exemple, l’attribut placeholder est utilisé pour informer du caractère obligatoire du champ.

Votre date de naissance
Dans ce dernier exemple incorrect, l’attribut placeholder est utilisé pour afficher un format de donnée attendu.

Les raisons

La mauvaise utilisation du placeholder peut notamment entraîner les problèmes d’accessibilité et d’ergonomie suivants :

Certaines personnes déficientes cognitives (en particulier les personnes ayant des troubles de la mémoire) peuvent rencontrer des difficultés à retenir le texte du placeholder une fois celui-ci effacé.
Le contenu de l’attribut placeholder n’est pas restitué par tous les couples navigateurs/lecteurs d’écran (synthèse vocale et/ou plage braille). Par conséquent, les personnes aveugles ou malvoyantes utilisant ce type d’aide technique peuvent ne pas disposer de l’information.
Le contenu du placeholder peut laisser penser à l’utilisateur que le champ est déjà renseigné, engendrant ainsi des erreurs de validation une fois le formulaire envoyé. Toutefois, pour cet écueil, il est envisageable de distinguer visuellement les textes du placeholder des textes réellement renseignés (par de la mise en gras ou en italique, par exemple).
La couleur par défaut du texte du placeholder n’est pas suffisamment contrastée sur certains navigateurs (au regard des attentes des référentiels d’accessibilité). Par conséquent, entre autres, les personnes malvoyantes peuvent rencontrer des difficultés pour les lire. Il est cependant possible d’y remédier. Je reviendrai d’ailleurs sur ce point un peu plus bas dans cet article (partie « Le contraste du placeholder »).

Quand utiliser `placeholder` ?

L’attribut placeholder peut être utilisé pour présenter des aides à la saisie secondaires/facultatives (non indispensables à la compréhension des informations à saisir).

Exemples d’usages corrects

Concrètement, cet attribut peut par exemple convenir pour les cas suivants :

Dans cet exemple de champ de recherche, la mention « Saisissez vos mots-clés » intégrée dans l’attribut placeholder n’est pas nécessaire pour comprendre la fonction du champ. Ici, son usage est donc approprié.

(À noter que l’attribut aria-label renseigné avec le texte « Votre recherche » fait office d’étiquette.)

Votre sport préféré
Dans ce cas de figure, les exemples de sport affichés dans l’attribut placeholder ne sont pas indispensables à la bonne saisie du champ.

Astuce

Une technique pour savoir si placeholder peut convenir pour afficher du texte peut consister à se demander si en son absence, il est toujours possible de renseigner correctement le champ (sans faire d’erreur).

Le contraste du `placeholder`

Sur certains navigateurs (Chrome 46, par exemple), la couleur par défaut du texte du placeholder n’est pas suffisamment contrastée au regard des attentes des référentiels d’accessibilité (WCAG, RGAA, etc.), que le texte soit petit ou grand.

Pour plus de précisions à ce sujet, je vous invite à consulter la fiche du projet AcceDe Web suivante : Assurer un contraste suffisant entre les textes et l’arrière-plan ou proposer une alternative contrastée.

Toutefois, il est possible d’accentuer sa couleur en passant par une « surcharge » CSS via notamment les préfixes constructeurs suivants :

::-webkit-input-placeholder.
::-moz-placeholder.
:-ms-input-placeholder.

Concrètement, par exemple, pour accentuer le contraste du placeholder de vos <input type="text" /> sous Chrome, il s’agira d’écrire dans votre CSS :

input[type=text]::-webkit-input-placeholder {
   color: #767676;
}

À noter que le gris #767676 est le premier gris sur blanc permettant d’atteindre les ratios attendus.

La technique du `placeholder` « simulé »

Une des raisons du succès du placeholder provient très certainement du fait qu’il permet de gagner de l’espace dans les interfaces. Point particulièrement intéressant sur mobile.

Une technique permet de concilier cela avec l’accessibilité et l’ergonomie.
Il s’agit de passer par des placeholder dits « simulés ».

Cela consiste à utiliser une balise <label> se superposant visuellement au champ et se déplaçant une fois le focus en son sein.

Vous trouverez plusieurs exemples de ce comportement dans les démonstrations suivantes :

Cette pratique permet de pallier à l’ensemble des risques évoqués plus haut dans cet article (dans la partie « Les raisons »).

À noter qu’elle est également :

Fonctionnelle au clavier seul.
Accessible avec un lecteur d’écran (testé avec NVDA , VoiceOver ou encore ChromeVox).

Attention, certains des scripts listés ci-dessus ne sont pas compatibles avec les outils de navigateurs (natifs ou extensions) de remplissage automatique des formulaires.

Il est toutefois possible d’y remédier en les modifiant quelque peu.

Ressources complémentaires

Pour terminer, je vous propose ci-après quelques ressources complémentaires au sujet de l’attribut placeholder sur lesquelles je me suis appuyé pour la rédaction de ce billet :

Pour pouvez également retrouver la plupart de ces ressources sur notre liste publiée sur GitHub sous la thématique « placeholder ».

Vos commentaires

Par levy, le 2 décembre 2015 à 12:44.

Merci Johan pour cet excellent article qui je n’en doute pas sera une précieuse ressource pour nombre de professionnels

Juste un mot sur l’aspect conforme mais pas accessible.

Le fait est que malheureusement lui comme d’autres se retrouvent parfois contraints de trouver la solution là moins pire malgré que nous nous battions tous pour faire le plus accessible possible.

De plus, les solutions proposées dans l’article ne sont pas pires qu’un champ avec un title sans label visible (problème pour les utilisateurs de zoom, problème pour les utilisateur navigation clavier) ou un champ avec label masqué lisible juste par un lecteur d’écran (problème pour les voyants/utilisateurs clavier/zoom), techniques qui sont conformes, largement utilisées mais tout aussi imparfaites que le faux placeholder où d’autres solutions de compromis.

Ces situations de compromis existent pour de multiples raisons (graphique, ergo, contractuel, planning, budget, support des aides techniques, etc). Elles s’imposent malheureusement à nous et je te rejoins sur le fait qu’il me semble préférable d’essayer d’être pragmatique et constructif en proposant des solutions surtout quand au final cela ne génère pas de blocage dans l’utilisation du site (typiquement dans le cas du placeholder mal utilisé pour spécifier un format, un message d’erreur bien fait permet de récupérer le coup).

Répondre
Par Matthieu Faure, le 27 novembre 2015 à 13:02.

Merci Johan pour ce billet, c’est toujours plaisant de lire un beau travail de synthèse.

Une question/complément. Dans « Les raisons », tu dis « Le contenu de l’attribut placeholder n’est pas restitué par tous les couples navigateurs/lecteurs d’écran « .

Pour terminer l’argumentation et satisfaire ma curiosité, serait-il possible d’avoir un tel exemple ?

Merci d’avance !

Répondre
- Par Johan Ramon, le 2 décembre 2015 à 11:04.
  
  Bonjour Matthieu,
  
  Merci pour ton commentaire !
  
  Concernant la restitution du placeholder par les lecteurs d’écran, par exemple, NVDA (2015.4) couplé avec Firefox (42) en mode formulaire :
  
  placeholder seul est restitué.
  
  title + placeholder sont tous les deux restitués.
  
  aria-label + placeholder : seul le premier est restitué.
  
  <label> + placeholder : seul le contenu du <label> est restitué.
  
  ChromeVox (45) ne le restitue pas non plus à tous les coups.
  Son support est en revanche bon avec VoiceOver (iOS 9.1).
  
  Bonne journée. :)
  Johan
  
  Répondre
Par Jean-Pierre Villain (@villainjp), le 26 novembre 2015 à 12:37.

Bonjour

« En matière d’accessibilité et de manière générale, il est important de réserver cet attribut pour présenter des informations non nécessaires à la compréhension des données à saisir dans les champs de formulaire. »

Citation très savoureuse en contradiction avec la spécification :

« The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief description of the expected format. »

Ce qu’on appelle en accessibilité des aides à la saisie.

Il faut lire attentivement l’alerte associée que je résume de cette manière : si vous voulez produire des formulaires accessibles n’utilisez pas placeholder.

Le premier exemple est incomplet : tel que présenté le placeholder fait office de relais « visible » à un label masqué, mais comme il va disparaitre à la saisie, au moment de l’action, plus de label visible. L’exemple serait plus acceptable en association avec un bouton très pertinent.

Sur le second exemple nous avons effectivement des valeurs qui, de prime abord, pourraient paraitre inutiles.

Mais dans ce cas pourquoi les afficher ?
Car si on les affichent parce qu’elles pourraient servir à quelques un ce sont des aides à la saisie du coup.

Ou bien, effectivement, elles ne servent à rien ce qui pose d’intéressantes questions sur l’argumentation ergonomique de l’utilisation de placeholder.

Placeholder à l’origine a été créé comme une simple feature par Safari pour simplifier la vie des développeurs qui avaient la très mauvaise habitude de mettre des valeurs par défaut, effacées à la prise de focus. Les plus vieux d’entre-nous se souviennent sans doute du dur combat que nous avons mené à ce sujet.

Les solution qui se répandent comme une trainée de poudre sont tout aussi savoureuses puisqu’il s’agit d’utiliser des labels dont on diminue sciemment l’accessibilité.

Feature inutile et mal fagotée pour geek en mal d’effets spectaculaires serait une meilleur approche à mon avis pour qualifier les solutions proposées.

« Mais c’est conforme » murmure le choeur des devs anxieux face à la pression du client en mal d’ergonomie de bazard.

Oui, tu n’a rien gagné en place, tu fais sauter des trucs et des bidules au visage de ton utilisateur, tu a considérablement diminué l’accessibilité par défaut des labels…

Mais t’es conforme mec !

L’honneur est sauf.

Répondre
- Par Johan Ramon, le 27 novembre 2015 à 16:38.
  
  Bonjour,
  
  Si vous voulez produire des formulaires accessibles n’utilisez pas placeholder.
  
  Nous ne sommes pas d’accord. Cf. exemple ci-après dans lequel le contenu du placeholder (« Où habitez-vous ? ») n’est qu’une simple reformulation de l’étiquette « Votre lieu d’habitation ».
  
  Votre lieu d’habitation
  
  Ce champ est donc parfaitement accessible même avec l’usage d’un placeholder.
  
  Mais dans ce cas pourquoi les afficher ?
  
  Pour de l’esthétisme par exemple (de l’ordre du subjectif).
  
  Les solution qui se répandent comme une trainée de poudre sont tout aussi savoureuses puisqu’il s’agit d’utiliser des labels dont on diminue sciemment l’accessibilité.
  
  Nous ne voyons pas en quoi les placeholder « simulés » correctement codés nuisent à l’accessibilité.
  
  Le seul tout léger argument en leur défaveur peut être qu’on réduit la zone d’activation des champs en question. Sachant qu’on est pas sur des boutons radio et/ou des cases à cocher.
  
  Feature inutile et mal fagotée pour geek en mal d’effets spectaculaires serait une meilleur approche à mon avis pour qualifier les solutions proposées.
  
  « Mais c’est conforme » murmure le choeur des devs anxieux face à la pression du client en mal d’ergonomie de bazard.
  
  Qu’on le veuille ou non c’est une tendance. Il faut composer avec et proposer des solutions.
  
  Plutôt que de les rejeter sans faire avancer le sujet.
  
  Oui, tu n’a rien gagné en place.
  
  Si si, certains font vraiment gagner de la place.
  Celui-ci par exemple Floated Labels! (à imaginer sur une interface mobile).
  
  Enfin, sinon, effectivement, sorti de son contexte, mon premier exemple est incomplet. J’ai ajouté un bouton « Rechercher ».
  
  Nous voilà accessibles ; et, cerise sur le gâteau, conformes. :)
  
  Répondre
  - Par Jean-Pierre Villain (@villainjp), le 27 novembre 2015 à 19:05.
    
    Mon commentaire n’était pas destiné à critiquer ton travail, c’est un très bon travail mais à taquiner un peut les arguments.
    
    Une petite dernière pour la route.
    
    Pas super chaud pour l’exemple avec « votre lieu d’habitation » qui pourrait attendre un truc comme « maison » ou « appartement ». C’est déjà plus clair avec le placeholder « Où habitez-vous ? » qui laisse supposer une adresse, quoique hum pas sur… ?
    
    Je ne dis pas que placeholder ne sert à rien, je dis juste que pour l’accessibilité c’est le pire truc qu’on ai inventé depuis longtemps.
    
    La remarque sur le gain de place est en écho avec l’argumentation très évolutive autour de placeholder.
    
    Au début on à essayé de nous le vendre comme support d’aide la saisie, bon…
    Maintenant les arguments sont le gain de place et la simplification de l’interface.
    
    Qu’est ce qui fait gagner de la place sur l’exemple floated labels ? Le fait que le label est à cheval sur la bordure du champ. Pas besoin de simuler un placeholder pour ça.
    L’autre argument est la simplification de l’interface. Je ne suis pas ergonome ou UX, je peux juste dire que je trouve ça un chouia plus complexe que si on implémentait les labels directement à cheval sur la bordure du champ.
    
    Après je n’ai rien contre ce genre de dispositif pour fashion victim, en fait d’ailleurs pour être parfaitement honnête je m’en contrefiche.
    
    Mon âge avancé me donne l’avantage d’avoir beaucoup de recul face aux geekeries qui traversent le web.
    
    On se souvient tous, la larme à l’oeil des nuages de tags ou plus exotiques et moins connus les « moteurs de résultats », un truc super rigolo.
    
    Je classe les labels sautillants, entre-choquants, giclants ou glissants dans la même veine.
    
    Pour la diminution de l’accessibilité du label, je laisse chacun se faire une opinion sur les démos linkées.
    
    Je rejette les placeholders mais ton papier aussi et heureusement puisque tu suggère essentiellement de ne pas les utiliser.
    
    Bon sauf pour des raisons ma foi très étranges d’esthétisme, mouais…
    
    Oui, le sujet avance, passer de dispositifs d’aide à la saisie à un truc vaguement esthétique c’est plutôt une bonne nouvelle.