Formulaire de contact : aider le visiteur jusqu’à la confirmation

Un visiteur rédige sa demande, clique sur le bouton d’envoi et revient devant le même formulaire. Doit-il corriger quelque chose, patienter ou recommencer ? Cette hésitation mérite autant d’attention que la présentation de la page. Un formulaire de contact doit permettre de comprendre ce qui est demandé, de réparer une erreur et de reconnaître la fin de l’envoi.

Pour examiner le vôtre, partez d’une demande simple et fictive : obtenir un renseignement sur une prestation. Notez les informations que la personne doit fournir pour recevoir une réponse. Cette petite préparation donne un critère de lecture : chaque champ doit avoir une fonction compréhensible dans cet échange.

Un repère qui reste visible pendant la saisie

Le W3C, organisme qui développe les standards du Web, recommande des étiquettes associées aux champs. L’étiquette indique la fonction du champ : adresse email, nom ou message. Elle doit être reliée au champ dans le code, afin que les outils d’assistance puissent aussi identifier ce qui est attendu. Une inscription placée à proximité ne prouve pas cette association technique.

Dans notre exemple, « Votre adresse email » est un repère plus précis que « Contact ». Ajoutez une indication de format seulement lorsqu’elle résout une difficulté réelle. Évitez de faire porter toute l’explication sur un texte qui disparaît dès la première lettre : le visiteur doit pouvoir relire la consigne après avoir commencé. La qualité du libellé et sa bonne association technique se complètent.

Une erreur doit indiquer la prochaine action

« Formulaire invalide » laisse le lecteur chercher. « Adresse email : vérifiez la présence du signe @ » donne une piste précise, si cette vérification correspond bien au problème détecté. Les recommandations WAI sur les notifications demandent des messages clairs, des indications de correction et un retour sur la réussite de l’envoi. La couleur seule ne suffit pas à expliquer une erreur.

Préparez une grille de recette, c’est-à-dire de vérification avant validation de la page. Les formulations ci-dessous sont des exemples éditoriaux à adapter au comportement réel du site.

Situation à essayer	Ce que le visiteur doit comprendre
Un champ obligatoire reste vide	Quel champ renseigner et quelle information fournir.
Une adresse email est mal formée	Où corriger la saisie et quel format est attendu.
Le traitement échoue après le clic	Si la demande a été enregistrée et quelle action reste possible.
L’envoi aboutit	Que le site a accepté la demande et quelle suite est réellement prévue.

Utilisez des données de test autorisées et évitez les envois répétés dans la boîte de production. Sur un environnement de recette, faites volontairement une erreur, corrigez-la puis terminez le parcours. Relevez le texte exact affiché, la facilité à retrouver le champ et le maintien du message déjà rédigé. Ces observations donnent des corrections concrètes au responsable du site.

Une confirmation affichée par le site ne prouve pas, à elle seule, que la notification email est arrivée chez son destinataire. Prévoyez donc aussi un contrôle interne de réception. Et si aucun délai de réponse n’est organisé, n’en promettez pas dans le message final. La phrase doit refléter ce que l’équipe peut réellement assurer.

Faire du contact une suite logique de la page

Le bon formulaire prolonge une offre déjà compréhensible et laisse le visiteur savoir où il en est. La page Communication de Gaia présente ce travail sur l’ordre des informations et les actions utiles. Si le formulaire s’inscrit dans une création ou une refonte, les offres de sites internet permettent d’examiner le projet dans son ensemble. Cette vérification ciblée reste un point de départ, pas un audit complet d’accessibilité.