Skip to main content
WCAGrules
Quick navigation

Three Flashes or Below Threshold

Nothing on the page may flash more than three times in any one second, and the way past that is to keep the flash below the general flash and red flash thresholds. Those thresholds are a defined term with numbers inside, not a judgement call. Content passes if it stays at three flashes or fewer per second, or if everything flashing at once covers no more than a quarter of a 10 degree slice of the viewer's vision. That quarter carries a pixel figure, and it is smaller than the number usually quoted. W3C estimates the whole 10 degree field at a 341 by 256 rectangle, so the quarter you are allowed is roughly 21,824 square pixels rather than the 87,296 of the field itself. Both numbers rest on an assumed screen size and viewing distance, which is why neither is a promise. A general flash means a pair of opposing changes in relative luminance of 10% or more, where the darker state sits below 0.80. A red flash means a pair of opposing transitions through saturated red, and WCAG 2.2 added a numeric definition of what red means there. A third route out exists as well. Fine balanced patterns such as white noise, or a checkerboard with very small squares, are excused by name.

Why it matters

Every other rule here protects access to information. This one protects a person's body. Photosensitive epilepsy means a strobing sequence can trigger a seizure in somebody who did nothing but load the page, so a marketing asset is capable of causing physical harm to a customer. There is nothing on the other side of that scale to weigh against it. W3C is honest about the limits of its own numbers, too. The threshold assumes a viewing distance, and a person sitting closer than that, or using magnification, can be affected by content that passes. So the conforming answer and the safe answer are not always the same answer. Where there is doubt, cut the flash.

Who this rule protects

This affects people with photosensitive epilepsy, for whom a failure is a medical risk rather than an inconvenience, and it affects visitors who get migraines, dizziness or nausea from flashing content without ever having a seizure.

How to check it yourself

  1. Count the flashes first. Three or fewer in any one second and the content passes, with no tool and no argument.
  2. For anything faster, measure the area. The threshold is a quarter of a ten degree field of vision, and W3C works that out as roughly 21,824 square pixels for a 1024 by 768 screen viewed from about two feet. A 341 by 256 block is the whole field, so it is four times the size of the limit and not the number to measure against. Somebody sitting closer, or enlarging the page, moves the real boundary again.
  3. Test video at the biggest size it can be played, not the size it sits at on the page. Full screen is where the area test starts to fail.
  4. Test short animations while they loop, because the loop point can add a flash the single play never showed. Three flashes in a clip that runs for a second become four in a second once it starts again. A clip long enough to space those three flashes out is unchanged by looping, so check the transitions either side of the join rather than assuming.
  5. Run anything borderline through a photosensitivity analysis tool before it goes live. Lightning, gunfire, fast cuts and glitch effects are the recurring four, and using a tool is a documented way to satisfy this rule rather than a precaution.
  6. Check third-party and user-uploaded video too. This rule reaches every part of the page, so an advertisement you did not make is still your failure.

Failures we see most often

  • A promotional video strobing white frames full screen at roughly 8 flashes per second.
  • A glitch-style text animation flickering on a continuous loop, above the flash rate and above the area limit.
  • A video that passes in its 640 pixel player and fails the moment somebody presses fullscreen, because the flashing area scales up with it.
  • A short animation that flashes three times per play and loops immediately, so the loop point produces a fourth flash inside the same second.
  • A third-party advertisement flashing above the rate and over the area limit, on a page whose own content is clean. Somebody else's asset is your failure here, though flashing on its own is not, since an ad that stays inside the thresholds passes like anything else.

Who this one is for

Read from this rule's own note above, so the grouping and the note cannot disagree.

How to fix it

  • Cut the sequence to three flashes per second or fewer. That is the fix that needs no measurement afterwards, and W3C's own example is a lightning scene edited down to three.
  • Or shrink it. Keeping the flashing area under the threshold is a documented answer, and the standard's muzzle-flash example is exactly that, a bright flash confined to a small part of the frame.
  • Or dim it. A general flash needs a luminance swing of 10% or more with the darker state below 0.80, so softening either end takes the sequence out of that definition. It does not take it out of the red flash definition, which turns on transitions through saturated red rather than on brightness, so anything red has to clear both tests.
  • Screen third-party and user-uploaded video before it publishes. Somebody else's asset becomes your finding on this rule.
  • Where video ships in a wide colour space or high dynamic range, test the highest dynamic range version, because the thresholds there are stated in luminance rather than in sRGB values.
Step-by-step fix guides (3)

Passes vs. fails

A general illustration of the pattern rather than a test of 2.3.1. Passes: under the flash threshold. Fails: flashing above 3 per second.

Passes

The same edit, recut so the flashes land three times a second, keeps the energy and drops the hazard.

Fails

A launch video strobes white frames across the whole screen at roughly 8 flashes per second.

In audits and lawsuits

This finding is rare, and it is the most severe one we issue. It goes straight to a takedown recommendation rather than into the fix queue. It is also the place where automated help is worth being precise about, because two different kinds of tool get called the same thing. W3C publishes no test rule for this criterion, or for either of the other two in the same guideline, so the accessibility scanner in your pipeline returns a clean sheet on the whole of the one guideline whose failure is a medical event. A photosensitivity analyser is a different instrument. It reads the frames rather than the markup, and using one is a documented way to satisfy this rule. Two testing habits change what either finds, and both are easy to skip. Analyse content at the largest size a user can view it, so a video that passes in a 640 pixel player gets checked again at full screen. And analyse short clips while they loop, because a three-flash GIF can produce a fourth flash at the loop point.

Go somewhere useful

Find tools, resources and your workspace.

29 destinations