WCAG 1.4.13: Contenido al pasar el cursor o al enfocar

Qué significa esta regla

WCAG 1.4.13 aborda un patrón de interacción común en la web: contenido que se vuelve visible cuando una persona usuaria pasa un puntero por encima de un elemento o mueve el foco del teclado hacia él. Esto incluye tooltips, submenús, ayudas desplegables personalizadas, popovers de selectores de fecha y cualquier otra superposición que aparezca en respuesta a eventos de hover o de foco. El criterio se aplica siempre que dicho contenido no esté controlado de forma nativa por el navegador (por ejemplo, el tooltip nativo del atributo title está exento) y establece tres requisitos fundamentales que deben cumplirse todos simultáneamente.

Desactivable: La persona usuaria debe poder cerrar el contenido adicional sin mover el foco del puntero ni el foco del teclado. El mecanismo estándar para esto es pulsar la tecla Escape. Esto evita que la superposición oculte otro contenido de la página de una forma que la persona usuaria no pueda resolver, algo especialmente crítico para quienes han ampliado la pantalla y no pueden simplemente mirar a otra zona.

Interactuable con hover: Si el contenido adicional apareció porque la persona usuaria pasó el puntero sobre un elemento disparador, debe poder mover el puntero sobre el contenido recién aparecido sin que este desaparezca. Si un tooltip se desvanece en el momento en que el cursor abandona el elemento disparador, las personas usuarias no pueden leer contenido extenso, copiar texto de él ni activar enlaces o controles dentro de él.

Persistente: El contenido adicional debe permanecer visible hasta que se elimine el hover o el foco que lo disparó, la persona usuaria lo cierre (por ejemplo, mediante Escape) o la información deje de ser válida. El contenido no debe desaparecer mediante un temporizador ni tras una demora arbitraria mientras el puntero o el foco sigan en el disparador o en la propia superposición.

Para aprobar, las tres condiciones deben cumplirse. Se produce un fallo si falta cualquiera de ellas; por ejemplo, un tooltip que desaparece cuando el puntero se mueve desde el disparador hacia el tooltip (no es interactuable con hover), o uno que se cierra automáticamente tras tres segundos (no es persistente), o uno que no puede cerrarse sin mover el foco (no es desactivable). La única excepción oficial establecida por WCAG es cuando la presentación visual del contenido adicional está totalmente controlada por el agente de usuario: los tooltips nativos del navegador producidos únicamente por el atributo title entran en esta categoría y están exentos, aunque tienen sus propias limitaciones de accesibilidad.

Por qué es importante

Este criterio beneficia principalmente a personas usuarias que tienen dificultades para controlar interacciones estándar con ratón o teclado, a quienes dependen de la ampliación de pantalla y a quienes procesan la información más lentamente. Entender quién se ve afectado ayuda a los equipos a priorizar correctamente la solución.

Personas con baja visión suelen usar software de ampliación de pantalla como ZoomText o el magnificador integrado del sistema operativo, lo que significa que solo ven una pequeña parte de la pantalla con niveles altos de zoom. Cuando aparece un tooltip, puede quedar parcialmente fuera de la pantalla y la persona usuaria debe desplazarse hacia él. Si el tooltip desaparece en el momento en que el puntero abandona el disparador, la persona usuaria no puede desplazarse para leerlo. Según la Organización Mundial de la Salud, aproximadamente 2.2 mil millones de personas en todo el mundo viven con algún tipo de discapacidad visual, y una parte significativa de quienes usan computadoras dependen de la ampliación en lugar de un lector de pantalla.

Personas con discapacidades motoras, incluidas personas con enfermedad de Parkinson, temblores o control motor fino limitado, pueden usar dispositivos apuntadores alternativos, punteros de cabeza o sistemas de seguimiento ocular. El control preciso del puntero es difícil para estas personas, lo que significa que moverse desde un elemento disparador pequeño a un tooltip pequeño sin abandonar accidentalmente ambos puede ser casi imposible si el área de hover no es tolerante. El requisito de ser interactuable con hover aborda directamente este problema.

Personas con discapacidades cognitivas pueden leer lentamente o necesitar releer el contenido. Un tooltip que se cierra automáticamente tras unos segundos no les da tiempo suficiente para asimilar la información, y un tooltip que no puede cerrarse sin mover el foco puede atrapar su atención en un estado de interacción confuso.

