WCAG 2.4.11 : Focus non masqué (minimum)

Ce que signifie cette règle

WCAG 2.4.11 Focus Not Obscured (Minimum) est un critère de niveau AA introduit dans WCAG 2.2 qui traite d’un problème d’accessibilité courant mais grave : lorsqu’un élément ayant le focus est complètement caché derrière une autre couche de contenu sur la page. Le critère stipule que lorsqu’un composant d’interface utilisateur reçoit le focus clavier, ce composant ne doit pas être entièrement dissimulé par du contenu créé par l’auteur.

Le mot clé ici est entièrement. WCAG 2.4.11 fixe le seuil minimal — il exige seulement qu’une partie de l’élément focalisé reste visible. Si une barre de navigation fixe chevauche la moitié supérieure d’un bouton focalisé mais que la moitié inférieure reste visible, cela respecte techniquement le critère 2.4.11. Le critère compagnon plus strict, WCAG 2.4.12 Focus Not Obscured (Enhanced) au niveau AAA, va plus loin en exigeant que le composant focalisé ne soit pas du tout masqué par du contenu créé par l’auteur — même pas partiellement.

Les types de contenu créés par l’auteur le plus souvent responsables de ce problème incluent les en-têtes et pieds de page collants ou en position fixe, les bandeaux de consentement aux cookies, les widgets de support par chat, les notifications « toast », les superpositions modales, les boutons d’action flottants et les barres de navigation inférieures dans les mises en page adaptatives pour mobile. Ces éléments sont rendus à l’aide de propriétés CSS telles que position: fixed, position: sticky ou des valeurs de z-index élevées, ce qui les fait flotter au-dessus du flux normal du document et peut les amener à recouvrir des éléments interactifs qui reçoivent le focus.

Un succès signifie que lorsqu’un utilisateur de clavier parcourt les éléments interactifs avec la touche Tab, au moins une partie de l’indicateur visuel de chaque élément focalisé est visible à l’écran en permanence — même si un élément d’interface collant en recouvre une partie. Un échec se produit lorsqu’un élément focalisé est complètement caché sous une couche créée par l’auteur, ce qui signifie que l’utilisateur n’a absolument aucun indice visuel sur l’emplacement actuel du focus. Le contenu rendu par le navigateur, comme la barre d’outils propre au navigateur, n’est pas considéré comme du contenu créé par l’auteur et est donc exclu du champ d’application de ce critère. De même, le contenu que l’utilisateur a lui-même repositionné (comme un panneau déplaçable par l’utilisateur) est également exclu.

Ce critère s’applique à tous les éléments HTML interactifs pouvant recevoir le focus clavier par défaut ou rendus focalisables via tabindex, y compris <a>, <button>, <input>, <select>, <textarea> et les éléments avec tabindex='0' ou des valeurs de tabindex positives.

Pourquoi c’est important

La navigation au clavier est fondamentale pour l’accessibilité de plusieurs groupes d’utilisateurs. Les personnes ayant un handicap moteur qui ne peuvent pas utiliser une souris dépendent entièrement des claviers, des dispositifs à contacteur ou des contrôleurs par souffle pour se déplacer sur une page web. Les personnes aveugles utilisent des lecteurs d’écran en combinaison avec des claviers. Les personnes malvoyantes qui utilisent la navigation au clavier sans lecteur d’écran dépendent fortement de l’indicateur de focus visible pour comprendre où elles se trouvent. Lorsque cet élément focalisé est caché derrière un en-tête collant ou un widget flottant, ces utilisateurs sont effectivement perdus — ils doivent appuyer de manière répétée sur Tab, deviner leur position ou abandonner complètement la tâche.

Considérons un scénario concret du monde réel : une personne en fauteuil roulant avec une mobilité limitée des mains remplit un formulaire de réservation de vol sur le site web d’une compagnie aérienne turque. Elle utilise la touche Tab pour se déplacer entre les champs du formulaire. La page comporte un bandeau de consentement aux cookies collant en bas de la fenêtre d’affichage. Lorsque l’utilisateur atteint par tabulation la case à cocher de confirmation finale, celle-ci est rendue complètement sous le bandeau de cookies. L’utilisateur n’a aucun indice visuel indiquant que la case à cocher a le focus. Il ne peut pas savoir si son appui sur Tab a fonctionné, s’il doit appuyer à nouveau sur Tab ou si la case à cocher est même obligatoire. Cette confusion peut conduire à l’abandon du formulaire, à des envois manqués ou à des frappes répétées entraînant des actions involontaires.

