WCAG 2.4.12 : Focus non masqué (amélioré)

Ce que signifie cette règle

WCAG 2.4.12 — Focus non masqué (amélioré) — est l’équivalent AAA de WCAG 2.4.11 (Focus non masqué, AA). Alors que le critère AA permet qu’un composant ayant le focus soit partiellement visible, le critère AAA exige que le composant ayant le focus soit entièrement visible — aucune partie de celui-ci ne peut être masquée par un contenu créé par l’auteur lorsqu’il reçoit le focus clavier.

Concrètement, cela signifie que lorsqu’un utilisateur navigue avec la touche Tab jusqu’à un élément interactif comme un lien, un bouton, un champ de formulaire ou un widget personnalisé, la zone englobante complète de cet élément doit être dégagée de tout en-tête fixe, pied de page fixe, superposition modale, bannière de cookies, widget de chat ou tout autre contenu placé sur la page par l’auteur. La règle vise spécifiquement le contenu créé par l’auteur ; le W3C fait une exception explicite pour le contenu que l’utilisateur lui-même a déplacé de manière à masquer l’indicateur de focus — par exemple, un panneau flottant que l’utilisateur a fait glisser devant l’élément ayant le focus. Dans ce cas, l’auteur n’est pas responsable.

Pour satisfaire au critère 2.4.12, il faut qu’au moment où un élément reçoit le focus, l’intégralité du composant ayant le focus soit visible dans la fenêtre d’affichage et ne soit recouverte par aucun élément fixe, collant (sticky) ou positionné en absolu que l’auteur de la page contrôle. Un échec se produit lorsque n’importe quelle portion de la bordure visible de l’élément ayant le focus est cachée derrière de telles superpositions — même un seul pixel de l’anneau de focus ou du composant lui-même coupé est considéré comme un échec au niveau AAA.

Il est important de comprendre ce que 2.4.12 ne couvre pas. Il n’impose pas un style particulier d’indicateur de focus (ce point est traité par 2.4.11 et 2.4.7). Il n’exige pas que les indicateurs de focus aient un ratio de contraste minimal (couvert par 2.4.13). Il traite spécifiquement de la relation spatiale entre l’élément ayant le focus et les autres contenus de la page — le problème de superposition qui découle le plus souvent de l’utilisation de positionnements fixed et sticky en CSS.

Les éléments HTML concernés incluent tout élément focalisable ou atteignable par Tab : <a>, <button>, <input>, <select>, <textarea>, <details>, les éléments avec tabindex, et les widgets interactifs personnalisés construits avec des rôles ARIA. Le critère s’applique à tous les contextes de navigation, y compris les iframes, les boîtes de dialogue et les transitions de routes dans les applications monopage.

Pourquoi c’est important

La navigation au clavier est un mode d’accès principal pour un large éventail d’utilisateurs. Les personnes ayant des troubles moteurs — y compris celles vivant avec des pathologies telles que la SLA, la sclérose en plaques, la paralysie cérébrale ou des troubles musculo-squelettiques liés à des mouvements répétitifs — s’appuient entièrement sur le clavier ou sur des dispositifs d’accès par contacteurs plutôt que sur une souris. Les personnes aveugles ou malvoyantes utilisant des lecteurs d’écran naviguent également au clavier, et même si leur technologie d’assistance annonce la position du focus à l’oral, les utilisateurs voyants qui se servent du clavier dépendent entièrement de l’indicateur visuel de focus pour s’orienter sur la page.

Lorsque l’élément ayant le focus est masqué, même partiellement, ces utilisateurs se retrouvent face à une expérience frustrante et potentiellement désorientante : la page semble ne proposer aucun élément ayant le focus, ou l’utilisateur doit deviner où il se trouve dans le document. Au niveau AA (2.4.11), la visibilité partielle est tolérée — au moins une partie du composant est visible, fournissant un indice. Le critère AAA élimine complètement ce compromis, en reconnaissant que même un indicateur de focus partiellement masqué peut être manqué par des utilisateurs ayant une sensibilité au contraste réduite, une vision tubulaire ou des troubles cognitifs qui rendent le balayage visuel de l’écran plus difficile.

