WCAG A Prestataire Moyen

Y a-t-il des endroits sur votre site où la navigation au clavier se bloque — impossible de continuer sans utiliser la souris ?

Critère officiel 12.9 — Dans chaque page web, la navigation ne doit pas contenir de piège au clavier. Cette règle est-elle respectée ?

Pourquoi c'est important

Un utilisateur piégé dans un élément interactif — carte Google Maps, lecteur PDF intégré, widget externe — ne peut plus avancer ni reculer au clavier. La seule issue est d'utiliser la souris ou de fermer le navigateur et de tout recommencer, avec perte de l'endroit où il en était.

Exemples concrets

Ce qui est conforme

La carte Google Maps intégrée sur la page « Contact » peut être atteinte par Tab, explorée avec les flèches, et quittée avec Échap ou Maj+Tab. Aucun élément ne capture le focus de façon permanente.

Ce qui pose problème

La même carte capte le focus dès qu'on y entre au clavier. Tab ne fait que parcourir les contrôles internes de la carte à l'infini. Échap ne fonctionne pas. L'utilisateur est bloqué — la seule sortie est la souris.

Comment agir

Test autonome : naviguez à Tab sur chaque élément interactif de vos pages (cartes, lecteurs vidéo, carrousels, widgets externes). Vous devez toujours pouvoir en sortir par Maj+Tab ou Échap. Si vous êtes bloqué quelque part, notez l'élément précis et signalez-le à votre prestataire — les pièges au clavier proviennent souvent de composants tiers mal intégrés.

Mise en œuvre avec WordPress FSE

Dans l'éditeur, sans code

Les blocs natifs de WordPress FSE (Navigation, Détails, Modale, Menu en accordéon) ne créent pas de piège au clavier : la touche Tab permet toujours d'entrer et de sortir de l'élément, la touche Échap ferme les modales et les menus déroulants. Les pièges au clavier apparaissent généralement quand votre prestataire ajoute un bloc tiers ou un widget JavaScript personnalisé mal conçu — typiquement un carrousel, une pop-up d'inscription à la newsletter, une vidéo embarquée avec overlay. Pour tester : naviguez votre page uniquement avec Tab et Maj+Tab. Si le focus reste bloqué à l'intérieur d'un élément sans pouvoir en sortir, vous tenez un piège : demandez à votre prestataire de le corriger ou de désactiver le composant concerné.

Section complémentaire pour les sites utilisant WordPress en édition complète (FSE). Les principes RGAA exposés plus haut s'appliquent à tous les CMS.

Règles clés

Une modal ouverte DOIT avoir un focus trap actif (Tab/Shift+Tab circulent uniquement dans la modal) — c'est une exigence APG, pas un bug.
Toute zone avec focus trap doit offrir une sortie accessible : touche Échap ET bouton de fermeture focusable dans le DOM.
À la fermeture d'une modal, le focus doit retourner sur l'élément déclencheur — pas être perdu dans le vide.
Les iframes tierces posent un problème structurel : signaler dans le rapport si la sortie clavier est impossible, même avec un titre correct.
Tester systématiquement : entrer dans chaque composant interactif au clavier et vérifier qu'on peut en sortir.

Erreurs fréquentes

Modal qui piège le focus mais ne peut pas être fermée avec Échap
Bannière cookies dont le focus entre mais ne permet pas d'en sortir sans interaction souris
iframe embarquant un lecteur vidéo ou une carte dont le focus entre et ne ressort plus
Éditeur de texte riche (TinyMCE) dont Tab insère une tabulation au lieu de passer au champ suivant
Menu mobile dont le focus trap reste actif après fermeture

Exemples de code

modal — focus trap sans sortie

✗ Non conforme

// Focus trap actif sur Tab/Shift+Tab
// Mais :
// - Aucun listener sur la touche Échap
// - Bouton fermer non focusable ou absent du DOM
document.addEventListener('keydown', e => {
  if (e.key === 'Tab') trapFocus(modalEl, e);
  // Jamais de : if (e.key === 'Escape') fermerModal()
});

L'utilisateur entre dans la modal et ne peut plus en sortir. Le piège est actif sans porte de sortie — c'est un keyboard trap au sens WCAG 2.1.2.

modal — focus trap correct avec sortie

✓ Conforme

function ouvrirModal(triggerEl, modalEl) {
  modalEl.removeAttribute('hidden');
  const focusables = modalEl.querySelectorAll(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  focusables[0]?.focus();
  modalEl._trigger = triggerEl;

  modalEl.addEventListener('keydown', function gestionnaire(e) {
    const premier = focusables[0];
    const dernier = focusables[focusables.length - 1];
    if (e.key === 'Tab') {
      if (e.shiftKey && document.activeElement === premier) {
        e.preventDefault(); dernier.focus();
      } else if (!e.shiftKey && document.activeElement === dernier) {
        e.preventDefault(); premier.focus();
      }
    }
    if (e.key === 'Escape') fermerModal(modalEl);
  });
}

function fermerModal(modalEl) {
  modalEl.setAttribute('hidden', '');
  modalEl._trigger?.focus(); // retour au déclencheur
}

Focus trap complet avec double sortie : Échap ferme et rend le focus au déclencheur ; le bouton fermer dans le DOM fait de même. Tab/Shift+Tab circulent dans la modal. Le piège est intentionnel et contrôlé.

iframe tierce sans sortie clavier

✗ Non conforme

<!-- Carte Google Maps embarquée -->
<iframe src="https://maps.google.com/maps?..."></iframe>

Sans titre, l'iframe est non identifiable (critère 2.1). Selon le contenu et le navigateur, il peut être impossible de sortir de l'iframe avec Shift+Tab après y être entré.

iframe — titre présent, sortie à vérifier

✓ Conforme

<iframe
  src="https://maps.google.com/maps?..."
  title="Carte — Localisation de notre agence à Brest"
></iframe>

Le title est obligatoire (critère 2.1). La sortie clavier depuis une iframe tierce dépend du contenu interne sur lequel on n'a pas la main — documenter le résultat du test dans le rapport.

Référence WCAG : 2.1.1, 2.1.2

⚠ Pourquoi c'est important

Exemples concrets

✓ Ce qui est conforme

✗ Ce qui pose problème

💡 Comment agir

✓ Règles clés

⚠ Erreurs fréquentes