Formulaire de devis accessible : 7 vérifications avant publication

Un prospect souhaite décrire son projet, mais le champ à compléter n'est plus identifiable après la saisie. Sur téléphone, le bouton d'envoi passe derrière une fenêtre de discussion. Au clavier, une liste de choix reste inaccessible. Ces obstacles peuvent empêcher une demande d'aboutir, même si le reste du site fonctionne.

Avant de publier ou de refaire votre formulaire de devis, vérifiez le parcours complet, depuis le premier champ jusqu'au message de confirmation. Voici sept contrôles à préparer avec votre prestataire web. Le fil conducteur est une menuiserie fictive qui reçoit des demandes de travaux ; les exemples proposés sont des choix de conception, pas des résultats clients.

1. Garder les questions nécessaires au premier échange

Pour chaque champ, demandez-vous quelle décision l'équipe pourra prendre grâce à la réponse. Si l'information ne sert qu'après une visite ou un entretien, elle peut souvent attendre.

Dans notre exemple, la menuiserie pourrait commencer par un moyen de contact, la commune du chantier et une description du besoin. Exiger immédiatement des dimensions précises risquerait de bloquer une personne qui souhaite justement être conseillée. L'équipe doit décider ce qui est indispensable selon sa façon de travailler.

Le W3C recommande des formulaires courts et limités aux informations nécessaires au processus. Il ne fixe pas un nombre universel de champs. Source : W3C, introduction aux formulaires accessibles.

2. Donner un libellé visible à chaque champ

« Votre adresse email » doit rester lisible lorsque la personne commence à écrire. Un exemple affiché à l'intérieur d'un champ vide, appelé placeholder, disparaît généralement pendant la saisie et ne remplace pas un libellé.

Demandez au développeur de relier chaque libellé à son champ dans le code, généralement avec l'élément HTML label. Cette association permet notamment aux technologies d'assistance d'identifier le contrôle. Vérifiez aussi les cases à cocher et les boutons : leur fonction doit être compréhensible sans deviner le sens d'une icône. Sources : W3C, association des libellés et instructions des formulaires.

Un contrôle simple consiste à relire le formulaire entièrement rempli : sait-on encore à quoi correspond chaque réponse ?

3. Expliquer les choix et les formats attendus

Indiquez les champs obligatoires et facultatifs avant que la personne tente l'envoi. Si vous utilisez un astérisque, expliquez sa signification. Pour une pièce jointe, annoncez les formats acceptés et la taille maximale réellement configurée.

Placez les consignes près du champ concerné et faites vérifier leur association technique, afin qu'elles soient aussi disponibles avec un lecteur d'écran. Le W3C décrit notamment l'utilisation d'aria-describedby pour relier une aide au champ. Source : W3C, instructions des formulaires.

Si notre menuiserie propose « Fenêtres », « Portes » et « Autre projet », l'ensemble doit avoir une question explicite. Pour des boutons radio, les éléments fieldset et legend permettent de relier le groupe à son intitulé. Source : W3C, regroupement des contrôles.

4. Effectuer tout le parcours sans souris

Ouvrez la page dans un navigateur configuré pour la navigation au clavier. Utilisez Tab pour avancer et Maj + Tab pour revenir, puis les touches adaptées aux listes et aux boutons.

Vous devez pouvoir atteindre les champs et les actions, savoir où se trouve le focus, puis quitter chaque contrôle. L'ordre doit rester logique. Testez aussi les éléments autour du formulaire, notamment une fenêtre de discussion ou un sélecteur de date : ils peuvent interrompre le parcours.

Le W3C recommande de vérifier l'accès aux fonctions, l'ordre de navigation, la visibilité du focus et l'absence de blocage au clavier. Source : W3C, premiers contrôles d'accessibilité.

Notez le contrôle précis qui pose problème, plutôt qu'un verdict général comme « le clavier ne fonctionne pas ».

5. Vérifier le formulaire sur petit écran et avec le zoom

Sur un téléphone, remplissez réellement les champs. Contrôlez ce qui se passe lorsque le clavier virtuel apparaît, lorsqu'une aide s'affiche et lorsque le texte d'une erreur prend plusieurs lignes. Le bouton d'envoi doit rester accessible.

Sur ordinateur, augmentez aussi le zoom. Les contenus doivent se réorganiser sans masquer les instructions ni les actions. Le critère Reflow des WCAG prend comme repère une largeur équivalente à 320 pixels CSS pour le contenu à défilement vertical, avec des exceptions pour les contenus nécessitant une disposition en deux dimensions. Source : W3C, compréhension du critère Reflow.

Pour notre exemple, une disposition sur une colonne constitue une piste simple à tester. Vérifiez particulièrement les éléments fixes qui pourraient recouvrir le formulaire.

6. Aider à corriger une erreur de saisie

Testez volontairement un champ obligatoire vide et une adresse email incomplète. Le retour doit indiquer le champ concerné et ce qu'il faut corriger. Une bordure rouge seule ne donne pas cette explication.

Par exemple : « Adresse email incomplète. Vérifiez la partie après le signe @. » Faites contrôler l'annonce des erreurs avec un lecteur d'écran et le déplacement du focus après un envoi refusé. Source : W3C, notifications des formulaires.

Préservez les réponses déjà saisies lorsque cela convient au contexte. Enfin, demandez une validation côté serveur : les contrôles du navigateur améliorent l'expérience, mais peuvent être contournés. Ils ne suffisent pas à sécuriser les données reçues. Source : MDN, validation des formulaires.

7. Afficher une confirmation compréhensible

Après l'envoi, indiquez clairement ce qui s'est passé. Le W3C souligne l'importance d'un message de réussite pour confirmer la fin de la tâche. Source : W3C, notifications des formulaires.

Pour notre menuiserie fictive, le message pourrait préciser : « Votre demande a été enregistrée. Notre équipe vous contactera pour préciser le projet. » Ce texte suppose que l'enregistrement a bien été confirmé. N'affichez pas une réussite dès le clic sur le bouton.

Ajoutez uniquement un délai de réponse que votre organisation peut réellement tenir. Faites aussi vérifier que la confirmation reste perceptible avec un lecteur d'écran, notamment lorsqu'elle apparaît sans changement de page.

Transformer ces contrôles en critères de réception

Avant la mise en ligne, demandez une démonstration avec des données fictives : parcours complet au clavier, usage sur téléphone, zoom, erreur corrigée et confirmation. Conservez les problèmes observés, leur correction et la date du nouvel essai.

Cette checklist constitue un premier contrôle pratique. Elle ne remplace pas une évaluation complète de l'accessibilité et ne suffit pas à déclarer un site conforme. Le W3C précise lui-même les limites de ses vérifications préliminaires.

Lors d'un projet de création ou de refonte de site web, inscrivez ces essais dans les livrables attendus. Vous pouvez décrire votre parcours de demande de devis pour identifier les points à vérifier avant publication.