Pièges au clavier : Un frein majeur à l'accessibilité web

Imaginez naviguer sur un site web et vous retrouver soudainement bloqué, incapable de continuer. C'est exactement ce que vivent les utilisateurs qui rencontrent un piège au clavier. Ce problème d'accessibilité critique affecte les personnes qui ne peuvent pas utiliser une souris.

Qu'est-ce qu'un piège au clavier ?

Un piège au clavier (keyboard trap en anglais) se produit lorsque le focus clavier entre dans un élément de la page mais ne peut plus en sortir en utilisant uniquement le clavier. L'utilisateur se retrouve littéralement "piégé" dans un composant.

Le critère WCAG 2.1.2 "Pas de piège au clavier" est un critère de niveau A, le niveau de base de la conformité. Un site qui échoue à ce critère ne peut pas être considéré comme accessible.

[!NOTE] Ce problème touche particulièrement les utilisateurs aveugles, les personnes avec des handicaps moteurs et tous ceux qui préfèrent ou doivent naviguer au clavier.

Les causes fréquentes

Modales et dialogues mal implémentés

Les fenêtres modales sont la source numéro un des pièges au clavier. Une modale correcte doit :

• Capturer le focus à l'ouverture
• Confiner le focus à l'intérieur pendant qu'elle est ouverte
• Permettre la fermeture avec Échap
• Restaurer le focus à l'élément déclencheur après fermeture

Le problème survient souvent quand le confinement du focus empêche toute sortie, même après tentative de fermeture.

Plugins et widgets embarqués

Les contenus tiers posent de nombreux problèmes :

• Lecteurs vidéo Flash ou Silverlight (obsolètes)
• Cartes Google Maps mal configurées
• Widgets de réseaux sociaux
• Chatbots et outils de support client
• Éditeurs de texte enrichi (WYSIWYG)

Scripts personnalisés défaillants

Du JavaScript mal écrit peut créer des pièges involontaires :

// MAUVAIS : boucle infinie du focus
element.addEventListener('keydown', (e) => {
  if (e.key === 'Tab') {
    e.preventDefault(); // Bloque la navigation !
    // Logique de focus mal implémentée
  }
});

Comment détecter les pièges au clavier

Test manuel simple

La méthode la plus fiable reste le test manuel :

1. Ouvrez la page à tester
2. Cliquez dans la barre d'adresse (pour partir d'un point neutre)
3. Appuyez sur Tab pour naviguer dans la page
4. Continuez jusqu'à atteindre le bas de la page
5. Utilisez Shift+Tab pour remonter
6. Vérifiez que vous pouvez sortir de tout élément interactif

Si vous restez bloqué quelque part, vous avez trouvé un piège.

Points de vigilance

Testez particulièrement :

• Les menus déroulants
• Les modales et popovers
• Les carrousels et sliders
• Les formulaires complexes
• Les iframes et embeds
• Les éditeurs de texte
• Les sélecteurs de date

[!TIP] Utilisez notre outil d'audit RGAA pour détecter automatiquement certains pièges au clavier avant un test manuel approfondi.

Solutions techniques

Modales accessibles

Une modale conforme au WCAG doit implémenter :

<div role="dialog"
     aria-modal="true"
     aria-labelledby="modal-title"
     tabindex="-1">
  <h2 id="modal-title">Titre de la modale</h2>
  <p>Contenu de la modale</p>
  <button>Fermer</button>
</div>

Le JavaScript associé doit gérer :

• Le confinement du focus (focus trap volontaire et contrôlé)
• La fermeture avec Échap
• La restauration du focus

Méthodes de sortie alternatives

Quand un composant nécessite légitimement de confiner le focus (comme une modale), il DOIT offrir une méthode de sortie claire :

• Bouton de fermeture visible et accessible
• Touche Échap fonctionnelle
• Clic en dehors (pour souris)
• Instructions si méthode non standard

Informer l'utilisateur

Si la méthode de sortie n'est pas évidente (ni Tab, ni Échap), le composant doit informer l'utilisateur :

<div role="application" aria-describedby="nav-instructions">
  <!-- Widget complexe -->
  <p id="nav-instructions" class="sr-only">
    Utilisez les flèches pour naviguer, Entrée pour sélectionner,
    Échap pour quitter.
  </p>
</div>

Cas particuliers autorisés

Le WCAG reconnaît que certains cas légitimes nécessitent un confinement temporaire du focus :

Modales modales

Une vraie modale (dialog) confine le focus pour empêcher l'interaction avec le contenu en arrière-plan. C'est un comportement attendu ET accessible si :

• Un bouton de fermeture est présent
• Échap ferme la modale
• Le focus est restauré après fermeture

Applications complexes

Certains widgets comme les tableurs ou éditeurs graphiques peuvent nécessiter une navigation non standard. Dans ce cas :

• Documentez les raccourcis
• Offrez une méthode de sortie claire
• Indiquez le mode de navigation

Impact sur les utilisateurs

Les pièges au clavier ont des conséquences graves :

Un seul piège au clavier peut rendre un site entier inutilisable pour ces populations.

Prévention et bonnes pratiques

Pendant le développement

1. Utilisez des composants testés : les bibliothèques comme Radix UI, Headless UI ou React Aria gèrent correctement le focus
2. Testez au clavier : intégrez le test clavier dans votre workflow
3. Évitez preventDefault sur Tab : sauf si vous gérez explicitement le focus
4. Attention aux iframes : vérifiez que le contenu embarqué est accessible

Lors de l'intégration de tiers

• Testez chaque widget avant intégration
• Vérifiez les options d'accessibilité du service
• Prévoyez une alternative si le widget n'est pas accessible
• Documentez les problèmes connus

En maintenance

• Auditez régulièrement les parcours critiques
• Testez après chaque mise à jour de dépendances
• Surveillez les retours utilisateurs

Conclusion

Les pièges au clavier représentent une violation grave de l'accessibilité car ils bloquent complètement certains utilisateurs. Heureusement, ils sont relativement simples à détecter et à corriger.

Intégrez le test clavier dans votre processus de développement et consultez notre guide complet du RGAA pour maîtriser tous les critères liés à la navigation au clavier.