Des formulaires web que les gens envoient vraiment

Un formulaire est l'endroit où le visiteur cesse de lire et commence à agir : s'inscrire au congrès, renouveler son adhésion, demander une subvention, poser une question.

Tous ces visiteurs ont déjà décidé d'agir. Quand ils partent sans envoyer, c'est le formulaire qui les en a dissuadés.

Ce guide couvre les choix qui font la différence, dans l'ordre où le visiteur les rencontre. Chaque section comporte un exemple fonctionnel dans lequel vous pouvez écrire. Les exemples tournent dans votre navigateur et n'envoient rien, et chaque bonne pratique de ce guide fonctionne aussi sur les formulaires de ce site.

Pourquoi un seul guide désormais. Il a commencé comme une série en huit parties. Nous l'avons réuni sur une seule page avec des exemples en direct, parce qu'on apprend davantage sur un formulaire en le remplissant qu'en lisant à son sujet.

C'est le premier de nos articles à recevoir ce traitement. Nous reprenons tout ce que nous avons publié pour le rendre plus court, plus facile à parcourir et plus concret.

Vous voulez d'abord voir les erreurs ? La page des versions cassées propose des formulaires en direct qui échouent exprès.

Chaque champ a besoin d'un libellé visible

Un libellé se trouve hors du champ et y reste. Un placeholder se trouve dans le champ et disparaît dès que l'on écrit.

Les formulaires qui utilisent des placeholders comme libellés ont l'air calmes sur une maquette, le seul moment où quelqu'un les voit vides. Une fois remplis, les questions ont disparu :

• Le visiteur qui relit ses réponses avant d'envoyer n'a rien à quoi les comparer.
• Celui qu'un appel interrompt revient devant des cases qui ne disent plus ce qu'elles sont.
• Le remplissage automatique remplit tous les champs d'un coup, et la vérification devient tout le travail du visiteur. Essayez-le sur l'exemple ci-dessous : les libellés restent, donc vérifier prend un coup d'œil.

Les placeholders ont encore un rôle : montrer le format d'une réponse. Le libellé demande « Téléphone » et le placeholder montre (555) 012-3456. Quand l'exemple disparaît, le visiteur n'en a plus besoin.

Pour les personnes qui utilisent un lecteur d'écran, un libellé associé à son champ dans le code est annoncé quand le champ reçoit le focus. L'annonce d'un placeholder dépend du lecteur d'écran, et il n'a jamais été conçu comme le nom du champ.

Pour les organismes et institutions publics, un libellé visible est aussi une exigence de la norme d'accessibilité qui s'impose à eux, et les responsables des achats publics le vérifient.

Ne comptez pas sur un outil automatique pour repérer ce problème. Les règles que lancent la plupart des outils acceptent un placeholder comme nom de champ, si bien qu'un formulaire à placeholders seuls peut réussir l'analyse. Nous avons vérifié : la version cassée de ce formulaire réussit les mêmes règles automatiques qui signalent son menu et son bouton d'envoi.

Des libellés flottants bien construits

Un libellé flottant commence dans le champ, là où serait un placeholder. Il passe au-dessus du champ quand le visiteur y entre ou tape une réponse.

Il fait gagner une ligne de hauteur sur un long formulaire, et il peut être bien fait. Bien fait signifie trois choses :

• C'est un vrai libellé associé au champ, annoncé comme n'importe quel autre.
• Il reste lisible dans les deux positions, avec un contraste complet, jamais estompé au gris d'un placeholder.
• Il s'écarte avant que le texte du visiteur puisse le toucher.

La plupart des libellés flottants décident de flotter en posant une seule question : le champ est-il vide ? L'astuce CSS habituelle vérifie si le placeholder est visible.

Cette question reçoit la mauvaise réponse dès qu'un masque de saisie entre en jeu.

Quand un masque de saisie remplit le champ

Un masque de saisie met en forme la réponse pendant la frappe : un numéro devient (703) 555-0142, une date devient 10/11/2026.

Les masques aident, jusqu'à ce que leurs caractères soient écrits dans le champ avant que quiconque ne tape. Le champ n'est alors jamais vide, et trois choses cassent :

• Un libellé flottant voit (___) ___-____, conclut qu'il y a une réponse, et saute au chargement de la page ou reste posé sur le masque.
• La validation du formulaire voit du texte et peut laisser passer un numéro vide.
• Un lecteur d'écran lit les tirets bas à voix haute.

