Popover API: nuevas posibilidades para los tooltips nativos del navegador

• La Popover API reemplaza con funciones nativas del navegador los listeners de eventos de JavaScript, la gestión de estado y la sincronización manual de atributos ARIA que antes eran imprescindibles para implementar tooltips
• Solo con los atributos popover y popovertarget, la apertura/cierre, el manejo de la tecla Esc y la navegación con teclado funcionan automáticamente
• Mejora la previsibilidad para lectores de pantalla, sincroniza aria-expanded automáticamente y elimina categorías enteras de bugs de accesibilidad, como la restauración del foco
• En algunas áreas, como el control de tiempos y la detección de intención de hover, sigue siendo necesario usar JavaScript, pero el modelo principal de interacción queda a cargo del navegador
• En sistemas de diseño grandes o cuando se necesita posicionamiento complejo, las librerías siguen siendo válidas, pero el valor predeterminado está cambiando hacia la API nativa

---

Problemas de los tooltips tradicionales

• Antes de la Popover API, el navegador no tenía un concepto nativo de tooltip que funcionara en conjunto con mouse, teclado y tecnologías de asistencia
• Se repetía el mismo patrón: un elemento disparador, un elemento de tooltip oculto y JavaScript para coordinar ambos
• En apariencia era simple, pero al llevarlo a usuarios reales aparecían muchos problemas
  • El tooltip no se mostraba cuando una persona que usa teclado entraba al disparador con Tab
  • El lector de pantalla lo leía dos veces o no lo leía en absoluto
  • Si el mouse se movía rápido, aparecía parpadeo (flicker)
  • En pantallas pequeñas, el contenido se superponía
  • No se cerraba con la tecla Esc y se perdía el foco
• Con el tiempo, el código crecía por la acumulación de listeners, el manejo separado de hover/focus, los casos especiales de clic externo y la sincronización manual de atributos ARIA

Por qué se usaban librerías

• Las librerías resolvían trabajo real: posicionamiento, flipping en los bordes del viewport, coordinación de eventos según el tipo de entrada y reconocimiento del scroll dentro de layouts complejos
• Solo el posicionamiento ya justificaba una dependencia, porque manejar contenedores con scroll, transformaciones y layouts responsivos es complejo
• El verdadero problema estaba en el comportamiento de accesibilidad
  • El tooltip aparecía tarde o directamente no aparecía
  • Al tabular rápido, se saltaba el tooltip
  • El cierre con Esc era inestable
• Quienes usan mouse esperan inmediatez, mientras que quienes usan teclado esperan previsibilidad; soportar ambos generaba demoras y casos límite
• En lectores de pantalla, el tooltip podía leerse, no leerse o leerse dos veces, con un comportamiento inconsistente
• Si faltaba actualizar aunque fuera un solo atributo ARIA manualmente, aparecía confusión en el árbol de accesibilidad o estados invisibles

No era un problema del código, sino una limitación de la plataforma

• La implementación estaba probada y las librerías eran sólidas, pero el problema central era la falta de affordances adecuadas en la plataforma web
• El navegador no tenía forma de reconocer que ese elemento era un tooltip; todo dependía de convenciones basadas en elementos genéricos, listeners, ARIA manual y lógica de cierre personalizada
• Con el tiempo, cambios pequeños implicaban riesgo y ajustes mínimos podían causar regresiones, en una estructura frágil
• Cada tooltip nuevo heredaba la misma complejidad

Primer uso de la Popover API

• El cambio no surgió por experimentar con algo nuevo, sino por el cansancio de mantener el comportamiento de tooltip que el navegador ya debería entender
• Se probó con la forma más pequeña posible: <button popovertarget="tip-1"> + <div id="tip-1" popover="manual" role="tooltip">
• Sin listeners de eventos, sin seguimiento de estado, sin actualizar ARIA desde JavaScript
• Al enfocar el botón, el tooltip se mostraba; al presionar Esc, desaparecía

Diferencias que se notan de inmediato

• Abrir/cerrar sin JavaScript: el navegador maneja la invocación solo con HTML y la relación entre disparador y tooltip queda explícita
• La tecla Esc funciona automáticamente: no hace falta agregar listeners de teclado, porque el navegador ya entiende cómo descartar el popover
• Sincronización automática del estado ARIA: el atributo aria-expanded se actualiza automáticamente al abrir/cerrar el popover, sin gestión manual ni riesgo de estados desactualizados
• Más importante que reducir código es el cambio de responsabilidad: antes el tooltip “existía” gracias a JavaScript; ahora el navegador entiende su papel en el markup y participa en el modelo de foco, el árbol de accesibilidad y las reglas nativas de descarte

Entender los Invoker Commands

• popovertarget="id" conecta el botón con el elemento popover
• popovertargetaction define la acción
  • show: solo abrir
  • hide: solo cerrar
  • toggle (predeterminado): si está abierto, cierra; si está cerrado, abre
• Se pueden tener varios disparadores para el mismo tooltip, y no hace falta JavaScript para la interacción básica

Beneficios gratis en accesibilidad

