WCAG 2.3.2: Tres destellos

Qué Significa Esta Regla

WCAG 2.3.2 Tres Destellos es un criterio de éxito de nivel AAA bajo el principio de Operable. Establece que las páginas web no deben contener nada que destelle más de tres veces en cualquier período de un segundo. A diferencia de su equivalente de nivel AA (2.3.1 Tres Destellos o Por Debajo del Umbral), este criterio no permite ninguna excepción para áreas pequeñas que destellan o destellos que estén por debajo de los umbrales generales de destello y de destello rojo. La regla es absoluta: si el contenido destella más de tres veces por segundo, falla, independientemente del tamaño, color o contraste.

Un destello se define en WCAG como un par de cambios opuestos en la luminancia relativa que pueden causar convulsiones en algunas personas. De forma más práctica, cualquier parpadeo visible de encendido-apagado, animación tipo estroboscópica, imágenes que se ciclan rápidamente o video parpadeante que complete más de tres ciclos completos por segundo entra dentro del alcance de esta regla. El término "tres destellos" se refiere a tres oscilaciones completas, es decir, contenido que alterna entre un estado más claro y uno más oscuro tres veces dentro de un solo segundo.

Los tipos de contenido afectados son amplios e incluyen GIFs animados, animaciones CSS que usan @keyframes, actualizaciones del DOM impulsadas por JavaScript que causan cambios visuales rápidos, animaciones en HTML5 Canvas, contenido de video incrustado, animaciones SVG y redes publicitarias o widgets de terceros que incrustan medios animados. Incluso un parpadeo sutil en texto tipo marquesina desplazándose o visualizaciones de datos que se actualizan rápidamente pueden activar este criterio si la frecuencia supera los tres destellos por segundo.

Un aprobado bajo 2.3.2 significa que la página no contiene ningún contenido que destelle que supere el umbral de tres destellos por segundo. Un fallo ocurre cada vez que cualquier parte de la página —sin importar cuán pequeña sea el área— destella más de tres veces dentro de cualquier ventana de un segundo. No existe una excepción de área segura bajo este criterio, lo que lo distingue de 2.3.1. Un cursor diminuto parpadeando, un indicador de carga animado o un banner publicitario que cicla rápidamente podrían constituir fallos si destellan a frecuencias superiores a 3 Hz.

Por Qué Importa

La epilepsia fotosensible afecta aproximadamente a 1 de cada 4,000 personas a nivel mundial, pero la población total susceptible a alguna forma de respuesta neurológica fotosensible —incluyendo migrañas fotosensibles, trastornos vestibulares y fotosensibilidad no epiléptica— es significativamente mayor. Para estas personas, la exposición a contenido que destella rápidamente en una pantalla no es una simple molestia: puede desencadenar convulsiones tónico-clónicas, pérdida de conciencia, lesiones o, en casos raros, la muerte. A diferencia de muchas barreras de accesibilidad que degradan la experiencia de usuario, el contenido que destella presenta un riesgo de seguridad agudo.

Considere un escenario práctico: un sitio web de noticias turco incrusta un marcador en vivo con un efecto de resaltado animado que pulsa a 8 Hz para llamar la atención sobre noticias de última hora. Una persona con epilepsia fotosensible abre la página en su teléfono mientras se desplaza al trabajo. En cuestión de segundos, el parpadeo rápido desencadena una convulsión focal, haciendo que la persona deje caer el teléfono y pierda el control muscular momentáneamente. No tuvo advertencia, ni forma de desactivar el efecto de antemano, ni recurso alguno. Este escenario es completamente prevenible limitando las tasas de destello a tres por segundo o menos, o eliminando el contenido que destella por completo, como exige 2.3.2.

Más allá de la dimensión de seguridad neurológica, cumplir con este criterio también beneficia a personas con trastornos vestibulares (que experimentan mareos, náuseas o desorientación por el movimiento), personas con migrañas desencadenadas por patrones visuales y personas con trastornos por déficit de atención que encuentran imposible ignorar o sortear contenido que destella rápidamente. Reducir o eliminar el contenido que destella también tiende a mejorar la percepción de profesionalismo de la página y reducir las tasas de abandono, ya que muchas personas —con discapacidad o sin ella— encuentran irritantes las animaciones agresivas.

Desde la perspectiva de SEO y rendimiento, eliminar animaciones pesadas y transiciones CSS rápidas reduce la carga de CPU y GPU, mejorando métricas de Core Web Vitals como el Tiempo Total de Bloqueo (Total Blocking Time) y el Cambio Acumulativo de Diseño (Cumulative Layout Shift), ambas señales de posicionamiento para Google.

Reglas Relacionadas de Axe-core

