WCAG 1.4.13 : Contenu au survol ou au focus

Ce que signifie cette règle

La WCAG 1.4.13 traite d’un schéma d’interaction courant sur le web : le contenu qui devient visible lorsqu’un utilisateur survole un élément avec un pointeur ou y déplace le focus clavier. Cela inclut les info-bulles, les sous-menus, les aides déroulantes personnalisées, les popovers de sélecteur de date et tout autre calque qui apparaît en réponse à des événements de survol ou de focus. Le critère s’applique chaque fois que ce contenu n’est pas contrôlé nativement par le navigateur (par exemple, l’info-bulle native de l’attribut title est exemptée), et il établit trois exigences fondamentales qui doivent toutes être respectées simultanément.

Rétractable : L’utilisateur doit pouvoir fermer le contenu supplémentaire sans déplacer le focus du pointeur ni le focus clavier. Le mécanisme standard pour cela est la pression sur la touche Échap. Cela empêche le calque de masquer d’autres contenus de la page d’une manière que l’utilisateur ne peut pas résoudre — ce qui est particulièrement crucial pour les personnes qui ont agrandi l’écran et ne peuvent pas simplement regarder ailleurs.

Survolable : Si le contenu supplémentaire est apparu parce que l’utilisateur a survolé un élément déclencheur, l’utilisateur doit pouvoir déplacer son pointeur sur le contenu nouvellement apparu sans qu’il disparaisse. Si une info-bulle disparaît au moment où le curseur quitte l’élément déclencheur, les utilisateurs ne peuvent pas lire un contenu long, copier du texte ou activer des liens ou des contrôles qu’elle contient.

Persistant : Le contenu supplémentaire doit rester visible jusqu’à ce que le déclencheur de survol ou de focus soit supprimé, que l’utilisateur le ferme (par exemple via Échap) ou que l’information ne soit plus valide. Le contenu ne doit pas disparaître selon un minuteur ou après un délai arbitraire tant que le pointeur ou le focus est toujours sur le déclencheur ou sur le calque lui-même.

Une conformité nécessite que les trois conditions soient satisfaites. Un échec se produit si une seule condition manque — par exemple, une info-bulle qui disparaît lorsque le pointeur se déplace du déclencheur vers l’info-bulle (non survolable), ou une qui se ferme automatiquement après trois secondes (non persistante), ou une qui ne peut pas être fermée sans déplacer le focus (non rétractable). La seule exception officielle prévue par la WCAG est lorsque la présentation visuelle du contenu supplémentaire est entièrement contrôlée par l’agent utilisateur — les info-bulles natives du navigateur produites uniquement par l’attribut title entrent dans cette catégorie et sont exemptées, bien qu’elles comportent leurs propres limites en matière d’accessibilité.

Pourquoi c’est important

Ce critère bénéficie principalement aux utilisateurs qui ont des difficultés à contrôler les interactions standard de la souris ou du clavier, aux utilisateurs qui s’appuient sur l’agrandissement d’écran et à ceux qui traitent l’information plus lentement. Comprendre qui est concerné aide les équipes à hiérarchiser correctement la correction.

Les utilisateurs malvoyants utilisent souvent des logiciels d’agrandissement d’écran tels que ZoomText ou la loupe intégrée au système d’exploitation, ce qui signifie qu’ils ne voient qu’une petite portion de l’écran à des niveaux de zoom élevés. Lorsqu’une info-bulle apparaît, elle peut être partiellement hors écran, et l’utilisateur doit se déplacer vers elle. Si l’info-bulle disparaît au moment où le pointeur quitte le déclencheur, l’utilisateur ne peut pas se déplacer pour la lire. Selon l’Organisation mondiale de la Santé, environ 2,2 milliards de personnes dans le monde vivent avec une forme de déficience visuelle, et une part significative de celles qui utilisent des ordinateurs s’appuient sur l’agrandissement plutôt que sur un lecteur d’écran.

Les utilisateurs ayant des troubles moteurs — y compris les personnes atteintes de la maladie de Parkinson, de tremblements ou d’un contrôle moteur fin limité — peuvent utiliser des dispositifs de pointage alternatifs, des pointeurs de tête ou des systèmes de suivi oculaire. Le contrôle précis du pointeur est difficile pour ces utilisateurs, ce qui signifie que passer d’un petit élément déclencheur à une petite info-bulle sans quitter accidentellement les deux peut être presque impossible si la zone de survol n’est pas tolérante. L’exigence de survolabilité répond directement à ce problème.

