Qu'est-ce que l'ordre de navigation au clavier ?

Qu'est-ce que l'ordre de navigation au clavier ?

L'ordre de navigation au clavier, aussi appelé ordre de tabulation ou ordre du focus, est la séquence dans laquelle les liens, boutons et champs de formulaire reçoivent le focus quand on appuie sur Tab. Il doit correspondre au sens et au déroulement visuel de la page. Le critère WCAG 2.4.3 Parcours du focus (niveau A) exige que les composants focalisables reçoivent le focus dans un ordre qui préserve le sens et l'utilisabilité.

Comment il fonctionne

Par défaut, l'ordre suit le code HTML. Les éléments focalisables nativement, comme les liens avec href, les boutons, champs, listes de sélection, textareas, iframes et éléments summary, sont parcourus dans l'ordre où ils apparaissent dans le document. Trois choses le modifient (voir MDN sur tabindex) :

• tabindex="0" rend un élément accessible par Tab selon l'ordre du code.
• tabindex="-1" le retire de la séquence de Tab mais permet à un script de lui donner le focus, utile pour une fenêtre modale qui s'ouvre ou un message d'erreur après un envoi raté.
• Un tabindex positif le place avant tout le reste. MDN recommande de n'utiliser que 0 et -1, car les valeurs positives et le CSS qui réordonne des éléments focalisables compliquent la navigation des personnes qui utilisent le clavier et des technologies d'assistance.

Le piège : le CSS peut déplacer visuellement les éléments (ordre flexbox, grille, positionnement absolu) alors que le focus continue de suivre le code. Le focus saute alors à travers l'écran.

Les critères WCAG concernés

L'ordre au clavier relève d'un petit groupe de critères des Web Content Accessibility Guidelines (WCAG) (source : documents Understanding du W3C pour WCAG 2.2) :

• 2.1.1 Clavier (A) : toutes les fonctionnalités sont utilisables au clavier, avec de rares exceptions pour les saisies qui dépendent du tracé, comme le dessin à main levée.
• 2.1.2 Pas de piège au clavier (A) : si le focus peut entrer dans un composant au clavier, il peut en sortir au clavier, et l'utilisateur est informé si cela demande plus que Tab ou les flèches.
• 2.4.3 Parcours du focus (A) : l'ordre préserve le sens et l'utilisabilité. Il n'a pas à reproduire la mise en page visuelle, mais ne doit pas sauter au hasard.
• 2.4.7 Focus visible (AA) : l'indicateur de focus du clavier est visible.
• 2.4.11 Focus non masqué, minimum (AA, nouveau dans WCAG 2.2) : un composant qui reçoit le focus n'est pas entièrement masqué par un contenu créé par l'auteur, comme un en-tête fixe ou une bannière de cookies.

Exemple : un formulaire de paiement

Un formulaire affiche Nom, Adresse et Numéro de carte en colonne, mais une règle CSS place visuellement le bouton Payer en bas alors qu'il est en premier dans le HTML. Au clavier, on tabule depuis le haut et on tombe sur Payer avant d'avoir rempli quoi que ce soit. La solution consiste à ordonner le HTML comme les gens utilisent les éléments, et non à ajouter des valeurs de tabindex. Si un en-tête fixe cache le champ ciblé quand on descend avec Tab, ajoutez un scroll-padding pour que le champ reste visible.

Erreurs courantes

• Corriger l'ordre avec un tabindex positif. Cela crée un second ordre caché qui casse dès qu'on ajoute un champ.
• Masquer le contour du focus. Supprimer l'outline sans le remplacer échoue au critère Focus visible.
• Des div cliquables. Un div avec un gestionnaire de clic n'est pas focalisable. Utilisez un bouton ou un lien ; les rôles ARIA n'ajoutent pas à eux seuls un comportement clavier.
• Des modales qui perdent ou piègent le focus. Placez le focus dans la boîte de dialogue à l'ouverture, gardez-le à l'intérieur tant qu'elle est ouverte, prévoyez une fermeture au clavier et rendez le focus au déclencheur ensuite.
• Du contenu hors écran toujours accessible par Tab. Des menus cachés visuellement mais focalisables font disparaître le focus.
• Ne tester qu'à la souris. Les problèmes d'ordre n'apparaissent que lorsqu'on appuie sur Tab.

Ordre du clavier, tests et surveillance

Le test est manuel : lâchez la souris, parcourez la page avec Tab et Maj+Tab, et vérifiez que chaque contrôle est atteignable, que le focus reste toujours visible et que l'ordre a du sens. Un passage avec un lecteur d'écran offre un second regard sur la même structure. Les audits automatiques repèrent les étiquettes manquantes et certains problèmes de focus, mais ne jugent pas si l'ordre a du sens ; lisez notre article sur la raison pour laquelle les tests de performance doivent inclure l'accessibilité. Pour surveiller les régressions, la surveillance de vitesse de LoadFocus lance des audits Lighthouse planifiés et suit le score Accessibility en plus des performances. Complétez avec un test manuel à la touche Tab sur les pages clés et voyez comment concevoir une mise en page accessible.

Questions fréquentes : ordre de navigation au clavier

Quel est l'ordre de tabulation par défaut ?

L'ordre des éléments focalisables dans le code HTML. La position visuelle ne compte pas, d'où les sauts de focus déroutants que peut causer un réordonnancement CSS.

Faut-il utiliser un tabindex positif ?

Presque jamais. MDN recommande seulement 0 et -1. Réorganisez plutôt le HTML de façon logique.

Quels critères WCAG couvrent la navigation au clavier ?

Les principaux sont 2.1.1 Clavier, 2.1.2 Pas de piège au clavier, 2.4.3 Parcours du focus, 2.4.7 Focus visible et, dans WCAG 2.2, 2.4.11 Focus non masqué (minimum). Les trois premiers sont de niveau A, les deux derniers de niveau AA.

Qu'est-ce qu'un piège au clavier ?

Un composant dans lequel le focus du clavier entre mais dont il ne peut pas sortir avec le seul clavier, par exemple un widget intégré mal conçu. WCAG 2.1.2 l'interdit.

L'ordre du focus doit-il suivre l'ordre visuel ?

Pas exactement. WCAG exige un ordre qui préserve le sens et l'utilisabilité, et plusieurs ordres peuvent être valides. Il doit tout de même paraître logique et ne pas sauter.