Formulaire accessible : 7 erreurs qui font abandonner les paniers e-commerce
Publié le 6 octobre 2026 · Lecture : 7 minutes · Par l’équipe Brozapi
Un client arrive au paiement, renseigne son adresse, choisit une livraison… puis quitte le site. On pense souvent à un prix trop élevé ou à des frais de livraison inattendus. Mais un formulaire inaccessible peut provoquer le même résultat : le client ne comprend pas quoi saisir, ne voit pas son erreur ou ne parvient pas à terminer la commande.
Pour une boutique en ligne, le checkout est la zone la plus sensible du parcours. Une étiquette absente, un message d’erreur invisible ou un champ inutilisable au clavier n’est pas seulement un point à corriger dans un audit : c’est une commande qui risque de ne jamais aboutir. Voici les sept erreurs à rechercher en priorité.
1. Un champ sans étiquette claire
Le problème : le champ affiche seulement un exemple dans la zone de saisie, comme « 12 rue des Lilas », ou son intitulé disparaît dès que l’utilisateur commence à écrire. Un lecteur d’écran peut alors annoncer un champ sans nom compréhensible. Une personne qui zoome fortement peut également perdre le lien entre le texte et la zone à remplir.
L’impact sur le panier : l’utilisateur hésite, saisit une information au mauvais endroit ou renonce avant le paiement. Les champs « Nom », « Adresse e-mail » et « Numéro de rue » ne devraient pas être devinés.
La correction : associer chaque champ à une étiquette visible et persistante. En HTML, un élément <label> correctement relié au champ par for et id est une solution simple. Le placeholder peut donner un exemple, mais il ne remplace pas l’étiquette.
2. Des intitulés vagues ou incohérents
Le problème : le même champ s’appelle « Ville » sur une page et « Localité » sur une autre, ou plusieurs champs portent un intitulé imprécis comme « Information ». Un intitulé visible peut aussi être différent du nom transmis aux technologies d’assistance.
L’impact sur le panier : le client doit réinterpréter le formulaire à chaque étape. Cette charge supplémentaire est particulièrement pénalisante avec un lecteur d’écran, une commande vocale ou une mémoire de travail limitée.
La correction : utiliser des intitulés précis et cohérents tout au long du tunnel. « Adresse e-mail de facturation » est plus utile que « Contact ». Si un nom accessible est fourni avec aria-label ou aria-labelledby, il doit reprendre l’intitulé visible au lieu de le contredire.
3. Les champs obligatoires ne sont pas annoncés
Le problème : un astérisque coloré signale visuellement qu’un champ est obligatoire, mais aucune explication textuelle n’est fournie. Ou bien la légende « * champ obligatoire » est éloignée du champ et n’est pas annoncée par le lecteur d’écran.
L’impact sur le panier : l’utilisateur valide le formulaire, reçoit plusieurs erreurs et ne sait pas immédiatement quelles informations manquent. Après plusieurs tentatives, il peut abandonner, surtout si le panier contient déjà des données saisies.
La correction : indiquer clairement le caractère obligatoire dans l’étiquette ou dans une instruction associée. Ne pas dépendre de la couleur ou d’un symbole seul. Regrouper les champs qui appartiennent à la même information, par exemple les options de livraison ou les coordonnées de facturation, avec une structure compréhensible.
4. Un message d’erreur trop discret ou incompréhensible
Le problème : après validation, le formulaire se contente de colorer le champ en rouge, d’afficher une icône ou de présenter « Erreur » sans préciser ce qui doit être corrigé. Le message peut aussi être placé loin du champ concerné.
L’impact sur le panier : une personne daltonienne ne perçoit pas la différence de couleur. Une personne utilisant un lecteur d’écran n’entend pas forcément le message. Dans les deux cas, elle ne sait pas si l’adresse est incomplète, si l’e-mail est mal formé ou si le paiement a échoué.
La correction : écrire un message explicite, au plus près du champ : « Saisissez une adresse e-mail au format nom@exemple.fr ». Relier ce texte au champ avec aria-describedby lorsque c’est pertinent, et signaler l’état invalide de manière programmatique. Le message doit rester visible jusqu’à la correction.
5. Le focus clavier se perd après une erreur
Le problème : l’utilisateur appuie sur « Valider » avec la touche Entrée ou la touche Tabulation. Une erreur apparaît, mais le focus revient en haut de la page, disparaît dans une fenêtre modale ou reste sur le bouton. Il faut alors parcourir à nouveau tout le formulaire.
L’impact sur le panier : le parcours devient long et imprévisible. Une personne qui navigue uniquement au clavier peut ne plus savoir où agir. Ce n’est pas un détail d’ergonomie : si l’étape suivante est introuvable, la commande s’arrête.
La correction : après l’envoi, placer le focus sur le premier champ en erreur ou sur un résumé d’erreurs contenant des liens vers les champs concernés. Vérifier ce comportement avec la seule touche Tab, sans souris, et après chaque étape du checkout.
6. Un sélecteur ou un champ de date impossible à utiliser au clavier
Le problème : le site remplace les composants natifs par un calendrier ou une liste développée qui ne répond qu’au clic. Les flèches, les mois ou les options ne sont pas atteignables au clavier, ou l’ordre de Tabulation devient incohérent.
L’impact sur le panier : le client ne peut pas choisir une date de livraison ou une option de retrait. Sur mobile, un composant trop précis peut également être difficile à manipuler. Il quitte le tunnel plutôt que de lutter avec le calendrier.
La correction : proposer un contrôle réellement utilisable au clavier, avec un nom, un état et des instructions compréhensibles. Tester les touches Tab, Entrée, Échap et les flèches lorsque le composant les utilise. Si un calendrier riche n’est pas nécessaire, un champ de date simple et correctement étiqueté peut être plus robuste.
7. Le bouton final ne dit pas ce qu’il va faire
Le problème : le dernier bouton indique « Continuer », « OK » ou affiche seulement une icône. À ce moment du parcours, plusieurs actions sont possibles : enregistrer l’adresse, passer au paiement ou confirmer une commande.
L’impact sur le panier : l’utilisateur craint de déclencher une action irréversible ou ne comprend pas pourquoi le formulaire ne progresse pas. Un bouton ambigu peut faire perdre confiance au moment où l’achat devrait être finalisé.
La correction : donner à chaque bouton un intitulé explicite et cohérent avec l’étape : « Passer au paiement » ou « Confirmer la commande ». Vérifier que son nom est également correctement restitué par les technologies d’assistance.
Des correctifs souvent simples à vérifier
Ces problèmes ne demandent pas tous une refonte du checkout. Une étiquette persistante, un message d’erreur rédigé en toutes lettres, une association avec aria-describedby ou un focus replacé au bon endroit peuvent changer l’expérience immédiatement. Encore faut-il vérifier le parcours complet, sur ordinateur et mobile, au clavier et avec une technologie d’assistance.
Le RGAA consacre sa thématique 11 aux formulaires. Il traite notamment de la présence et de la pertinence des étiquettes (critères 11.1 et 11.2), de leur cohérence et de leur proximité avec les champs. Pour les messages d’erreur et l’aide à la saisie, consultez directement les critères et tests officiels : référentiel RGAA, thématique Formulaires. Un audit de conformité ne se déduit pas de la seule présence de quelques attributs ARIA.
Et l’European Accessibility Act ?
La directive (UE) 2019/882 inclut le commerce électronique parmi les services concernés et prévoit une application des mesures à partir du 28 juin 2025. Son champ et ses exemptions doivent être appréciés selon la situation de chaque entreprise ; cet article ne constitue pas un avis juridique. Consultez le texte officiel sur EUR-Lex, ainsi que sa transposition applicable à votre activité.
Vérifiez votre tunnel avant de perdre une commande
Commencez par passer une commande test : pouvez-vous remplir chaque champ au clavier ? Les étiquettes restent-elles visibles ? Après une erreur volontaire, comprenez-vous immédiatement quoi corriger et retrouvez-vous le champ sans chercher ? Le bouton final annonce-t-il clairement l’action ?
Le scan gratuit AccessiCheck permet d’obtenir un premier signal sur les problèmes détectables automatiquement. Pour aller plus loin, demandez un audit complet : 29 € pour une page ou 49 € pour cinq pages, puis une surveillance à 9 €/mois. Ces prestations identifient des problèmes à corriger ; elles ne constituent pas une garantie RGAA.
Vérifiez votre formulaire avant de perdre une commande
Scannez gratuitement la page d’accueil de votre site et repérez les premiers obstacles détectables automatiquement. Pour un document exploitable, l’audit complet identifie les problèmes à corriger : 29 € (1 page) ou 49 € (5 pages), avec un suivi possible à 9 €/mois.
Scanner mon site gratuitementSources : RGAA, critères et tests — thématique 11 : Formulaires (accessibilite.numerique.gouv.fr) ; Directive (UE) 2019/882, texte officiel sur EUR-Lex (CELEX:32019L0882).
Cet article est fourni à titre informatif et ne constitue pas un conseil juridique. Pour une analyse de votre situation, consultez un professionnel du droit.
Derniers articles : Accessibilité et SEO : les corrections WCAG qui font aussi progresser votre référencement · Les CAPTCHAs excluent-ils vos clients handicapés ? Même les agents IA les détestent · Overlays d'accessibilité : pourquoi ces widgets « clés en main » font baisser votre score · Checklist accessibilité : les 12 points à vérifier avant de livrer un site web · Déclaration d’accessibilité RGAA : où l’afficher, quoi écrire, et les erreurs à éviter · European Accessibility Act et PME e-commerce : ce que change l’obligation du 28 juin 2025