Le problème

Le piège au clavier est l'un des problèmes d'accessibilité les plus critiques car il bloque totalement l'utilisateur. Le critère 12.9 du RGAA exige qu'aucun composant de la page ne piège le focus clavier : l'utilisateur doit toujours pouvoir quitter un élément interactif en utilisant Tab, Shift+Tab, Échap ou une autre touche documentée. Un piège au clavier se produit quand le focus entre dans un composant (iframe, widget JavaScript, lecteur vidéo, éditeur de texte enrichi, carte interactive) et ne peut plus en sortir. L'utilisateur appuie sur Tab indéfiniment et le focus tourne en boucle à l'intérieur du composant, sans jamais atteindre les éléments situés après. Il est alors obligé de fermer l'onglet ou de cliquer à la souris — ce qui est impossible pour les personnes qui dépendent exclusivement du clavier. Les pièges au clavier surviennent le plus souvent dans les cas suivants : widgets tiers intégrés via iframe (chatbots, lecteurs vidéo, cartes Google Maps, formulaires de paiement), éditeurs WYSIWYG (TinyMCE, CKEditor), composants de sélection de date (datepickers), et modales qui ne gèrent pas correctement la sortie du focus. Les iframes provenant de services tiers sont particulièrement problématiques car le développeur n'a pas de contrôle sur leur code interne. Certains lecteurs vidéo embarqués piègent le focus dans leurs contrôles. Certains chatbots capturent le focus dès qu'ils s'ouvrent et ne fournissent aucun mécanisme de sortie au clavier. Le RGAA considère le piège au clavier comme un défaut bloquant. C'est l'un des rares problèmes d'accessibilité qui rend une page littéralement inutilisable pour l'utilisateur affecté, sans aucune possibilité de contournement.

Votre site a-t-il ce problème ?

106 critères RGAA analysés en 5 minutes par notre IA.

Testez votre site gratuitement

Impact sur les utilisateurs

Lorsqu'un utilisateur de clavier tombe dans un piège, il est complètement bloqué. Il ne peut plus atteindre le contenu qui suit le composant piégeant, ni les liens de navigation, ni le pied de page, ni le bouton de soumission d'un formulaire. Son seul recours est de fermer l'onglet et de perdre son travail en cours. Pour une personne en situation de handicap moteur utilisant un contacteur ou un système de commande par le souffle, cette situation est encore plus frustrante car le rechargement de la page et la navigation jusqu'au point de blocage prennent beaucoup plus de temps qu'avec un clavier standard. Les personnes aveugles utilisant un lecteur d'écran sont aussi piégées : le lecteur d'écran annonce les mêmes éléments en boucle sans que l'utilisateur comprenne pourquoi il ne peut pas avancer dans la page. C'est une expérience désorientante et anxiogène. En termes de conformité, un seul piège au clavier sur un site peut faire échouer un audit d'accessibilité complet sur ce critère, car il constitue un obstacle absolu à la navigation.

Exemple de code

Avant (non conforme)
<!-- Widget chatbot qui piège le focus -->
<div id="chatbot" tabindex="0" onfocus="openChat()">
  <input type="text" placeholder="Tapez votre message...">
  <button onclick="sendMessage()">Envoyer</button>
  <!-- Pas de bouton fermer, pas de gestion de Échap -->
</div>

<!-- Modale sans gestion de focus -->
<div class="modal" style="display:block">
  <div class="modal-content">
    <input type="text">
    <button>Valider</button>
    <!-- Focus boucle entre input et button indéfiniment -->
  </div>
</div>
Après (conforme)
<!-- Chatbot avec fermeture au clavier -->
<div id="chatbot" role="dialog" aria-label="Chat d'assistance">
  <button type="button" onclick="closeChat()" aria-label="Fermer le chat">
    &times;
  </button>
  <input type="text" placeholder="Tapez votre message...">
  <button onclick="sendMessage()">Envoyer</button>
</div>
<script>
  // Fermer avec Échap
  document.addEventListener('keydown', (e) => {
    if (e.key === 'Escape') closeChat();
  });
</script>

<!-- Modale avec piège de focus contrôlé -->
<div class="modal" role="dialog" aria-modal="true" aria-label="Confirmation">
  <div class="modal-content">
    <button type="button" onclick="closeModal()" aria-label="Fermer">
      &times;
    </button>
    <input type="text">
    <button>Valider</button>
  </div>
</div>

Questions fréquentes

Comment détecter un piège au clavier sur mon site ?
Naviguez sur votre site uniquement au clavier en utilisant Tab. Si à un moment donné vous ne pouvez plus avancer (le focus tourne en boucle dans un composant) ni sortir avec Échap, vous avez un piège au clavier. Scrutia détecte automatiquement les pièges au clavier lors de son audit en simulant un parcours Tab complet de la page.
Les iframes créent-elles toujours des pièges au clavier ?
Non, pas toujours. Une iframe bien conçue permet au focus de traverser son contenu puis de revenir à la page principale. Le problème survient quand le contenu de l'iframe capture le focus sans mécanisme de sortie. C'est fréquent avec les widgets tiers mal développés. Testez chaque iframe de votre site au clavier.
Une modale doit-elle piéger le focus intentionnellement ?
Oui, mais de manière contrôlée. Une modale doit confiner le focus à l'intérieur de son contenu (c'est le « focus trapping ») pour éviter que l'utilisateur n'interagisse avec la page en arrière-plan. Mais elle doit toujours fournir un mécanisme de sortie : un bouton Fermer focusable et la touche Échap. Le focus doit revenir à l'élément déclencheur à la fermeture.
Que faire si un widget tiers crée un piège au clavier ?
Contactez le fournisseur du widget pour signaler le problème. S'il ne peut pas être corrigé, envisagez de remplacer le widget par une alternative accessible ou de l'isoler avec un mécanisme de contournement (un lien d'évitement qui permet de sauter le widget). En dernier recours, documentez le problème dans votre déclaration d'accessibilité.

Votre site a-t-il ce problème ?

Scrutia audite votre site sur 106 critères RGAA en 5 minutes. Navigation clavier, composants ARIA, focus visible, contrastes, et bien plus.

Lancer un audit gratuit