API Popover — de nouvelles possibilités pour les info-bulles natives du navigateur

• L’API Popover remplace par une fonctionnalité native du navigateur les écouteurs d’événements JavaScript, la gestion d’état et la synchronisation manuelle des attributs ARIA, auparavant indispensables pour implémenter une info-bulle
• Avec les seuls attributs popover et popovertarget, l’ouverture/fermeture, la gestion de la touche Esc et la navigation au clavier fonctionnent automatiquement
• Amélioration de la prévisibilité pour les lecteurs d’écran, synchronisation automatique de aria-expanded, restauration du focus, etc. : toute une catégorie de bugs liés à l’accessibilité disparaît
• Du JavaScript reste nécessaire dans certains cas, comme le contrôle du timing ou la détection de l’intention au survol, mais le navigateur prend désormais en charge le modèle d’interaction central
• Pour les grands design systems ou les besoins de positionnement complexes, les bibliothèques restent pertinentes, mais le comportement par défaut bascule vers une API native

---

Les problèmes des info-bulles traditionnelles

• Avant l’API Popover, il n’existait pas dans le navigateur de véritable concept natif d’info-bulle fonctionnant avec la souris, le clavier et les technologies d’assistance
• On répétait toujours le même schéma : un élément déclencheur, un élément d’info-bulle caché, et du JavaScript pour coordonner les deux
• En apparence c’était simple, mais une fois déployé auprès de vrais utilisateurs, de nombreux problèmes apparaissaient
  • Un utilisateur clavier entrant sur le déclencheur avec Tab ne voyait pas l’info-bulle
  • Le lecteur d’écran lisait deux fois, ou ne lisait rien du tout
  • Un déplacement rapide de la souris provoquait un clignotement (flicker)
  • Le contenu se chevauchait sur les petits écrans
  • Impossible de fermer avec la touche Esc, ou perte du focus
• Avec le temps, le code grossissait : accumulation d’écouteurs d’événements, traitement séparé du hover et du focus, cas particuliers pour les clics extérieurs, synchronisation manuelle des attributs ARIA, etc.

Pourquoi utiliser des bibliothèques

• Les bibliothèques prenaient en charge le vrai travail : positionnement, bascule aux limites du viewport, coordination des événements selon le type d’entrée, prise en compte du scroll dans des mises en page complexes, etc.
• Rien que le positionnement justifiait souvent une dépendance, tant la gestion des conteneurs scrollables, des transforms et des layouts responsives est complexe
• Mais le vrai problème se situait dans le comportement d’accessibilité
  • L’info-bulle apparaissait trop tard, ou pas du tout
  • Elle était sautée lors d’une navigation rapide à la touche Tab
  • La fermeture via Esc était peu fiable
• Les utilisateurs de la souris attendent de l’instantanéité, ceux du clavier de la prévisibilité ; prendre en charge les deux générait des délais et des edge cases
• Sur les lecteurs d’écran, l’info-bulle était parfois lue, parfois non, parfois deux fois : un comportement incohérent
• Oublier une seule mise à jour manuelle d’un attribut ARIA suffisait à créer de la confusion dans l’arbre d’accessibilité ou à rendre un état invisible

Le problème ne venait pas du code lui-même, mais des limites de la plateforme

• Les implémentations étaient testées et les bibliothèques solides, mais le problème central était l’absence d’affordance adaptée dans la plateforme web
• Le navigateur n’avait aucun moyen de comprendre qu’un élément était une info-bulle ; tout reposait sur des éléments génériques, des écouteurs d’événements, de l’ARIA manuel et une logique de fermeture personnalisée, donc sur une convention
• Avec le temps, la moindre modification devenait risquée, et les petits ajustements provoquaient des régressions : une structure fragile
• À chaque nouvelle info-bulle, on héritait à nouveau de la même complexité

Première utilisation de l’API Popover

