Lecture : 12 min · Yoan Gwizdala

Tunnel de commande accessible : les 9 points qui font perdre la vente

C'est la partie du site où une erreur coûte de l'argent immédiatement. Un tunnel de commande inutilisable au clavier ne perd pas seulement les clients en situation de handicap : il perd tous ceux qui commandent sur un téléphone, au soleil, en zoom, avec une main occupée. Voici les neuf points que je teste, dans l'ordre où je les teste.

1. Aller du panier à la confirmation avec la seule touche Tab

Le premier test, et celui qui élimine le plus de boutiques : on débranche la souris et on commande. Tabulation pour avancer, Maj+Tab pour reculer, Entrée pour activer, Espace pour cocher, les flèches pour les groupes de boutons radio.

Ce qui casse, presque toujours :

• Un sélecteur de quantité fait de deux <div> cliquables, que la tabulation ne peut pas atteindre.
• Un choix de mode de livraison présenté comme des cartes cliquables, sans <input type="radio"> dessous.
• Un « Continuer » qui n'est pas un <button> mais un <a> sans href, donc hors du parcours clavier.
• Un menu déroulant de pays qui s'ouvre à la souris mais ne se pilote pas aux flèches.

La règle qui résout 90 % de ces cas est ennuyeuse et sans appel : un élément interactif est un <button>, un <a href> ou un <input>. Pas un <div> avec un gestionnaire de clic. Le composant natif apporte gratuitement le focus, l'activation clavier, le rôle annoncé et l'état.

2. Chaque champ a une étiquette, et le placeholder n'en est pas une

C'est le troisième défaut le plus répandu du web : 51 % des pages d'accueil analysées par le rapport WebAIM Million 2026 comportent au moins un champ sans étiquette. Sur un formulaire de commande, cela veut dire un client qui ne sait pas ce qu'on lui demande.

<!-- non : le placeholder disparaît à la saisie -->
<input type="text" placeholder="Code postal">

<!-- oui -->
<label for="cp">Code postal</label>
<input type="text" id="cp" name="postal-code" autocomplete="postal-code" inputmode="numeric">

Le placeholder pose trois problèmes cumulés : il s'effface dès qu'on tape, son contraste est presque toujours insuffisant, et il n'est pas systématiquement lu comme une étiquette. Une étiquette visible au-dessus du champ ne coûte rien et résout les trois.

3. autocomplete et inputmode, les deux attributs qui font le plus de bien

Ils passent pour du confort. Ce sont en réalité des critères d'accessibilité, et ils réduisent le taux d'abandon pour tout le monde.

• autocomplete="name", "email", "tel", "street-address", "postal-code", "country-name", "cc-number" : le navigateur remplit, et l'utilisateur n'a pas à ressaisir vingt caractères sur un clavier virtuel.
• inputmode="numeric" sur un code postal, "tel" sur un téléphone, "email" sur un email : le bon clavier s'ouvre du premier coup.
• Un champ par information. Découper un numéro de carte en quatre champs de quatre chiffres empêche l'auto-remplissage et le collage : c'est un obstacle inventé.

4. Les erreurs de saisie : dire quoi, où, et comment corriger

Trois exigences, et la plupart des tunnels n'en satisfont qu'une seule : la couleur.

• Identifier le champ en erreur autrement que par la couleur. Un liseré rouge est invisible pour huit pour cent des hommes. Il faut du texte.
• Expliquer la correction attendue. « Champ invalide » ne sert à rien. « Le code postal doit comporter 5 chiffres » sert.
• Rattacher le message au champ, pour qu'il soit lu quand on y arrive.

<label for="mail">Email</label>
<input type="email" id="mail" name="email" autocomplete="email"
       aria-invalid="true" aria-describedby="mail-err">
<p id="mail-err">Cette adresse ne contient pas de « @ ».</p>

Et au moment de la soumission : déplacer le focus sur le résumé des erreurs, ou sur le premier champ fautif. Un client qui appuie sur « Payer » et à qui rien ne semble se passer, parce que l'erreur est affichée six écrans plus haut, abandonne quelle que soit sa vue.

5. Le focus doit rester visible. Toujours.

Il existe une ligne de CSS qui, à elle seule, rend une boutique inutilisable au clavier :

/* jamais ça */
*:focus { outline: none; }

Elle est encore présente dans beaucoup de thèmes, souvent parce que l'anneau par défaut du navigateur était jugé inesthétique. La réponse n'est pas de le supprimer mais de le dessiner : un anneau contrasté, épais de deux pixels, avec un décalage, et l'on peut même le réserver à la navigation clavier avec :focus-visible.

:focus-visible {
  outline: 2px solid #e9c778;
  outline-offset: 2px;
}

6. Savoir où l'on est dans le parcours

Un tunnel en trois étapes doit dire laquelle est en cours, et pas seulement en la coloriant. Le titre de la page change (<title> compris, c'est ce que le lecteur d'écran annonce en premier), l'étape courante porte aria-current="step", et la structure de titres suit la logique du parcours.

Corollaire souvent oublié : quand une étape se charge sans rechargement de page, rien n'est annoncé. Il faut alors déplacer le focus sur le titre de la nouvelle étape. Sans ça, l'utilisateur reste au même endroit dans un contenu qui a changé sous lui.

7. Les modales : le focus entre, reste, et revient

Panier latéral, choix de taille, bandeau de cookies, sélecteur de point relais : le e-commerce en est rempli, et presque aucune n'est correcte. Quatre règles :

• À l'ouverture, le focus entre dans la modale.
• Tant qu'elle est ouverte, le focus n'en sort pas, sinon on tabule dans une page qu'on ne voit plus.
• Échap la ferme.
• À la fermeture, le focus revient sur l'élément qui l'a ouverte.

