Pas de piège au clavier
Si le focus clavier peut atteindre un composant, il doit également pouvoir en sortir en utilisant uniquement le clavier. Les modales, les contenus embarqués et les widgets personnalisés sont les coupables habituels.
Ce que ce critère demande
Si un utilisateur peut naviguer au clavier vers un composant, il doit pouvoir en sortir avec Tab (ou Maj+Tab, ou une autre touche documentée) sans recourir à la souris. Si une touche autre que les flèches ou Tab standard est nécessaire pour quitter — par exemple Ctrl+M pour sortir d’un lecteur vidéo embarqué — l’utilisateur doit en être informé.
Cela ne doit pas être confondu avec le piège de focus à l’intérieur d’une modale, qui est un pattern souhaitable : une modale fait circuler le focus en son sein, mais le libère lorsque l’utilisateur la ferme. Un piège au clavier, c’est lorsqu’il n’existe aucun moyen documenté de sortir.
Comment y répondre
- Dans une boîte de dialogue modale, faire circuler le focus entre le premier et le dernier élément focusable avec Tab et Maj+Tab, et fermer la boîte de dialogue sur Échap en restituant le focus à l’élément déclencheur.
- Pour les contenus tiers embarqués (lecteurs vidéo, cartes, iframes de sources inconnues), vérifier si Tab continue au-delà de l’embed. Si ce n’est pas le cas, documenter la touche de sortie à proximité de l’embed.
- Pour les widgets personnalisés consommant les touches fléchées (sélecteurs de date, comboboxes, arborescences), conserver Tab comme sortie universelle — ne jamais le bloquer.
- Pour les poignées de glisser ou les éditeurs de texte enrichi qui utilisent Tab pour l’indentation, fournir une alternative documentée (Échap pour libérer, Ctrl+M pour quitter le mode édition) et l’afficher dans l’interface.
Erreurs courantes
- Boîtes de dialogue modales qui piègent le focus mais ne se ferment pas sur Échap et n’exposent pas de bouton Fermer focusable.
- Visionneuses PDF embarquées, reliques Flash et certains tableaux de bord Tableau / Power BI qui capturent Tab indéfiniment.
- Éditeurs de texte enrichi (TinyMCE, CKEditor dans ses anciennes versions) qui capturent Tab pour l’indentation et ne le libèrent jamais.
- Comboboxes personnalisées où les touches fléchées permettent de naviguer parmi les options mais Tab ne fait rien — l’utilisateur reste bloqué sur le champ de saisie.
- Bandeaux de cookies avec une gestion du focus qui tourne en boucle sans jamais proposer de focus sur Accepter / Refuser.
Les outils automatisés détectent rarement ce problème — axe et Lighthouse ne peuvent signaler que des patterns suspects. Le test manuel au clavier est la seule vérification fiable.
Pourquoi c’est important
Un piège au clavier est l’un des échecs d’accessibilité les plus graves : l’utilisateur est littéralement incapable de quitter cette partie de la page. Un utilisateur aveugle peut être contraint d’actualiser la page, perdant ainsi sa session et toute donnée saisie dans un formulaire. Pour de nombreux utilisateurs, c’est le moment où ils abandonnent le site définitivement. Parmi tous les critères WCAG, c’est celui qui rend le plus facilement une page indéfendable juridiquement — les tribunaux et les autorités de contrôle considèrent le blocage des utilisateurs comme un obstacle manifeste.