WCAG 2.4.7 : Focus visible

Ce que signifie cette règle

WCAG 2.4.7 Focus Visible exige que chaque élément interactif d’une page web — liens, boutons, champs de formulaire, widgets personnalisés et tout autre composant utilisable au clavier — affiche un indicateur de focus visible lorsqu’il reçoit le focus clavier. En termes simples, lorsqu’un utilisateur appuie sur la touche Tab pour parcourir une page, il doit pouvoir voir exactement quel élément est actuellement actif.

Le critère n’impose pas de style visuel spécifique pour l’indicateur de focus. Il exige seulement qu’un certain changement visible se produise. Cela dit, un indicateur à peine perceptible — par exemple, un contour en pointillés d’un pixel qui se fond dans l’arrière-plan — peut techniquement satisfaire 2.4.7 tout en échouant à l’exigence plus stricte WCAG 2.4.11 (Focus Appearance) introduite dans WCAG 2.2. Au titre de 2.4.7 uniquement, tout changement visuel discernable est suffisant.

Ce qui est considéré comme conforme : Un indicateur de focus est conforme si un utilisateur voyant qui navigue dans la page avec la touche Tab peut identifier quel élément est focalisé sans s’appuyer sur les annonces du lecteur d’écran ou d’autres signaux non visuels. Parmi les implémentations courantes acceptables, on trouve les contours par défaut du navigateur, des règles CSS personnalisées outline ou box-shadow, des changements de soulignement ou de couleur de fond appliqués sur :focus ou :focus-visible.

Ce qui est considéré comme non conforme : Un échec se produit lorsqu’un développeur supprime l’anneau de focus par défaut du navigateur — généralement via outline: none ou outline: 0 en CSS — et ne le remplace pas par un indicateur personnalisé équivalent. Des échecs se produisent également lorsqu’un composant personnalisé (construit avec des éléments <div> ou <span>) est rendu focalisable au clavier via tabindex mais ne reçoit aucun changement de style visible au focus.

Exceptions officielles : WCAG précise que le critère s’applique uniquement aux interfaces utilisables au clavier. Les composants purement décoratifs ou explicitement exclus de l’ordre de tabulation (via tabindex='-1') ne sont pas tenus d’afficher un indicateur de focus, car ils ne peuvent pas recevoir le focus par la navigation clavier normale.

Pourquoi c’est important

La visibilité du focus est fondamentale pour l’accessibilité clavier, et l’accessibilité clavier est la porte d’entrée vers l’accès pour un large éventail de groupes de personnes handicapées. Environ 26% des adultes aux États-Unis vivent avec une forme de handicap selon le CDC, et beaucoup de ces personnes s’appuient sur des claviers ou des technologies d’assistance émulant le clavier plutôt que sur des dispositifs de pointage.

Les utilisateurs ayant une déficience motrice — y compris les personnes atteintes de pathologies telles que la SLA, la paralysie cérébrale, les troubles musculo-squelettiques liés aux mouvements répétitifs ou la maladie de Parkinson — s’appuient fréquemment sur des claviers, des contacteurs, des commandes par souffle et aspiration ou des logiciels de suivi oculaire. Tous ces modes d’entrée dépendent du modèle de focus clavier du navigateur. Si l’indicateur de focus est invisible, ces utilisateurs ne peuvent pas déterminer où ils se trouvent sur la page, ne peuvent pas activer le bon contrôle et peuvent être totalement empêchés d’accomplir des tâches critiques comme soumettre un formulaire, finaliser un achat ou naviguer dans un menu.

Les utilisateurs malvoyants qui n’utilisent pas de lecteur d’écran mais peuvent agrandir l’affichage dépendent également du focus visible. Lorsqu’ils effectuent un zoom sur une partie de la page, l’anneau de focus visible leur indique quel élément est actif et guide leur interaction.

Les handicaps cognitifs et liés à l’attention bénéficient également d’indicateurs de focus clairs. Les personnes ayant un TDAH ou des difficultés de mémoire perdent souvent la trace de leur position sur une page complexe ; un indicateur de focus bien visible fournit un repère visuel fiable.

