←

→

Pré-remplir les champs textes

décembre 15th, 2008 | Réflexions

Petite question accessibilité les amis. Mains sur les buzzers !

Selon-vous, il vaut mieux pré-remplir les champs textes ? Et de quelle manière ?

Sans rien de particulier (mais un intitulé adapté)

HTML

    <p>
        <label for="courriel">Courriel</label>
        <input type="text" id="courriel" name="courriel" />
    </p>

Avec une aide à la saisie

HTML

    <p>
        <label for="courriel">Courriel</label>
        <input type="text" id="courriel" name="courriel" value="Votre courriel" />
    </p>

Avec un véritable exemple

HTML

    <p>
        <label for="courriel">Courriel</label>
        <input type="text" id="courriel" name="courriel" value="courriel@exemple.com" />
    </p>

Avec une sur-couche JS et l’utilisation du title (ici en jQuery)

HTML

    <p>
        <label for="courriel">Courriel</label>
        <input class="exemple" type="text" id="courriel" name="courriel" title="courriel@exemple.com" />
    </p>

JS

    $("input.exemple").each(function(){
        $(this).addClass("ex").val($(this).attr("title"));
        $(this).focus(function(){
            if($(this).val()==$(this).attr("title"))
                $(this).removeClass("ex").val("");
        });
        $(this).blur(function(){
            if($(this).val()=="")
                $(this).addClass("ex").val($(this).attr("title"));
        });
    });

CSS

    .ex
    {
        color:#DDD;
        background-color:inherit;
    }

J’utilise actuellement la dernière technique, qui me semble se dégrader proprement sans le support JS.

15 commentaires ↓

#1 Kerweb le 12.15.08 à 16:10

J’utilisais un préremplissage de temps à autre (notamment pour l’email). Maintenant j’ai pris l’habiture de ne plus rien remplir lorsqu’il s’agit de formulaires de contact.

En revanche pour les champs de texte de recherche, j’ai tendance à mettre des exemples (« pantalon, tshirt, … » lorsqu’il s’agit d’une boutique de fringue par exemple).

#2 Thomas le 12.15.08 à 17:34

Quand le champ est classique je troue qu’il ne vaut rien mettre (nom, prénom„ etc.).

Pour un numéro de téléphone par exemple, soit on impose une syntaxe particulière et on l’affichage à mon avis dans le label (ou à coté) soit on autorise toute sorte de syntaxe valide :) Du coup as besoin de mettre quelque chose dans le champ de texte.

Si on y met quelque chose le mieux est de le faire en JavaScript. En effet si on a désactivé JavaScript ou si on le met en dur ça fais chiez plus qu’autre chose. Ce qui est bien c’est un clic dans le champ et tout disparaît pur qu’on y mette notre texte. Mais pour faire ça, le navigateur devrait le gérer par défaut, Webkit le fait via -webkit-input-placeholder : http://hanblog.info/blog/post/2008/10/13/La-semaine-de-WebKit-5

#3 Frank Taillandier le 12.15.08 à 17:52

Utiliser l’attribut title pour ajouter de l’information supplémentaire, ça me paraît une chouette idée.

Tant que l’utilisateur n’a pas à effacer la valeur par défaut pour mettre la sienne, je n’y vois pas de problème.

#4 Stéphane Deschamps le 12.15.08 à 18:35

Rouge !

(c’est à cause de « mains sur les buzzers »)

(tu veux une vraie réponse maintenant ?)

Ça dépend.

Pour une adresse mail, vous@exemple.com est parlant et se vire avec un bout de JS, effectivement.

Pour le reste, garder un champ vide est moins déstabilisant. Les gens, quand ils cliquent sur un truc, et qu’il disparaît, ça leur fait peur. (c’est mon expérience d’observateur des usages, pas ma casquette accessibilité, attention).

La réponse officielle des WCAG1, de tête, c’était : mettre une value tant que les clients ne sauront pas faire l’association label/champ automatiquement. Or maintenant ils savent. Donc walou.

#5 Rik le 12.15.08 à 19:02

Wouhou ! On me cite !

Bah la meilleure solution me semble être utilisé l’attribut placeholder de HTML5 . Et donc son quasi-équivalent en Javascript là où ce n’est pas disponible (c’est à dire dans les moteurs moins bien que WebKit 😉 )

En plus, scool HTML5 décrit ce qu’il est cool de mettre en dedans du champ.

Pour le côté « Oh ça disparait, j’ai peur » des utilisateurs, l’utilisation d’une couleur un peu plus fade (comme le fait placeholder, comme le font les champs recherche de nos logiciels classiques) est assez commune et donc moins anxiogène.

(j’ai le droit à des points bonus pour avoir placé ce dernier mot ?)

#6 STPo le 12.15.08 à 20:37

Par une coïncidence troublante, je suis actuellement en train de monter le formulaire de contact de mon portfolio…

Je vais donc injecter via JS mon title dans chaque champ (laissé vide sans JS donc), ça a l’air de contenter tout le monde. Le coup de la couleur plus fade me plaît, je bidouillerai ça sans doute plus tard (passske là je prends du retaaaaaard).

Ca fait plaisir de revoir un peu d’activité par ici ! Ca y est ? Paris-web 2008 a fini de régner sur les blogs des geeks ? =D

#7 Rik le 12.15.08 à 22:41