WCAG 2.3.2 requiere pruebas manuales. Ninguna regla automatizada de axe-core se asigna directamente a este criterio, y esto es intencional: estas son las razones por las que las herramientas automatizadas no pueden detectar de forma fiable las infracciones:

• Se requiere prueba manual — Detección de la tasa de destello: Los escáneres de accesibilidad automatizados inspeccionan el DOM y el CSS estáticos en un único punto en el tiempo. No pueden observar cómo se comporta el contenido durante un segundo completo de reproducción de la animación, medir la frecuencia de oscilación de luminancia de un video o GIF animado, ni evaluar la tasa de fotogramas de una animación en Canvas. La tasa de destello es una propiedad temporal que requiere observación en tiempo real, lo que la sitúa fundamentalmente fuera del alcance de herramientas de análisis estático como axe-core. Una persona evaluadora —o herramientas especializadas de análisis de fotosensibilidad como Photosensitive Epilepsy Analysis Tool (PEAT)— debe revisar el contenido animado en movimiento para determinar si supera el umbral de tres destellos por segundo.
• Se requiere prueba manual — Contenido de terceros e incrustado: Anuncios, videos incrustados, widgets de redes sociales e iframes pueden inyectar contenido animado que axe-core no puede analizar, porque opera dentro de las restricciones de la política de mismo origen del navegador. Una persona evaluadora debe observar manualmente todo el contenido incrustado y de terceros durante la reproducción para evaluar el cumplimiento.
• Se requiere prueba manual — Animaciones impulsadas por JavaScript: Alternar clases CSS rápidamente, actualizar píxeles de canvas o manipular elementos SVG mediante JavaScript a alta frecuencia puede producir efectos de destello que son invisibles en una instantánea estática del DOM. Las personas evaluadoras deben ejecutar la página en un navegador en vivo, observar todos los estados animados y cronometrar los ciclos de destello manualmente o con herramientas de análisis de tasa de fotogramas.

Cómo Probar

1. Ejecutar un escaneo automatizado como línea base: Use axe DevTools, Lighthouse o la auditoría integrada del widget de Accsible para identificar cualquier problema relacionado con animaciones que se haya marcado. Aunque ninguna regla se asigna directamente a 2.3.2, estas herramientas pueden mostrar advertencias relacionadas sobre animaciones CSS o regiones ARIA en vivo que se actualizan rápidamente. Tome nota de cualquier elemento marcado, pero entienda que un informe automatizado limpio no confirma el cumplimiento de 2.3.2.
2. Identificar todo el contenido animado manualmente: Cargue la página en un navegador y obsérvela durante al menos 30 segundos sin interactuar. Tome nota de cada elemento que parpadea, destella, se anima o cambia de estado visual repetidamente. Incluya indicadores de carga, banners, animaciones en el área principal (hero), videos de reproducción automática, fondos animados y cualquier widget de terceros. Cree un inventario de estos elementos.
3. Usar Photosensitive Epilepsy Analysis Tool (PEAT): Para contenido de video o grabaciones de pantalla de animaciones, use PEAT (una herramienta gratuita del Trace Research and Development Center) para analizar el metraje fotograma a fotograma. PEAT marcará cualquier secuencia que supere los umbrales de destello y reportará tanto el umbral general de destello como el umbral de destello rojo. Un fallo de 2.3.2 es cualquier destello que supere tres por segundo, independientemente de otros umbrales.
4. Medir las tasas de animación CSS y JavaScript: Abra las DevTools del navegador (Chrome o Firefox) y use la pestaña Performance para registrar una sesión de 5 segundos mientras se reproducen las animaciones. Inspeccione el gráfico de llamas (flame graph) en busca de operaciones de pintura o diseño que se repitan rápidamente. También puede abrir el panel Animations en Chrome DevTools para ver las animaciones en ejecución y sus duraciones; divida 1000 ms por la duración de la animación para calcular los Hz.
5. Probar con NVDA + Firefox, VoiceOver + Safari y JAWS + Chrome: Las personas usuarias de lectores de pantalla no están exentas de fotosensibilidad. Inicie cada lector de pantalla y navegue por la página normalmente. Si algún contenido que destella visualmente también se presenta de una manera que cause actualizaciones rápidas de la pantalla (como una región en vivo que anuncia cada fotograma de un contador), documente esto. El destello visual sigue siendo una infracción incluso para personas usuarias de lectores de pantalla porque pueden tener algo de visión funcional.
6. Verificar contenido de terceros e incrustado: Desplácese por todos los iframes, publicaciones incrustadas de redes sociales, espacios publicitarios y reproductores de video. Reproduzca manualmente cualquier video con reproducción automática deshabilitada y observe si hay parpadeo rápido. Revise los GIFs animados haciendo clic derecho e inspeccionando los datos de fotogramas en un editor de imágenes o en la pestaña Network del navegador para estimar la tasa de fotogramas.
7. Repetir las pruebas en distintos dispositivos y navegadores: Algunas animaciones se ejecutan a diferentes velocidades en dispositivos móviles frente a escritorio debido a diferencias en la aceleración por hardware. Pruebe tanto en un navegador de escritorio como en un dispositivo móvil (Safari en iOS y Chrome en Android) para confirmar un cumplimiento consistente.