Les utilisateurs ayant des handicaps cognitifs peuvent lire lentement ou avoir besoin de relire le contenu. Une info-bulle qui se ferme automatiquement après quelques secondes ne laisse pas à ces utilisateurs suffisamment de temps pour assimiler l’information, et une info-bulle qui ne peut pas être fermée sans déplacer le focus peut piéger leur attention dans un état d’interaction déroutant.

Considérons un scénario concret : un site bancaire affiche les détails du taux d’intérêt d’un compte dans une info-bulle qui apparaît lorsque l’utilisateur survole une petite icône d’information. Un utilisateur malvoyant, zoomé à 400 %, ne voit qu’une partie de la page à la fois. Il survole l’icône, l’info-bulle apparaît, et il commence à déplacer son pointeur vers l’info-bulle pour lire les petites lignes — mais l’info-bulle disparaît immédiatement car elle est uniquement liée à l’état de survol de l’élément parent. L’utilisateur ne peut pas accéder aux informations obligatoires de divulgation. Ce n’est pas seulement un inconvénient d’ergonomie ; dans les secteurs réglementés, cela peut constituer un obstacle légal en matière d’accessibilité.

Au-delà de l’impact spécifique au handicap, une mise en œuvre correcte de ce critère améliore également l’ergonomie générale pour tous les utilisateurs sur des appareils hybrides tactile-clavier, réduit les demandes d’assistance causées par des éléments d’interface « qui disparaissent » et signale la qualité de l’interface aux utilisateurs comme aux auditeurs.

Règles axe-core associées

La WCAG 1.4.13 nécessite des tests manuels. Les outils automatisés ne peuvent pas détecter de manière fiable les violations, car le critère implique des comportements basés sur le temps et les mouvements du pointeur que l’analyse statique du DOM ne peut pas évaluer. Aucune règle axe-core unique ne correspond directement à ce critère, mais les considérations suivantes expliquent pourquoi l’automatisation est insuffisante et ce qu’il faut rechercher lors de la revue manuelle.

• Tests manuels requis — comportement au survol : Les analyseurs automatisés inspectent le DOM et le CSSOM à un instant donné ; ils ne peuvent pas simuler le déplacement d’un pointeur d’un élément déclencheur vers une info-bulle nouvellement rendue et observer si l’info-bulle persiste. Un outil pourrait théoriquement détecter qu’une pseudo-classe CSS :hover masque un élément enfant lorsque le parent perd le survol, mais il ne peut pas distinguer entre une fermeture intentionnelle et un non-respect de l’exigence de survolabilité sans simuler des trajectoires de pointeur.
• Tests manuels requis — fermeture via Échap : Détecter si la pression sur Échap ferme un calque nécessite une simulation d’événements JavaScript qui va au-delà de l’ensemble de règles actuel d’axe-core. Axe peut signaler l’absence de rôles ARIA sur les popups ou l’absence d’attributs aria-expanded, mais il ne peut pas vérifier qu’un écouteur d’événement keydown pour Échap est relié à une fonction de fermeture et masque effectivement l’élément.
• Tests manuels requis — persistance / fermeture automatique : Une info-bulle qui se masque elle-même via un appel setTimeout après trois secondes apparaîtra parfaitement valide dans un scan statique effectué dans cette fenêtre. Seul un testeur qui observe le calque dans le temps — ou qui examine le code JavaScript — peut identifier un minuteur de fermeture automatique comme une violation.
• Règles axe complémentaires à exécuter en parallèle des vérifications manuelles : Bien qu’elles ne testent pas directement 1.4.13, l’exécution de règles telles que aria-tooltip-name (s’assurer que les info-bulles ont des noms accessibles), color-contrast (s’assurer que le texte de l’info-bulle est lisible) et focus-visible (s’assurer que les déclencheurs focalisés sont visuellement identifiables) peut faire apparaître des problèmes connexes qui aggravent l’impact des échecs de 1.4.13.

Comment tester