L'élément HTML <dialog> avec showModal() fournit les quatre gratuitement, et il est disponible dans tous les navigateurs à jour. Une modale maison qui ne les implémente pas est un piège : littéralement, le focus y reste coincé ou s'en échappe sans retour.

8. Le temps : paniers qui expirent, sessions qui tombent, captchas

Les exigences réglementaires demandent de laisser à l'utilisateur « suffisamment de temps pour lire et utiliser le contenu ». Sur une boutique, cela se traduit en trois cas concrets :

• Un panier ou une session qui expire doit être prolongeable, et l'utilisateur doit être averti avant l'échéance. Remplir une adresse prend plus longtemps quand on utilise un clavier virtuel ou une commande vocale.
• Un compte à rebours de stock qui vide le panier est un obstacle ; s'il est purement décoratif, il n'a rien à faire là.
• Un captcha visuel sans alternative bloque définitivement. Il existe des solutions sans épreuve visuelle ; sur ce site, le formulaire de contact se contente d'un champ piège invisible, qui ne demande rien à personne.

9. La confirmation doit être annoncée, pas seulement affichée

Le geste central d'une boutique : on clique « Ajouter au panier », un compteur s'incrémente en haut à droite. Pour qui n'a pas les yeux sur ce compteur, rien ne s'est passé. La correction tient en une région vivante :

<p role="status">Chemise en lin, taille M, ajoutée au panier. Panier : 3 articles.</p>

role="status", ou aria-live="polite", fait lire le message dès qu'il apparaît, sans interrompre. Même principe pour le retrait d'un article, l'application d'un code promo, le recalcul des frais de port. C'est trois lignes de code, et c'est la différence entre une boutique utilisable et une boutique muette.

Le cas particulier du paiement

La saisie de carte est presque toujours dans une iframe fournie par le prestataire de paiement, sur laquelle vous n'avez pas la main. Deux choses restent de votre côté, et elles suffisent souvent :

• L'iframe doit porter un titre (title="Paiement par carte bancaire"), sinon elle est annoncée comme un cadre anonyme.
• Le choix du prestataire vous appartient. C'est un point à mettre sur la table : si son formulaire n'est pas utilisable au clavier, la commande échoue chez vous, pas chez lui.

Même remarque pour un tunnel hébergé, celui de Shopify par exemple, que l'on ne modifie pas librement. Le fait que la couche technique échappe au marchand ne déplace pas la responsabilité du service : j'en parle dans l'article sur les trois plateformes.

Dans quel ordre corriger

Par ce qui bloque une commande, pas par ce qui remonte dans un rapport d'outil.

1. Tout ce qui est inatteignable au clavier dans le parcours d'achat.
2. Les boutons et liens sans nom accessible : 30,6 % et 46,3 % des pages, respectivement.
3. Les champs sans étiquette du tunnel.
4. Les messages d'erreur et le déplacement du focus à la soumission.
5. Les contrastes des prix, des frais de port et des mentions de stock.
6. Le reste, qui est réel mais moins urgent.

Ce classement n'est pas une hiérarchie de gravité réglementaire : c'est une hiérarchie de chiffre d'affaires. Elle a l'avantage de conduire aux mêmes corrections, avec un ordre défendable devant un dirigeant.

Faire tester mon tunnel de commande

Questions fréquentes

Comment tester si mon tunnel de commande est accessible ?

Débranchez la souris et passez une commande complète avec la seule touche Tab, plus Entrée et Espace. Si vous ne parvenez pas à choisir une quantité, un mode de livraison ou à valider le paiement, vous avez trouvé le défaut le plus grave et le plus fréquent. C'est un test de cinq minutes qui ne demande aucun outil.

Le placeholder peut-il remplacer une étiquette de champ ?

Non. Il disparaît dès que l'utilisateur commence à taper, son contraste est presque toujours insuffisant, et il n'est pas systématiquement annoncé comme une étiquette par les lecteurs d'écran. Il faut un vrai élément label associé au champ par son attribut for. Si l'étiquette ne doit pas être visible, on la masque visuellement sans la retirer du code.

Pourquoi ne faut-il jamais écrire outline: none ?

Parce que cette règle supprime l'indicateur de focus, donc la seule chose qui permet à un utilisateur au clavier de savoir où il se trouve dans la page. Si l'anneau par défaut du navigateur ne convient pas esthétiquement, la réponse est de le redessiner, par exemple avec un contour de deux pixels contrasté et un décalage, et de le cibler par la pseudo-classe focus-visible pour ne l'afficher qu'en navigation clavier.

Comment annoncer un ajout au panier à un lecteur d'écran ?

En écrivant le message de confirmation dans une région vivante, c'est-à-dire un élément portant role égal à status, ou aria-live à la valeur polite. Le texte y est lu dès qu'il apparaît, sans interrompre l'utilisateur. Le même mécanisme sert pour le retrait d'un article, l'application d'un code promo ou le recalcul des frais de port.

Que faire du formulaire de paiement, qui vient du prestataire ?

Deux choses restent de votre côté. D'abord donner un titre à l'iframe qui le contient, sans quoi elle est annoncée comme un cadre anonyme. Ensuite choisir son prestataire en connaissance de cause : si son formulaire n'est pas utilisable au clavier, c'est votre commande qui échoue. Le fait que la couche technique vous échappe ne déplace pas la responsabilité du service.

Un panier qui expire est-il un problème d'accessibilité ?

Oui, dès lors qu'il expire sans avertissement et sans possibilité de prolonger. Les exigences demandent de laisser suffisamment de temps pour lire et utiliser le contenu, et remplir une adresse prend plus longtemps avec un clavier virtuel, une commande vocale ou une motricité réduite. Un avertissement avant échéance et un bouton pour prolonger suffisent.