Comment construire un masque qui fonctionne :

• Comptez les chiffres, pas les caractères. Le champ est vide tant qu'il ne contient aucun chiffre. La ponctuation ajoutée par le masque n'est jamais une réponse.
• N'affichez le modèle que lorsque le champ a le focus, derrière le texte du visiteur et hors de la valeur. Le libellé flotte d'abord, donc rien ne se chevauche.
• Acceptez tous les formats. Quelqu'un colle 703.555.0142 ou le tape avec des espaces. Gardez les chiffres et mettez-les en forme vous-même.
• Laissez le curseur là où le visiteur l'a mis. Un masque qui renvoie le curseur à la fin transforme chaque correction en ressaisie.
• Laissez passer les numéros internationaux. Un + au début doit désactiver le masque américain. Un masque trop strict est la raison pour laquelle les gens de l'étranger ne peuvent pas s'inscrire.
• Enregistrez les chiffres, pas le texte mis en forme. L'enregistrement doit contenir 7035550142, pour que la recherche, le dédoublonnage et le système suivant s'accordent sur le numéro.

Demandez le bon clavier

Sur un téléphone, le type du champ décide quel clavier apparaît :

• Un champ e-mail met @ sur le premier écran.
• Un champ téléphone ouvre un pavé numérique.
• Un champ texte générique donne au visiteur le clavier complet pour tout, et il fouille les écrans de symboles pour taper une adresse.

<input type="email" autocomplete="email" autocapitalize="off" spellcheck="false">
<input type="tel" autocomplete="tel">
<input inputmode="numeric" autocomplete="postal-code">
<input inputmode="decimal">

Les mêmes attributs alimentent le remplissage automatique. Quand les champs disent ce qu'ils contiennent (nom, e-mail, organisation, code postal), le navigateur propose de les remplir, et la partie la plus lente d'un formulaire mobile devient un seul geste.

Les claviers de téléphone mettent aussi une majuscule à la première lettre et corrigent les mots qu'ils ne connaissent pas. C'est utile dans un message. Dans une adresse e-mail ou un numéro de référence, cela change la réponse sans prévenir : désactivez donc les majuscules automatiques et la correction pour les champs qui contiennent des identifiants.

La taille compte autant que le clavier :

• Donnez aux zones tactiles au moins 44 pixels de haut.
• Associez le libellé de chaque case à cocher, pour que le texte soit lui aussi cliquable.
• Gardez le texte des champs à 16 pixels ou plus. En dessous, l'iPhone zoome sur le champ et laisse la page agrandie une fois la saisie terminée.

Des erreurs qui disent comment corriger la réponse

Quand une vérification échoue, le formulaire sait quel champ a échoué et quelle règle n'est pas respectée. « Saisie invalide » jette cette information.

Un message utile nomme le champ, dit ce qui ne va pas et montre une réponse correcte : « Saisissez un numéro américain à 10 chiffres avec l'indicatif régional, par exemple 555-012-3456. »

Le moment compte aussi. Un formulaire qui vérifie à chaque touche déclare une adresse e-mail invalide pendant tout le temps où on la tape. Vérifiez quand le visiteur quitte le champ, c'est-à-dire quand la réponse devrait être terminée.

Une fois un champ signalé, vérifiez-le pendant la frappe, pour que le message disparaisse dès que la réponse est corrigée. Ensuite :

• Placez chaque message à côté de son champ, là où le visiteur regarde déjà.
• À l'envoi, listez tous les problèmes en haut avec un lien vers chaque champ, et placez le focus sur cette liste.
• Ne comptez jamais sur la couleur seule. Une bordure rouge est invisible pour certaines personnes daltoniennes et pour tous les lecteurs d'écran. Des mots, une icône et une bordure plus épaisse portent le message.
• Associez le message au champ dans le code, pour qu'il soit annoncé quand le champ reçoit le focus.
• Ne videz jamais un champ à cause d'une erreur ailleurs. Une faute dans le téléphone n'est pas une raison d'effacer le message.

Repérer les fautes dans l'adresse e-mail sans bloquer personne

Quelqu'un tape gamil.com au lieu de gmail.com. L'adresse est bien formée, donc tous les validateurs l'acceptent.

Votre réponse, votre reçu ou votre confirmation d'inscription ne vont nulle part. Du côté du visiteur, il vous a écrit et vous n'avez jamais répondu.