Consideremos un escenario concreto: un sitio web bancario muestra detalles del tipo de interés de una cuenta dentro de un tooltip que aparece cuando la persona usuaria pasa el puntero sobre un pequeño icono de información. Una persona con baja visión con zoom al 400% solo ve una parte de la página a la vez. Pasa el puntero sobre el icono, aparece el tooltip y comienza a mover el puntero hacia el tooltip para leer la letra pequeña, pero el tooltip desaparece de inmediato porque solo está vinculado al estado de hover del elemento padre. La persona usuaria no puede acceder a la información de divulgación requerida. Esto no es simplemente un inconveniente de usabilidad; en sectores regulados puede constituir una barrera legal de accesibilidad.

Más allá del impacto específico en la discapacidad, la implementación correcta de este criterio también mejora la usabilidad general para todas las personas usuarias en dispositivos híbridos táctil‑teclado, reduce las solicitudes de soporte causadas por elementos de interfaz que "desaparecen" y transmite calidad de la interfaz tanto a personas usuarias como a auditores.

Reglas relacionadas de Axe-core

WCAG 1.4.13 requiere pruebas manuales. Las herramientas automatizadas no pueden detectar de forma fiable las infracciones porque el criterio implica comportamientos basados en el tiempo y en el movimiento del puntero que el análisis estático del DOM no puede evaluar. Ninguna regla individual de axe-core se corresponde directamente con este criterio, pero las siguientes consideraciones explican por qué la automatización no es suficiente y qué buscar durante la revisión manual.

• Se requieren pruebas manuales — comportamiento de hover: Los escáneres automatizados inspeccionan el DOM y el CSSOM en un momento dado; no pueden simular el movimiento de un puntero desde un elemento disparador hacia un tooltip recién renderizado ni observar si el tooltip persiste. Teóricamente, una herramienta podría detectar que una pseudoclase CSS :hover oculta un elemento hijo cuando el padre pierde el hover, pero no puede distinguir entre un cierre intencional y un incumplimiento del requisito de ser interactuable con hover sin simular trayectorias del puntero.
• Se requieren pruebas manuales — cierre con Escape: Detectar si pulsar Escape cierra una superposición requiere simulación de eventos de JavaScript que va más allá del conjunto actual de reglas de axe-core. Axe puede marcar la ausencia de roles ARIA en popups o la falta de atributos aria-expanded, pero no puede verificar que un listener de keydown para Escape esté conectado a una función de cierre y que realmente oculte el elemento.
• Se requieren pruebas manuales — persistencia / cierre automático: Un tooltip que se oculta mediante una llamada a setTimeout tras tres segundos parecerá totalmente válido en un análisis estático realizado dentro de esa ventana. Solo una persona evaluadora que observe la superposición a lo largo del tiempo —o revise el código JavaScript— puede identificar un temporizador de cierre automático como una infracción.
• Reglas complementarias de axe para ejecutar junto con las comprobaciones manuales: Aunque no prueban directamente 1.4.13, ejecutar reglas como aria-tooltip-name (garantizar que los tooltips tengan nombres accesibles), color-contrast (garantizar que el texto del tooltip sea legible) y focus-visible (garantizar que los disparadores enfocados sean visualmente identificables) puede sacar a la luz problemas relacionados que agravan el impacto de los fallos de 1.4.13.

Cómo hacer las pruebas

