Série Bases RGAA · Épisode 3 · 4 min

Navigation au clavier

Focus visible, boutons natifs, modales sans piège clavier.

Publié le 22 juillet 2026.Consulter la transcription de la vidéo Voir sur YouTube (nouvelle fenêtre)

Chapitres

Transcription

Texte intégral de la narration de l’épisode.

Situations du quotidien

Imagine que tu n’utilises pas la souris. Clavier seulement : Tab, Entrée, Échap, flèches. Si un menu s’ouvre uniquement au survol, si le focus disparaît, si une modale te piège : le parcours est cassé. Le RGAA exige que les fonctionnalités soient utilisables au clavier, avec un focus visible.

Naviguer sans souris

Naviguer au clavier, ce n’est pas un mode de secours rare. C’est le quotidien de beaucoup de personnes, et c’est aussi un excellent test de robustesse pour ton interface. Trois idées à retenir : atteindre les actions, voir où on est, et ne jamais rester prisonnier d’un composant.

Parcours focus (journey)

Le focus visible, critère 10.7 : quand tu tabes, tu dois voir quel élément est actif. Un contour net, un fond, un soulignement fort : peu importe la forme, tant qu’elle est claire. Supprimer le outline sans proposer d’équivalent, c’est rendre le parcours invisible. Sur cette maquette, l’élément Contact porte le focus : tu sais où tu es. Voici le même lien, deux traitements. À gauche, le focus est là en théorie, mais rien ne le montre : on tab, on est perdu. À droite, un contour de focus bien net indique l’élément actif. C’est le cœur du critère 10.7 : le focus doit se voir, pas seulement exister dans le code. Un piège fréquent : une belle carte cliquable faite avec une div et un onClick. À la souris, ça marche. Au clavier, rien. Préfère un bouton ou un lien natif. Si tu construis un composant custom, tu dois gérer le clavier et le nom accessible. Teste vraiment : Tab, Entrée, Espace, Échap. Menus, onglets, modales, carrousels : le parcours complet compte.

Rendu div vs button

Regarde la différence à l’écran. À gauche, une fausse commande en div : à la souris ça marche, au clavier rien, pas de focus. À droite, un vrai bouton : le focus se voit, Entrée et Espace activent. Le rendu dit déjà ce que le code va confirmer juste après. En code, c’est la même histoire. Une div cliquable : pas de focus natif, pas d’activation clavier standard, sémantique floue. Un bouton : le navigateur gère déjà une grande partie du comportement. Le HTML natif n’est pas ringard : c’est souvent le chemin le plus court vers un composant utilisable au clavier.

Modale : où va le focus ?

Les modales sont un cas d’école. D’abord le piège : la fenêtre s’affiche, mais le focus reste derrière, sur la page. Tab continue d’explorer ce qu’on ne voit plus clairement. Ensuite le bon comportement : le focus entre dans la modale, Tab reste dedans, et Échap permet de sortir. À la fermeture, on revient en général sur le contrôle qui a ouvert la fenêtre. Si l’utilisateur ne peut plus taber nulle part, c’est un piège clavier : bloquant, et à corriger en priorité.

Checklist

Checklist express. Tu tabes toute la page : tu atteins les contrôles utiles. Le focus reste visible. L’ordre suit à peu près la lecture visuelle. Aucun composant ne te captive sans sortie claire. Si tu fais ce test à chaque nouvelle interface, tu évites une tonne de retours d’audit.

À retenir

À retenir. Le clavier n’est pas un bonus. Focus visible, éléments atteignables, pas de piège. Pars du HTML natif, et si tu customises, assume le clavier. Prochain épisode : le lecteur d’écran et le nom accessible.

CTA

Laisse la souris cinq minutes sur un parcours critique de ton site. Note ce qui bloque. Puis corrige. Pour analyser une page et prioriser, rendez-vous sur rgaa-checker.com.

Approfondir dans le guide

Cet épisode aborde ces critères du RGAA 4.1.2. Ouvre leur fiche pour la méthode de test détaillée, les cas particuliers et les exemples.

Passer à l’action

La vidéo pose le cadre. Pour repérer des pistes d’amélioration sur un site réel, lance une analyse ou explore le guide des 106 critères.

Analyser un site Guide RGAA