• El teclado “simplemente funciona”

  • Antes había una estructura en capas: el foco debía disparar la apertura, el blur debía ocultarlo, Esc debía conectarse manualmente y además había que ajustar los tiempos
  • Al establecer el atributo popover (auto o manual), el navegador se encarga del manejo predeterminado: Tab/Shift+Tab funcionan bien y Esc cierra de forma confiable cada vez
  • Del código desaparecen los handlers globales de keydown, la lógica de limpieza específica para Esc y las comprobaciones de estado durante la navegación por teclado

• Más previsibilidad con lectores de pantalla

  • Es el área con mayor mejora: antes, incluso con ARIA cuidadosamente implementado, el comportamiento variaba y cualquier pequeño cambio era riesgoso
  • Al usar popover="manual" role="tooltip", el comportamiento se vuelve mucho más estable y predecible
  • Después del cambio, Lighthouse ya no muestra advertencias sobre estados ARIA incorrectos, porque directamente ya no existe ese estado ARIA personalizado que podía implementarse mal

• Gestión del foco

  • Antes había reglas complejas: mostrar al enfocar el disparador, no cerrar si el foco se movía al tooltip, manejar blur y restaurar manualmente el foco
  • Con la Popover API, el foco se mueve de forma natural al popover y, al cerrarse, se restaura automáticamente al disparador
  • No se agregó código de restauración del foco; se eliminó

Lo que todavía le falta a la Popover API

• Tiempos del tooltip

  • El popover nativo se abre y se cierra de inmediato; si el mouse se mueve apenas más rápido o roza el disparador, el tooltip puede parpadear y sentirse inestable
  • Sigue haciendo falta controlar el delay entre hover/focus y la apertura
  • El navegador y los HTML invoker commands se encargan del comportamiento básico de abrir/cerrar, y JavaScript se usa solo para mejorar el comportamiento intencional, por ejemplo cancelando el ocultamiento si el puntero se mueve hacia el tooltip
  • También se está explorando esto desde CSS, y el trabajo relacionado con interest/invoker avanza hacia expresar directamente en CSS los delays de entrada/salida

• Hover intent e Invoker Commands

  • El navegador no puede saber por qué alguien hizo hover sobre un elemento: no puede determinar si fue intencional o si el puntero solo iba pasando
  • Como los invoker commands manejan la apertura/cierre principal, JavaScript ya no es dueño del modelo de interacción, sino que solo agrega intención encima
  • JavaScript se usa únicamente para comportamientos que el navegador no puede inferir, como un pequeño delay antes de ocultar o cancelar el cierre si el puntero se mueve al tooltip

• Manual Popover y foco

  • Con popover="manual", a diferencia del auto popover, el navegador no restaura el foco automáticamente
  • Si el tooltip se abre por foco y se cierra por blur, hay que devolver explícitamente el foco al disparador
  • Es un límite claro entre el comportamiento de la plataforma y la intención del usuario

• Evaluación honesta

  • La Popover API no resuelve los tooltips por arte de magia, pero sí evita tener que reconstruir infraestructura frágil
  • Todavía hay que usar JavaScript y pensar en casos límite, pero ahora es posible enfocarse en resolver problemas del producto en vez de volver a crear primitives de UI

Cuándo sigue haciendo falta una librería de tooltips

• Sistemas de diseño grandes o maduros

  • En sistemas de diseño grandes usados por varios equipos, una librería tiene sentido para ofrecer comportamiento centralizado, patrones documentados y valores predeterminados consistentes
  • Cambiar el modelo de interacción subyacente no es solo una decisión técnica, sino también una decisión organizacional
  • También aporta guardrails para integrantes del equipo que no están familiarizados con los matices de accesibilidad

• Requisitos complejos de posicionamiento

  • Si se necesita detección de colisiones entre contenedores con scroll anidados, lógica de flipping personalizada o control fino de offsets/límites, una librería como Floating UI sigue siendo ventajosa
  • CSS anchor positioning ya empieza a cubrir buena parte de ese problema: permite ubicar elementos relativamente al disparador, considerar el viewport y hacer edge flipping solo con CSS
  • Sigue siendo una funcionalidad nueva y tiene problemas conocidos, pero está incluida en Interop y apunta a un soporte completo y consistente entre navegadores
  • Si hoy se necesita un comportamiento consistente entre navegadores, una librería sigue siendo la opción práctica

• Equipos con poca experiencia en accesibilidad

  • En equipos con poco conocimiento de accesibilidad, una buena librería funciona como red de seguridad: no garantiza accesibilidad perfecta, pero sí evita errores comunes
  • La Popover API ofrece mejores valores predeterminados, pero todavía hace falta saber cuándo agregar roles, etiquetas, gestión del foco y pruebas
  • Sin comprensión, incluso las herramientas nativas pueden usarse mal

Conclusión

• Gracias a la Popover API, los tooltips dejan de ser algo simulado y pasan a ser elementos que el navegador entiende
• La apertura, el cierre, el comportamiento con teclado, el manejo de Esc y gran parte de la accesibilidad ahora vienen desde la propia plataforma
• En sistemas de diseño complejos, con alta personalización o restricciones legacy, las librerías siguen siendo válidas, pero el valor predeterminado está cambiando
• Es la primera vez que el tooltip más simple puede ser, al mismo tiempo, el tooltip más correcto
• Si reemplazas aunque sea un solo tooltip de tu producto con la Popover API, puedes ver exactamente qué desaparece del código