1. Analyse automatisée de base : Exécutez axe DevTools ou Lighthouse sur la page contenant du contenu déclenché au survol/focus. Notez tout problème signalé concernant les rôles d’info-bulle, le contraste ou la visibilité du focus — cela ne confirme pas la conformité à 1.4.13 mais établit une base. Relevez quels éléments déclenchent du contenu en calque afin de pouvoir les cibler dans les étapes manuelles.
2. Identifier tout le contenu déclenché au survol/focus : Faites défiler la page et survolez systématiquement chaque élément interactif — boutons icône, liens avec descriptions supplémentaires, aides de champ de formulaire, éléments de navigation, en-têtes de tableaux de données et points de données de graphiques. Dressez la liste de chaque élément qui fait apparaître du contenu supplémentaire.
3. Tester l’exigence de survolabilité : Pour chaque déclencheur identifié, survolez-le pour afficher le calque, puis déplacez lentement le pointeur de l’élément déclencheur vers le contenu du calque lui-même. Le calque doit rester visible tout au long de ce mouvement. S’il disparaît avant que le pointeur ne l’atteigne, le critère n’est pas respecté.
4. Tester l’exigence de rétractabilité : Tant qu’un calque est visible (déclenché par survol ou focus clavier), appuyez sur la touche Échap. Le calque doit se fermer. S’il ne se ferme pas, le critère n’est pas respecté. Effectuez ce test avec le pointeur toujours sur le déclencheur et aussi avec le pointeur sur le calque.
5. Tester l’exigence de persistance : Déclenchez un calque puis laissez votre pointeur immobile sur le déclencheur ou sur le calque pendant au moins 10–15 secondes. Le calque doit rester visible pendant toute cette durée. S’il s’estompe, expire ou disparaît sans action de l’utilisateur, le critère n’est pas respecté.
6. Test clavier uniquement : Parcourez la page avec la touche Tab en utilisant uniquement le clavier. Lorsque le focus arrive sur un déclencheur qui révèle du contenu supplémentaire, vérifiez : (a) que le contenu apparaît, (b) qu’appuyer sur Échap le ferme, et (c) que le contenu ne disparaît pas de lui-même tant que le focus reste sur le déclencheur. Utilisez NVDA avec Firefox, JAWS avec Chrome et VoiceOver avec Safari pour confirmer que les lecteurs d’écran exposent également correctement le contenu.
7. Test avec agrandissement d’écran : Réglez le zoom du navigateur à 400 % ou activez l’agrandissement au niveau du système d’exploitation. Répétez les tests de survol. Vérifiez qu’un utilisateur qui doit déplacer la fenêtre d’affichage pour atteindre l’info-bulle peut le faire sans que l’info-bulle ne disparaisse.
8. Revue du code JavaScript : Recherchez dans la base de code les gestionnaires d’événements setTimeout, mouseleave, mouseout et blur associés à la logique de masquage des calques. Vérifiez que la logique de masquage n’est pas déclenchée tant que le pointeur est sur le calque ou tant que le déclencheur conserve le focus, et qu’aucun minuteur de fermeture automatique n’est défini.

Comment corriger

Info-bulle uniquement en CSS qui disparaît au mouseleave — Incorrect

<!-- Tooltip only shown via CSS :hover on parent; disappears as soon as
     the pointer moves off the trigger toward the tooltip text -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip'>This is the tooltip content.</span>
</span>

<!-- CSS (illustrative) -->
<!--
.tooltip { display: none; }
.tip-wrapper:hover .tooltip { display: block; }
-->

Info-bulle uniquement en CSS qui disparaît au mouseleave — Correct

<!-- Correct: tooltip is also shown when the pointer is over the tooltip itself,
     and the gap between trigger and tooltip is covered so pointer movement
     does not accidentally dismiss the overlay. -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip' role='tooltip' id='tip1'>This is the tooltip content.</span>
</span>

<!-- CSS (illustrative) -->
<!--
.tooltip { display: none; position: absolute; }
.tip-wrapper:hover .tooltip,
.tooltip:hover { display: block; }
/* Use padding or a transparent pseudo-element bridge between trigger and tooltip */
-->

Info-bulle JavaScript sans fermeture via Échap — Incorrect

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
// Only mouseenter/mouseleave — no keyboard or Escape handling
document.querySelector('button').addEventListener('mouseenter', () => {
  document.getElementById('tip2').removeAttribute('hidden');
});
document.querySelector('button').addEventListener('mouseleave', () => {
  document.getElementById('tip2').setAttribute('hidden', '');
});
</script>

Info-bulle JavaScript sans fermeture via Échap — Correct

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
const btn = document.querySelector('button');
const tip = document.getElementById('tip2');