1. Análisis automatizado de referencia: Ejecuta axe DevTools o Lighthouse en la página que contiene contenido activado por hover/foco. Ten en cuenta cualquier problema marcado con roles de tooltip, contraste o visibilidad del foco; esto no confirma el cumplimiento de 1.4.13, pero establece una referencia. Registra qué elementos disparan contenido superpuesto para poder dirigirte a ellos en los pasos manuales.
2. Identificar todo el contenido activado por hover/foco: Recorre la página y pasa sistemáticamente el puntero sobre cada elemento interactivo: botones de icono, enlaces con descripciones adicionales, ayudas de campos de formulario, elementos de navegación, cabeceras de tablas de datos y puntos de datos en gráficos. Enumera cada elemento que haga aparecer contenido adicional.
3. Probar el requisito de ser interactuable con hover: Para cada disparador identificado, pasa el puntero sobre él para mostrar la superposición y luego mueve lentamente el puntero desde el elemento disparador hacia el propio contenido de la superposición. La superposición debe permanecer visible durante todo este movimiento. Si desaparece antes de que el puntero la alcance, el criterio falla.
4. Probar el requisito de ser desactivable: Mientras una superposición esté visible (activada por hover o por foco de teclado), pulsa la tecla Escape. La superposición debe cerrarse. Si no se cierra, el criterio falla. Realiza esta prueba con el puntero aún sobre el disparador y también con el puntero sobre la superposición.
5. Probar el requisito de persistencia: Activa una superposición y luego deja el puntero quieto sobre el disparador o sobre la superposición durante al menos 10–15 segundos. La superposición debe permanecer visible durante todo ese tiempo. Si se desvanece, se agota el tiempo o desaparece sin acción de la persona usuaria, el criterio falla.
6. Prueba solo con teclado: Recorre la página usando únicamente el teclado. Cuando el foco se sitúe en un disparador que muestre contenido adicional, verifica: (a) que el contenido aparezca, (b) que pulsar Escape lo cierre y (c) que el contenido no desaparezca por sí solo mientras el foco permanezca en el disparador. Usa NVDA con Firefox, JAWS con Chrome y VoiceOver con Safari para confirmar que los lectores de pantalla también exponen correctamente el contenido.
7. Prueba con ampliación de pantalla: Ajusta el zoom del navegador al 400% o activa la ampliación a nivel de sistema operativo. Repite las pruebas de hover. Confirma que una persona usuaria que deba desplazar la ventana para llegar al tooltip pueda hacerlo sin que el tooltip desaparezca.
8. Revisar el código JavaScript: Busca en la base de código los manejadores de eventos setTimeout, mouseleave, mouseout y blur asociados con la lógica de ocultar superposiciones. Confirma que la lógica de ocultar no se active mientras el puntero esté sobre la superposición o mientras el disparador mantenga el foco, y que no se haya configurado ningún temporizador de cierre automático.

Cómo solucionarlo

Tooltip solo con CSS que desaparece en mouseleave — Incorrecto

<!-- 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; }
-->

Tooltip solo con CSS que desaparece en mouseleave — Correcto

<!-- 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 */
-->

Tooltip con JavaScript sin cierre con tecla Escape — Incorrecto

<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>

Tooltip con JavaScript sin cierre con tecla Escape — Correcto

<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>

Tooltip con cierre automático mediante setTimeout — Incorrecto

<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>

Tooltip con cierre automático mediante setTimeout — Correcto

<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>

Errores comunes

• Usar solo CSS :hover sin cubrir el espacio entre el disparador y el tooltip: Cuando hay incluso un espacio de 1–2 px entre el elemento disparador y el contenedor del tooltip, mover el puntero entre ellos hace que se pierda el estado de hover, ocultando el tooltip antes de que la persona usuaria llegue a él. Usa un pseudo-elemento transparente o un padding superpuesto para salvar este espacio.
• Vincular la lógica de ocultar a mouseleave en el disparador sin comprobar si el puntero se ha movido al tooltip: El tooltip desaparece en el instante en que el cursor abandona el disparador, incluso si el destino es el propio tooltip. Comprueba siempre tip.matches(':hover') antes de ocultar, o usa un breve retardo de rebote (debounce).
• Olvidar conectar los eventos de focus y blur junto con mouseenter y mouseleave: Las personas que solo usan teclado y que navegan con tabulador hasta el disparador nunca verán el tooltip si solo se gestionan eventos de ratón, lo que hace que la información asociada sea completamente inaccesible sin ratón.
• No añadir un listener para la tecla Escape, suponiendo que hacer clic fuera es suficiente: Las personas que usan solo teclado y quienes usan ampliación de pantalla no pueden "hacer clic fuera" de una superposición con facilidad. Escape es el mecanismo de cierre esperado y requerido para este criterio.
• Colocar el listener de Escape solo en el elemento disparador en lugar de en el document: Si la persona usuaria mueve el foco al tooltip o a otro elemento, un listener limitado al disparador no se ejecutará. El manejador de Escape debe estar en el documento o en un ancestro compartido que reciba siempre los eventos de teclado cuando la superposición esté abierta.
• Usar setTimeout para cerrar automáticamente los tooltips tras una duración fija: Cualquier cierre basado en temporizador que se dispare mientras el puntero siga sobre el disparador o el tooltip, o mientras el disparador mantenga el foco de teclado, es una infracción directa del requisito de persistencia. Elimina todos los temporizadores de cierre automático de las superposiciones activadas por hover/foco.
• Activar la visibilidad del tooltip exclusivamente mediante la sustitución del atributo title con estilos personalizados: Las personas desarrolladoras que eliminan el tooltip nativo de title y lo sustituyen por una versión personalizada deben implementar por sí mismas los tres requisitos de 1.4.13. La exención para los tooltips nativos del navegador no se extiende a las reproducciones personalizadas con JavaScript del mismo patrón.
• No hacer pruebas con ampliación de pantalla al 400% de zoom: Un tooltip que parece accesible con zoom normal puede quedar parcialmente fuera de la pantalla con niveles altos de zoom, lo que obliga a la persona usuaria a desplazarse; y si se cierra antes de que pueda desplazarse hasta él, la prueba que pasó al 100% de zoom falla en condiciones reales de uso.
• Aplicar pointer-events: none al contenedor del tooltip: Esta propiedad CSS impide que el puntero se considere nunca "sobre" el tooltip, lo que hace imposible cumplir el requisito de ser interactuable con hover independientemente de la demás lógica. Los tooltips con los que las personas usuarias puedan necesitar interactuar o simplemente pasar el puntero para mantenerlos visibles nunca deben tener pointer-events: none.
• Tratar ARIA role='tooltip' por sí solo como suficiente para el cumplimiento: Añadir role='tooltip' y aria-describedby es importante para la accesibilidad con lectores de pantalla, pero aborda una capa diferente del problema. Estos atributos ARIA no hacen que el contenido sea automáticamente desactivable, interactuable con hover o persistente; el comportamiento de interacción debe seguir implementándose explícitamente.

