Navigation au clavier d'un site e-commerce : les règles WCAG
En bref — tout doit fonctionner au clavier
Une part importante des utilisateurs n'emploie pas de souris : personnes aveugles avec lecteur d'écran, personnes à mobilité réduite des mains, utilisateurs de commande vocale ou de claviers adaptés. L'European Accessibility Act (norme EN 301 549 / WCAG 2.1 AA) exige qu'une boutique soit entièrement utilisable au clavier seul. Les points clés :
- Tout est atteignable et activable au clavier — menus, filtres, fiche produit, panier, paiement (critère 2.1.1) ;
- Aucun piège clavier : on peut toujours ressortir d'un élément avec Tab ou Échap (critère 2.1.2) ;
- Ordre de tabulation logique, qui suit l'ordre visuel et de lecture (critère 2.4.3) ;
- Focus toujours visible : on voit en permanence où l'on se trouve (critère 2.4.7) ;
- Un lien d'évitement pour sauter le menu et aller droit au contenu (critère 2.4.1) ;
- Pas de changement de contexte surprise au simple passage du focus (critère 3.2.1).
Test express : rangez la souris et faites un achat complet uniquement avec Tab, Entrée et les flèches. Si vous restez bloqué, vos clients aussi.
Le clavier est le dénominateur commun de l'accessibilité : un lecteur d'écran, une commande vocale, un contacteur ou un clavier adapté s'appuient tous sur la même logique de navigation au clavier. Si votre boutique se parcourt entièrement au clavier, elle franchit du même coup une grande partie des barrières d'accessibilité. À l'inverse, un seul bouton inaccessible au clavier dans le tunnel de paiement, et la vente est perdue. Voici les six règles WCAG que l'EAA impose, et comment les vérifier en cinq minutes.
Pourquoi le clavier est central
Beaucoup de personnes ne peuvent pas — ou ne veulent pas — utiliser une souris : utilisateurs de lecteurs d'écran (qui se déplacent au clavier), personnes ayant des troubles moteurs qui rendent le pointage précis impossible, utilisateurs de commande vocale ou de dispositifs adaptés (contacteurs, claviers ergonomiques). Tous reposent sur la même base : l'Tab pour avancer d'un élément interactif au suivant, Maj+Tab pour reculer, Entrée / Espace pour activer, les flèches à l'intérieur des composants (menus, listes, carrousels).
L'EAA ne crée pas de règle « clavier » à part : la référence reste l'EN 301 549, fondée sur les WCAG 2.1 niveau AA, applicables aux services de commerce électronique depuis le 28 juin 2025. Mais l'accessibilité au clavier en est le socle : c'est le tout premier principe (« Utilisable ») et le test le plus rapide à faire soi-même.
Les 6 règles de la navigation au clavier
Chaque fonction est atteignable et activable sans souris
Le critère 2.1.1 (Clavier) demande que toutes les fonctionnalités soient utilisables au clavier seul : ouvrir le menu, appliquer un filtre, choisir une variante, ajouter au panier, valider le paiement. Le piège classique : un élément « cliquable » construit avec une <div> ou un <span> munis d'un onclick, qui ne reçoit jamais le focus. Utilisez des éléments natifs (<a>, <button>) qui sont focalisables et activables par défaut ; sinon, ajoutez tabindex="0", un rôle ARIA et la gestion des touches Entrée/Espace.
<button> ; filtres en cases natives ; menu déroulant ouvrable au clavier.<div onclick> en guise de bouton ; un sélecteur de couleur qui ne réagit qu'à la souris.On peut toujours ressortir d'un élément
Le critère 2.1.2 (Pas de piège au clavier) interdit qu'un composant capture le focus sans qu'on puisse en sortir au clavier. Les coupables fréquents : une fenêtre modale (pop-up « newsletter », sélecteur de taille) dont on ne peut pas s'échapper, un lecteur vidéo ou un widget tiers qui retient l'Tab. Règle : on doit pouvoir quitter avec Tab / Maj+Tab, et toute modale doit se fermer avec Échap en rendant le focus à son point de départ.
La tabulation suit l'ordre visuel et de lecture
Le critère 2.4.3 (Ordre de focus) exige que l'on parcoure les éléments dans un ordre cohérent avec la présentation visuelle : de haut en bas, de gauche à droite, sans sauts déroutants. Cela se joue surtout dans l'ordre du code HTML (l'ordre du DOM), pas dans le CSS qui réarrange l'affichage. Évitez les valeurs de tabindex positives (tabindex="3"…) : elles désorganisent l'ordre naturel et créent presque toujours des incohérences.
On voit en permanence où l'on se trouve
Le critère 2.4.7 (Visibilité du focus) impose qu'un indicateur de focus visible signale l'élément actif quand on navigue au clavier. Erreur très répandue : un outline: none en CSS qui supprime le liseré du navigateur « pour faire propre » — la personne ne sait plus où elle est. Ne le retirez jamais sans le remplacer : prévoyez un style :focus-visible bien contrasté (contour épais, halo). Rappel utile : cet indicateur doit lui-même avoir un contraste suffisant (au moins 3:1 avec l'arrière-plan).
*:focus { outline: none } sans alternative ; un focus à peine visible (gris pâle sur fond clair).Sauter le menu pour aller droit au contenu
Le critère 2.4.1 (Contournement de blocs) demande un moyen de sauter les blocs répétés — typiquement l'en-tête et le grand menu de navigation — pour atteindre directement le contenu. La solution standard est un lien d'évitement (« Aller au contenu ») placé tout en haut, masqué visuellement mais qui apparaît au focus dès la première tabulation. Sans lui, un utilisateur au clavier doit traverser des dizaines de liens de menu sur chaque page avant d'atteindre les produits. Une structure en repères (balises <header>, <nav>, <main>) facilite aussi cette navigation pour les lecteurs d'écran.
Le simple passage du focus ne change pas le contexte
Le critère 3.2.1 (Au focus) interdit qu'un changement de contexte se produise juste parce qu'un élément reçoit le focus : ouvrir une nouvelle fenêtre, soumettre un formulaire, naviguer ailleurs ou réorganiser brutalement la page dès qu'on arrive sur un champ. Une action importante doit toujours demander une validation explicite (appuyer sur Entrée, cliquer un bouton). C'est fréquent sur les menus déroulants natifs (<select>) mal codés qui redirigent dès le changement de valeur, sans bouton « Valider ».
<select> de tri qui recharge la page dès qu'on le survole au clavier ; un champ qui ouvre un nouvel onglet à la prise de focus.Récapitulatif des critères clavier
| Point à vérifier au clavier | Niveau | Critère WCAG |
|---|---|---|
| Toute fonction utilisable au clavier seul | A | 2.1.1 |
| Aucun piège au clavier (on peut ressortir) | A | 2.1.2 |
| Ordre de tabulation logique | A | 2.4.3 |
| Indicateur de focus visible | AA | 2.4.7 |
| Contournement de blocs (lien d'évitement) | A | 2.4.1 |
| Pas de changement de contexte au focus | A | 3.2.1 |
| Raccourcis à une touche désactivables / remappables | A | 2.1.4 |
outline: none « pour l'esthétique ». C'est rendre la navigation au clavier invisible — l'utilisateur ne sait plus où il se trouve. Ne retirez jamais le contour sans le remplacer par un style :focus-visible nettement contrasté. Le corriger est souvent une poignée de lignes de CSS.
<div>, ne rend pas un focus visible et ne crée pas un ordre de tabulation logique — ce sont des défauts du code de vos pages. Rappel : la FTC américaine a sanctionné un éditeur d'overlay d'un million de dollars pour des allégations de conformité trompeuses. Voir pourquoi les overlays ne suffisent pas.Comment tester la navigation au clavier
Le test le plus utile est aussi le plus simple — il ne demande aucun outil :
- Rangez la souris et parcourez une page entière avec Tab (avancer), Maj+Tab (reculer), Entrée / Espace (activer), les flèches dans les menus et listes.
- Surveillez l'indicateur de focus : voyez-vous toujours où vous êtes ? Disparaît-il quelque part ?
- Vérifiez l'ordre : la progression suit-elle la lecture, sans saut surprenant ?
- Faites un achat complet au clavier — recherche, filtres, fiche produit, ajout au panier, paiement. Tout doit se faire sans toucher la souris.
- Ouvrez les pop-ups et modales : pouvez-vous en sortir avec Échap et Tab ?
→ Méthode complète : comment tester l'accessibilité de son site. Pour les champs et la validation, voir le guide du tunnel de commande et des formulaires accessibles.
Vérifiez l'accessibilité de votre boutique gratuitement
DeclareAccess analyse une page de votre site avec le moteur axe-core selon les WCAG 2.1 AA, repère les manquements (clavier, focus, structure, contraste, formulaires…) et génère la déclaration d'accessibilité prête à publier — modèle français (RGAA), allemand (BFSG), italien ou espagnol. Gratuit, sans carte bancaire.
Rapport WCAG par e-mail sous 24 h ouvrées.
C'est noté. Votre client e-mail va s'ouvrir avec la demande pré-remplie — il vous suffit de l'envoyer.
Questions fréquentes
Un scan automatique détecte-t-il les problèmes de clavier ?
En partie seulement. Un moteur comme axe-core repère certains défauts (élément interactif sans nom accessible, structure de repères manquante, valeurs de tabindex suspectes), mais il ne peut pas « ressentir » un piège au clavier, juger si l'ordre de tabulation est logique ou vérifier qu'on peut tout activer. Le test manuel au clavier reste indispensable : il prend cinq minutes et révèle l'essentiel.
Que sont l'ordre de tabulation et le tabindex ?
L'ordre de tabulation est la séquence dans laquelle le focus passe d'un élément interactif au suivant quand on appuie sur Tab. Par défaut, il suit l'ordre du code HTML. L'attribut tabindex="0" rend un élément non natif focalisable au bon endroit ; tabindex="-1" le rend focalisable par script mais hors séquence Tab. Évitez les valeurs positives (tabindex="1", "2"…) : elles forcent un ordre artificiel qui finit presque toujours par créer des incohérences.
Pourquoi ne faut-il jamais supprimer l'outline de focus ?
Parce que l'outline est, pour beaucoup de navigateurs, le seul signal visuel indiquant où se trouve le focus clavier. Le retirer (outline: none) sans le remplacer rend la navigation au clavier impossible à suivre et viole le critère 2.4.7. Si le style par défaut ne vous plaît pas, remplacez-le par un indicateur :focus-visible personnalisé et bien contrasté plutôt que de le supprimer.
Qu'est-ce qu'un lien d'évitement et est-il obligatoire ?
Un lien d'évitement (« Aller au contenu ») est un lien placé en tout début de page, souvent masqué jusqu'à ce qu'il reçoive le focus, qui permet de sauter les blocs répétés (en-tête, menu) et d'aller directement au contenu principal. C'est la façon la plus courante de satisfaire le critère 2.4.1 (Contournement de blocs), de niveau A ; une structure en repères HTML (<nav>, <main>) peut aussi y contribuer. Pour un site avec un grand menu, il est en pratique indispensable.
La navigation au clavier suffit-elle à être conforme ?
Non. C'est une base essentielle, mais la conformité EAA couvre l'ensemble des WCAG 2.1 AA : contraste des couleurs, texte alternatif des images, formulaires correctement étiquetés, contenu lisible par lecteur d'écran, etc. Un site parfaitement utilisable au clavier peut encore échouer sur d'autres critères. La navigation au clavier est néanmoins le meilleur point de départ, car beaucoup d'autres barrières s'y révèlent.