Navigation au clavier sur une landing page : focus visible, ordre de tabulation et pièges à éviter

La souris disparaît dès qu'on teste une landing page à la tabulation : chaque pression sur Tab déplace le focus d'un élément interactif au suivant, dans l'ordre où ils apparaissent dans le DOM, et rien d'autre ne permet de savoir où l'on se trouve. Ce mode de navigation n'est pas une niche marginale de l'accessibilité — il concerne les personnes ayant un handicap moteur qui ne peuvent pas utiliser de souris, les utilisateurs de lecteur d'écran qui se déplacent presque exclusivement au clavier, et une part non négligeable d'utilisateurs avancés qui remplissent un formulaire plus vite à la tabulation qu'à la souris. Sur une page conçue pour convertir en quelques secondes, un focus invisible ou un ordre de tabulation incohérent fait perdre silencieusement une partie de ces visiteurs avant même qu'ils atteignent le formulaire.

Ce que la recherche dit de la navigation clavier

Shari Trewin et Helen Pain, dans « Keyboard and mouse errors due to motor disabilities », publiée en 1999 dans l'International Journal of Human-Computer Studies (disponible sur Google Scholar), documentent les erreurs de frappe et de ciblage que rencontrent les utilisateurs ayant un handicap moteur lorsqu'une interface suppose un contrôle précis de la souris — un constat qui justifie directement pourquoi le clavier doit rester une voie de navigation complète, et non un simple repli technique. Jonathan Lazar, Aaron Allen, Jason Kleinman et Chris Malarkey, dans « What Frustrates Screen Reader Users on the Web: A Study of 100 Blind Users », publiée en 2007 dans l'International Journal of Human-Computer Interaction (disponible sur Google Scholar), montrent que les formulaires mal étiquetés et le comportement imprévisible du focus figurent parmi les principales sources de frustration relevées par les 100 utilisateurs aveugles de l'étude — or un lecteur d'écran se pilote quasi entièrement au clavier, ce qui relie directement ce constat à l'état du focus sur une page.

Le focus visible : la base non négociable

Le critère WCAG 2.4.7 (Focus visible) impose qu'à tout instant, l'élément qui a le focus clavier soit repérable visuellement, avec un contraste d'au moins 3:1 par rapport à son environnement. En pratique, le réflexe le plus répandu — et le plus dommageable — reste outline: none; appliqué globalement pour « nettoyer » l'apparence des boutons et des champs, sans rien pour le remplacer : le focus continue de se déplacer normalement, mais devient invisible pour quiconque ne peut pas s'appuyer sur la souris. La pseudo-classe :focus-visible règle le problème sans compromis esthétique, puisqu'elle n'affiche l'indicateur que lorsque la navigation se fait réellement au clavier :

button:focus-visible,
a:focus-visible,
input:focus-visible {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}

En Tailwind, l'équivalent tient en une classe utilitaire — focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-blue-600 — appliquée sur chaque bouton, lien et champ interactif du template. Le clic à la souris ne déclenche jamais cet état ; seule la tabulation le fait apparaître, ce qui évite l'argument habituel du « ça fait moche au clic ».

L'ordre de tabulation : le DOM, pas le CSS