Relación con la normativa de accesibilidad de Turquía

La Circular Presidencial 2025/10 de Turquía, publicada en el Boletín Oficial número 32933 el 21 de junio de 2025, establece un mandato formal de accesibilidad que incorpora las normas WCAG por referencia. La circular exige que las entidades cubiertas implementen medidas de accesibilidad web alineadas con directrices reconocidas internacionalmente, y la conformidad de Nivel AA —que incluye WCAG 1.4.13— se fomenta firmemente y es obligatoria para las entidades que busquen el Logotipo de Accesibilidad (Erişilebilirlik Logosu) emitido por el Ministerio de Familia y Servicios Sociales (Aile ve Sosyal Hizmetler Bakanlığı).

La circular abarca una amplia gama de tipos de entidades que operan en Turquía. Las instituciones públicas y los organismos gubernamentales de todos los niveles administrativos están obligados a hacer accesibles sus servicios digitales. En el sector privado, la obligación se extiende a las plataformas de comercio electrónico, bancos y proveedores de servicios financieros, hospitales e instituciones privadas de atención sanitaria, operadores de telecomunicaciones con 200,000 o más abonados, agencias de viajes, empresas de transporte privado y escuelas privadas que operan bajo autorización del Ministerio de Educación Nacional (Millî Eğitim Bakanlığı).

WCAG 1.4.13 es especialmente relevante en contextos digitales turcos donde los patrones de tooltip y popover se usan ampliamente en portales de gobierno electrónico (como las integraciones de e-Devlet), interfaces bancarias y fintech que muestran información de comisiones o tipos de interés en tooltips y sistemas de citas sanitarias que presentan instrucciones adicionales mediante superposiciones activadas por hover. Una plataforma bancaria que incumpla 1.4.13 podría impedir que clientes con baja visión lean las divulgaciones de intereses presentadas mediante tooltip, un escenario que tiene implicaciones tanto de accesibilidad como de protección de las personas consumidoras de servicios financieros.

Para las entidades que persiguen el Erişilebilirlik Logosu, una auditoría de accesibilidad incluirá pruebas manuales de los comportamientos de hover y foco precisamente porque las herramientas automatizadas no pueden detectar estas infracciones. Las organizaciones que usen un SDK de superposición de accesibilidad como Accsible deben asegurarse de que cualquier tooltip, popover de recorridos guiados o panel de ayuda contextual inyectado por el propio SDK cumpla plenamente los tres requisitos de 1.4.13: desactivable mediante Escape, interactuable con hover sin cierre y persistente hasta que haya una acción de la persona usuaria. No hacerlo introduciría nuevas barreras a través de la propia herramienta destinada a mejorar la accesibilidad, socavando tanto el cumplimiento normativo como la confianza de las personas usuarias.