Quelques pour cent des adresses tapées à la main contiennent une faute, et les plus courantes sont prévisibles. Quand le visiteur quitte le champ :

• Comparez l'adresse à une courte liste de fautes connues.
• Expliquez la suggestion et proposez une correction en un geste.
• Laissez le visiteur garder ce qu'il a tapé. Les adresses inhabituelles existent, et le dernier mot revient toujours au visiteur.

Montrez chaque état du bouton d'envoi

Un bouton d'envoi doit au visiteur quatre états :

• Au repos, il invite au clic.
• En cours, il montre que le clic a été reçu. Le bouton change de texte et se désactive, pour qu'un second clic nerveux n'envoie pas le formulaire deux fois.
• Échec explique ce qui s'est passé, près du bouton, pendant que chaque champ garde ce que le visiteur a saisi.
• Terminé remplace le formulaire par une confirmation qui dit ce qui a été reçu et ce qui suit. Cette confirmation est annoncée aux lecteurs d'écran en plus d'être affichée.

Soignez surtout l'échec. Si le formulaire garde les mots du visiteur, une connexion perdue coûte un clic de plus. S'il les perd, très peu de gens réécrivent un long message de mémoire. Activez l'échec simulé ci-dessus et appuyez sur envoyer.

Construisez un vrai formulaire sous le script. Si le script ne se charge pas sur le réseau strict d'un bureau, le formulaire doit quand même s'envoyer de la manière classique et afficher une page de confirmation simple.

Quand une requête expire, dites que le résultat est inconnu. Afficher un succès que vous ne pouvez pas confirmer mène à des excuses pour des messages jamais arrivés.

Découpez les longs formulaires en étapes

Une demande de subvention ou une inscription à un événement peut compter trente questions. Sur une seule page, la barre de défilement annonce au visiteur tout le travail qui l'attend avant même de commencer.

Découpé en étapes, le même formulaire demande quelques minutes à la fois. Voici ce qui fait fonctionner les étapes :

• Un seul sujet par étape.
• Un indicateur de progression qui dit vrai : « Étape 2 sur 3 », jamais une barre qui saute de 20 à 90 %.
• Vérifiez chaque étape avant de continuer, pour que les problèmes apparaissent tant que les questions sont fraîches.
• Revenir en arrière ne fait rien perdre. Le visiteur qui revient corriger une date retrouve toutes les réponses suivantes là où il les a laissées.
• Terminez par un écran de relecture qui montre chaque réponse avec un moyen de la modifier, avant l'envoi final.
• Placez le focus sur le titre de la nouvelle étape, pour que les utilisateurs de lecteur d'écran entendent où ils sont.
• Entrée fait avancer d'une étape. Elle ne doit jamais envoyer un formulaire à moitié rempli.

Enregistrez les réponses pour qu'on puisse revenir

Peu de gens terminent un long formulaire d'une traite. Il leur faut un chiffre du service financier, une lettre de recommandation, l'accord d'un collègue. Un formulaire qui oublie tout à la fermeture de l'onglet les oblige à tout recommencer, et beaucoup ne le feront pas.

Il y a deux façons d'enregistrer les réponses. Quelle que soit la vôtre, dites-le : « Enregistré sur cet appareil » à côté du formulaire suffit.

Pour un formulaire court ou anonyme, gardez les réponses dans le navigateur du visiteur pendant qu'il écrit, comme le fait l'exemple en plusieurs étapes ci-dessus. Rechargez cette page et vos réponses reviennent.

• Rien ne quitte l'appareil, et aucun compte n'est nécessaire.
• Un bouton « Effacer mes réponses » permet de les supprimer sur un ordinateur partagé.
• N'enregistrez jamais de mots de passe, de données de paiement ni rien de sensible dans le navigateur.

Pour une longue candidature, enregistrez des brouillons sur le serveur et envoyez au visiteur un lien pour reprendre. Protégez ce lien :

• Envoyez-le uniquement à l'adresse saisie dans le formulaire.
• Faites-le expirer.
• Limitez le nombre de demandes par visiteur. Sinon, la case de reprise devient un moyen d'envoyer vos e-mails à des inconnus.

Fonds sombres : prévenez le navigateur

Votre CSS met en forme la boîte, la bordure et le texte d'un champ. Le navigateur et le système d'exploitation dessinent le reste : la flèche d'un menu, la liste qui s'ouvre dessous, le calendrier d'un champ date, la coche d'une case.

