Level AAA Operable WCAG 2.3.2

What This Criterion Requires

WCAG 2.3.2 Three Flashes is the AAA-level enhancement of criterion 2.3.1 (Three Flashes or Below Threshold, Level A). While 2.3.1 allows flashing content if it falls below the general flash and red flash thresholds (meaning the flashing area is small enough or the color shifts are not in the dangerous red spectrum), criterion 2.3.2 removes all exceptions. Under this stricter criterion, web pages must not contain anything that flashes more than three times in any one-second period, regardless of how small the flashing area is or what colors are involved. This absolute prohibition exists to provide the highest level of protection against photosensitive seizure disorders. Photosensitive epilepsy affects approximately 1 in 4,000 people, and seizures triggered by flashing content can be life-threatening. The condition varies significantly between individuals: some are sensitive only to large-area red flashing, while others may have seizures triggered by small areas of any rapidly changing luminance. The Level A criterion attempts to define safe thresholds based on research into typical seizure triggers, but these thresholds cannot account for every individual sensitivity profile. By simply prohibiting all rapid flashing, criterion 2.3.2 ensures that no user is put at risk, regardless of their specific photosensitivity profile. Content that must convey rapid change should use techniques like progressive transitions, smooth animations with easing functions, or sequential reveals rather than abrupt flash-like changes. Video content should be analyzed frame-by-frame using tools like the Photosensitive Epilepsy Analysis Tool (PEAT) and any sequences exceeding three flashes per second should be re-edited or replaced with alternative visual treatments.

Why It Matters

Photosensitive seizures are among the most immediately dangerous accessibility failures on the web. Unlike most accessibility barriers, which cause frustration or prevent task completion, flashing content can trigger grand mal seizures that result in physical injury, hospitalization, or in extreme cases, death. The 1997 Pokemon episode Denno Senshi Porygon caused seizures in approximately 685 viewers in Japan, demonstrating the real-world scale of harm that flashing visual content can cause. On the web, flashing can appear in video content, animated advertisements, CSS animations, GIF images, canvas-based visualizations, and even rapidly updating data displays. While the Level A criterion provides meaningful protection for most people with photosensitive epilepsy, it relies on threshold calculations that may not account for all individual variation in seizure susceptibility. Some individuals experience seizures from stimuli well below the standard thresholds. Meeting this AAA criterion provides the highest possible assurance that content will not trigger a photosensitive reaction in any user. For organizations serving healthcare, education, government, or large public audiences, eliminating all rapid flashing demonstrates a commitment to safety that goes beyond minimum compliance.

Common Failures and How to Fix Them

Inaccessible
Accessible

Inaccessible
Accessible

Inaccessible
Accessible

Inaccessible
Accessible

Inaccessible
Accessible

Inaccessible
Accessible

How to Test

  1. Use the free Photosensitive Epilepsy Analysis Tool (PEAT) from the Trace Center to analyze any video content on the site. PEAT reports whether any sequence exceeds three flashes per second.
  2. Manually review all CSS animations and transitions. Search stylesheets for rapid keyframe changes, particularly any animation with a duration under 333ms that alternates between visually distinct states.
  3. Check all animated images (GIF, WebP, APNG) by examining their frame rates and visual content. Any animated image with frames that create apparent flashing should be replaced with a static image or a smooth animation.
  4. Test the site in a slow-motion screen recording (record at normal speed, play back at 0.25x) to identify any flashing that might be too fast to notice in real-time viewing.
  5. Review all third-party content including advertisements, embedded widgets, and social media feeds for flashing elements. Implement content security policies or sandboxing that can block violating third-party content.
  6. Test with browser developer tools by throttling CPU performance. Rapidly updating JavaScript animations may flash more on slower devices where frame rates drop unevenly.

CMS-Specific Guidance

This criterion commonly causes issues on these platforms:

Further Reading

Related WCAG Criteria