Aller au contenu

Bonnes pratiques

Navigation au clavier : focus visible, lien d’évitement et pièges (RGAA)

Tester son site au clavier en 5 minutes, rendre le focus visible, ajouter un lien d’évitement, éviter les pièges : critères 7.3, 10.7 et 12.6 à 12.9 du RGAA.

Par un auditeur RGAA d’AraspeedPublié le 4 min de lecture

Beaucoup de personnes n’utilisent pas de souris : personnes aveugles avec un lecteur d’écran, personnes avec un handicap moteur, utilisateurs de contacteurs ou de commande vocale, et beaucoup de développeurs pressés. Pour elles, un site qui ne se parcourt pas au clavier est un site fermé.

C’est aussi le test d’accessibilité le plus simple à faire soi-même : il ne demande aucun outil.

Le test des 5 minutes

Posez la souris, ouvrez votre page et appuyez sur Tab, encore et encore.

  1. Voyez-vous toujours où vous êtes ? Chaque lien, bouton ou champ doit être clairement mis en évidence quand il reçoit le focus.
  2. L’ordre est-il logique ? Le focus doit suivre l’ordre de lecture : de haut en bas, de gauche à droite.
  3. Pouvez-vous tout faire ? Ouvrir le menu, fermer la fenêtre de cookies, choisir une option, envoyer le formulaire. Entrée active un lien ou un bouton, Espace coche une case, les flèches naviguent dans un groupe de boutons radio.
  4. Pouvez-vous toujours repartir ? Si le focus reste coincé dans un élément (une vidéo, une carte, une fenêtre), c’est un piège.
  5. Pouvez-vous aller droit au contenu ? Le premier Tab devrait proposer « Aller au contenu ».

Si l’un de ces points échoue, voici les critères concernés et comment corriger.

Le focus doit être visible (critère 10.7)

L’erreur la plus répandue tient en une ligne de CSS :

/* À ne jamais faire sans le remplacer */
:focus {
  outline: none;
}

Supprimer le contour de focus rend la navigation au clavier impossible : on ne sait plus où l’on est. Si le contour par défaut ne convient pas au design, remplacez-le, ne le supprimez pas :

:focus-visible {
  outline: 3px solid #1a56db;
  outline-offset: 2px;
}

:focus-visible n’affiche le contour qu’en navigation au clavier, pas au clic de souris : c’est le bon compromis entre design et accessibilité. Vérifiez aussi que le contour reste contrasté sur tous vos fonds, y compris les boutons colorés.

Tout doit être utilisable au clavier (critère 7.3)

Un div ou un span avec un onclick n’est pas accessible au clavier : il ne reçoit pas le focus et ne réagit pas à Entrée.

<!-- Non : invisible au clavier -->
<div class="btn" onclick="ouvrirMenu()">Menu</div>

<!-- Oui : focus, Entrée et Espace gérés par le navigateur -->
<button type="button" onclick="ouvrirMenu()">Menu</button>

La règle : un lien (<a href>) pour changer de page, un bouton (<button>) pour déclencher une action. Les éléments natifs gèrent le clavier tout seuls. Recréer un bouton avec role="button" et tabindex="0" est possible, mais il faut alors gérer Entrée et Espace à la main.

Un lien d’évitement (critère 12.7)

Sans lien d’évitement, une personne au clavier doit traverser tout le menu sur chaque page avant d’atteindre le contenu. Le lien d’évitement est le premier élément de la page :

<body>
  <a href="#contenu" class="lien-evitement">Aller au contenu</a>
  <header>…</header>
  <main id="contenu" tabindex="-1">…</main>
</body>
.lien-evitement {
  position: absolute;
  transform: translateY(-200%);
}
.lien-evitement:focus {
  transform: none;
}

Il est masqué visuellement, et apparaît dès qu’il reçoit le focus.

Un ordre de tabulation cohérent (critère 12.8)

L’ordre du focus suit l’ordre du code HTML. Deux causes fréquentes de désordre :

  • un tabindex positif (tabindex="3") : il casse l’ordre naturel, à bannir ;
  • une mise en page CSS (order, grilles, position: absolute) qui affiche les éléments dans un autre ordre que celui du code.

Si l’ordre visuel et l’ordre du code divergent, corrigez le code, pas le tabindex.

Pas de piège au clavier (critère 12.9)

Un piège clavier, c’est un élément dans lequel le focus entre sans pouvoir en sortir : un lecteur vidéo intégré, une carte interactive, un éditeur de texte, une fenêtre modale mal codée. C’est l’erreur la plus bloquante : l’utilisateur doit recharger la page.

Pour une fenêtre modale, la bonne pratique est inverse : le focus doit rester dans la fenêtre tant qu’elle est ouverte, mais Échap doit la fermer et rendre le focus au bouton qui l’a ouverte. L’élément <dialog> avec showModal() le fait nativement.

Les zones de la page atteignables (critère 12.6)

Les repères HTML (<header>, <nav>, <main>, <footer>) permettent aux utilisateurs de lecteur d’écran de sauter d’une zone à l’autre. Une page qui n’utilise que des div les en prive.

Les critères en bref

Critère Ce qu’il vérifie
7.3 Les éléments interactifs fonctionnent au clavier
10.7 Le focus est visible
12.6 Les zones de la page (en-tête, menu, contenu, pied) sont atteignables
12.7 Un lien d’évitement mène au contenu
12.8 L’ordre de tabulation est cohérent
12.9 Aucun piège au clavier

Automatiser le test

Le test manuel reste indispensable, mais il est long à répéter sur chaque page. Araspeed parcourt la page au clavier comme le ferait un utilisateur et vérifie gratuitement le focus visible (10.7), les éléments cliquables inaccessibles au clavier (7.3), les zones de la page (12.6), le lien d’évitement (12.7) et les pièges (12.9). C’est justement ce que les outils comme Lighthouse ne testent pas. Voir le comparatif des outils de test.

Et votre page, elle en est où ?

Araspeed vérifie 34 critères du RGAA en moins d’une minute, gratuitement, et vous donne le code pour corriger.

Analyse de

À lire aussi