Chrome 156 Can Pause a GIF With One CSS Line: What It Changes for WCAG 2.2.2 and the EAA

Chrome 156 lands in stable on October 20, 2026 with image-animation — the first CSS property that pauses an animated image without JavaScript, without touching the server, and without changing the file format. If you run accessibility audits, this matters: WCAG 2.2.2 "Pause, Stop, Hide" (Level A) has been flagging sites with animated GIFs for years, and the technical excuse of "there is no way to pause a GIF" stops existing in Chrome on October 20. If you care about performance, it matters too: the same browser that tells you to stop serving 4 MB GIFs now hands you the control to keep small animations without punishing the user.

This is not a framework revolution. It is a small platform piece that solves an old problem, and — like sizes="auto" or text-wrap: balance — whoever discovers it late collects the crumbs.

What exactly shipped in Chrome 156

Chrome 156 implements the CSS Image Animation Module Level 1 (W3C First Public Working Draft, April 9, 2026, edited by Florian Rivoal). It ships two pieces:

Details that matter when you implement:

• It inherits. You can write :root { image-animation: paused } and pause the whole document through inheritance, then hand normal or running back to the img elements that should animate. This is exactly the pattern the specification itself proposes for prefers-reduced-motion.
• It applies to content and decorative images: img (including inside picture), backgrounds, border images, and images injected via content. When an element carries several images, the computed value affects all of them.
• It does not apply to <video> or <canvas>, nor to programmatic images. This is image control, not general media control.
• normal synchronizes all instances of the same file; running breaks that synchronization per element. Toggling between paused and running resumes from the current frame and detaches from the group; returning to normal re-groups it.

Why this lands right on WCAG 2.2.2

Success criterion 2.2.2 "Pause, Stop, Hide" (Level A) requires: when content starts automatically, lasts more than five seconds, and is presented in parallel with other content, there must be a mechanism for the user to pause, stop, or hide it. A product GIF looping in a carousel, an animated promo banner, a reaction sticker in a feed — all of them fall under it.

The historical problem was that a GIF could not be paused. There was no attribute, no property, no event. The only real workarounds were fragile:

With image-animation: paused plus a visible control (your own button, or the hover/focus play pattern the specification enables via :animated-image), the 2.2.2 mechanism genuinely exists: the user decides, the animation stops or starts, and no JavaScript is needed to hold the state.

One nuance worth keeping: the criterion requires the mechanism to be operable, not merely present in CSS. Pausing everything through prefers-reduced-motion without offering a control does not satisfy 2.2.2 — it satisfies 2.3.3, which is AAA. The correct pattern is to pause by default when the user asked for it, and always offer a visible play/pause for everyone else.

The pressure underneath: the EAA is already auditing

This update does not land in a regulatory vacuum. The European Accessibility Act has been enforceable since June 2025 and surveillance has normalized: the Dutch authority ACM showed in early 2026 that 61% of online shops failed accessibility requirements, and Italy (AgID) gives 90 days to remediate before daily fines start accumulating without a cap. There is also a recent technical twist that stops 2.2.2 from being "a WCAG 2.1 criterion, we'll look at it later": version v4.1.1 of EN 301 549, published on September 2, 2026, adopts WCAG 2.2 Level AA as the technical reference. In practice: audit against 2.1 today, build against 2.2 — we broke down the whole EN 301 549 to WCAG 2.2 migration.

In our EAA audits, the animated-image pattern always shows up in the same places: product galleries, home banners, and embedded social content. It is one of the few findings that used to require structural surgery (changing the format) and now closes with a declaration inside a support block. In the EAA non-compliance audit we published, the expensive findings were architectural; the cheap ones were interface. This one just moved from expensive to cheap.

What to ship on October 20 (and what to wait for)

Honesty first: Chrome 156 is the only implementation. Safari and Firefox do not have it, and the specification is not even a consolidated draft. In a real market, the strategy is dual: progressive enhancement with @supports, format fallback with video.

/* 1. Progressive layer: only browsers that understand the property */
@supports (image-animation: paused) {
  /* Pause decorative images through inheritance, keep intentional content animating */
  :root { image-animation: stopped; }
  .intentional-gif { image-animation: normal; }

  /* Reduced motion: pause, but the user can still play */
  @media (prefers-reduced-motion: reduce) {
    :root { image-animation: paused; }
    img:animated-image { cursor: pointer; }
  }
}

/* 2. Fallback for Safari/Firefox: the existing JS overlay, or better,
   serve the cover frame and animate only under interaction */
.intentional-gif { image-animation: normal; }

Before touching CSS, take the inventory. In every audit we run, this resolves the same way:

And one observation on timing: do not wait for Interop to solve cross-browser availability for you. The module just shipped as a First Public Working Draft; the cycle to three implementations is measured in years, not months. Meanwhile, the difference between a site that pauses GIFs in Chrome and one that does not is exactly the kind of finding an auditor writes into a report — and accessibility reports are showing up more often in procurement processes.

What is still your job

image-animation fixes none of this by itself:

• Heavy GIFs still weigh the same. Pausing a 4 MB GIF still downloads 4 MB. The format plan (video for animations longer than a few seconds, animated WebP for short ones) remains correct and remains performance, not accessibility. In our analysis of the LCP trap with image formats we measured how image format decides LCP before any CSS does.
• CSS animations do not belong here. animation-play-state already existed and remains the control for keyframes. image-animation is for animated files — a gap that sat unsolved for twenty years.
• Autoplay <video> still needs its own mechanism — controls or explicit pause. This module does not touch it.
• Synchronization matters in galleries: five instances of the same sticker in a feed share a timeline under normal. If your design depends on them starting together, account for that when toggling values.

The bottom line

Chrome 156 turns a twenty-year-old problem — "there is no way to pause a GIF" — into a one-line declaration, and it does so exactly when Europe starts scrutinizing online stores. It will not change your architecture. It will change what an auditor writes in the findings column, and that column now carries dates, fines, and remediation windows. On October 20, when stable updates, the question in your audits stops being "does this site have a mechanism to pause the GIF?" and becomes "why not, if it is one line?"