The marketing team was proud of it. A looping, high-energy background animation on the homepage hero, fast cuts, bright flashes of light against dark panels, timed to feel like a movie trailer. It tested well. Engagement was up. Time on page ticked up too. Nobody in the review meeting asked the one question that mattered: how many times per second does that thing actually flash.
That question is not a style note. For a specific and real population, a fast, high-contrast flashing animation is not a mild annoyance or a matter of taste. It is a documented, physical trigger for seizures. Photosensitive epilepsy is real, it affects real visitors to real websites, and a homepage hero built to "pop" can cross the line from bold design into a genuine health hazard without a single person on the team intending it.
The Stat: WCAG 2.3.1 (Three Flashes or Below Threshold) is a Level A success criterion, the most basic conformance level, that exists specifically because flashing content can trigger seizures in people with photosensitive epilepsy. (Source: W3C WCAG 2.2)
What WCAG 2.3.1 Actually Measures
Most teams have never heard of WCAG 2.3.1 because it lives quietly under the "seizures and physical reactions" category, next to the more famous rules about color contrast and alt text. But it earns its Level A status. Level A is the floor. It is the set of rules the W3C considers non-negotiable because failing them causes direct harm, not just inconvenience.
The rule is specific: content should not flash more than three times in any one-second period, unless the flash is small enough and low-contrast enough to fall under a separate general flash threshold. It is not about whether an animation is annoying or distracting. It is about a measurable flash rate that has been tied, through real clinical research, to seizure onset in people with photosensitive epilepsy.
Here is the part that catches marketing and design teams off guard: a "flash" in this context does not require literal strobe-light effects. A rapid transition between a bright and dark frame, a quick pulse of high-contrast color across a large part of the screen, or a fast-cutting video loop used as a hero background can all cross the threshold. The visual language of "energetic" and "punchy" web design overlaps uncomfortably with the visual language of a seizure trigger.
Where This Hides on a Real Homepage
This is not just a hero background problem, though that is the most common place it shows up. Watch for it in a few other spots that rarely get flagged during a normal design review:
Autoplaying promo videos. Fast-cut product reels, especially ones edited for social media and then repurposed as homepage content, are frequently built with flash rates nobody measured because nobody was measuring for this.
Looping CSS or Lottie animations. A pulsing badge, a strobing "sale" banner, or a rapid color-cycling gradient behind a call-to-action button can technically loop fast enough to be a hazard, even though it was built in an afternoon as a small polish detail.
Loading and progress animations. Spinners and skeleton screens with aggressive flash-style pulsing are usually harmless because they are small, but a full-width version used during a slow page load can land in dangerous territory.
Notification and alert flashes. Any UI element that blinks urgently to grab attention, an unread counter, a "new message" indicator, a countdown timer, is worth a second look if it flashes rather than fades.
None of these get caught by a spellchecker or a basic contrast tool. They get caught by someone actually watching the page and asking the right question, or by running the content through a dedicated flash-analysis tool.
How to Actually Test for This
You do not have to eyeball a video frame by frame and guess. The Photosensitive Epilepsy Analysis Tool, built by the Trace Center at the University of Maryland, is designed for exactly this job. It analyzes video and animation content against the same flash and red-flash thresholds that WCAG references, and it will tell you plainly whether a clip is safe or not. If your team ships any video or animated content on high-traffic pages, running it through PEAT before launch should be as routine as checking it in a mobile viewport.
For the full technical detail on what counts as a flash, how the general flash threshold and red flash threshold are calculated, and where the exceptions live, the W3C's own guidance on Three Flashes or Below Threshold is the authoritative source. It is dense, but it is worth having someone on your team actually read it rather than relying on secondhand summaries.
Fixing It Without Killing the Design
The good news is that fixing a flash-rate problem almost never means gutting the creative direction of a homepage. It means adjusting the mechanics underneath it. A practical checklist:
- Slow the cut rate. If a promo loop is cutting between high-contrast frames faster than three times per second, extend the hold time on each frame or smooth the transition instead of hard-cutting.
- Reduce the flashing area. A small flashing element in a corner is far less risky than the same flash rate applied across a large portion of the viewport. Shrinking the affected area can bring content under the general flash threshold.
- Swap flashes for fades. A hard cut between a bright and dark state reads as a flash. A cross-fade of the same length does not. Same visual rhythm, none of the risk.
- Add a pause control. Give visitors a visible way to stop a looping animation entirely. This also happens to satisfy other WCAG requirements around motion and animation control.
- Test before launch, not after a complaint. Run any video or animated asset through PEAT as a standard step in your pre-launch checklist, the same way you'd run a broken-link check.
It is worth being precise about the mechanism here, because it is genuinely different from a related issue our team has written about before. Our piece on motion, animation, and prefers-reduced-motion covers vestibular disorders, where large-scale parallax scrolling and sweeping motion effects cause dizziness and nausea for people with inner-ear and balance conditions. That is a motion-sickness mechanism. Flashing content is a seizure mechanism. They are both cases where "animation can genuinely harm someone," but they call for different fixes and they affect different people. Treating them as the same problem, or fixing one and assuming you've covered the other, leaves a real gap.
And flash risk is rarely the only thing hiding in a homepage that tested well for engagement. Teams that skip a flash-rate check often skip other basics too, like whether keyboard users can actually see where focus is landing as they tab through that same hero section. Our guide on keyboard navigation and visible focus covers that gap in more depth, and it is worth reviewing at the same time you're auditing hero animations, since both tend to fall through the cracks of a purely visual design review.
The Real Cost of Getting This Wrong
A flashing homepage animation is not an edge case dressed up as a compliance technicality. It is a Level A accessibility failure attached to a real, physical health risk, and it sits on the highest-traffic page of your site, the one every visitor and every automated scanner sees first. Fixing it is usually a matter of hours, not a redesign.
If you are not sure whether anything on your site crosses this line, or you would rather have someone else run the check than dig through your own animation timelines, a free accessibility audit will tell you exactly where you stand, flash risk included.
Want to talk it through with an actual person first? Email experts@wcag.world and someone on our team will walk you through what we look for, no sales script required. Or just start with the free audit and see what turns up.