Ordre de tabulation et gestion du focus : comment faciliter la navigation pour tous les utilisateurs ?

Le focus, un repère indispensable

Le focus clavier désigne l'élément actif à un instant donné : celui qui recevra le prochain clic de la touche Entrée. La touche Tab déplace ce focus d'un élément interactif à l'autre et Maj + Tab le fait reculer.
Pour rappel, les éléments interactifs sont les liens, les boutons, les champs de formulaire et les autres éléments HTML spécifiques qui reçoivent le focus nativement (ex : details/summary). Comme leur nom l’indique, les éléments de la page avec lesquels les utilisateurs peuvent interagir.

Pour revenir au focus, sans indicateur visuel clair de sa position dans la page, un utilisateur qui navigue au clavier perd tout repère : il ne sait plus où il se trouve sur la page, ni ce qui se passera s'il appuie sur Entrée. Sa présence est absolument nécessaire pour les personnes qui n'utilisent pas de souris (ex : handicap moteur) mais représente aussi un vrai confort pour toute personne qui préfère, ponctuellement, naviguer sans dispositif de pointage (souris).

Comment fonctionne l'ordre de tabulation par défaut

Par défaut, le navigateur parcourt les éléments focusables (éléments interactifs) dans l'ordre où ils apparaissent dans le code source, c'est-à-dire l'ordre du DOM. Les liens, boutons, champs de formulaire et autres éléments interactifs natifs reçoivent le focus automatiquement, dans cet ordre, sans configuration particulière.

C'est une bonne nouvelle : un HTML structuré de façon logique (ex : le menu avant le contenu, le contenu avant le pied de page, les champs d'un formulaire dans l'ordre où ils doivent être remplis) produit naturellement un ordre de tabulation cohérent. Le problème apparaît surtout quand le CSS réorganise visuellement des éléments (via flex-direction, order ou un positionnement absolu) sans que l'ordre du DOM ne suive : l'utilisateur voit alors un élément à un endroit, mais le focus saute ailleurs, de façon incohérente avec ce qu'il voit à l'écran.

Utiliser l'attribut tabindex sans en abuser

L'attribut tabindex permet de modifier le comportement par défaut du focus. Trois valeurs sont possibles, mais une seule est réellement à éviter :

• tabindex="0" rend focusable un élément qui ne l'est pas nativement (une <div> ou un <span> transformée en composant interactif, par exemple). C'est une valeur utile mais à réserver aux cas où un élément HTML natif (bouton, lien, champ de formulaire) ne peut vraiment pas être utilisé à la place. L’utilisation du HTML natif (boutons, liens) est toujours à privilégier.
• tabindex="-1" fait agit de deux façons différentes.
  Placé sur un élément interactif, il le retire de l'ordre de tabulation. L’élément n’est plus pris au focus, il n’est donc plus utilisable au clavier.
  Placé sur un élément non-tabulable (ex : <div>, <span>, paragraphe <p>), l’élément peut alors recevoir le focus par un script via la méthode JavaScript element.focus();. C'est la valeur utilisée pour envoyer le focus à un endroit précis.
• Les valeurs positives (tabindex="1", tabindex="2", etc.) créent un ordre de tabulation artificiel, sans aucun rapport avec la structure HTML de la page. Le focus suivra alors l’ordre des tabindex présents sur les éléments (1, 2, 3, etc.). Un attribut tabindex positif mal placé dans une page suffit à casser la logique de navigation. Cette pratique est déconseillée : si un élément doit apparaître plus tôt dans l'ordre de tabulation, la bonne solution est de le déplacer dans le code source et non pas de forcer artificiellement sa position.

Le piège au clavier : un blocage total

Un piège au clavier se produit lorsqu'un utilisateur entre dans un élément avec Tab mais ne peut plus en ressortir. C'est l'un des problèmes les plus bloquants qui existent en accessibilité clavier : contrairement à un simple inconfort, il empêche littéralement de continuer à utiliser le site.

Les cas les plus fréquents :

• Une fenêtre modale sans moyen de la fermer au clavier.
• Un éditeur de texte enrichi qui capture la touche Tab pour gérer l'indentation du texte, sans prévoir de moyen d'en sortir.
• Un composant personnalisé (menu, sélecteur de date) duquel il est impossible de sortir au clavier.

La règle à retenir : tout élément qui reçoit le focus doit pouvoir être atteint mais aussi quitté au clavier.

La visibilité du focus

Le focus doit toujours être visible à l'écran, sous une forme suffisamment contrastée (rapport de contraste d’au minimum 3:1 par rapport à l’arrière-plan).

L'erreur la plus fréquente et la plus impactante pour les utilisateurs reste l'utilisation de la propriété CSS outline: none; , sans remplacement. Ce réflexe, souvent motivé par une volonté esthétique (le contour par défaut du navigateur est jugé "moche"), supprime purement et simplement le seul repère visuel dont dispose un utilisateur au clavier ou avec une technologie d’assistance spécifique. Si le style par défaut ne convient pas, la bonne pratique est de le remplacer par un style personnalisé tout aussi visible.

Gérer le focus dans les composants dynamiques (modales et autres)

Pour les composants complexes, une fenêtre modale, un menu déroulant complexe ou des onglets personnalisés, par exemple, n’existent pas nativement en HTML. Il est donc nécessaire de prendre en compte la gestion du focus lors de leur développement.

Prenons l’exemple d’une fenêtre modale : à l'ouverture, le focus doit être envoyé à l'intérieur de la fenêtre, à la fermeture, il doit revenir sur l'élément qui avait ouvert la modale.

Ce type de comportement attendu existe pour la plupart des composants courants (modale, menu, onglets, accordéon, carrousel...). En cas de doute sur la façon dont le focus doit se comporter pour un composant donné, les modèles de conception ARIA du W3C constituent une référence fiable pour s'en inspirer, plutôt que de réinventer un comportement au cas par cas.

Les erreurs les plus fréquentes à éviter

• Utiliser des valeurs positives de tabindex qui cassent l'ordre naturel de navigation.
• Réorganiser visuellement des éléments en CSS sans que l'ordre du DOM ne suive, créant un décalage entre ce que l'utilisateur voit et ce que le focus parcourt.
• Supprimer l'indicateur visuel de focus (outline: none;) sans le remplacer par un style tout aussi visible.
• Oublier de gérer le focus après une action dynamique (ouverture de modale, affichage d'un message), laissant l'utilisateur sans aucun repère sur ce qui vient de se passer.

Comment tester

Le test le plus simple et le plus révélateur reste manuel : parcourir l'intégralité d'une page avec la seule touche Tab (et Maj + Tab pour reculer) en observant si l'ordre suit une logique cohérente, si le focus reste toujours visible et si chaque élément atteint peut aussi être quitté.

Vous voulez vérifier la gestion du focus sur votre site ? Découvrez nos offres d'audit d'accessibilité, pour identifier potentiels les points de blocage de vos utilisateurs.

Conclusion : un détail technique, un vrai confort de navigation

L'ordre de tabulation et la gestion du focus reposent sur des principes techniques précis mais leur enjeu est avant tout humain : permettre à chacun de savoir où il se trouve sur une page et de s'y déplacer sans se perdre ni rester bloqué. Un HTML bien structuré évite déjà la majorité des problèmes. Le reste se joue dans la rigueur apportée aux composants personnalisés, là où le comportement par défaut du navigateur ne suffit plus.