Une personne souhaite poser une question, remplit votre formulaire de contact et clique sur Envoyer. Rien ne se passe. Ou une bordure rouge apparaît, sans explication. Pour l’équipe qui gère le site, le formulaire semble pourtant terminé : les champs existent, la validation fonctionne et les demandes sont traitées. Mais pour cette personne, le parcours s’arrête là.
L’accessibilité se vérifie sur l’ensemble du parcours, du premier champ à la confirmation de réception. Ces sept contrôles aident les designers, développeurs et équipes produit à examiner ce cheminement. Il s’agit d’un point de départ pratique, pas d’un audit WCAG complet.
Commencer par les informations réellement nécessaires
Prenons une simple question adressée à une organisation. Un nom, une adresse e-mail et un message suffisent-ils ? Chaque champ supplémentaire demande un effort et peut devenir un obstacle. Le W3C recommande de ne demander que les informations utiles à la tâche.
Premier contrôle : limiter les données demandées et identifier les champs obligatoires avant la saisie. Le deuxième en découle : chaque champ doit avoir un libellé visible, compréhensible et lié techniquement au champ. Un texte indicatif tel que « Adresse e-mail » disparaît pendant la saisie et ne remplace pas un vrai libellé.
Que se passe-t-il sans souris ?
La personne atteint le premier champ et utilise uniquement Tab, Maj+Tab et le clavier. Le focus suit-il un ordre logique ? L’élément actif reste-t-il visible ? Est-il possible de modifier un choix et d’envoyer le formulaire ? C’est le troisième contrôle.
Ne limitez pas le test aux champs. Une bannière de cookies, une protection antispam ou un composant de sélection peuvent interrompre le parcours. Une interface claire sur un grand écran peut également devenir difficile à utiliser sur téléphone avec un texte agrandi. Le quatrième contrôle consiste donc à répéter le parcours sur un écran étroit et avec un agrandissement, sans perdre l’accès aux libellés, explications et boutons.
Le message d’erreur fait partie de l’interface
Imaginons maintenant une adresse e-mail mal saisie. « Saisie incorrecte » n’aide pas beaucoup. « Saisissez une adresse e-mail valide, par exemple nom@organisation.fr » indique ce qui doit être corrigé.
Cinquième contrôle : exprimer les erreurs en texte clair, relier chaque message au champ concerné et expliquer comment continuer. Une bordure rouge ne suffit pas. Les recommandations du W3C précisent que les erreurs détectées doivent être identifiées et décrites textuellement. Conservez les données correctement saisies lorsqu’un envoi échoue.
Pour la mise en œuvre des libellés, messages et comportements de focus, consultez notre tutoriel sur la validation accessible.
Envoyé ne veut pas toujours dire reçu
La personne corrige son adresse et réessaie. Une animation de chargement apparaît. Le message est-il arrivé ? Pas forcément. Le serveur peut refuser la demande, une intégration peut échouer ou une notification peut être retardée.
Sixième contrôle : n’afficher une confirmation de succès qu’après l’acceptation de l’envoi par le système. Distinguez réception, traitement et réponse humaine. N’annoncez pas de délai que l’organisation ne peut garantir. Lors d’un test de bout en bout, vérifiez aussi que la demande arrive au bon endroit.
Tester surtout les situations problématiques
Le septième contrôle couvre les exceptions : formulaire vide, adresse incorrecte, message long et panne temporaire du serveur. Recommencez les étapes essentielles avec le clavier et un lecteur d’écran. Notez le navigateur, l’appareil, les aides techniques et les problèmes restants.
Les scanners d’accessibilité sont utiles, mais ne montrent pas à eux seuls si une personne peut envoyer sa demande de manière autonome. Si possible, faites participer des personnes présentant différents handicaps aux tests d’usage.
Faire du parcours complet un critère de livraison
Un formulaire n’est pas terminé parce que les équipes design, frontend et backend ont chacune livré leur partie. Il est terminé lorsque le parcours fonctionne réellement : demandes claires, libellés associés, navigation au clavier, erreurs corrigeables et confirmation fiable.
Intégrez ces points aux critères de réception et répétez les tests après toute modification du formulaire, des extensions, de l’antispam ou des intégrations. La véritable question n’est pas de savoir si le bouton Envoyer fonctionne, mais si chaque visiteur peut aller au bout de sa démarche.
Si les demandes doivent rejoindre un CRM, la vérification de l’acheminement fait également partie de la conception. Notre sponsor BlazeForce présente ses services d’intégration et d’automatisation, qui ne remplacent pas les vérifications d’accessibilité.
Sources
- W3C WAI — Forms Tutorial
- W3C WAI — Labeling Controls
- W3C WAI — User Notifications
- W3C WAI — Validating Input
- WCAG 2.2 — Error Identification
Contactez-nous
Dites-nous comment nous pouvons vous aider ; nous répondons sous deux jours ouvrés.