Un scénario concret : imaginez une personne atteinte de sclérose en plaques qui parcourt un site d’e-commerce uniquement au clavier parce que l’utilisation précise de la souris est devenue difficile. Elle parcourt la page produit avec la touche Tab pour atteindre le bouton « Add to Cart ». Si le développeur a supprimé l’anneau de focus, l’utilisateur ne voit aucune indication de l’emplacement du focus. Il appuie sur Entrée et soit rien ne se passe (le focus est arrivé sur un élément non interactif), soit la mauvaise action est déclenchée. Le résultat est de la frustration, l’abandon de la tâche et une perte de revenus pour l’entreprise — tout cela pouvant être évité avec une simple règle CSS.

Au-delà du handicap, les indicateurs de focus profitent à tous les utilisateurs dans les situations où l’usage de la souris est peu pratique : utilisateurs avancés naviguant par raccourcis clavier, utilisateurs d’ordinateurs portables sans souris externe et personnes remplissant de longs formulaires. Un focus visible améliore également le SEO de manière indirecte en encourageant l’HTML sémantique et un ordre de tabulation correct, deux aspects valorisés par les robots d’indexation des moteurs de recherche.

Règles Axe-core associées

WCAG 2.4.7 nécessite des tests manuels car les outils automatisés ne peuvent pas déterminer de manière fiable si un indicateur de focus est visible. Axe-core et des moteurs similaires peuvent détecter l’existence d’une règle CSS telle que outline: none, mais ils ne peuvent pas évaluer le rendu visuel final à travers tous les thèmes, modes à contraste élevé et moteurs de rendu des navigateurs. Ce qui suit explique le paysage des tests :

• Test manuel requis — suppression de focus-visible : Axe-core ne fournit pas de règle dédiée qui signale de manière définitive les échecs 2.4.7, car cela nécessiterait de rendre la page, de parcourir chaque élément avec la touche Tab et d’effectuer une analyse de contraste au niveau des pixels sur l’indicateur de focus — une tâche qui dépasse l’analyse statique ou au niveau du DOM. À la place, les testeurs doivent parcourir manuellement la page avec la touche Tab et confirmer visuellement que chaque élément interactif affiche un changement de focus.
• Signal partiel à partir de css-orientation-lock et des vérifications de style : Certaines configurations d’axe-core signalent la présence de outline: 0 ou outline: none dans les feuilles de style comme un avertissement de bonne pratique, mais il s’agit d’une heuristique, pas d’une vérification de violation définitive, car la règle peut être surchargée par un style de focus personnalisé valide ailleurs dans la cascade.
• Pourquoi l’automatisation est insuffisante : Un indicateur de focus peut être masqué uniquement dans certains états (par exemple, lorsqu’une fenêtre modale est ouverte), uniquement pour certains types d’éléments ou uniquement dans certains thèmes de couleurs. Ces échecs conditionnels nécessitent qu’un testeur humain navigue sur chaque élément interactif dans l’environnement réellement rendu et confirme la visibilité. Des outils comme axe DevTools Pro peuvent aider en mettant en évidence les éléments auxquels outline: none est appliqué, mais la décision finale de conformité/non-conformité doit être prise par un humain.

Comment tester