function showTip() { tip.removeAttribute('hidden'); }
function hideTip() { tip.setAttribute('hidden', ''); }

// Show on hover and focus
btn.addEventListener('mouseenter', showTip);
btn.addEventListener('focus', showTip);

// Hide only when pointer leaves BOTH trigger AND tooltip
btn.addEventListener('mouseleave', (e) => {
  // Short delay allows pointer to reach the tooltip
  setTimeout(() => {
    if (!tip.matches(':hover') && !btn.matches(':hover')) hideTip();
  }, 100);
});
tip.addEventListener('mouseleave', () => {
  if (!btn.matches(':hover')) hideTip();
});

// Hide on blur (keyboard)
btn.addEventListener('blur', hideTip);

// Dismissible via Escape key — required by 1.4.13
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape' && !tip.hidden) hideTip();
});
</script>

Info-bulle avec fermeture automatique via setTimeout — Incorrect

<button id='info-btn'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
document.getElementById('info-btn').addEventListener('mouseenter', () => {
  const t = document.getElementById('tip3');
  t.removeAttribute('hidden');
  // Violation: auto-dismisses after 3 seconds regardless of user state
  setTimeout(() => t.setAttribute('hidden', ''), 3000);
});
</script>

Info-bulle avec fermeture automatique via setTimeout — Correct

<button id='info-btn' aria-describedby='tip3'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
const btn2 = document.getElementById('info-btn');
const tip3 = document.getElementById('tip3');

// No setTimeout — tooltip persists until user removes hover/focus or presses Escape
function show() { tip3.removeAttribute('hidden'); }
function hide() {
  setTimeout(() => {
    if (!tip3.matches(':hover') && !btn2.matches(':hover') && document.activeElement !== btn2) {
      tip3.setAttribute('hidden', '');
    }
  }, 100);
}

btn2.addEventListener('mouseenter', show);
btn2.addEventListener('focus', show);
btn2.addEventListener('mouseleave', hide);
btn2.addEventListener('blur', hide);
tip3.addEventListener('mouseleave', hide);
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') tip3.setAttribute('hidden', '');
});
</script>

Erreurs courantes

• Utiliser uniquement le CSS :hover sans couvrir l’espace entre le déclencheur et l’info-bulle : Lorsqu’il existe ne serait-ce qu’un espace de 1–2 px entre l’élément déclencheur et le conteneur de l’info-bulle, le déplacement du pointeur entre eux fait tomber l’état de survol, masquant l’info-bulle avant que l’utilisateur ne l’atteigne. Utilisez un pseudo-élément transparent ou un padding chevauchant pour combler cet espace.
• Lier la logique de masquage à mouseleave sur le déclencheur sans vérifier si le pointeur s’est déplacé sur l’info-bulle : L’info-bulle disparaît dès que le curseur quitte le déclencheur, même si la destination est l’info-bulle elle-même. Vérifiez toujours tip.matches(':hover') avant de masquer, ou utilisez un court délai de temporisation (debounce).
• Oublier de relier les événements focus et blur en plus de mouseenter et mouseleave : Les utilisateurs uniquement clavier qui tabulent jusqu’au déclencheur ne verront jamais l’info-bulle si seuls les événements souris sont gérés, rendant l’information associée totalement inaccessible sans souris.
• Ne pas ajouter d’écouteur sur la touche Échap, en supposant qu’un clic à l’extérieur suffit : Les utilisateurs clavier et les utilisateurs d’agrandissement d’écran ne peuvent pas facilement « cliquer ailleurs » pour fermer un calque. Échap est le mécanisme de fermeture attendu et requis pour ce critère.
• Placer l’écouteur Échap uniquement sur l’élément déclencheur au lieu du document : Si l’utilisateur déplace le focus vers l’info-bulle ou vers un autre élément, un écouteur limité au déclencheur ne se déclenchera pas. Le gestionnaire Échap doit être placé sur le document ou sur un ancêtre commun qui reçoit toujours les événements clavier lorsque le calque est ouvert.
• Utiliser setTimeout pour fermer automatiquement les info-bulles après une durée fixe : Tout mécanisme de fermeture basé sur un minuteur qui se déclenche alors que le pointeur est encore sur le déclencheur ou l’info-bulle, ou alors que le déclencheur a toujours le focus clavier, constitue une violation directe de l’exigence de persistance. Supprimez tous les minuteurs de fermeture automatique des calques déclenchés par survol/focus.
• Déclencher la visibilité de l’info-bulle exclusivement via un remplacement de l’attribut title avec un style personnalisé : Les développeurs qui suppriment l’info-bulle native de title et la remplacent par une version personnalisée doivent implémenter eux-mêmes les trois exigences de 1.4.13. L’exemption pour les info-bulles natives du navigateur ne s’étend pas aux reproductions JavaScript personnalisées du même schéma.
• Ne pas tester avec un agrandissement d’écran à 400 % de zoom : Une info-bulle qui semble accessible à un zoom normal peut être partiellement hors écran à des niveaux de zoom élevés, obligeant l’utilisateur à se déplacer — et si elle se ferme avant qu’il ne puisse se déplacer jusqu’à elle, le test qui réussissait à 100 % de zoom échoue dans les conditions réelles d’utilisation.
• Appliquer pointer-events: none au conteneur de l’info-bulle : Cette propriété CSS empêche le pointeur d’être considéré comme « au-dessus » de l’info-bulle, rendant impossible le respect de l’exigence de survolabilité, quelle que soit la logique par ailleurs. Les info-bulles avec lesquelles les utilisateurs doivent éventuellement interagir ou simplement survoler pour les garder visibles ne doivent jamais avoir pointer-events: none.
• Considérer que l’ARIA role='tooltip' suffit à elle seule pour la conformité : Ajouter role='tooltip' et aria-describedby est important pour l’accessibilité avec les lecteurs d’écran mais traite une autre couche du problème. Ces attributs ARIA ne rendent pas automatiquement le contenu rétractable, survolable ou persistant — le comportement d’interaction doit encore être implémenté explicitement.

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

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit un mandat formel en matière d’accessibilité qui intègre les normes WCAG par référence. La circulaire exige des entités concernées qu’elles mettent en œuvre des mesures d’accessibilité web alignées sur des lignes directrices reconnues au niveau international, et la conformité de niveau AA — qui inclut la WCAG 1.4.13 — est à la fois fortement encouragée et requise pour les entités souhaitant obtenir le logo d’accessibilité (Erişilebilirlik Logosu) délivré par le ministère de la Famille et des Services sociaux (Aile ve Sosyal Hizmetler Bakanlığı).