Considérons un scénario concret : un site e-commerce turc utilise une barre de navigation fixe de 80px de hauteur en haut de la fenêtre d’affichage et une bannière de consentement aux cookies collante de 60px de hauteur en bas. Un utilisateur qui appuie sur Tab pour naviguer parmi les cartes produits peut constater que le bord supérieur ou inférieur de la carte ayant le focus — y compris son anneau de focus — passe sous l’une de ces surfaces fixes. Selon WCAG 2.4.11 (AA), si une partie quelconque de la carte reste visible, le site est conforme. Selon 2.4.12 (AAA), la carte entière doit être entièrement visible. Cette distinction est significative : une étiquette de bouton partiellement masquée combinée à un anneau de focus partiellement masqué peut rendre réellement impossible pour un utilisateur malvoyant de déterminer quel élément est actif ou quelle action il effectuera.

Selon l’Organisation mondiale de la Santé, environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, et les handicaps moteurs en touchent des centaines de millions d’autres. Les améliorations de l’accessibilité clavier profitent non seulement à ces groupes, mais aussi aux utilisateurs avancés qui préfèrent la navigation au clavier pour sa rapidité, aux utilisateurs sur des appareils dépourvus de dispositif de pointage, et aux utilisateurs dont la motricité fine est temporairement altérée.

Au-delà de l’accès pour les personnes handicapées, un focus entièrement visible améliore l’ergonomie générale et réduit les coûts de support. Lorsque tous les utilisateurs — y compris ceux sans handicap — peuvent suivre clairement la position du focus, les taux de complétion des formulaires augmentent et les taux d’erreur diminuent. Pour les sites ciblant le marché turc, démontrer une conformité AAA signale un programme d’accessibilité mature et renforce la confiance des utilisateurs comme des équipes d’achats institutionnels.

Règles axe-core associées

WCAG 2.4.12 est classé comme nécessitant un test manuel et fait partie des ajouts de WCAG 2.2. Il n’existe aucune règle axe-core entièrement automatisée capable de détecter de manière fiable cette violation, et comprendre pourquoi est important pour les équipes qui construisent leurs chaînes de tests.

• Inspection manuelle — focus-not-obscured-enhanced (aucune règle automatisée) : Les analyseurs d’accessibilité automatisés comme axe-core opèrent sur le DOM statique ou sur un instantané de l’état rendu. Détecter si un élément ayant le focus est masqué nécessite : (1) simuler le focus clavier sur chaque élément interactif, dans l’ordre, (2) calculer le rectangle englobant de l’élément après le défilement induit par le focus, (3) identifier tous les éléments positionnés en fixed et sticky et leurs rectangles englobants, et (4) tester les chevauchements géométriques. Bien qu’une automatisation partielle soit théoriquement possible, la nature dynamique du comportement de défilement, de la propriété CSS scroll-padding, du défilement fluide et de la gestion du focus pilotée par JavaScript rend cette approche très peu fiable en pratique. Un élément ayant le focus qui est parfaitement visible à une taille de fenêtre d’affichage peut être totalement masqué à une autre. axe-core signale ce critère comme nécessitant un jugement humain et marque les résultats comme « à vérifier » plutôt que comme violations automatiques. Les testeurs doivent parcourir manuellement au clavier chaque élément interactif et confirmer visuellement la pleine visibilité à chaque largeur de fenêtre pertinente.
• scrollable-region-focusable (règle axe) : Bien qu’elle ne soit pas directement mappée à 2.4.12, cette règle axe signale les éléments à l’intérieur de régions défilables qui sont focalisables mais peuvent ne pas défiler correctement dans la vue. C’est un signal connexe qui indique des problèmes de gestion du défilement susceptibles de provoquer un masquage du focus par des en-têtes ou pieds de page collants — le mode de défaillance le plus courant pour 2.4.12.

Parce que les outils automatisés ne peuvent pas détecter de manière fiable les violations de 2.4.12, les organisations doivent intégrer des parcours clavier manuels dans leur processus d’assurance qualité, idéalement à plusieurs tailles de fenêtre d’affichage et avec toutes les couches d’interface persistantes (barres de navigation, widgets de chat, bannières de cookies, notifications RGPD) actives.

Comment tester