1. Pré-analyse automatisée : Exécutez axe DevTools (extension de navigateur ou CLI) ou Google Lighthouse sur la page. Recherchez tout avertissement de bonne pratique ou expérimental lié aux styles de focus. Bien que ceux-ci ne confirment pas de manière définitive un échec 2.4.7, ils mettent en évidence des éléments à inspecter. Dans Lighthouse, vérifiez la catégorie « Accessibility » pour les résultats liés au focus. Exportez le rapport et notez tous les éléments interactifs signalés.
2. Test manuel de tabulation au clavier : Débranchez ou éloignez votre souris. Appuyez de manière répétée sur Tab depuis le haut de la page et parcourez chaque élément interactif — liens, boutons, champs, listes déroulantes, modales, onglets, accordéons et sélecteurs de date. À chaque arrêt, confirmez que l’élément focalisé est visuellement distinguable de ses voisins non focalisés. Relevez tout élément pour lequel l’arrivée du focus ne produit aucun changement visible.
3. Test de tabulation inversée : Utilisez Shift+Tab pour naviguer en arrière dans la page et répétez la vérification visuelle. Certaines implémentations ne cassent la visibilité du focus que dans une direction en raison de problèmes de spécificité CSS.
4. Test NVDA + Firefox : Ouvrez Firefox avec NVDA en cours d’exécution. Utilisez le mode Parcourir (touches fléchées) puis passez en mode Formulaires (Entrée) pour interagir avec les contrôles de formulaire. Confirmez que chaque élément que NVDA annonce comme focalisé affiche également un indicateur visible à l’écran — utile pour détecter les écarts entre le focus de la technologie d’assistance et le focus du navigateur.
5. Test VoiceOver + Safari (macOS/iOS) : Activez VoiceOver et utilisez Tab ou VO+Flèche droite pour parcourir les éléments interactifs. Vérifiez visuellement que l’anneau de focus à l’écran correspond à ce que VoiceOver annonce.
6. Test JAWS + Chrome : Utilisez JAWS en mode curseur virtuel puis en mode application. Parcourez les contrôles interactifs avec Tab et confirmez que l’indicateur de focus visible apparaît sur chaque élément focalisé.
7. Test en mode à contraste élevé : Activez le mode Windows High Contrast (ou l’option Increase Contrast sur macOS) et répétez le test avec Tab. Certains indicateurs de focus reposent sur des couleurs qui disparaissent dans les thèmes à contraste élevé ; l’indicateur doit rester visible dans ces modes.
8. Inspection CSS : Ouvrez les DevTools du navigateur, sélectionnez un élément interactif, donnez-lui le focus en appuyant sur Tab jusqu’à ce qu’il soit actif, puis inspectez les styles calculés. Vérifiez qu’aucune règle ne définit outline: none ou outline: 0 sans style de focus compensatoire. Vérifiez également l’utilisation de :focus-visible par rapport à :focus pour vous assurer que le focus déclenché au clavier est couvert.

Comment corriger

Suppression globale de outline sans remplacement — Incorrect