Ah oui j’oubliais, le code JS a l’air bien adapté (ne vide pas le champ à chaque focus, remet l’indice que si le champ est vide). Il lui manquerait juste un ajout/enlevage de classe. Ceci pour donner la police fade (ou tout autre changement) à l’indice. Je vous invite à tester placeholder (qui marche dans Safari 3.2 et Chrome) pour mieux comprendre ce que j’explique.

#8 Vincent le 12.15.08 à 22:57

Rik,

Mis à jour : merci pour l’idée.

#9 Stéphane Deschamps le 12.16.08 à 15:22

@Rik : pas mal, anxiogène.

(ceci est ma contribution hautement constructive au débat, mais je sais que Vincent validera mon commentaire parce que quand même, on ne peut pas négliger les joueurs de Scrabble® qui nous lisent)

#10 Pierre Bertet le 12.16.08 à 16:35

Pour Unobtrusivelib (un script regroupant des comportements simples et souvent rencontrés), j’utilise très classiquement l’attribut value, ce qui est effectivement moyennement intéressant d’un point de vue utilisation lorsque Javascript n’est pas activé, puisqu’il faut l’effacer « à la main » si on utilise la souris pour cibler le champ.

D’un point de vue sémantique, l’attribut title semble plus intéressant, mais l’information est moins visible pour les navigateurs graphiques : il faut survoler un certain temps l’élément pour voir apparaître la valeur de title.

Corrigez-moi si je me trompe, mais en navigant à l’aide du clavier (sans JS, et sans aide vocale), l’information n’est plus du tout accessible avec un title, tandis qu’avec un value, le contenu est entièrement sélectionné lorsque le champ prend le focus. Dans ce cas, l’attribut value est clairement plus intéressant, puisqu’une simple pression sur une touche permet de remplacer la valeur pré-remplie par une autre.

Même chose pour les interfaces tactiles, sur lesquelles le survol n’existe évidemment pas.

Une des solutions pourrait être d’utiliser l’attribut placeholder combiné à l’attribut title en attendant, et de tester le support de placeholder pour appliquer ou non le script à l’élément. Cette méthode ne résout pas le problème de visibilité pour les navigateurs ne supportant pas encore l’attribut placeholder, c’est à dire tous les navigateurs en version stable.

Je crois que je vais rester au bon vieux value pour le moment, de manière à éviter tout comportement anxiogène.

#11 Yves Van Goethem le 12.17.08 à 13:52

Ce retrouver avec un champs pré-remplis qui ne s’efface pas … c’est un peu frustrant …

Ton dernier exemple en jQuery est très utile pour la majorité des utilisateurs.

Néanmoins, les utilisateurs sans JS, n’aurons pas d’exemple vraiment visible… L’attribut title c’est bien joli, mais quel utilisateur lambda va attendre 2sec pour voir apparaitre une petite bulle jaune avec un exemple à peine lisible ? Sans parler des utilisateurs de lecteurs d’écrans qui n’auront pas configuré la lecture de ces tooltips …

Perso je prévois des exemples derrières les inputs, avec la balise em voir kbd … et on peut toujours envisager de les manipuler en DOM…

LukeW a écrit un joli pdf reprennant de bonnes et mauvaises pratiques pour la structure de formulaires : http://www.lukew.com/ff/entry.asp?502

#12 Vincent le 12.17.08 à 16:35

Pas bête le coup du kbd tiens.

#13 Christophe C le 12.22.08 à 18:03

Il ne vaut mieux pas pré-remplir un champs texte !

Pour plusieurs raisons : - un champs rempli donne implicitement comme information à notre cerveau que l’endroit où il doit faire saisir aux doigts qqc est déjà rempli ! pas besoin de le faire … - un champs rempli se vide au moment de la prise de contrôle : ce qui est une erreur ergonomique car cela force à mémoriser le champs (sur un fraction de secondes où sur qq minutes : le concepteur du site ne peut pas savoir comment l’utilisateur va utiliser l’interface dans le temps !) - un champs saisi attire moins l’attention de l’utilisateur : il est déjà rempli :) car l’internaute sait aujourd’hui qu’un temps de saisi est rectangulaire et vide (le champs attend un texte : cf mon 1er point)

Toutes ces raisons sont liées à l’affordance des champs de saisie (merci Amélie Boucher, à sa conférence ParisWeb et à son livre)

Un champs de saisie dit à notre cerveau « saisissez ici qqc ». Pré-saisir interfère donc sur cette interaction. Et sur le plan de l’accessibilité, mieux vaut mettre l’intitulé en dehors du champs ! :)

#14 JulienW le 12.24.08 à 17:39

Ce que j’ai fait une fois, c’est de, plutôt que supprimer le texte quand on entre dans la case, sélectionner le texte. Ainsi, à la première frappe d’une touche, le texte précédent est effacé.

Après, je pense que les personnes pas habituées vont avoir tendance à effacer le texte « à la main » (genre le resélectionner, ou bien aller à la fin et faire backspace plein de fois, etc.). Mais j’ai trouvé néanmoins que c’était la meilleure solution si on voulait préremplir.

#15 Pré-remplir les champs textes (suite) — HTML Zen Garden le 10.21.09 à 13:37

[…] déterre ce vieux billet sur les champs textes car il était plein de bonnes idées dans les […]

Laisser un commentaire

Mise en forme : vous pouvez utiliser la syntaxe Markdown. Vous verrez, c’est chouette !