1. Analyse automatisée de base : Exécutez axe DevTools ou Lighthouse sur la page pour identifier tout problème connexe, comme des violations scrollable-region-focusable ou des problèmes de débordement CSS. Ces résultats, bien que n’étant pas des violations directes de 2.4.12, indiquent les zones de la page les plus susceptibles de provoquer des problèmes de masquage du focus. Dans axe DevTools, filtrez par critères WCAG 2.2 et examinez tous les éléments « à vérifier » liés à la visibilité du focus.
2. Identifier tous les contenus superposés persistants : Avant les tests clavier, dressez visuellement la liste de chaque élément avec position: fixed ou position: sticky sur la page — typiquement les barres de navigation, bannières de cookies, widgets de chat, boutons d’action flottants et barres d’outils de pied de page. Notez leurs hauteurs et positions afin de savoir quelles zones de la fenêtre d’affichage ils occupent.
3. Parcours de navigation au clavier : En partant du haut de la page (ou après avoir fermé toute fenêtre modale initiale), appuyez de manière répétée sur Tab pour déplacer le focus à travers chaque élément interactif. À chaque arrêt du focus, vérifiez que l’élément ayant le focus dans son intégralité — y compris son indicateur de focus visible (contour ou anneau) — se trouve entièrement dans la zone non masquée de la fenêtre d’affichage. N’acceptez pas une visibilité partielle. Si une portion quelconque de l’élément ou de son anneau de focus disparaît derrière un élément fixe, consignez cela comme un échec au titre de 2.4.12.
4. Navigation en sens inverse : Répétez le parcours en utilisant Maj+Tab pour naviguer en arrière. Les pieds de page fixes sont souvent manqués lors des tests en sens avant uniquement, mais peuvent masquer des éléments lors de la navigation en sens inverse.
5. Tests avec lecteur d’écran NVDA + Firefox : Ouvrez NVDA, lancez Firefox et naviguez avec Tab. Lorsque NVDA annonce le focus sur un élément, confirmez visuellement que l’élément est entièrement visible. Le mode focus de NVDA ne fait pas défiler automatiquement les éléments pour les dégager des couches fixes, de sorte que les violations peuvent différer du comportement natif du navigateur.
6. Tests avec lecteur d’écran VoiceOver + Safari (macOS/iOS) : Activez VoiceOver et utilisez Tab (ou le balayage sur iOS) pour naviguer. La gestion du défilement de Safari diffère parfois de celle de Chromium, ce qui peut révéler des états de focus masqués qui n’apparaissent pas dans Chrome.
7. Tests sur des fenêtres d’affichage responsives : Répétez le parcours clavier aux points de rupture courants — 320px, 768px, 1024px et 1440px de large. Les éléments collants changent souvent de hauteur ou de position à différents points de rupture, modifiant les zones à risque.
8. Tester après les interactions utilisateur : Ouvrez des menus déroulants, développez des accordéons, déclenchez des modales et naviguez vers de nouvelles routes dans les applications monopage. Après chaque changement d’état, reprenez la navigation avec Tab et revérifiez la pleine visibilité du focus, car le contenu dynamique introduit souvent de nouvelles superpositions fixes.

Comment corriger

En-tête collant masquant les liens ayant le focus — Incorrect

<!-- Fixed header with no scroll compensation -->
<header style='position:fixed; top:0; height:80px; background:#fff; width:100%;'>
  <nav>...</nav>
</header>

<main>
  <!-- When Tab reaches this link near the top of main, the header covers it -->
  <a href='/products'>View all products</a>
</main>

En-tête collant masquant les liens ayant le focus — Correct

<!-- scroll-padding-top ensures focused elements scroll clear of the fixed header -->
<style>
  html {
    /* Match this value to the height of your fixed header */
    scroll-padding-top: 88px; /* 80px header + 8px breathing room */
  }
</style>

<header style='position:fixed; top:0; height:80px; background:#fff; width:100%;'>
  <nav>...</nav>
</header>

<main style='margin-top:80px;'>
  <!-- Focus now scrolls the element fully clear of the header -->
  <a href='/products'>View all products</a>
</main>

Bannière de cookies recouvrant les éléments interactifs en bas de la fenêtre d’affichage — Incorrect

<!-- Cookie banner fixed to the bottom, no scroll compensation -->
<div id='cookie-banner' style='position:fixed; bottom:0; height:72px; width:100%; background:#222;'>
  <button>Accept All</button>
  <button>Manage Preferences</button>
</div>

<footer>
  <!-- These links at the bottom of the page get covered by the cookie banner -->
  <a href='/privacy'>Privacy Policy</a>
  <a href='/terms'>Terms of Service</a>
</footer>

Bannière de cookies recouvrant les éléments interactifs en bas de la fenêtre d’affichage — Correct

<!-- Add scroll-padding-bottom and body padding to compensate for the banner height -->
<style>
  html {
    scroll-padding-bottom: 80px; /* 72px banner + 8px breathing room */
  }
  body {
    padding-bottom: 80px; /* Prevent content from being permanently under the banner */
  }
