WCAG 2.3.1 Three Flashes or Below Threshold is a Level A rule that says a web page must not contain anything that flashes more than three times in any one-second period — unless that flashing is small enough and dim enough to fall below the defined “flash thresholds.” Its single purpose is to stop your site from triggering seizures.

What WCAG 2.3.1 requires

The official wording is short: “Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds” (W3C, Understanding 2.3.1).

There are two ways to pass:

  1. Stay under three flashes per second. If no part of the page flashes more than three times in any single second, you pass — full stop, at any size or brightness.
  2. Stay below the flash thresholds. Faster flashing is still allowed only if it is small and dim enough not to be dangerous.

A “flash” has a specific technical meaning. The W3C defines it as a pair of opposing changes in relative luminance — a step up in brightness followed by a step back down — that can provoke seizures at the wrong size and frequency. So a single rapid flicker counts as one flash, and it is the transitions that matter, not just the bright frames.

The two thresholds, in plain terms

You only need the threshold math if your content flashes faster than three times a second and you want to keep it. Two limits apply at once:

  • General flash threshold. Per the W3C Understanding 2.3.1 document, a general flash is a pair of opposing luminance changes of 10% or more of maximum relative luminance (1.0), where the darker state is below 0.80 relative luminance. Content fails if it produces more than three general flashes in any one second and the combined flashing area occupies more than .006 steradians within a 10-degree visual field. The W3C estimates that 10-degree central field — the part of the eye most prone to triggering a seizure — as a 341 × 256 pixel rectangle anywhere on screen when content is viewed at 1024 × 768.
  • Red flash threshold. Saturated red is dangerous out of proportion to its brightness, so there is a separate, stricter limit on any pair of opposing transitions involving a saturated red. Deep-red strobes can trigger seizures even when a luminance-only test would pass them.

The takeaway for most small businesses: you almost never need to do this math. If your content does not strobe rapidly, you are already compliant. The threshold rules exist for the rare case where fast flashing is creatively essential — and even then it must be tiny and not red.

Who it protects

This criterion exists for people with photosensitive epilepsy and other photosensitive seizure disorders, for whom a flashing screen is not an annoyance but a medical event. According to MDN’s seizure disorders guide, “flashing lights between the frequencies of five to 30 flashes per second (Hertz) are most likely to trigger seizures” — and saturated-red flashing is especially dangerous. Unlike most accessibility issues, this one is not about whether someone can use your site — it is about whether your site can physically harm them.

It also affects people with vestibular disorders and migraine, who can be made dizzy or nauseated by aggressive flashing and motion. Importantly, assistive technology cannot help here. A screen reader does not strip out a flashing animation, and a blind user is not at risk — but a sighted keyboard or mouse user with epilepsy gets no protection from any tool except your decision to remove the hazard.

Concrete failures (and the fix)

Flashing problems are rarely intentional. They usually sneak in through media and effects:

  • A looping animated GIF that strobes. A “glitch” or strobe-effect GIF in a header or ad that flickers six or eight times a second over a large area. Fix: replace it with a still image or a slowed, low-contrast version. Looping GIFs must be analyzed across the full loop, not a single playthrough.
  • Autoplay hero video with rapid cuts or strobe lighting. Concert footage, lightning, camera flashes, or fast scene cuts that flash more than three times a second at full width. Fix: re-edit the clip, slow the cuts, or do not autoplay it. Test video at full-screen size, where the flashing area — and the risk — is largest.
  • A CSS/JS flash or “blink” effect. A notification badge or sale banner animated to flash for attention. This is the easiest to fix in code:
/* Risky: a fast, full-contrast strobe that can exceed 3 flashes/sec */
.sale-badge {
  animation: strobe 0.2s steps(1) infinite; /* 5 flashes per second */
}
@keyframes strobe {
  50% { opacity: 0; }
}

/* Safer: slow it well under the threshold, or drop the flash entirely */
.sale-badge {
  animation: pulse 2s ease-in-out infinite; /* one gentle pulse / 2s */
}
@keyframes pulse {
  50% { opacity: 0.6; } /* small luminance change, no full on/off */
}

Respecting the user’s motion preference is good practice alongside this — wrap nonessential animation in @media (prefers-reduced-motion: reduce) so it stops for users who have asked their OS to reduce motion. Note that 2.3.1 is non-negotiable: it has no “user can pause it” escape hatch the way WCAG 2.2.2 Pause, Stop, Hide does. A seizure can happen in under a second, so the fix must be to make the content safe by default, not to add a button.

How to test for 2.3.1

You cannot eyeball flash frequency reliably, so use the right tools:

  1. Inventory your moving content. List every animated GIF, autoplay video, ad slot, carousel, and CSS/JS animation. Static pages pass automatically.
  2. Run flagged media through a flash analyzer. W3C technique G15 names the PEAT (Photosensitive Epilepsy Analysis Tool) from the Trace Center and the Harding Flash and Pattern Analyzer. These measure luminance and red transitions frame by frame and tell you if content exceeds the general or red flash thresholds — math you cannot do by hand.
  3. Test at the real display size. Check video and animation at full-screen, because the flashing area must be measured against that 10-degree central field.
  4. Watch for embedded and third-party content. Auto-playing ads, social embeds, and user-uploaded GIFs are common offenders. Platforms like YouTube already run Harding-style analysis on upload, but content you host yourself is your responsibility.

The three W3C “sufficient techniques” map directly to these steps: G19 (ensure nothing flashes more than three times per second), G176 (keep any flashing area small enough), and G15 (use a tool to confirm the thresholds aren’t violated). This kind of media review is hands-on judgment work, which is why it belongs in a real accessibility audit rather than an automated-only scan.

Why it matters legally and practically

WCAG 2.1 — including 2.3.1 at Level A — is the practical benchmark courts and regulators point to for an accessible website. The Department of Justice’s April 2024 Title II final rule formally adopted WCAG 2.1 Level AA for state and local government sites, and Level AA includes every Level A criterion, so flashing content is squarely in scope for covered entities. For private businesses, ADA Title III claims routinely cite WCAG 2.1 as the yardstick.

Flashing content also carries a uniquely serious risk profile because it can cause physical injury, not just exclusion. In Eichenwald v. Rivello, a man who tweeted a strobing GIF to a journalist with epilepsy — deliberately triggering a seizure — faced criminal charges where the GIF was treated as a “deadly weapon,” and ultimately a $100,000 civil judgment (The Daily Record). That was an intentional assault, not a website-compliance case — but it shows how the law already recognizes flashing media as capable of real harm. A business that ships a dangerous strobe by accident is in a far better position having removed it than having to explain why it was there.

This is general information, not legal advice. For how these rules apply to your specific situation, consult a qualified attorney.

Fixing it the Curbcut way

Curbcut is deliberately anti-overlay. An overlay widget cannot un-flash a GIF or stop a strobing autoplay video that your page is already rendering, and a “pause” toggle a user has to find cannot act faster than a seizure that arrives in under a second. So we do the real work by hand: we inventory every GIF, autoplay clip, ad slot, and CSS/JS animation, run the flagged items through PEAT or Harding to measure them against the general and red flash thresholds, and rebuild or replace anything over the line directly in your code — then document conformance as part of broader remediation. If you are not sure whether anything on your site flashes, the fastest first step is a free accessibility scan; from there our team — [EXPERT_NAME] at [AGENCY_NAME] — can analyze your media frame by frame and tell you exactly what, if anything, crosses a threshold.