Seizure Risk in Generated Motion and Strobe
Model defaults love lightning, glitch, and strobe. Photosensitive thresholds, a pre-publish flash test, and how to dim or recut for web and social.
Prompt a video model for energy and it will give you lightning, a glitch cut, a camera flash, police bars, a rave. Those are not "high motion." They are flashes: pairs of opposing luminance changes, often saturated red or white, often looping. WCAG 2.2 Success Criterion 2.3.1 (Level A) does not care that a model made the clip. It cares whether the published page contains anything that flashes more than three times in any one-second period, unless the flash is below the general flash and red flash thresholds.
Broadcast teams already know the Harding Flash and Pattern Analyser as a delivery gate. This post is not that gate. Social clips, site heroes, and looping stories are watched closer, on smaller screens, often full-bleed, often repeating. WCAG's own understanding document says content should be analysed at the largest scale a user may view it, including fullscreen, and that short clips which loop should be analysed while looping. A six-frame strobe that passes a linear play-out can fail the moment the story sticks.
Generated motion loves a flash
The failure is upstream of the QC tool. Models trained on "cinematic" and "viral" footage have seen a lot of lightning, muzzle flash, glitch transitions, and club lighting. Ask for "dramatic reveal" or "energy" and you will get a luminance spike. Ask for "glitch" and you will get alternating frames. None of that is a safety-checker refusal in the way a photoreal person might be. Motion level in a prompt is not a flash budget.
Patterns that become 2.3.1 problems: lightning with several strikes in a second; glitch templates that slam to white every few frames; camera-flash bursts; police or alarm LEDs in saturated red; club lighting; explosion and muzzle-flash close-ups that fill the frame. Rapid crash zooms are a separate craft issue (crash zooms and whip pans); the exposure flicker on top of them is the flash.
A defect taxonomy for generated video will catch extra limbs. It will not catch a four-flash-per-second plate unless flash is on the list. Add it. WCAG distinguishes blinking (a distraction you can stop) from flashing (a seizure risk you cannot wait out). 2.3.1 is a non-interference criterion: failing content can make the whole page unusable.
The thresholds that matter
The simplest pass is also the one most generated clips should aim for.
Three flashes per second. If nothing flashes more than three times in any one-second window, you pass 2.3.1 without measuring area or colour. WCAG technique G19 is that rule. Count a flash as a pair of opposing changes: light-dark-light or dark-light-dark. Four lightning strikes in 800 ms is already over, even if the rest of the ten-second clip is calm.
If you cannot stay under three, you are in the threshold test:
- A general flash is a pair of opposing changes in relative luminance of 10% or more of the maximum, where the darker image is below 0.80 (on the 0–1 relative-luminance scale).
- A red flash is a pair of opposing transitions involving a saturated red. People are more sensitive to red; WCAG 2.2's working definition of that pair is a transition to or from a state with R/(R+G+B) ≥ 0.8 and a CIE 1976 UCS chromaticity difference greater than 0.2. Police bars and alarm LEDs land here more often than a white glitch.
- The combined area of concurrent flashes must stay within 0.006 steradians of any 10-degree visual field at typical viewing distance, described as 25% of that field. The worked web estimate is a 341 × 256 CSS-pixel rectangle on a 1024 × 768 reference. WCAG 2.2 notes that the same CSS-pixel area is the right unit across devices, because a phone screen fills less of the world even when the clip is full-bleed. It also notes the specification cannot account for someone who sits closer than the idealised distance. Social video is often held closer. Do not spend your margin.
For colour spaces other than sRGB, WCAG points at ITU-R BT.1702: a general flash is a change of 20 cd/m² or more where the darker image is below 160 cd/m², with a further Michelson-contrast rule for HDR when the darker state is already at or above 160 cd/m². Test the highest-dynamic-range version you ship. A fine checkerboard with squares smaller than 0.1 degree is excepted. A full-frame glitch is not. SC 2.3.2 (Level AAA) drops the thresholds: no more than three flashes per second, full stop. Hitting G19 also hits 2.3.2.
A pre-publish flash test
You do not need a broadcast Harding licence to catch the obvious cases. You do need a step that is not "it looked fine on my laptop."
- Watch once at the real size, looping. Play the clip fullscreen on a phone and on a desktop, with the loop that the destination will use. Count flashes in the worst one-second window. If you count four or more, you have already failed G19. Stop and recut before you open a tool.
- Do not trust a 480p pass as a luminance instrument. Versely's editor preview is a free 480p render with a short per-user cooldown. Use it to see a strobe and recut. It is not PEAT, and it is not Harding. Do not log it as a 2.3.1 test.
- If the clip is over three flashes, measure. The Trace Center Photosensitive Epilepsy Analysis Tool (PEAT) is the web-oriented tool WCAG lists. It evaluates against the general and red flash thresholds. It is for web and computer content, not a substitute for a broadcast Harding FPA certificate. Harding FPA remains the UK broadcast instrument; WCAG cites it as a related resource, not as the web test.
- Capture at the largest presentation. A site hero that can go fullscreen must be tested fullscreen. A story that occupies the whole phone must be tested as a full-bleed 9:16, not as a small embed on a 16:9 monitor.
- Test the loop, not only the linear file. A 12-frame flash cycle that sits at the loop point can produce a fourth flash in a rolling one-second window even when a linear analyser, run once through, looks calmer. Export the looping GIF or the repeating story and analyse that.
- Log the window. Write down the timestamp of the worst second, the flash count, and whether red was involved. A check-before-publish pass with
analyze_videowill describe beats and on-screen text. It will not certify 2.3.1. Keep flash on a separate checklist next to the defect taxonomy.
If you cannot run PEAT, G19 still holds: recut until no one-second window contains more than three flashes. That is a complete 2.3.1 pass.
How to dim or recut
Fix in this order. Each step is cheaper than the next.
Recut the flash count. Delete strikes. Hold on the aftermath of the lightning instead of the strike. Replace a four-pop glitch with a single hit and a recovery. This is the G19 fix and it is the one you should try first.
Shrink the flashing area. WCAG technique G176 is keep the flashing area small enough. A muzzle flash in a corner can pass when a full-frame version fails. Crop, mask, or regenerate on a wider shot so the spike is not the whole phone.
Dim the peak. Lower the white. Lower the contrast of the glitch layer. For HDR, the BT.1702 numbers are in cd/m²; a grade that pulls the peak down is a real mitigation, not a vibe. Do not "fix" a strobe by adding a dark overlay that still flips at 8 Hz.
Get off saturated red. Swap police-bar red for a cooler strobe, or recut the red out. Red flashes fail at sizes and contrasts a white flash might still pass.
Stop the loop. A story that repeats a three-flash sting becomes a four-plus flash in the overlap. Either do not loop, or put more than a second of non-flashing picture between the last flash and the first.
Change the prompt, then regenerate. On a text-to-video job, say what you do not want. A negative prompt that names "strobe, flashing lights, rapid lightning, rapid glitch, police lights" is more useful here than "low motion," which the model may read as a locked-off camera with a still-flashing sky. If the last four seconds of a clip are the problem, extend from a clean frame rather than from the strobe.
Do not ship a warning as the fix. A "this video may trigger seizures" line does not satisfy 2.3.1. The criterion is the content, not a notice after it has started.
Harding still matters if the same master goes to linear television in a territory that requires it. A social encode that passed G19 is not a broadcast pass, and a Harding pass on a 16:9 SDR tape is not a WCAG pass on a looping 9:16 HDR story. Different screens, distances, and loops.
FAQ
Does a clip that flashes twice a second still need PEAT?
No. If no one-second window contains more than three flashes, 2.3.1 is met. PEAT and Harding are for the cases where you are over the count and need to know whether area and colour still save you. Prefer recutting under three.
Is a glitch overlay a flash or just a style?
If it is a pair of opposing luminance changes, large enough and fast enough, it is a flash. Style is not a category in 2.3.1. Count the inversions in the worst second. If you cannot count them because the overlay is a fine checkerboard of tiny squares, you may be in the pattern exception; a full-frame RGB slam is not.
Can I rely on the model's safety checker for this?
Not for photosensitivity. Safety checkers are built around people, sexual content, and some violence. They do not grade 10% relative-luminance transitions. Flash is a publish-time test on the file you will actually loop.
Does this apply to a muted autoplay hero?
Yes. 2.3.1 is visual. Mute does not reduce a flash. A muted looping hero is the case WCAG's "analyse while looping" and "analyse at fullscreen" notes are written for.