Tunnel de commande et formulaires accessibles : le guide e-commerce

Chaque champ a un libellé visible et associé

Tout champ doit porter une étiquette explicite, visible et liée par le code : un <label for="…"> qui pointe vers l'id du champ (ou un aria-label à défaut). Le placeholder gris ne compte pas comme libellé : il disparaît dès qu'on tape, il a un contraste insuffisant, et un lecteur d'écran ne le restitue pas de façon fiable.

• « Nom », « Adresse e-mail », « Code postal »… visibles en permanence au-dessus ou à gauche du champ ;
• Indiquez le format attendu en texte (« JJ/MM/AAAA »), pas seulement dans le placeholder ;
• Les champs obligatoires sont signalés autrement que par la seule couleur (mention « obligatoire » ou aria-required).

Les erreurs sont identifiées en texte et expliquées

Quand une saisie échoue (e-mail mal formé, carte refusée, champ vide), l'erreur doit être : annoncée en texte (pas seulement une bordure ou une icône rouge), reliée au champ concerné (via aria-describedby), et actionnable — elle dit quoi corriger. « Erreur » ne suffit pas ; « Le code postal doit comporter 5 chiffres » oui.

• Ne dépendez jamais de la seule couleur pour signaler une erreur ;
• Déplacez le focus vers le premier champ en erreur, ou listez les erreurs en haut du formulaire avec des liens ;
• Pour le paiement, expliquez le motif du refus autant que la loi bancaire le permet.

Tout se fait au clavier, dans un ordre logique

Un utilisateur doit pouvoir parcourir et remplir tout le tunnel sans souris : atteindre chaque champ avec Tab, cocher une case avec Espace, ouvrir un menu déroulant et le valider, déclencher « Payer » avec Entrée. L'ordre de tabulation doit suivre l'ordre visuel, et aucune étape ne doit piéger le focus (modale de paiement, sélecteur d'adresse).

• Testez vous-même : rangez la souris et allez du panier jusqu'au bouton de paiement ;
• Vérifiez que les fenêtres modales se ferment avec Échap et rendent le focus à l'élément déclencheur ;
• Méfiez-vous des champs « adresse » à autocomplétion par carte : ils doivent rester saisissables au clavier.

On voit toujours où l'on est

À chaque tabulation, l'élément actif doit être nettement visible (contour, surbrillance). C'est vital dans un formulaire long : sans indicateur de focus, une personne qui navigue au clavier ne sait pas quel champ elle est en train de remplir. Ne supprimez jamais le contour de focus par outline: none sans le remplacer par un style au moins aussi lisible.

Les champs d'identité se pré-remplissent

Les champs qui demandent des informations personnelles (nom, e-mail, adresse, téléphone, carte) doivent porter l'attribut autocomplete adapté (par exemple autocomplete="email", "postal-code", "cc-number"). Cela permet au navigateur de proposer les valeurs déjà connues — un confort essentiel pour les personnes ayant des troubles moteurs ou cognitifs, et un gain de conversion pour tous les clients.

Les éléments « maison » exposent nom, rôle et valeur

Sélecteur de quantité en +/–, calendrier de livraison, menu de pays « stylé », bouton bascule… dès qu'un composant n'est pas un élément HTML natif, il doit exposer son nom, son rôle et sa valeur au lecteur d'écran (rôles et états ARIA corrects : role, aria-expanded, aria-checked…). Sinon, l'utilisateur entend « bouton » sans savoir ce qu'il fait. Le plus sûr reste d'utiliser les éléments natifs (<select>, <input type="number">) chaque fois que possible.

Les changements sont annoncés, et on peut se relire

Quand le contenu change sans rechargement — « Article ajouté au panier », « Code promo appliqué », « Carte refusée », total mis à jour —, l'information doit être annoncée au lecteur d'écran via une région aria-live, sinon elle passe inaperçue. Et avant le paiement définitif, prévoyez une étape de relecture (vérifier l'adresse, la commande, le montant) ou une confirmation : pour les transactions financières, l'utilisateur doit pouvoir corriger une erreur avant de valider.