L’impact va au-delà des utilisateurs en situation de handicap. Les utilisateurs avancés qui préfèrent la navigation au clavier pour la rapidité — développeurs, professionnels de la saisie de données et utilisateurs expérimentés — bénéficient également d’une visibilité claire du focus. Selon l’Organisation mondiale de la Santé, environ 1,3 milliard de personnes dans le monde vivent avec une forme de handicap, et une part significative d’entre elles dépend des technologies d’assistance ou de la navigation au clavier. En Turquie spécifiquement, l’Institut turc de statistique (TÜİK) rapporte qu’environ 12,7% de la population présente une forme de handicap, ce qui représente environ 10 millions de personnes pouvant bénéficier directement d’une meilleure gestion du focus sur les plateformes numériques.

Du point de vue commercial, des indicateurs de focus masqués augmentent les taux d’abandon de tâche, réduisent la conversion et exposent les organisations à des risques juridiques et réglementaires. Les sites qui ne respectent pas ce critère sont également susceptibles d’échouer aux audits d’accessibilité exigés par la législation turque, compromettant leur capacité à obtenir ou à conserver le Erişilebilirlik Logosu (Logo d’accessibilité) officiel.

Règles axe-core associées

WCAG 2.4.11 est classé comme nécessitant des tests manuels dans axe-core. Il n’existe aucune règle axe-core automatisée qui détecte directement cette violation. Comprendre pourquoi les outils automatisés ne peuvent pas signaler de manière fiable ce problème aide les équipes à mettre en place de meilleurs processus de test manuel.

• Test manuel requis — Focus masqué par positionnement fixe : Les outils automatisés ne peuvent pas détecter si un élément focalisé est visuellement masqué, car cela nécessite de rendre la page, de calculer les rectangles englobants de tous les éléments fixes ou collants à l’exécution, et de les comparer au rectangle englobant de l’élément actuellement focalisé au moment du focus. Les dimensions de la fenêtre d’affichage, la position de défilement et l’état dynamique de la page (par exemple, si un bandeau de cookies a déjà été fermé) influencent tous le résultat. Aucune analyse statique ni inspection du DOM ne peut reproduire de manière fiable ce calcul visuel dans tous les états possibles. Axe-core marque ce critère comme manuel parce qu’il nécessite un testeur humain — ou un outil sophistiqué de régression visuelle — pour réellement parcourir la page avec Tab et observer si les composants focalisés disparaissent derrière des couches superposées.
• Test manuel requis — Contenu de superposition dynamique : De nombreux éléments masquants sont injectés dynamiquement via JavaScript après le chargement initial de la page — widgets de chat tiers, bandeaux de conformité RGPD, fenêtres promotionnelles surgissantes et menus de navigation flottants. Les analyseurs automatisés qui examinent l’instantané DOM initial peuvent ne pas capturer ces éléments du tout, ou les capturer dans un état réduit ou caché qui ne reflète pas l’expérience réelle de l’utilisateur. Les tests manuels par un utilisateur de clavier qui interagit avec la page dans son état pleinement rendu et dynamique sont le seul moyen fiable de détecter ces scénarios.

Comment tester

