Clavier et focus visible

Pose ta souris. Maintenant, débrouille-toi.

Qui navigue un site sans souris ? Plus de monde que tu ne crois. La personne avec un handicap moteur qui ne peut pas viser un curseur. La personne malvoyante, dont le lecteur d'écran pilote tout au clavier. Le power user qui va trois fois plus vite au Tab. Et toi, le jour où ta souris rend l'âme en plein rush.

Pour tous ceux-là, le clavier n'est pas un confort : c'est la seule porte d'entrée. À la leçon 2, on a vu que le HTML sémantique fait 80 % du travail. Le clavier, c'est là que ces 80 % se vérifient ou s'effondrent.

La mécanique de Tab : l'ordre du DOM, pas du CSS

Quand tu appuies sur Tab, le navigateur déplace le focus d'un élément focusable au suivant. Règle d'or à graver : l'ordre de tabulation suit l'ordre du DOM, c'est-à-dire l'ordre des balises dans ton HTML. Pas l'ordre visuel, pas le CSS. Tu peux déplacer un bouton à droite avec float ou en haut avec order Flexbox : le Tab, lui, l'atteindra à sa position dans le code source.

Bonne nouvelle, rappel direct de la leçon 2 : les éléments natifs sont déjà focusables tout seuls. Un <a href>, un <button>, un <input>, un <select> entrent dans l'ordre de tabulation sans que tu fasses quoi que ce soit. C'est précisément la récompense d'avoir choisi la bonne balise. Une <div>, elle, n'est pas focusable : le Tab l'ignore.

Pour les cas particuliers, il existe l'attribut tabindex :

• tabindex="0" : rend focusable un élément qui ne l'est pas naturellement, à sa place normale dans l'ordre du DOM. Utile quand tu fabriques un composant custom (rare, et seulement si tu ne peux pas utiliser une vraie balise).
• tabindex="-1" : retire l'élément de l'ordre de tabulation, mais le laisse focusable par script (element.focus()). C'est ce qui permet, par exemple, de déplacer le focus vers un message d'erreur après une soumission.
• tabindex="3" et toute valeur positive : à fuir.

Le crime : outline: none

Voici la faute la plus répandue de tout le web. Par défaut, le navigateur dessine un anneau autour de l'élément focusé : c'est le focus visible. Et quelque part, un jour, un designer l'a trouvé moche. Alors quelqu'un a écrit cette ligne :

*:focus { outline: none; }

Le rendu est plus « propre ». Sauf que tu viens de crever les yeux de l'utilisateur clavier. Réfléchis : il navigue au Tab, mais il n'a aucune souris pour pointer où il en est. L'anneau était sa seule indication de position. Sans lui, le focus existe toujours (Entrée fonctionne), mais il est invisible. La personne tabule à l'aveugle, sans jamais savoir quel bouton elle va activer. C'est exactement la troisième question du test de 30 secondes qui s'effondre : « sais-tu où tu es ? » Non.

Le compromis moderne : :focus-visible

Le vrai grief du designer était subtil : l'anneau apparaissait même au clic souris, ce qui faisait « cliqué/sélectionné » de façon inélégante. La plateforme a entendu et a créé une pseudo-classe qui réconcilie tout le monde : :focus-visible. Elle n'applique le style que lorsque le navigateur juge l'anneau utile, c'est-à-dire en pratique lors d'une navigation clavier, et pas lors d'un simple clic souris sur un bouton.

/* l'anneau au clavier, pas au clic souris */
:focus-visible {
  outline: 2px solid #2b6cb0;
  outline-offset: 2px;
}

C'est exactement le :focus croisé au cours CSS (leçon sur les sélecteurs et pseudo-classes), mais en plus fin : même idée d'« état au focus », appliqué seulement quand l'utilisateur en a besoin. Le designer a son rendu propre à la souris, l'utilisateur clavier garde son repère. Personne ne perd.

À toi : répare la page inaccessible

Cette page a deux fautes. D'abord, un outline: none global qui rend le focus invisible. Ensuite, une fausse « action » bâtie sur une <div> cliquable : la souris la déclenche, mais le Tab ne l'atteint même pas. Ta mission : passer en :focus-visible avec un anneau visible, et remplacer la div par un vrai <a href> (ou <button>), naturellement focusable. Clique Exécuter, puis vérifie au Tab.

<style>
  /* l'anneau au clavier, propre à la souris */
  :focus-visible {
    outline: 2px solid #f6ad55;
    outline-offset: 2px;
  }
  .lien { /* ...inchangé... */ }
</style>

<a href="#" class="lien">Vrai lien (focusable)</a>

<!-- une vraie action = un vrai bouton -->
<button class="lien" onclick="alert('clic')">Vrai bouton</button>

Le skip link : « Aller au contenu »

Imagine un site avec un menu de 20 liens en haut de chaque page. L'utilisateur souris l'ignore : il vise directement le contenu. Mais l'utilisateur clavier, lui, doit retraverser les 20 liens au Tab, sur chaque page, avant d'atteindre l'article. À la dixième page, c'est l'abandon.

La solution est un grand classique : le skip link, un lien « Aller au contenu » placé tout en premier dans le HTML. Il est invisible tant qu'on ne le focus pas, et il apparaît au premier Tab. L'activer saute par-dessus la navigation, droit au contenu principal.

<a href="#contenu" class="skip-link">Aller au contenu</a>

<style>
.skip-link {
  position: absolute;
  top: -60px;            /* hors de l'écran par défaut */
  left: 0;
  background: #2b6cb0;
  color: #fff;
  padding: 10px 16px;
}
.skip-link:focus-visible {
  top: 0;                /* réapparaît au focus clavier */
}
</style>

Ce que WCAG 2.2 ajoute

La version 2.2 des règles d'accessibilité (WCAG) a introduit deux critères qui touchent directement le clavier et le pointage. Tu vas les rencontrer en audit.

Le chemin du Tab sur une page

Voici l'ordre dans lequel le focus voyage, en suivant le DOM. Note le skip link : c'est le tout premier arrêt, le raccourci qui saute par-dessus la nav pour aller droit au contenu.