Le focus suit l'ordre des éléments dans le DOM, pas leur position visuelle à l'écran. Un positionnement CSS (grid-column, order, position absolue) qui réorganise visuellement une section sans toucher au balisage source produit un parcours de tabulation qui saute d'un bout à l'autre de la page, dans un ordre que rien à l'écran n'explique. Sur une landing page, ce décalage apparaît le plus souvent sur les mises en page à deux colonnes (visuel à gauche, formulaire à droite en desktop, empilés en mobile) : si le DOM place le formulaire avant le visuel pour des raisons de mise en page mobile, un utilisateur clavier en desktop atteint le formulaire avant même d'avoir vu l'argumentaire qui le précède visuellement. La règle la plus fiable reste de faire correspondre l'ordre du DOM à l'ordre de lecture visuel attendu, et de réserver tabindex à deux usages précis : tabindex="0" pour rendre focusable un élément non natif (une carte cliquable en <div>, par exemple, ce qu'un <button> ou un <a> évite déjà nativement), et tabindex="-1" pour un focus programmatique (déplacer le focus vers un message d'erreur après soumission d'un formulaire). Une valeur positive (tabindex="1", "2"…) court-circuite l'ordre naturel du document et devient rapidement impossible à maintenir dès que la page évolue.

Le piège de focus dans une modale

Les popups d'inscription, les modales de confirmation et les fenêtres de capture d'email en overlay sont fréquentes sur une landing page — et c'est justement là que la navigation clavier échoue le plus souvent. Trois comportements sont attendus d'une modale accessible : à l'ouverture, le focus se déplace vers l'intérieur de la modale (typiquement son premier élément interactif ou son titre) ; tant qu'elle est ouverte, la tabulation reste piégée à l'intérieur — Tab depuis le dernier élément revient au premier, Shift+Tab depuis le premier revient au dernier — sans jamais atteindre le contenu masqué derrière l'overlay ; à la fermeture (bouton, touche Escape, ou clic hors de la modale), le focus revient précisément sur l'élément qui avait ouvert la modale, pas sur le haut de la page. Sans ce piège, la tabulation continue tout simplement de traverser les éléments cachés derrière l'overlay — un visiteur clavier peut se retrouver à remplir un champ invisible sans aucun retour visuel, ou pire, croire la modale fermée alors qu'elle recouvre toujours l'écran.

Implémenter le piège de focus en React

Plutôt que de recoder ce comportement à la main, l'élément HTML natif <dialog> gère nativement le piège de focus et la fermeture à Escape dans les navigateurs récents, et reste la base la plus simple pour une modale de capture d'email. Pour un composant plus riche (étapes multiples, validation), une bibliothèque dédiée à l'accessibilité des composants — Radix UI ou React Aria, par exemple — implémente déjà ce comportement testé sur l'ensemble des lecteurs d'écran majeurs, ce qui évite de reproduire un piège de focus maison, source fréquente de régressions au moindre changement de mise en page.

Erreurs fréquentes à corriger en premier

• outline: none; sans remplacement — supprime le focus visible pour tout le monde plutôt que de le styliser ; :focus-visible permet de personnaliser l'indicateur sans jamais le retirer complètement.
• Modale sans piège de focus — la tabulation continue derrière l'overlay, ce qui rend la page inutilisable au clavier tant que la popup est ouverte.
• Focus qui ne revient pas après fermeture — fermer une modale sans replacer le focus sur l'élément déclencheur oblige à retrouver sa position en retabulant depuis le début de la page.
• Bandeau ou CTA sticky mobile qui s'intercale — un élément fixé en bas d'écran ajouté après coup dans le DOM peut se retrouver hors de l'ordre logique de tabulation par rapport au contenu qu'il recouvre visuellement.
• Champ anti-spam (honeypot) focusable — un champ invisible destiné aux robots doit être retiré de l'ordre de tabulation (tabindex="-1" et aria-hidden="true"), sinon un utilisateur clavier tombe dessus sans comprendre à quoi il correspond.

Le test le plus rapide reste manuel : ouvrir la landing page, ne plus toucher la souris, et parcourir la page entière à Tab et Shift+Tab en observant où se pose le focus à chaque pression. Sur les dix templates React/Next.js LanderKit, ce test prend moins de deux minutes et révèle immédiatement les trois problèmes les plus fréquents — utile en particulier sur les templates qui ouvrent une popup de capture, comme SaaS Waitlist ou Webinaire & Masterclass. Ce sujet complète notre article plus général sur l'accessibilité RGAA d'une landing page, et rejoint les questions de contraste déjà abordées pour les boutons CTA et le daltonisme : un focus visible dépend lui aussi d'un contraste suffisant, pas seulement de sa présence.