1. Commencez par exécuter une analyse d’accessibilité automatisée. Utilisez axe DevTools (extension de navigateur), Lighthouse dans Chrome DevTools ou une analyse axe-core intégrée au CI pour identifier les problèmes détectables automatiquement sur la page. Bien que 2.4.11 nécessite lui-même une vérification manuelle, une analyse automatisée peut faire apparaître des problèmes connexes tels que l’absence d’indicateurs de focus (2.4.7) ou un empilement z-index incorrect suggérant des éléments qui se chevauchent. Notez tous les éléments signalés comme potentiellement problématiques avant de commencer les tests manuels.
2. Identifiez tous les éléments fixes et collants sur la page. Ouvrez les DevTools du navigateur et inspectez le CSS de la page. Recherchez les éléments utilisant position: fixed ou position: sticky. Vérifiez également les éléments avec des valeurs de z-index élevées (par exemple, 100 ou plus). Documentez chacun de ces éléments — en-têtes, pieds de page, bandeaux, widgets de chat, notifications de cookies — car ce sont les candidats les plus susceptibles de masquer des composants focalisés. Redimensionnez la fenêtre du navigateur pour simuler différentes tailles de fenêtre d’affichage, y compris les largeurs tablette et mobile, car les éléments collants/fixes se comportent souvent différemment selon les points de rupture.
3. Effectuez un parcours complet au clavier avec Tab. Cliquez en dehors de tout élément interactif pour vous assurer que le focus commence en haut de la page, puis appuyez de manière répétée sur Tab pour parcourir chaque élément focalisable. Observez attentivement chaque élément lorsqu’il reçoit le focus. Portez une attention particulière aux éléments qui apparaissent près du haut ou du bas de la fenêtre d’affichage, là où les en-têtes ou pieds de page fixes sont les plus susceptibles de se superposer. Si, à un moment donné, l’anneau de focus visible ou l’élément mis en évidence disparaît complètement derrière une couche fixe, il s’agit d’un échec du critère 2.4.11. Utilisez Shift+Tab pour parcourir en sens inverse également, car la position de défilement et la mise en page peuvent différer.
4. Testez avec NVDA et Firefox. Ouvrez NVDA (lecteur d’écran gratuit et open source pour Windows) et lancez Firefox. Activez le mode navigation de NVDA et utilisez Tab pour vous déplacer dans la page. Bien que NVDA annonce chaque élément focalisé à l’oral, observez également l’écran visuellement. Notez tout élément pour lequel NVDA annonce le focus mais où aucun indicateur de focus visuel n’est visible en raison d’un contenu masquant. Cette combinaison est largement utilisée en Turquie et dans le monde et représente un duo clé de technologies d’assistance.
5. Testez avec VoiceOver et Safari sur macOS/iOS. Activez VoiceOver (Commande+F5 sur Mac) et utilisez Tab ou les gestes de navigation de VoiceOver pour parcourir les éléments focalisables. Sur iOS, utilisez les gestes de balayage. Vérifiez que les éléments focalisés sont visuellement présents et non cachés sous des couches d’interface fixes, en particulier sur mobile où les barres de navigation et les bandeaux de cookies peuvent occuper une plus grande partie de la fenêtre d’affichage.
6. Testez avec JAWS et Chrome. Ouvrez JAWS (Job Access With Speech) et utilisez Chrome. Parcourez tous les éléments interactifs avec Tab et surveillez tout moment où le curseur JAWS se déplace vers un élément qui est visuellement caché sous une couche fixe. JAWS est largement utilisé dans les environnements d’entreprise et gouvernementaux, ce qui rend cette combinaison particulièrement importante pour tester les sites du secteur public et les sites d’entreprise.
7. Testez après les interactions utilisateur qui modifient la mise en page. Fermez les bandeaux de cookies, ouvrez et fermez les menus de navigation, déclenchez des notifications « toast » et ouvrez les widgets de chat. Après chaque changement d’état, effectuez un nouveau parcours avec Tab pour vous assurer que la nouvelle mise en page n’introduit pas de nouveaux cas de focus masqué. Le contenu dynamique est une source fréquente d’échecs 2.4.11 qui n’apparaissent qu’après une interaction utilisateur.
8. Testez à plusieurs positions de défilement. Faites défiler jusqu’au milieu ou au bas d’une longue page, puis parcourez les éléments de cette zone avec Tab. Les en-têtes fixes peuvent ne pas masquer les éléments proches du haut de la page mais peuvent recouvrir les éléments qui apparaissent au bord supérieur de la fenêtre d’affichage lorsque l’utilisateur fait défiler vers le bas. Vérifiez qu’aucune combinaison de position de défilement et d’élément focalisé ne conduit à une dissimulation visuelle complète.

Comment corriger

En-tête collant chevauchant des liens focalisés — Incorrect

<!-- Sticky header with no scroll offset accommodation -->
<header style='position: fixed; top: 0; left: 0; width: 100%; height: 60px; z-index: 1000; background: white;'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- No scroll-margin-top set; focused link at top of main scrolls under the header -->
  <a href='/section-one'>Go to Section One</a>
  <a href='/section-two'>Go to Section Two</a>
</main>

En-tête collant chevauchant des liens focalisés — Correct

<!-- Fixed header with scroll-margin-top applied to all focusable elements -->
<header class='site-header'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- scroll-margin-top ensures the browser scrolls the element into view
       with enough clearance so the fixed header does not cover it -->
  <a href='/section-one' class='content-link'>Go to Section One</a>
  <a href='/section-two' class='content-link'>Go to Section Two</a>
</main>

<!-- In your stylesheet: -->
<!-- .site-header { position: fixed; top: 0; height: 60px; z-index: 1000; } -->
<!-- * { scroll-margin-top: 70px; } -->
<!-- The 70px (header height + 10px buffer) keeps focused elements
     visible below the fixed header when the browser auto-scrolls. -->

Bandeau de cookies recouvrant un champ de formulaire focalisé en bas — Incorrect