</style>

<div id='cookie-banner' style='position:fixed; bottom:0; height:72px; width:100%; background:#222;'>
  <button>Accept All</button>
  <button>Manage Preferences</button>
</div>

<footer>
  <!-- Links now scroll fully into the unobscured viewport area -->
  <a href='/privacy'>Privacy Policy</a>
  <a href='/terms'>Terms of Service</a>
</footer>

Gestion du focus en JavaScript ne tenant pas compte des couches fixes — Incorrect

<!-- SPA route change: focus moved to heading but scrollIntoView ignores header -->
<script>
function navigateTo(section) {
  const heading = document.querySelector('#' + section + ' h2');
  heading.setAttribute('tabindex', '-1');
  heading.focus();
  // scrollIntoView with no offset — heading scrolls behind fixed header
  heading.scrollIntoView({ behavior: 'smooth', block: 'start' });
}
</script>

Gestion du focus en JavaScript ne tenant pas compte des couches fixes — Correct

<!-- Use scroll-margin-top on the target element, or manually offset scrollY -->
<style>
  .focus-target {
    /* scroll-margin-top offsets this element's scroll position from the top */
    scroll-margin-top: 96px;
  }
</style>

<script>
function navigateTo(section) {
  const heading = document.querySelector('#' + section + ' h2');
  heading.setAttribute('tabindex', '-1');
  // scroll-margin-top on the element handles the visual offset automatically
  heading.classList.add('focus-target');
  heading.focus();
  // scrollIntoView now respects scroll-margin-top, clearing the fixed header
  heading.scrollIntoView({ behavior: 'smooth', block: 'start' });
}
</script>

Erreurs courantes

• Définir scroll-padding-top sur body au lieu de html : La propriété CSS scroll-padding doit être appliquée au conteneur de défilement. Pour le défilement de page complète, le conteneur de défilement est l’élément html, pas body. L’appliquer à body n’a aucun effet dans la plupart des navigateurs et constitue l’une des erreurs de mise en œuvre les plus fréquentes.
• Coder en dur une valeur en pixels fixe pour scroll-padding-top qui ne correspond pas à la hauteur réelle de l’en-tête à tous les points de rupture : Lorsque l’en-tête se réduit à une hauteur plus petite sur mobile ou s’agrandit pour inclure une barre de navigation secondaire sur desktop, le décalage statique devient incorrect. Utilisez des variables CSS mises à jour via JavaScript ou utilisez calc() avec des unités relatives pour garder la valeur synchronisée.
• Oublier scroll-margin-top sur les cibles d’ancres internes : Même lorsque le scroll-padding-top global est correct pour la navigation avec Tab, les cibles de liens d’ancrage qui reçoivent le focus de manière programmatique (par exemple, liens d’évitement, navigation par hash dans les SPAs) peuvent encore se retrouver sous l’en-tête, à moins que scroll-margin-top ne soit également défini sur ces éléments spécifiques.
• Fermer la bannière de cookies sans refaire de tests : De nombreuses équipes testent la navigation au clavier uniquement après avoir accepté la bannière de cookies. Comme la bannière occupe le bas de la fenêtre d’affichage, les éléments focalisables ancrés en bas peuvent être masqués uniquement tant que la bannière est active. Testez toujours avec toutes les couches d’interface persistantes dans leur état pleinement affiché.
• Tester uniquement à une largeur de fenêtre d’affichage : Les éléments collants changent souvent de hauteur, deviennent visibles ou disparaissent complètement à différents points de rupture. Un échec à 375px peut ne pas apparaître à 1440px, et inversement. Tester à une seule taille fait passer à côté d’une proportion importante de violations réelles.
• Utiliser overflow: hidden sur un conteneur parent pour couper les indicateurs de focus : Lorsqu’un composant de carte ou un conteneur a overflow: hidden, le contour de focus par défaut du navigateur sur les éléments enfants est coupé à la limite du conteneur. Cela peut donner l’impression que le focus est entièrement visible dans l’inspecteur d’éléments de DevTools tout en étant visuellement tronqué pour l’utilisateur.
• Supposer que les lecteurs d’écran gèrent automatiquement le défilement, rendant les tests visuels inutiles : Bien que les lecteurs d’écran annoncent l’élément ayant le focus à l’oral, les utilisateurs voyants qui se servent du clavier — y compris ceux qui utilisent des outils de grossissement d’écran — s’appuient entièrement sur la position visuelle. Un état de focus visuellement masqué constitue une véritable défaillance, quel que soit le comportement du lecteur d’écran.
• Ne pas tester les boîtes de dialogue modales et les panneaux latéraux (drawers) : Lorsqu’une modale s’ouvre et que le focus est déplacé à l’intérieur, l’arrière-plan ou le chrome de la modale lui-même peut masquer le premier élément ayant le focus dans la boîte de dialogue. Cela est particulièrement fréquent dans les panneaux de type tiroir qui s’animent depuis le côté ou le bas.
• Ignorer les widgets tiers tels que les bulles de chat en direct et les bannières publicitaires interstitielles : Les widgets de chat flottants (par exemple Intercom, Zendesk) et les bannières promotionnelles fixes injectées par des gestionnaires de balises sont des contenus créés par l’auteur et entrent dans le champ de ce critère. Les équipes les négligent souvent parce qu’ils sont gérés en dehors de la base de code principale.
• Se fier uniquement aux analyses d’accessibilité automatisées et clôturer le ticket : Comme 2.4.12 nécessite des tests manuels, un scan axe-core sans erreur ne confirme pas la conformité. Clôturer des tickets d’accessibilité sur la seule base de résultats automatisés conduira systématiquement à manquer ce critère.