• Le déclic n’est pas venu d’une envie d’expérimenter une nouveauté, mais d’une fatigue à maintenir un comportement d’info-bulle que le navigateur devrait déjà comprendre
• Premier essai dans sa forme minimale : <button popovertarget="tip-1"> + <div id="tip-1" popover="manual" role="tooltip">
• Aucun écouteur d’événement, aucun suivi d’état, aucune mise à jour ARIA depuis le JavaScript
• Quand le bouton reçoit le focus, l’info-bulle s’affiche ; en appuyant sur Esc, elle disparaît

Les différences ressenties immédiatement

• Ouverture/fermeture sans JavaScript : le navigateur gère l’invocation à partir du seul HTML, et la relation entre le déclencheur et l’info-bulle est explicite
• Gestion automatique de la touche Esc : sans ajouter d’écouteur clavier, le navigateur comprend nativement qu’un popover peut être fermé
• Synchronisation automatique de l’état ARIA : l’attribut aria-expanded est mis à jour automatiquement à l’ouverture/fermeture du popover, ce qui supprime la gestion manuelle et le risque d’un état obsolète
• Plus encore que la réduction du code, l’essentiel est le transfert de responsabilité : auparavant, le JavaScript « faisait exister » l’info-bulle ; désormais, le navigateur comprend son rôle dans le balisage et l’intègre au modèle de focus, à l’arbre d’accessibilité et aux règles natives de fermeture

Comprendre les Invoker Commands

• popovertarget="id" relie le bouton à l’élément popover
• popovertargetaction permet de définir l’action
  • show : ouvrir uniquement
  • hide : fermer uniquement
  • toggle (valeur par défaut) : ferme si c’est ouvert, ouvre si c’est fermé
• On peut avoir plusieurs déclencheurs pour une même info-bulle, sans JavaScript pour l’interaction de base

Les bénéfices « gratuits » côté accessibilité

• Le clavier « fonctionne tout simplement »

  • Avant, il fallait une structure à plusieurs couches : le focus devait déclencher l’affichage, le blur devait masquer, il fallait relier Esc manuellement, et gérer aussi le timing
  • Avec l’attribut popover (auto ou manual), le navigateur fournit le comportement de base : Tab/Shift+Tab fonctionnent normalement et Esc ferme de manière fiable à chaque fois
  • Cela permet de supprimer du code : gestionnaires globaux de keydown, logique de nettoyage dédiée à Esc, vérifications d’état pendant la navigation clavier, etc.

• Une meilleure prévisibilité pour les lecteurs d’écran

  • C’est la zone qui s’est le plus améliorée : auparavant, même avec un ARIA soigneusement conçu, le comportement variait et le moindre changement était risqué
  • Avec popover="manual" role="tooltip", le comportement devient nettement plus stable et prévisible
  • Après la migration, Lighthouse n’affiche plus d’avertissements sur des états ARIA incorrects — simplement parce qu’il n’y a plus d’état ARIA personnalisé à mal gérer

• Gestion du focus

  • Avant, il fallait composer avec des règles complexes : afficher lors du focus du déclencheur, ne pas fermer si le focus entrait dans l’info-bulle, traiter le blur, restaurer manuellement le focus, etc.
  • Avec l’API Popover, le focus se déplace naturellement vers le popover et, lors de la fermeture, il y a restauration automatique du focus vers le déclencheur
  • Le code de restauration du focus n’a pas été ajouté : il a été supprimé

Les limites actuelles de l’API Popover

• Le timing des info-bulles

  • Un popover natif s’ouvre et se ferme immédiatement ; si la souris bouge un peu trop vite ou frôle le déclencheur, l’info-bulle peut clignoter et donner une impression d’instabilité
  • Il reste nécessaire de contrôler le délai entre hover/focus et ouverture
  • Le navigateur et les commandes d’invocation HTML gèrent l’ouverture/fermeture de base, et le JavaScript n’intervient plus que pour affiner un comportement intentionnel, par exemple annuler le masquage si le pointeur se déplace vers l’info-bulle
  • Ce sujet est aussi exploré côté CSS, avec des travaux autour d’interest/invoker pour permettre d’exprimer directement en CSS les délais d’entrée et de sortie