<!-- CSS resets that remove all focus indicators globally -->
<style>
  * {
    outline: none; /* Removes focus ring from every element */
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>

Suppression globale de outline sans remplacement — Correct

<!-- Remove the global outline: none reset.
     Provide a custom focus style that is visually clear. -->
<style>
  /* Respect users who prefer reduced motion */
  :focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>
<!-- Now both elements show a high-contrast blue outline when focused via keyboard -->

Bouton personnalisé basé sur un div sans style de focus — Incorrect

<!-- A div styled as a button, made focusable, but missing :focus CSS -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  /* No :focus or :focus-visible rule defined */
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>

Bouton personnalisé basé sur un div sans style de focus — Correct

<!-- Add :focus-visible to the custom component so keyboard
     users see a clear indicator when this element is focused -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  .fake-btn:focus-visible {
    outline: 3px solid #ffcc00;
    outline-offset: 3px;
  }
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>
<!-- The yellow outline appears only on keyboard focus, not on mouse click -->

Anneau de focus masqué à l’intérieur d’une superposition modale — Incorrect

<!-- Modal applies overflow:hidden and a stacking context that clips
     the default outline, making it invisible -->
<style>
  .modal-body {
    overflow: hidden; /* Clips outlines that extend beyond the element */
    border-radius: 8px;
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Anneau de focus masqué à l’intérieur d’une superposition modale — Correct

<!-- Use box-shadow instead of outline so it renders
     inside the stacking context and is never clipped -->
<style>
  .modal-body {
    overflow: hidden;
    border-radius: 8px;
  }
  .modal-body button:focus-visible {
    /* box-shadow is not clipped by overflow:hidden --
       it stays within the element's own box -->
    box-shadow: 0 0 0 3px #005fcc;
    outline: none; /* Remove default to avoid double ring */
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Erreurs courantes

• Ajouter outline: none à une réinitialisation CSS de base sans auditer les éléments affectés. De nombreuses réinitialisations populaires (par exemple, d’anciennes versions de normalize.css ou des utilitaires Bootstrap) suppriment les anneaux de focus globalement. Ajoutez toujours ensuite une règle explicite :focus-visible qui rétablit la visibilité pour les utilisateurs de clavier.
• Se fier uniquement à :focus lorsque :focus-visible est plus approprié — ou inversement. Utiliser uniquement :focus applique l’indicateur également sur les clics de souris, ce qui peut paraître étrange. Utiliser uniquement :focus-visible sans solution de repli :focus peut laisser les anciens navigateurs sans aucun indicateur. Testez dans tous les navigateurs cibles.
• Appliquer outline: none dans une surcharge de thème de bibliothèque de composants sans comprendre la cascade. Une seule surcharge dans un fichier de thème peut effacer silencieusement les indicateurs de focus pour chaque composant qui en hérite, y compris les widgets tiers.
• Utiliser une couleur de focus ayant un contraste insuffisant avec l’élément ou l’arrière-plan de la page. Un contour gris clair sur un fond blanc ajoute techniquement un contour mais peut être imperceptible. Bien que 2.4.7 n’impose pas de ratio de contraste spécifique, 2.4.11 le fait — et les indicateurs de focus à faible contraste sont une source fréquente d’échecs d’audit même lorsque les développeurs pensent être conformes.
• Définir overflow: hidden ou clip-path sur un conteneur, ce qui rogne le contour par défaut du navigateur. La solution consiste à passer à des indicateurs de focus basés sur box-shadow, qui se rendent à l’intérieur de la boîte de l’élément et ne sont pas rognés par les règles d’overflow du parent.
• Oublier les indicateurs de focus sur les éléments interactifs à l’intérieur de composants SVG ou Canvas. Les info-bulles de graphiques personnalisés, les boutons d’icône basés sur SVG et les outils de dessin basés sur canvas n’ont souvent aucun style de focus natif. Ils nécessitent des rôles ARIA explicites, un tabindex et du CSS :focus-visible ou un retour visuel piloté par JavaScript.
• Supprimer la visibilité du focus uniquement dans le CSS de production (par exemple via un post-processeur ou une étape de build) tout en la laissant visible dans l’environnement de développement. Cela amène l’équipe de développement à valider son QA local tout en livrant une accessibilité dégradée aux utilisateurs finaux.
• Appliquer un indicateur de focus uniquement à l’élément <a> mais pas aux éléments role='link' de type span utilisés pour les liens de navigation SPA. Chaque élément focalisable au clavier — quel que soit son tag natif — a besoin d’un état de focus visible.
• Masquer les anneaux de focus uniquement dans certaines largeurs de fenêtre via des media queries, en supposant que les utilisateurs mobiles touchent toujours l’écran. Les utilisateurs de tablettes avec claviers Bluetooth et les utilisateurs en orientation paysage qui s’appuient sur l’entrée clavier se retrouvent sans aucun indicateur de focus.
• Utiliser JavaScript pour appeler .blur() immédiatement après un focus programmatique afin d’empêcher l’apparition de l’anneau de focus. C’est une erreur critique qui supprime complètement la visibilité du focus et ne doit jamais être utilisée comme raccourci de design.

Lien avec la réglementation d’accessibilité de la Turquie

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 impose la conformité à WCAG 2.2 au niveau AA pour les organisations concernées, faisant de WCAG 2.4.7 Focus Visible une exigence directement applicable plutôt qu’une simple recommandation de bonne pratique.

Les entités couvertes par la circulaire incluent les institutions et agences publiques, 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, ne pas fournir d’indicateurs de focus visibles sur leurs interfaces numériques constitue un problème de non-conformité réglementaire, et pas seulement un défaut d’ergonomie.

Le Erişilebilirlik Logosu (Logo d’accessibilité), délivré par le ministère de la Famille et des Services sociaux, sert de marque de certification officielle que les entités concernées peuvent afficher pour démontrer leur conformité. Obtenir le Logo d’accessibilité nécessite de réussir un audit formel au niveau AA de WCAG 2.2. WCAG 2.4.7 est l’un des critères de niveau AA que les auditeurs évalueront, généralement via des tests manuels au clavier comme décrit dans la section de test ci-dessus. Une organisation dont le site supprime les anneaux de focus ou n’implémente pas de focus visible sur les composants personnalisés ne réussira pas l’audit requis pour le logo.

Pour les plateformes d’e-commerce turques en particulier, la visibilité du focus a des implications commerciales directes : les sites accessibles atteignent une base d’utilisateurs plus large, y compris les clients ayant des déficiences motrices qui achètent exclusivement via le clavier ou des contacteurs, et la conformité à la Circulaire présidentielle 2025/10 protège les organisations contre les mesures administratives. Intégrer des modèles de focus visible dans la bibliothèque de composants dès le départ — plutôt que de les ajouter après un audit — est la voie la plus rentable pour conserver le Erişilebilirlik Logosu et respecter les obligations d’accessibilité de la Turquie.