<!-- Cookie banner fixed at bottom with no accommodation for form fields above it -->
<div id='cookie-banner' class='cookie-overlay'>
  <p>We use cookies. <button>Accept</button></p>
</div>

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <!-- This checkbox renders in the viewport area covered by the cookie banner -->
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Bandeau de cookies recouvrant un champ de formulaire focalisé en bas — Correct

<!-- Cookie banner pushes page content up instead of overlapping it -->
<div id='cookie-banner' class='cookie-banner-flow'>
  <p>We use cookies. <button id='accept-cookies'>Accept</button></p>
</div>

<!-- In your stylesheet: -->
<!-- .cookie-banner-flow { position: static; } instead of position: fixed -->
<!-- Alternatively, if fixed positioning is required for design reasons,
     add scroll-margin-bottom to all focusable elements equal to the
     banner height, or apply padding-bottom to <body> equal to
     the banner height so content is never hidden beneath it. -->

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Widget de chat tiers recouvrant un bouton focalisé — Incorrect

<!-- Third-party chat widget injected in bottom-right corner
     with a high z-index, obscuring the focused Submit button -->
<div id='chat-widget' class='chat-fixed'>
  <!-- Injected by third-party script, covers 120x120px in bottom-right -->
</div>

<section class='cta-section'>
  <!-- Button positioned in the bottom-right area of the layout;
       when focused, it is completely hidden beneath the chat widget -->
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

Widget de chat tiers recouvrant un bouton focalisé — Correct

<!-- Approach 1: Reposition the chat widget to avoid overlapping focusable content -->
<div id='chat-widget' class='chat-fixed-adjusted'>
  <!-- Widget repositioned to bottom-left, away from the CTA button -->
</div>

<!-- Approach 2: Ensure the button has scroll-margin that keeps it
     clear of the widget when focused -->
<section class='cta-section'>
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

<!-- Approach 3: Use JavaScript to detect focus events on elements
     near the widget's bounding box and temporarily collapse or
     move the widget so the focused element is visible. -->
<script>
  // Example: collapse widget when nearby element gains focus
  document.querySelectorAll('.cta-button').forEach(function(btn) {
    btn.addEventListener('focus', function() {
      var widget = document.getElementById('chat-widget');
      if (widget) widget.setAttribute('aria-hidden', 'false');
      // Additional logic to reposition or minimize widget
    });
  });
</script>

Erreurs courantes

• Appliquer position: fixed aux en-têtes et pieds de page sans ajouter scroll-margin-top ou scroll-margin-bottom aux éléments focalisables. Le défilement natif du focus par le navigateur ne tient pas compte des éléments fixes qui se superposent, de sorte que les éléments focalisés défilent jusqu’en haut ou en bas de la fenêtre d’affichage et se retrouvent cachés derrière la couche fixe. Une règle CSS globale telle que * { scroll-margin-top: [header-height]px; } résout ce problème efficacement.
• Définir body { padding-top: 60px; } pour compenser un en-tête fixe mais oublier d’ajouter un scroll-margin-top équivalent pour le focus clavier. Le padding garantit que le contenu n’est pas initialement caché, mais lorsque le focus clavier déclenche le défilement automatique du navigateur, la cible de défilement peut encore glisser derrière l’en-tête. Les deux approches doivent être utilisées ensemble.
• Utiliser z-index: 9999 sur des bandeaux promotionnels ou des widgets de chat sans vérifier quels éléments focalisables se trouvent dans leur empreinte. Un z-index élevé garantit que la superposition se rend au-dessus de tout, y compris des boutons et liens focalisés, ce qui en fait la cause racine la plus courante des échecs 2.4.11.
• Fermer les bandeaux de cookies via JavaScript sans les retirer immédiatement de la mise en page. Si l’élément DOM du bandeau reste avec visibility: hidden ou opacity: 0 mais occupe toujours de l’espace ou possède un z-index non nul, il peut continuer à masquer visuellement des éléments focalisés dans certains scénarios de rendu de navigateur.
• Intégrer des widgets tiers (chat en direct, superpositions d’accessibilité, gestionnaires RGPD) sans vérifier leur impact sur la visibilité du focus clavier. Les scripts tiers injectent souvent des éléments en position fixe avec des valeurs de z-index très élevées. Les équipes doivent tester explicitement ces intégrations dans le cadre de leur processus d’assurance qualité en accessibilité.
• Ne pas tester le critère 2.4.11 après des changements de points de rupture responsives. Une barre de navigation collante de 60px de hauteur sur ordinateur de bureau peut s’étendre à 120px sur tablette lorsqu’un menu hamburger est ouvert, masquant soudainement une zone beaucoup plus grande et créant de nouveaux échecs à des points de rupture qui passaient sur ordinateur.
• Appliquer scroll-margin-top uniquement aux cibles d’ancrage (<h2>, <section>) mais pas aux éléments interactifs comme <input>, <button> et <a>. Le décalage de défilement pour les ancres est souvent traité, mais le défilement automatique du focus clavier vers des éléments non ancrés est tout autant affecté et doit être couvert par la même règle CSS.
• Supposer que parce qu’un élément focalisé est annoncé par un lecteur d’écran, il est également visible visuellement. Les lecteurs d’écran accèdent à l’arbre d’accessibilité, pas au rendu visuel. Un élément peut être complètement caché derrière une superposition fixe tout en étant correctement annoncé par NVDA ou JAWS. Ce sont deux problèmes distincts — 2.4.11 concerne spécifiquement la visibilité du focus visuel pour les utilisateurs voyants au clavier.
• Négliger de tester le masquage du focus après des changements de route dans une application monopage (SPA). Dans les applications React, Vue ou Angular, les transitions de route re-rendent souvent les en-têtes fixes avec un état mis à jour, et la gestion du focus pendant la navigation peut placer le focus sur des éléments immédiatement masqués par un en-tête collant remonté avant que l’utilisateur ne voie la nouvelle page.
• Se fier uniquement aux outils de test automatisés et conclure qu’aucun problème 2.4.11 n’existe parce qu’aucune règle automatisée n’a signalé la page. Étant donné qu’axe-core n’a pas de règle automatisée pour ce critère, un rapport automatisé vierge ne signifie pas que la page est conforme. Un parcours manuel au clavier sur toutes les tailles de fenêtre d’affichage et tous les états de page est obligatoire.

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