• Hover intent et Invoker Commands

  • Le navigateur ne peut pas savoir pourquoi quelqu’un survole un élément : s’agit-il d’une action volontaire, ou le pointeur est-il simplement en train de passer ? Il est incapable d’en juger
  • Comme les invoker commands gèrent le cœur de l’ouverture/fermeture, le JavaScript ne possède plus le modèle d’interaction ; il ne fait qu’y ajouter l’intention
  • Le JavaScript ne sert plus qu’aux comportements que le navigateur ne peut pas déduire, comme un court délai avant de masquer ou l’annulation de la fermeture si le pointeur se déplace vers l’info-bulle

• Popover manuel et focus

  • Avec popover="manual", contrairement à un popover auto, le navigateur ne restaure pas automatiquement le focus
  • Si l’info-bulle s’ouvre au focus et se ferme au blur, il faut renvoyer explicitement le focus vers le déclencheur
  • Cela marque une frontière claire entre le comportement de la plateforme et l’intention de l’utilisateur

• Bilan honnête

  • L’API Popover ne résout pas magiquement le problème des info-bulles, mais elle permet d’arrêter de reconstruire une infrastructure fragile
  • Il faut encore du JavaScript et il reste des edge cases, mais on peut se concentrer sur la résolution des problèmes produit plutôt que sur la recréation de primitives d’interface

Quand une bibliothèque d’info-bulles reste nécessaire

• Design systems de grande taille ou matures

  • Dans un grand design system utilisé par plusieurs équipes, une bibliothèque reste un choix rationnel pour obtenir des comportements centralisés, des patterns documentés et des valeurs par défaut cohérentes
  • Changer le modèle d’interaction sous-jacent n’est pas seulement une décision technique, c’est aussi une décision organisationnelle
  • Elle fournit aussi des garde-fous aux membres de l’équipe moins familiers avec les subtilités de l’accessibilité

• Besoins complexes en positionnement

  • Si l’on a besoin de détection de collision entre conteneurs scrollables imbriqués, de logique de bascule personnalisée, ou d’un contrôle fin des offsets et des limites, une bibliothèque comme Floating UI reste avantageuse
  • Le positionnement par ancres CSS commence à couvrir une grande partie de ce problème : placement relatif par rapport au déclencheur, prise en compte du viewport, bascule aux bords, le tout en pur CSS
  • Cela reste une fonctionnalité récente avec des problèmes connus, mais elle fait partie d’Interop, ce qui laisse entrevoir un support navigateur complet et cohérent
  • Si l’on a besoin aujourd’hui d’un comportement cross-browser vraiment constant, la bibliothèque reste le choix le plus pratique

• Équipes peu expérimentées en accessibilité

  • Dans les équipes qui manquent de connaissances en accessibilité, une bonne bibliothèque joue un rôle de filet de sécurité : elle ne garantit pas une accessibilité parfaite, mais elle évite les erreurs les plus courantes
  • L’API Popover fournit de meilleures valeurs par défaut, mais il faut toujours savoir quand ajouter un role, un label, une gestion du focus et des tests
  • Sans compréhension du sujet, même des outils natifs peuvent être mal utilisés

Conclusion

• Avec l’API Popover, une info-bulle n’est plus quelque chose que l’on simule, mais un élément que le navigateur comprend
• L’ouverture, la fermeture, le comportement clavier, la gestion de Esc et une grande partie de l’accessibilité sont désormais fournis par la plateforme elle-même
• Les bibliothèques restent pertinentes pour les design systems complexes, les personnalisations poussées ou les contraintes legacy, mais le comportement par défaut est en train de changer
• C’est peut-être la première fois que l’info-bulle la plus simple peut aussi être la plus correcte
• Il suffit de remplacer une seule info-bulle du produit par l’API Popover pour voir ce qui disparaît du code