Lien avec la réglementation turque en matière d’accessibilité

La Circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences contraignantes en matière d’accessibilité web et mobile pour un large éventail d’entités opérant en Turquie. La circulaire adopte WCAG 2.1 niveau AA comme norme de conformité de base, ce qui signifie que WCAG 2.4.12 — en tant que critère AAA de WCAG 2.2 — n’est pas directement imposé par la réglementation actuelle. Toutefois, sa relation avec le cadre d’accessibilité de la Turquie est significative pour plusieurs raisons.

Les entités couvertes par la Circulaire présidentielle 2025/10 incluent les institutions publiques et organismes gouvernementaux à tous les niveaux, les plateformes d’e-commerce, les banques et prestataires de services financiers, les hôpitaux et organisations de santé, les entreprises de télécommunications comptant 200,000 abonnés ou plus, les agences de voyage, les entreprises de transport privé et les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE). Pour toutes ces organisations, atteindre la conformité WCAG 2.1 AA est une obligation légale, et la circulaire devrait être appliquée par des mécanismes d’audit administrés par les autorités de contrôle compétentes.

Bien que la conformité AAA ne soit pas exigée par la circulaire, les organisations des secteurs réglementés ont de fortes raisons pratiques de viser la conformité à WCAG 2.4.12. Premièrement, le paysage réglementaire turc évolue : la circulaire représente un renforcement significatif de l’application de l’accessibilité par rapport aux orientations antérieures, et de futures révisions pourraient adopter WCAG 2.2 ou relever le niveau de conformité. Les organisations qui mettent en place dès maintenant des pratiques AAA seront mieux préparées aux évolutions réglementaires. Deuxièmement, les processus de marchés publics et l’accès au marché de l’UE favorisent de plus en plus les fournisseurs capables de démontrer des programmes d’accessibilité renforcés, et la documentation de conformité AAA constitue un facteur de différenciation concurrentielle.

Troisièmement, et de manière plus directement liée à WCAG 2.4.12, ce critère traite un mode de défaillance qui affecte de manière disproportionnée les utilisateurs de technologies d’assistance en Turquie — une population estimée à plusieurs millions de personnes si l’on additionne les handicaps moteurs, visuels et cognitifs. Les banques, hôpitaux et portails de e-gouvernement qui s’appuient fortement sur des éléments de navigation fixes et des couches de notification persistantes sont précisément les sites où les défaillances de type masquage du focus sont les plus fréquentes. Investir dans une conformité complète à WCAG 2.4.12 démontre un engagement réel à servir tous les utilisateurs, s’aligne sur l’esprit de la circulaire présidentielle même lorsque sa lettre ne l’exige pas encore, et réduit les risques juridiques et de réputation à mesure que l’application de la réglementation turque se renforce.

Pour les organisations utilisant le SDK de superposition Accsible, la plateforme fournit des outils pour auditer les parcours de focus clavier et identifier les conflits liés au positionnement sticky, en soutenant à la fois les exigences AA obligatoires de la Circulaire présidentielle 2025/10 et les améliorations AAA volontaires telles que WCAG 2.4.12.