Focus invisible, piège clavier : les bugs d'accessibilité que personne ne voit

Vous avez déjà utilisé un site web exclusivement au clavier ? Probablement pas. Pourtant, c'est le quotidien de millions de personnes : utilisateurs malvoyants, personnes avec des troubles moteurs, utilisateurs de technologies d'assistance. Et ce qu'ils vivent est souvent un cauchemar.

Le focus invisible : l'élément que vous ne voyez pas

Le problème

Quand vous appuyez sur Tab dans un navigateur, le focus se déplace d'un élément interactif au suivant : liens, boutons, champs de formulaire. Un indicateur visuel — généralement un contour bleu — montre quel élément est actuellement sélectionné.

Sauf que beaucoup de designers trouvent ce contour "moche". Alors ils ajoutent cette ligne CSS :

*:focus {
  outline: none;
}

Résultat : l'utilisateur navigue au clavier, mais ne sait plus où il est dans la page. C'est comme naviguer dans un site les yeux fermés.

Comment Scrutia le détecte

Scrutia simule un parcours Tab réel sur votre page et vérifie que chaque élément interactif présente un changement visuel perceptible lorsqu'il reçoit le focus. Si aucun indicateur de focus n'est visible, c'est une non-conformité (critère 10.7).

La bonne pratique

Ne supprimez jamais outline globalement. Utilisez :focus-visible si vous voulez masquer l'indicateur pour les clics souris tout en le gardant pour le clavier :

/* Masquer pour le clic souris */
button:focus:not(:focus-visible) {
  outline: none;
}

/* Garder pour le clavier */
button:focus-visible {
  outline: 2px solid #4361ee;
  outline-offset: 2px;
}

Le piège clavier : l'impasse dont on ne sort pas

Le problème

Un piège clavier (critère RGAA 12.9, bloquant) se produit quand le focus entre dans un composant et ne peut plus en sortir avec Tab ou Shift+Tab. L'utilisateur est coincé.

Cas courants :

• Éditeurs de texte embarqués (TinyMCE, CKEditor) qui capturent Tab pour l'indentation
• Lecteurs vidéo avec des contrôles personnalisés qui ne gèrent pas Tab
• Cartes interactives (Google Maps, Leaflet) qui capturent les événements clavier
• Widgets personnalisés avec tabindex et onkeydown mal implémentés

Un exemple concret

Nous avons testé un site e-commerce français populaire. En naviguant au clavier, le focus est entré dans le carrousel de la page d'accueil. Tab faisait défiler les slides au lieu de passer à l'élément suivant. Impossible de sortir sans fermer la page.

Scrutia détecte les pièges clavier automatiquement en simulant un parcours Tab complet et en vérifiant que le focus progresse toujours à travers la page.

La solution

Chaque composant qui capture Tab doit offrir un moyen d'en sortir, généralement Escape. Pour les éditeurs de texte, une convention courante est Ctrl+M pour basculer entre le mode édition et le mode navigation.

<!-- Composant accessible : Escape permet de sortir -->
<div role="application" aria-label="Carrousel"
     onkeydown="if(event.key === 'Escape') this.blur()">
  ...
</div>

Les composants ARIA qui ne fonctionnent pas au clavier

Le problème

Les menus déroulants, modales, accordéons et onglets utilisent des rôles ARIA (role="menu", role="dialog", role="tablist"). Mais poser un rôle ARIA ne rend pas un composant accessible — c'est comme mettre un panneau "Sortie de secours" sur une porte qui ne s'ouvre pas.

Le W3C publie les APG Design Patterns qui définissent le comportement clavier attendu pour chaque composant :

Menu :

• Enter ou Espace : ouvrir le menu
• Flèches haut/bas : naviguer entre les items
• Escape : fermer le menu
• Tab : quitter le menu

Modale :

• Le focus doit être piégé dans la modale (boucle entre le premier et le dernier élément focusable)
• Escape ferme la modale
• Le focus retourne à l'élément déclencheur après fermeture

Onglets :

• Flèches gauche/droite : changer d'onglet
• Tab : entrer dans le panneau de contenu de l'onglet actif

Ce que nous avons observé

Sur nos 5 audits de sites français :

• 3 sites ont des menus qui ne répondent pas au clavier (seul le clic souris fonctionne)
• 2 sites ont des modales qui ne piègent pas le focus (Tab sort de la modale)
• 1 site a des onglets qui ne répondent pas aux flèches

Comment Scrutia teste

Scrutia détecte automatiquement les composants ARIA sur la page et vérifie qu'ils respectent les patterns d'interaction clavier définis par les APG Design Patterns du W3C.

Le coût humain

Un focus invisible, c'est naviguer à l'aveugle. Un piège clavier, c'est être enfermé. Un composant ARIA non fonctionnel, c'est une porte fermée.

Pour un utilisateur voyant avec une souris, ces problèmes sont totalement invisibles. Le site fonctionne parfaitement. Mais pour les 15% de la population mondiale en situation de handicap (source : OMS), ces bugs transforment un site web en obstacle.

Ce que vous pouvez faire maintenant

1. Naviguez sur votre site avec Tab uniquement. Pouvez-vous atteindre tous les liens et boutons ? Voyez-vous toujours où vous êtes ? Pouvez-vous sortir de chaque composant ?

2. Testez vos composants interactifs au clavier. Vos menus s'ouvrent-ils avec Enter ? Vos modales se ferment-elles avec Escape ? Vos onglets se naviguent-ils avec les flèches ?

3. Lancez un audit automatisé. Les scanners classiques ne détectent pas ces problèmes. Utilisez un outil qui teste les interactions réelles.

L'accessibilité clavier n'est pas un "nice to have". C'est la base de l'accessibilité web. Et depuis l'European Accessibility Act de juin 2025, c'est une obligation légale.