Cómo Corregir

Animación CSS con Keyframes Destellando Demasiado Rápido — Incorrecto

<!-- Una insignia que destella para llamar la atención, completando 8 ciclos por segundo -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.125s infinite; /* 8 Hz — supera ampliamente 3 por segundo */
  }
</style>
<span class='alert-badge'>NEW</span>

Animación CSS con Keyframes Destellando Demasiado Rápido — Correcto

<!-- Animación ralentizada para completar menos de 3 ciclos por segundo -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.4s infinite; /* ~2.5 Hz — con seguridad por debajo del umbral de 3 Hz */
  }
</style>
<span class='alert-badge'>NEW</span>
<!-- Mejor aún: elimine la animación por completo y use una insignia estática de alto contraste -->

Alternancia del DOM con JavaScript Causando Parpadeo Rápido — Incorrecto

<!-- El script alterna la visibilidad 10 veces por segundo para simular un efecto estroboscópico -->
<div id='strobe-element' style='width:200px;height:200px;background:white;'></div>
<script>
  setInterval(function() {
    var el = document.getElementById('strobe-element');
    el.style.background = el.style.background === 'white' ? 'black' : 'white';
  }, 100); /* Se ejecuta cada 100 ms = 10 destellos por segundo -- un grave riesgo de convulsión */
</script>

Alternancia del DOM con JavaScript Causando Parpadeo Rápido — Correcto

<!-- Se eliminó por completo la alternancia rápida; en su lugar, transmita el cambio de estado mediante texto o un ícono -->
<div id='status-element' style='width:200px;height:200px;background:#005fcc;'>
  <p style='color:white;padding:1rem;'>System Active</p>
</div>
<!-- Si la animación es realmente necesaria, manténgala muy por debajo de 3 Hz y prefiera transiciones
     de opacidad/color en lugar de cambios de luminancia de alto contraste -->

GIF Animado con Alta Tasa de Fotogramas — Incorrecto

<!-- Un anuncio en GIF animado que cicla por los fotogramas a 10 fps -->
<img src='promo-flash.gif' alt='Special offer — 50% off this weekend only'>
<!-- El retardo interno de fotogramas del GIF está configurado en 10 ms por fotograma, creando un parpadeo rápido -->

GIF Animado con Alta Tasa de Fotogramas — Correcto

<!-- Reemplace el GIF animado con una imagen estática, o vuelva a exportar el GIF
     con un retardo mínimo de 334 ms por fotograma (3 fps o más lento) -->
<img src='promo-static.png' alt='Special offer — 50% off this weekend only'>
<!-- Si es imprescindible conservar el movimiento, use una animación CSS con soporte para prefers-reduced-motion -->
<picture>
  <source srcset='promo-static.png' media='(prefers-reduced-motion: reduce)'>
  <img src='promo-slow.gif' alt='Special offer — 50% off this weekend only'>
</picture>

Errores Comunes

