Chapitre 4.1 — Naviguer au clavier

⏱️ TL;DR — Au clavier, on se déplace entre les éléments interactifs avec Tab (et Shift+Tab pour revenir en arrière), on active avec Entrée ou Espace, on navigue dans un composant avec les flèches, et on ferme avec Échap. Seuls les éléments interactifs (liens, boutons, champs, contrôles) doivent recevoir le focus — pas le texte statique. Le critère WCAG 2.1.1 (Clavier) exige que toute fonctionnalité soit utilisable au clavier seul. Le test le plus rentable du cours : débranche ta souris et fais Tab.

🎯 Objectifs

• Connaître les touches de navigation et ce que chacune fait.
• Savoir ce qui doit être focusable — et ce qui ne doit pas l’être.
• Comprendre le critère 2.1.1 (Clavier) : tout au clavier, sans exception.
• Tester une interface au clavier en 30 secondes et repérer ce qui casse.

Les touches, une bonne fois pour toutes

La navigation au clavier repose sur un petit vocabulaire de touches. Retiens-le : il structure toute la partie.

Deux niveaux se dessinent. Tab circule entre les composants (d’un champ au bouton, du bouton au lien suivant). Les flèches circulent dans un composant (d’une option de menu à la suivante). Cette distinction est le cœur des patterns de la Partie 10 : un menu bien fait se tabule comme un tout, et ses éléments se parcourent aux flèches.

♿ Côté utilisateur — Une personne tétraplégique qui pilote son ordinateur au contacteur, ou un utilisateur de lecteur d’écran, ne « voit » pas où cliquer : il avance case par case avec Tab et écoute ce qu’on lui annonce. Si un élément n’est pas dans l’ordre de tabulation, il n’existe tout simplement pas pour lui. Le focus, c’est son curseur.

Ce qui doit être focusable (et ce qui ne doit pas)

Règle simple : seuls les éléments interactifs reçoivent le focus au Tab. Un titre, un paragraphe, une image décorative ne sont pas actionnables : ils n’ont rien à faire dans l’ordre de tabulation. Les bombarder de tabindex (voir Chapitre 4.3) ne ferait que noyer l’utilisateur sous des arrêts inutiles.

Les éléments HTML interactifs sont focusables nativement, gratuitement :

• <a href="…"> — un lien (le href est obligatoire pour qu’il soit focusable).
• <button> — un bouton.
• <input>, <textarea>, <select> — les champs de formulaire.
• <summary>, les contrôles média, les éléments avec contenteditable.

C’est l’argument massue en faveur du HTML natif (Partie 3) : en utilisant la bonne balise, tu obtiens le focus clavier sans écrire une ligne de JavaScript.

Le critère 2.1.1 : tout, au clavier

Le critère WCAG 2.1.1 (Clavier), niveau A, est l’un des plus fondamentaux : toute fonctionnalité du contenu doit être opérable au clavier seul. Pas « la plupart ». Pas « les fonctions principales ». Tout. Ouvrir un menu, glisser un curseur, fermer une notification, valider un panier : chaque action doit avoir un chemin clavier.

Le corollaire est brutal : une fonctionnalité qui n’existe qu’à la souris (survol seul, glisser-déposer sans alternative, clic sur une <div> non focusable) échoue au niveau A — le socle minimal. Ce n’est pas un raffinement AAA, c’est la base.

Ce qui casse, et pourquoi

Deux fautes reviennent en boucle. Toutes deux naissent du même réflexe : coder « pour la souris » et oublier le reste.

Faute n°1 — la <div> cliquable. Une <div> (ou un <span>) avec un onclick n’est pas focusable et n’a aucun rôle interactif. À la souris, ça « marche ». Au clavier, l’utilisateur ne peut jamais l’atteindre.

<!-- ❌ Injoignable au clavier : pas focusable, aucun rôle, aucune touche -->
<div class="btn" onclick="ajouterAuPanier()">Ajouter au panier</div>

<!-- ✅ Focusable, annoncé « bouton », activable avec Entrée ET Espace, gratuitement -->
<button type="button" onclick="ajouterAuPanier()">Ajouter au panier</button>

Faute n°2 — les gestionnaires souris seuls. Cacher une action derrière un onmouseover / onmouseout (ou un :hover en CSS pour révéler un sous-menu, sans équivalent focus) la rend inatteignable pour qui n’a pas de pointeur.

<!-- ❌ Le sous-menu n'apparaît qu'au survol souris : invisible au clavier -->
<li onmouseover="ouvrirSousMenu()" onmouseout="fermerSousMenu()">Produits</li>

<!-- ✅ Un vrai bouton qui bascule l'état : marche à la souris ET au clavier -->
<button type="button" aria-expanded="false" onclick="basculerSousMenu()">
  Produits
</button>

⚠️ Piège — Le réflexe « je vais rendre ma <div> accessible en ajoutant un onclick et un tabindex="0" » est une fausse bonne idée. Même avec ça, il te manque encore le rôle (role="button"), la gestion d’Entrée et d’Espace, et la gestion de disabled. Tu réécris à la main, mal, ce que <button> fait parfaitement. Utilise le vrai bouton.

Tester en 30 secondes

Pas besoin d’outil : le meilleur test clavier est manuel et immédiat.

1. Débranche ta souris (ou pose-la, et interdis-toi d’y toucher).
2. Recharge la page. Le focus doit partir du haut.
3. Appuie sur Tab de façon répétée et observe où va le focus.

Trois questions à te poser à chaque Tab :

• Est-ce que je vois où je suis ? (le focus doit être visible — Chapitre 4.2).
• L’ordre est-il logique ? (il doit suivre la lecture visuelle).
• Puis-je tout atteindre et tout activer ? (chaque action interactive doit être joignable).

Si un bouton est sauté, si le focus « disparaît », ou si un menu s’ouvre à la souris mais reste mort au clavier : tu as trouvé un bug bloquant.

🧭 Sur A11yLearn — Sur A11yLearn, le bouton « S’inscrire au cours » de la première maquette était une <div class="cta"> stylée, avec un onclick. À la souris, parfait. Au clavier : impossible de s’inscrire — le point d’entrée principal de la plateforme était inaccessible. Le correctif a tenu en un mot : remplacer la <div> par un <button>. Focus, Entrée, Espace et l’annonce « bouton » sont arrivés d’un coup, sans JavaScript supplémentaire.

✏️ Exercices

Exercice 1 — Rends-le accessible au clavier. Voici une carte de cours entièrement cliquable, faite en <div>. Corrige-la pour qu’on puisse l’atteindre et l’activer au clavier, sans réécrire un faux bouton à la main.

<div class="carte-cours" onclick="ouvrirCours(42)">
  <h3>Introduction à l'accessibilité</h3>
  <p>12 leçons · 3 h</p>
</div>

<div class="carte-cours">
  <h3><a href="/cours/42">Introduction à l'accessibilité</a></h3>
  <p>12 leçons · 3 h</p>
</div>

Exercice 2 — Diagnostic éclair. Un collègue affirme : « J’ai testé, tout marche. » Tu passes derrière lui au clavier et le focus saute complètement le menu de navigation. Quelle est la cause la plus probable, et quel critère WCAG est en jeu ?

🧠 Quiz de révision

Chapitre suivant : Ordre & focus visible — pourquoi l’ordre du focus doit suivre le DOM, et pourquoi tuer l’outline est l’un des pires réflexes CSS.