WCAG 2.4.11 Focus Not Obscured (Minimum) est directement pertinent pour le cadre juridique émergent de l’accessibilité en Turquie. La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences obligatoires en matière d’accessibilité numérique qui s’alignent sur WCAG 2.2. Cette circulaire représente une expansion significative de l’engagement de la Turquie en faveur de l’inclusion numérique et impose des obligations exécutoires à un large éventail d’acteurs opérant sur le marché numérique turc.

La circulaire couvre un large éventail d’organisations, notamment les institutions publiques et les agences gouvernementales, les plateformes de commerce électronique, les banques et prestataires de services financiers, les hôpitaux et organisations de santé, les entreprises de télécommunications comptant plus de 200 000 abonnés, 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). Toutes ces entités sont tenues de veiller à ce que leurs interfaces numériques — sites web, applications mobiles et outils web — soient conformes au niveau AA de WCAG 2.2.

Parce que WCAG 2.4.11 est un critère de niveau AA dans WCAG 2.2, le respect de cette règle n’est pas facultatif pour les entités concernées. Les organisations cherchant à obtenir ou à conserver le Erişilebilirlik Logosu (Logo d’accessibilité) officiel, délivré par le ministère de la Famille et des Services sociaux (Aile ve Sosyal Hizmetler Bakanlığı), doivent atteindre la conformité de niveau AA. Le Logo d’accessibilité sert de signal public d’engagement en faveur de l’inclusion numérique et est de plus en plus attendu par les consommateurs turcs et les organismes de passation de marchés publics.

Concrètement, cela signifie que les sites web des institutions publiques turques avec des en-têtes de navigation collants, les sites de commerce électronique avec des bandeaux promotionnels persistants, les portails bancaires avec des widgets d’aide flottants et les systèmes de prise de rendez-vous de santé avec des superpositions de consentement aux cookies doivent tous être testés et corrigés pour le masquage du focus au titre du critère 2.4.11. Les échecs de ce critère sont particulièrement probables dans les interfaces complexes et fortement axées sur le marketing — précisément le type de sites exploités par les grandes entités commerciales couvertes par la circulaire.

Les organisations soumises à la circulaire devraient intégrer les tests relatifs au critère 2.4.11 dans leurs cycles réguliers d’audit d’accessibilité. Étant donné que ce critère nécessite des tests manuels, se fier uniquement à l’analyse automatisée ne satisfera pas aux obligations de diligence raisonnable. Il est recommandé aux entités turques visant une conformité complète d’effectuer des parcours manuels au clavier sur toutes les tailles de fenêtre d’affichage et tous les états dynamiques de page dans le cadre de leur documentation de conformité, et de traiter tout problème de masquage du focus identifié dans leur feuille de route de remédiation avant la demande ou le renouvellement du logo d’accessibilité.