• Suponer que la excepción de "área pequeña" de 2.3.1 aplica a 2.3.2: WCAG 2.3.1 permite contenido que destella y ocupa menos del 25% de un campo visual de 10 grados. WCAG 2.3.2 no tiene tal excepción: un cursor diminuto parpadeando o un pequeño punto de carga que destella más de tres veces por segundo es una infracción completa a nivel AAA.
• Configurar animation-duration de CSS con valores como 0.1s o 0.2s sin calcular la tasa de destello resultante: Una animación de 0.1 s que oscila entre dos estados completa 10 ciclos por segundo (10 Hz). Divida 1 por la duración en segundos para obtener los Hz; asegúrese de que el resultado sea 3 o menos.
• Incrustar scripts publicitarios de terceros sin revisar el comportamiento de las animaciones: Las redes publicitarias sirven con frecuencia creatividades animadas con altas tasas de destello optimizadas para el clic, no para la accesibilidad. Audite siempre el contenido de terceros usando PEAT o inspección manual de fotogramas antes de su implementación.
• Usar bucles de setInterval o requestAnimationFrame para alternar clases CSS rápidamente en indicadores de carga o progreso: Cualquier bucle de JavaScript que cambie la luminancia o visibilidad de un elemento más de tres veces por segundo crea una infracción de 2.3.2, incluso si el efecto parece sutil en condiciones normales de visualización.
• No probar SVGs animados y elementos Canvas: Las animaciones SVG que usan <animate> o SMIL, y los juegos o visualizaciones de datos basados en Canvas, rara vez se prueban con PEAT o herramientas de tasa de fotogramas, pero son totalmente capaces de superar el umbral de destello.
• Confiar únicamente en axe-core o Lighthouse para confirmar el cumplimiento de 2.3.2: Las herramientas automatizadas no pueden detectar este criterio. Un escaneo automatizado limpio no significa nada para 2.3.2; solo la revisión manual y el análisis con PEAT pueden confirmar el cumplimiento.
• Tratar prefers-reduced-motion como una solución completa para 2.3.2: Respetar la media query prefers-reduced-motion es una buena práctica y útil para muchas personas, pero es un mecanismo de participación voluntaria por parte de la persona usuaria. WCAG 2.3.2 exige que el contenido sea seguro por defecto, no solo cuando la persona usuaria ha configurado una preferencia del sistema. Las personas que no han configurado este ajuste siguen en riesgo.
• Aplicar límites de tasa de destello solo al video pero no a animaciones CSS, JavaScript o GIF: Algunos equipos auditan el contenido de video con PEAT pero pasan por alto las animaciones CSS con keyframes y las alternancias impulsadas por JavaScript. Todas las tecnologías de animación deben evaluarse.
• Usar propiedades CSS background-image para mostrar GIFs animados: Los GIFs animados configurados como imágenes de fondo CSS son menos visibles para quienes realizan una revisión visual y son fáciles de pasar por alto durante las auditorías. Incluya siempre las imágenes de fondo en su inventario de animaciones.
• No volver a probar después de que pruebas A/B o cambios de personalización inyectan nuevo contenido animado: Los sistemas de marketing y personalización pueden inyectar dinámicamente banners u overlays con animaciones que nunca se revisaron para el cumplimiento de WCAG 2.3.2. Establezca una etapa de revisión para cualquier contenido inyectado dinámicamente.

Relación con las Regulaciones de Accesibilidad de Turquía

La Circular Presidencial 2025/10 de Turquía, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025, establece estándares obligatorios de accesibilidad web y móvil para una amplia gama de entidades que operan en Turquía. La circular adopta WCAG 2.2 como su marco de referencia técnico, con cumplimiento obligatorio generalmente requerido en los niveles A y AA.

WCAG 2.3.2 es un criterio de nivel AAA y, por lo tanto, no es legalmente obligatorio bajo la circular para la mayoría de las entidades cubiertas. Sin embargo, su temática —la prevención de contenido que pueda desencadenar convulsiones— se cruza directamente con el deber general de cuidado y los principios de no discriminación que sustentan la regulación. Los siguientes tipos de entidades están cubiertos por la circular y deberían tratar 2.3.2 como una obligación de buena práctica sólida, incluso cuando no sea estrictamente requerida: plataformas de comercio electrónico, instituciones públicas y organismos gubernamentales, bancos e instituciones financieras, hospitales y proveedores de atención sanitaria, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE).

Para las instituciones públicas y los proveedores de atención sanitaria en particular, las implicaciones éticas de 2.3.2 son especialmente importantes. Un portal de salud gubernamental o una página de información para pacientes de un hospital que desencadene una convulsión en una persona visitante fotosensible representaría tanto un fallo de seguridad como una crisis reputacional. Aunque la circular no exige explícitamente el cumplimiento de nivel AAA, las organizaciones que busquen demostrar una accesibilidad de primer nivel —ya sea para ser elegibles en procesos de contratación pública, para generar confianza pública o para asociaciones comerciales internacionales— deberían implementar 2.3.2 junto con sus obligaciones obligatorias de nivel A y AA.

Las organizaciones que prestan servicios al mercado de la Unión Europea también deben tener en cuenta que la Ley Europea de Accesibilidad (EAA), que entró en aplicación en junio de 2025, hace referencia a la norma EN 301 549, que a su vez hace referencia a WCAG. Las empresas turcas que exportan productos o servicios digitales a estados miembros de la UE pueden enfrentarse a requisitos más estrictos a través de ese canal. Implementar 2.3.2 de forma proactiva posiciona bien a las organizaciones turcas tanto para el cumplimiento nacional como transfronterizo.

Desde una perspectiva de implementación práctica, el SDK del widget superpuesto de Accsible puede ayudar a las organizaciones cubiertas proporcionando a las personas usuarias la opción de pausar o detener todas las animaciones en una página, lo que ayuda a reducir el riesgo de fotosensibilidad para quienes son conscientes de su condición. Sin embargo, este control activado por la persona usuaria es una medida complementaria, no un sustituto de eliminar o ralentizar el contenido que destella en su origen, como exige 2.3.2.