La circulaire couvre un large éventail de types d’entités opérant en Turquie. Les institutions publiques et les organismes gouvernementaux à tous les niveaux administratifs sont tenus de rendre leurs services numériques accessibles. Dans le secteur privé, l’obligation s’étend aux plateformes de commerce électronique, aux banques et prestataires de services financiers, aux hôpitaux et établissements de santé privés, aux opérateurs de télécommunications comptant 200,000 abonnés ou plus, aux agences de voyage, aux entreprises de transport privé et aux écoles privées opérant sous autorisation du ministère de l’Éducation nationale (Millî Eğitim Bakanlığı).

La WCAG 1.4.13 est particulièrement pertinente dans les contextes numériques turcs où les schémas d’info-bulles et de popovers sont largement utilisés dans les portails de e-gouvernement (tels que les intégrations e-Devlet), les interfaces bancaires et fintech qui affichent des informations de frais ou de taux dans des info-bulles, et les systèmes de prise de rendez-vous de santé qui présentent des instructions supplémentaires via des calques déclenchés au survol. Une plateforme bancaire qui ne respecte pas 1.4.13 pourrait empêcher des clients malvoyants de lire les informations sur les taux d’intérêt fournies via une info-bulle — un scénario qui comporte à la fois des implications en matière d’accessibilité et de protection des consommateurs financiers.

Pour les entités visant l’Erişilebilirlik Logosu, un audit d’accessibilité inclura des tests manuels des comportements de survol et de focus précisément parce que les outils automatisés ne peuvent pas détecter ces violations. Les organisations utilisant un SDK de calque d’accessibilité tel qu’Accsible doivent s’assurer que toutes les info-bulles injectées par widget, les popovers de visites guidées ou les panneaux d’aide contextuelle introduits par le SDK lui-même respectent pleinement les trois exigences de 1.4.13 — rétractables via Échap, survolables sans fermeture et persistants jusqu’à l’action de l’utilisateur. Ne pas le faire introduirait de nouveaux obstacles par le biais même de l’outil censé améliorer l’accessibilité, compromettant à la fois la conformité réglementaire et la confiance des utilisateurs.