Chrome 156 puede pausar un GIF con una línea de CSS: lo que esto cambia para WCAG 2.2.2 y la EAA

Chrome 156 llega a stable el 20 de octubre de 2026 y trae consigo image-animation, la primera propiedad CSS que pausa una imagen animada sin JavaScript, sin tocar el servidor y sin cambiar el formato del archivo. Si auditas accesibilidad, esto importa porque el criterio WCAG 2.2.2 "Pausar, detener, ocultar" (nivel A) lleva años marcando como incumplidos a los sitios con GIF animados — y la excusa técnica de "no se puede pausar un GIF" deja de existir en Chrome el 20 de octubre. Si auditas rendimiento, también: el mismo navegador que te obliga a dejar de servir GIFs de 4 MB ahora te da el control para mantener animaciones pequeñas sin castigar al usuario.

No es una revolución de framework. Es una pieza pequeña del platform que resuelve un problema viejo, y como pasa con sizes="auto" o text-wrap: balance, quien la descubra tarde se lleva las migajas.

Qué llegó exactamente a Chrome 156

Chrome 156 implementa el módulo CSS Image Animation Module Level 1 (First Public Working Draft del W3C, 9 de abril de 2026, editado por Florian Rivoal). Trae dos piezas:

Detalles que importan al implementar:

• Se hereda. Puedes escribir :root { image-animation: paused } y pausar todo el documento por herencia, luego devolver normal o running a los img que sí deban animarse. Es exactamente el patrón que la propia especificación propone para prefers-reduced-motion.
• Aplica a imágenes de contenido y decorativas: img (incluido dentro de picture), fondos, bordes e imágenes inyectadas por content. Si un elemento tiene varias imágenes, el valor computado afecta a todas.
• No aplica a <video> ni a <canvas>, ni a imágenes programáticas. Es control de imágenes, no de media general.
• normal sincroniza todas las instancias del mismo archivo; running rompe esa sincronía a nivel de elemento. Si alternas entre paused y running, la animación continúa desde donde estaba y pierde el grupo; volver a normal la re-agrupa.

Por qué esto aterriza justo en WCAG 2.2.2

El criterio 2.2.2 "Pausar, detener, ocultar" (nivel A) exige: si el contenido arranca automáticamente, dura más de cinco segundos y se presenta en paralelo con otro contenido, debe existir un mecanismo para que el usuario lo pause, detenga u oculte. Un GIF de producto en bucle, un banner promocional animado, un sticker reaccional en un feed: todos caen ahí.

El problema histórico era que un GIF no se podía pausar. No existía atributo, propiedad ni evento. Las únicas salidas reales eran frágiles:

Con image-animation: paused más un control visible (botón propio o el enfoque/hover que la especificación permite construir con :animated-image), el mecanismo de 2.2.2 existe de verdad: el usuario decide, la animación se detiene o arranca, y no hace falta JavaScript para sostener el estado.

Matiz que no conviene saltarse: el criterio pide que el mecanismo sea operable, no que exista solo en el CSS. Pausar todo por prefers-reduced-motion sin ofrecer control no cumple 2.2.2 — cumple 2.3.3 (que es AAA). Lo correcto es pausar por defecto cuando el usuario lo pidió, y siempre ofrecer un play/pause visible para el resto.

La presión de fondo: la EAA ya está auditando

Este update no cae en un vacío regulatorio. La European Accessibility Act es exigible desde junio de 2025 y la vigilancia se ha normalizado: la autoridad neerlandesa ACM mostró a inicios de 2026 que el 61% de las tiendas online no cumplía los requisitos de accesibilidad, e Italia (AgID) da 90 días para corregir antes de activar multas diarias sin tope. Y hay un giro técnico reciente que hace que 2.2.2 deje de ser "criterio de WCAG 2.1, lo miramos luego": la versión v4.1.1 de EN 301 549, publicada el 2 de septiembre de 2026, adopta WCAG 2.2 a nivel AA como referencia técnica. En la práctica, audita contra 2.1 hoy y construye contra 2.2 — te contamos el desglose completo en el análisis de la migración EN 301 549 a WCAG 2.2.

En nuestras auditorías EAA el patrón de imagen animada aparece siempre en el mismo sitio: galerías de producto, banners de home y contenido incrustado de redes. Es de los pocos hallazgos que antes requería cirugía estructural (cambiar el formato) y ahora se cierra con una declaración CSS dentro de un bloque de soporte. En la auditoría de incumplimiento EAA que publicamos los hallazgos caros eran los de arquitectura; los baratos eran los de interfaz. Esto pasó de caro a barato.

Qué enviar el 20 de octubre (y qué esperar)

Honestidad primero: Chrome 156 es la única implementación. Safari y Firefox no lo tienen, y la especificación ni siquiera es una draft consolidada. En un mercado real, la estrategia es doble: capa progresiva con @supports, plan B con formato de video.

/* 1. Capa progresiva: solo los navegadores que entienden la propiedad */
@supports (image-animation: paused) {
  /* Pausa decorativas por herencia, respeta contenido animado intencional */
  :root { image-animation: stopped; }
  .gif-intencional { image-animation: normal; }

  /* Reduced motion: pausa, pero el usuario puede reproducir */
  @media (prefers-reduced-motion: reduce) {
    :root { image-animation: paused; }
    img:animated-image { cursor: pointer; }
  }
}

/* 2. Plan B para Safari/Firefox: el overlay JS existente, o mejor,
   servir cover frame y animar solo bajo interacción */
.gif-intencional { image-animation: normal; }

Antes de tocar el CSS, haz el inventario. En cada auditoría que hacemos esto se resuelve igual:

Y una observación sobre el calendario: no esperes a que Interop resuelva la disponibilidad cruzada por ti. El módulo acaba de salir como FPWD; el ciclo hasta tres implementaciones se mide en años, no en meses. Mientras tanto, la diferencia entre un sitio que pausa GIFs en Chrome y uno que no es exactamente el tipo de hallazgo que un auditor anota en un informe — y los informes de accesibilidad son cada vez más frecuentes en los procesos de compra.

Lo que sí sigue siendo trabajo tuyo

image-animation no arregla nada de esto solo:

• Los GIFs pesados siguen pesando. Pausar un GIF de 4 MB descarga igual 4 MB. El plan de formato (video para animaciones de más de unos segundos, WebP animado para las cortas) sigue siendo el correcto y sigue siendo rendimiento, no accesibilidad. En nuestro análisis de la trampa del LCP con imágenes medimos cómo el formato de imagen decide el LCP antes que cualquier CSS.
• Las animaciones CSS no entran aquí. animation-play-state ya existía y sigue siendo el control de keyframes. image-animation es para archivos animados, un hueco que llevaba veinte años sin solución.
• Los <video> autoplay siguen necesitando su propio mecanismo — controles o pausa explícita. Este módulo no los toca.
• La sincronía importa en galerías: cinco instancias del mismo sticker en un feed comparten timeline con normal. Si tu diseño depende de que arranquen juntas, tenlo en cuenta al alternar valores.

La línea de fondo

Chrome 156 convierte un problema de veinte años — "no se puede pausar un GIF" — en una declaración de una línea, y lo hace justo cuando Europa empieza a mirar las tiendas online con lupa. No va a cambiar tu arquitectura. Va a cambiar lo que un auditor escribe en la columna de hallazgos, y esa columna hoy tiene fechas, multas y ventanas de corrección. El 20 de octubre, cuando stable se actualice, la pregunta en tus auditorías deja de ser "¿tiene el sitio mecanismo para pausar el GIF?" y pasa a ser "¿por qué no lo tiene, si es una línea?".