Ils supposent une page claire, sauf si vous dites le contraire. Sur un pied de page sombre avec une inscription à la lettre d'information, cela peut donner une flèche gris foncé sur un menu presque noir, qui se lit comme un simple rectangle.

Une déclaration CSS règle le problème. Réglez color-scheme sur dark pour la zone sombre, et le navigateur redessine sa part de chaque contrôle pour s'y accorder.

.site-footer {
  background: #11141a;
  color-scheme: dark;
}

Vérifiez ensuite ce que color-scheme ne couvre pas, de préférence sur un système d'exploitation que votre équipe n'utilise pas, en mode clair et en mode sombre :

• Le remplissage automatique colore les champs remplis en jaune ou en bleu pâle, ce qui rend le texte blanc illisible.
• Le gris des placeholders est choisi pour les fonds blancs.
• Un anneau de focus évident sur blanc peut disparaître sur noir.

Bloquez le spam sans casse-tête

Un CAPTCHA transforme votre problème de spam en corvée pour le visiteur. Il pèse le plus sur les personnes malvoyantes, lentes de la main ou qui utilisent un lecteur d'écran.

La plupart du spam de formulaire est automatique et négligent, donc trois vérifications que le visiteur ne voit jamais en arrêtent presque tout :

• Un pot de miel : un champ supplémentaire caché aux personnes et aux lecteurs d'écran. Les robots remplissent tous les champs, donc un pot de miel rempli signale l'envoi comme spam.
• Un minuteur : personne ne remplit un formulaire de contact deux secondes après le chargement de la page.
• Une limite de fréquence : trente envois par minute depuis une même adresse ne sont pas trente personnes.

Ce qui passe ces vérifications a été tapé par une personne. Signalez-le pour relecture au lieu de le bloquer, pour qu'un faux positif ne fasse jamais perdre un vrai message.

Montrez à chacun la même confirmation, pour que l'opérateur d'un robot n'apprenne rien de la réponse.

Ce qui se passe après le bouton

Personne ne remplit un formulaire pour voir un écran de confirmation. On veut une réponse, et tout ce qui se trouve entre envoyé et répondu est un second système qui échoue plus souvent que n'importe quel bouton.

Le montage courant est un formulaire qui envoie un e-mail à une seule boîte, et cet e-mail est la seule copie. Si un filtre antispam l'intercepte, ou si le destinataire a changé de poste au printemps dernier, la demande disparaît sans laisser de trace.

Enregistrez d'abord, prévenez ensuite.

Veillez ensuite à ce que les notifications continuent d'arriver :

• Envoyez-les depuis votre propre domaine authentifié, avec l'adresse du visiteur en réponse, pour qu'elles passent les contrôles qu'imposent les fournisseurs de messagerie.
• Confiez l'acheminement du formulaire à une personne nommée, et revoyez-le à chaque changement de poste.
• Surveillez le silence. Un formulaire qui recevait cinq envois par semaine et n'en a reçu aucun depuis trois semaines est cassé, même si toutes les pages se chargent.
• Programmez un envoi de test qui parcourt toute la chaîne, du formulaire jusqu'à la boîte que l'équipe lit. Il repère ce que la surveillance de disponibilité ne voit pas.

Essayez les versions cassées

Lire qu'un placeholder disparaît n'est pas la même chose que remplir un formulaire et s'y perdre.

La page des versions cassées propose des formulaires en direct avec les erreurs contre lesquelles ce guide met en garde. Chacun est expliqué avant de commencer, et chacun renvoie à sa version corrigée ici.

Pourquoi une page à part. Nous exigeons de chaque page de LFW.com un score parfait aux vérifications automatiques d'accessibilité, et le site est analysé chaque nuit. Des formulaires qui échouent exprès enfreindraient cette règle sur le guide lui-même.

Les échecs vivent donc sur une seule page, et chacun est excusé avec précision : une règle, sur un élément, sur cette seule page. Tout autre échec sur cette page déclenche toujours une alerte, et la page garde son score réel, plus bas. Elle est aussi exclue des résultats de recherche.

Si vous voulez savoir où en sont vos propres formulaires, l'audit gratuit vérifie les champs de votre page d'accueil : libellés, contraste et les autres règles automatiques d'accessibilité.

Nous concevons et corrigeons aussi des formulaires pour les organisations dont le site web est sous WordPress. Parlez-nous de vos formulaires.