WCAG 2.3.1: Three Flashes or Below Threshold

What This Rule Means

WCAG 2.3.1 — Three Flashes or Below Threshold — is a Level A success criterion under the Operable principle. It mandates that web pages must not contain any content that flashes more than three times in any one-second period, unless that flashing content is small enough or dim enough to fall below the defined general flash threshold or red flash threshold.

A flash is defined as a pair of opposing changes in relative luminance that can cause seizures in susceptible individuals. Specifically, WCAG defines two types of hazardous flashes:

• General flash: A pair of opposing changes where the higher luminance is at least 10% of the maximum relative luminance (0.80), and the luminance difference is at least 10% of the maximum. In practice, this means content cycling between a bright state and a dark state rapidly enough to produce a stroboscopic effect.
• Red flash: A pair of opposing transitions involving a saturated red color. This is treated with special concern because red flashes have been clinically associated with a higher risk of triggering photosensitive seizures.

The criterion applies to all web content regardless of format — HTML animations, CSS transitions, JavaScript-driven effects, embedded videos, GIFs, SVG animations, WebGL scenes, canvas-rendered graphics, and third-party advertising widgets. If content flashes at a rate exceeding three flashes per second and does not fall below the luminance or size thresholds, it fails this criterion unconditionally.

Exceptions and thresholds that allow content to pass: WCAG 2.3.1 permits flashing content if it meets either of the following conditions:

• The combined area of flashes occurring simultaneously does not cover more than a total of 0.006 steradians within any 10-degree visual field on screen (approximately a 341 × 256 pixel rectangle at typical viewing distances, or roughly 21,824 square pixels on a 1024-pixel-wide display viewed at arm's length).
• The flash is below the general flash threshold (luminance change is less than 10%) or below the red flash threshold (the saturated red component does not change by more than the defined threshold).

A single-flash event with very low luminance contrast or a very small screen area can therefore be permissible. However, because these thresholds are nuanced and require photometric measurement tools to verify precisely, most practitioners adopt the conservative approach of simply avoiding all content that flashes more than three times per second. Content that flashes exactly three times per second (3 Hz) is on the boundary — content exceeding 3 Hz is non-compliant regardless of size unless the size or luminance thresholds are definitively met.

The criterion governs any content that is rendered during normal page interaction. It does not exempt content hidden behind user-triggered controls if that content auto-plays on page load. If a video begins playing automatically and contains flashing sequences that exceed the threshold, the page fails this criterion from the moment it loads.

Why It Matters

Photosensitive epilepsy affects approximately 1 in 4,000 people globally — roughly 3% of the overall epilepsy population. However, sensitivity to rapidly flashing or flickering light is broader than clinical epilepsy alone. Many individuals with migraine disorders, vestibular dysfunction, autism spectrum conditions, and post-concussion syndrome can experience significant discomfort, disorientation, nausea, or pain from rapidly flashing visual stimuli, even if they do not have a diagnosed seizure disorder.

The stakes are uniquely high for this criterion compared to most other accessibility requirements. A user encountering missing alternative text experiences exclusion and frustration. A user encountering content that triggers a photosensitive seizure can experience a medical emergency — including loss of consciousness, injury from falling, and in rare but documented cases, life-threatening outcomes. The Harding Flash and Pattern Analyzer, a widely used broadcast tool, was developed specifically to prevent such events in television, and the web presents analogous risks.

A concrete real-world scenario illustrates the danger well: consider a news website that auto-plays a promotional video containing a rapid sequence of alternating light and dark frames — a common artifact of certain video compression or camera flash effects. A user with photosensitive epilepsy visits the homepage during their morning commute on a mobile device. Without any warning and without any opportunity to disable the content, they are exposed to a sequence that triggers a seizure while they are using public transit. This scenario is not hypothetical; it has occurred in real-world contexts, including the infamous 2007 Pokémon episode incident that triggered seizures in hundreds of viewers in Japan, and documented cases involving web-based advertising units.

Beyond the safety dimension, compliance with this criterion also has usability implications for general audiences. Rapidly flashing content creates a poor reading experience, increases cognitive load, and is considered disruptive and unprofessional in most design contexts. Eliminating such content improves focus, reduces bounce rates, and signals trustworthiness — all of which contribute positively to SEO metrics such as dwell time and engagement rates. Additionally, search engine crawlers increasingly factor Core Web Vitals and user experience signals into rankings, and sites with invasive flashing advertisements or animations may be penalized indirectly.

Related Axe-core Rules

WCAG 2.3.1 requires manual testing because automated tools cannot reliably analyze the photometric properties of dynamic content in real time. No axe-core automated rule maps directly to this criterion. The reasons for this limitation are fundamental to how accessibility automation works:

• Why automation fails here: Automated scanners analyze the static DOM and CSS at a point in time. They can detect that an animation or video element exists, but they cannot measure the actual flash frequency, luminance values at each frame, or the spatial area of the flashing region as perceived by a human viewer at a typical viewing distance. Determining whether a flash exceeds the 3 Hz threshold or the 0.006 steradian area threshold requires frame-by-frame photometric analysis — a task that requires dedicated tools such as the Harding Flash and Pattern Analyzer (HFPA), the Photosensitive Epilepsy Analysis Tool (PEAT), or manual review of animation source files.
• Embedded video and third-party content: Much of the highest-risk content (auto-playing video ads, embedded social media widgets, third-party animation libraries) is loaded from external domains. Automated tools typically cannot access or analyze cross-origin content at the frame level, making it impossible to assess flash frequency within those resources programmatically.
• GIF and canvas animations: Animated GIF files and HTML5 canvas elements render their animation frames outside the normal accessibility tree. Axe-core and Lighthouse both lack the capability to decode GIF frame timing or intercept canvas draw calls to calculate luminance changes between frames.
• CSS and JavaScript animations: While axe-core can detect the presence of CSS animation or transition properties, it cannot evaluate whether the resulting visual output at runtime produces luminance changes that exceed the general or red flash thresholds.

Because no automated rule catches this violation, the entire burden of compliance rests on manual design review, video pre-publication analysis, and developer awareness during the content creation phase. This makes editorial and QA process controls — not just technical remediation — essential to sustainable compliance.

How to Test

1. Inventory all dynamic content: Before any tool-based testing, audit the page for all content that moves, flashes, blinks, or animates. This includes auto-playing videos, animated GIFs, CSS keyframe animations, JavaScript-driven animations, SVG animations, canvas elements, and embedded third-party widgets such as advertising units or social media embeds. Document each instance with its source and control mechanism.
2. Use the Photosensitive Epilepsy Analysis Tool (PEAT): PEAT is a free tool developed by the Trace Research and Development Center, specifically designed to analyze video content for flash hazards per the Harding specification. Record a screen capture of the web page or animation in question at full resolution, then import the video file into PEAT. The tool will report whether any sequence exceeds the general flash threshold or red flash threshold and at what timestamps.
3. Apply the Harding Flash and Pattern Analyzer for broadcast-quality content: For video content that will be embedded from production workflows (e.g., broadcaster websites, news organizations), run source video files through the HFPA before publishing. This is the gold-standard tool for pre-publication screening.
4. Manual observation — the three-flash count: For CSS animations, JavaScript effects, or GIF files where tool-based analysis is impractical, play the animation and attempt to count the number of complete light-to-dark-to-light cycles within a single second. If you observe three or more complete cycles per second, the content is likely non-compliant. Use screen recording software with frame-by-frame playback to assist with this count.
5. Check video content frame-by-frame: Open video files in a video editor (such as DaVinci Resolve, free tier) that displays frame-level waveform or histogram data. Scrub through sections of rapid visual change and check for alternating high-low luminance patterns occurring more than three times per second. Look especially for sequences involving saturated red against dark backgrounds.
6. Test with browser developer tools for CSS animations: In Chrome DevTools, open the Animations panel (More Tools → Animations). Inspect declared animation durations and iteration cycles. An animation with a duration of less than 333 milliseconds that alternates between high-contrast states on each iteration will exceed the 3 Hz threshold. Calculate: if a full light-dark-light cycle completes in under 333ms, the content is non-compliant.
7. Assess spatial area for borderline cases: If content flashes at a rate above 3 Hz but appears very small on screen, measure its pixel dimensions. At a 1024-pixel-wide display at normal viewing distance (approximately 57–60 cm), the safe area threshold is roughly 21,824 square pixels. Multiply the width and height of the flashing region; if the result is below this threshold, the content may fall within the safe area exception — but document this assessment carefully.
8. Test auto-play video on page load: Disable any interaction with the page after it loads and observe whether any video or animation begins playing automatically. If it does, apply the tests above to the auto-playing content immediately, as the user has no opportunity to intervene before exposure.

How to Fix

Auto-playing GIF with rapid flash — Incorrect

<!-- An animated GIF that cycles between a bright yellow and black frame
     at approximately 10 times per second, far exceeding the 3 Hz threshold -->
<img src='attention-flash.gif' alt='Special offer alert' width='600' height='300'>

Auto-playing GIF with rapid flash — Correct

<!-- Replace the flashing GIF with a static image and use a subtle CSS
     animation that does not alter luminance rapidly. The animation here
     uses a gentle scale pulse at a rate well below 3 Hz (one cycle per 2 seconds). -->
<img src='attention-static.png'
     alt='Special offer alert'
     class='pulse-attention'
     width='600'
     height='300'>

<style>
  @keyframes gentlePulse {
    0%, 100% { transform: scale(1); }
    50% { transform: scale(1.03); }
  }
  .pulse-attention {
    animation: gentlePulse 2s ease-in-out infinite;
  }
</style>

CSS keyframe animation flashing between high-contrast colors — Incorrect

<!-- A CSS animation that alternates a banner between white and black
     with a 100ms total duration, producing 10 flashes per second -->
<div class='flash-banner'>SALE NOW ON</div>

<style>
  @keyframes flashEffect {
    0% { background-color: #ffffff; color: #000000; }
    50% { background-color: #000000; color: #ffffff; }
    100% { background-color: #ffffff; color: #000000; }
  }
  .flash-banner {
    animation: flashEffect 0.1s linear infinite;
  }
</style>

CSS keyframe animation flashing between high-contrast colors — Correct

<!-- Slowing the animation duration to 1 second per full cycle means
     the luminance alternates once per second (1 Hz), well below the 3 Hz limit.
     Alternatively, use prefers-reduced-motion to disable animation entirely
     for users who have opted into reduced motion at the OS level. -->
<div class='flash-banner'>SALE NOW ON</div>

<style>
  @keyframes flashEffect {
    0% { background-color: #ffffff; color: #000000; }
    50% { background-color: #000000; color: #ffffff; }
    100% { background-color: #ffffff; color: #000000; }
  }
  .flash-banner {
    animation: flashEffect 1s linear infinite;
  }

  @media (prefers-reduced-motion: reduce) {
    .flash-banner {
      animation: none;
      background-color: #1a1a8c;
      color: #ffffff;
    }
  }
</style>

Embedded auto-playing video with flash sequences — Incorrect

<!-- Auto-playing video with no controls, no PEAT analysis performed,
     and no mechanism for the user to stop or pause before exposure -->
<video src='promo.mp4' autoplay loop muted width='800' height='450'></video>

Embedded auto-playing video with flash sequences — Correct

<!-- Best practice: provide controls so users can pause immediately,
     add a poster frame so no video plays without interaction,
     or use preload='none' to prevent auto-loading. If autoplay is
     genuinely required by business logic, the video MUST have been
     screened with PEAT or HFPA and confirmed free of flash hazards. -->
<video
  src='promo-screened.mp4'
  controls
  muted
  preload='metadata'
  poster='promo-poster.jpg'
  width='800'
  height='450'>
  <track kind='captions' src='promo-captions.vtt' srclang='tr' label='Türkçe'>
</video>
<p>Bu video flaş analizi aracıyla (PEAT) incelenmiş ve güvenli bulunmuştur.</p>

Common Mistakes

• Assuming GIF files are safe by default: Many developers believe that because animated GIFs are a legacy format, they are inherently harmless. In reality, GIFs can cycle between frames at rates that exceed 3 Hz, and the format places no technical limit on frame rate. Every GIF with alternating high-contrast frames must be timed and evaluated.
• Overlooking third-party advertising scripts: Display advertising networks frequently serve creative units that contain flashing or blinking animations. Publishers who embed ad tags without reviewing the creative content are still responsible for any WCAG 2.3.1 violations those ads produce on their pages. Implement ad creative review policies and contractual requirements with ad networks.
• Conflating WCAG 2.3.1 with WCAG 2.2.2 (Pause, Stop, Hide): Some teams address the symptom by adding a pause button (which satisfies 2.2.2) but do not address the underlying flash rate (which violates 2.3.1). The two criteria are independent: a pause control does not retroactively make content that has already started flashing compliant with 2.3.1, because the user is exposed before they can interact.
• Not accounting for the red flash threshold separately: Developers who are aware of the 3 Hz general threshold sometimes overlook the separate red flash threshold. Content involving rapidly alternating saturated red values can trigger photosensitive seizures even at frequencies slightly below 3 Hz in some individuals. Saturated red animations should be reviewed with special scrutiny.
• Ignoring content loaded in iframes: Pages that embed third-party content via <iframe> elements — including social media widgets, live chat tools, or embedded dashboards — are responsible for the accessibility of that content as rendered on their page. Flash hazards within an iframe are just as dangerous as those in the main document.
• Skipping prefers-reduced-motion media query implementation: Even when base animations are below the 3 Hz threshold, failing to implement @media (prefers-reduced-motion: reduce) means users who have signaled OS-level preferences for reduced motion receive no accommodation. While this is primarily addressed by WCAG 2.3.3 at AAA level, including the query is a low-cost, high-impact practice that demonstrates accessibility commitment and reduces risk.
• Using JavaScript setInterval or requestAnimationFrame without rate-limiting: Animations driven by setInterval(fn, 50) fire every 50 milliseconds, producing 20 cycles per second — far exceeding the 3 Hz limit. Developers must explicitly calculate the interval duration required to stay at or below one change per 333ms for any luminance-altering animation.
• Failing to screen video content before publishing: Many organizations have a publishing workflow that includes visual QA and copyright review but lacks a flash hazard screening step. Without integrating PEAT or HFPA into the pre-publication pipeline, photosensitivity hazards in video content can go undetected until they cause harm.
• Treating the size exception as easy to exploit: Some developers learn about the 0.006 steradian safe area exception and attempt to use it to justify leaving hazardous flash effects in place by making them small. In practice, accurately calculating whether content falls within the threshold requires knowledge of the user's viewing distance and display resolution — variables the developer cannot control. Relying on the size exception without photometric measurement is risky and legally precarious.
• Not documenting flash hazard assessments: Organizations that do test video or animation content for flash hazards often fail to retain records of those assessments. In the event of a user complaint or regulatory audit, documented evidence that PEAT or HFPA screening was conducted and that content was found compliant is essential to demonstrating due diligence.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in Official Gazette No. 32933 on June 21, 2025, establishes mandatory web and mobile accessibility requirements aligned with WCAG 2.2. WCAG 2.3.1, as a Level A success criterion, falls within the scope of mandatory compliance for all covered entities.

The circular defines a phased compliance timeline: public institutions and agencies must achieve full Level A conformance within one year of the circular's effective date, while private sector entities covered by the regulation have two years to comply. Given the safety-critical nature of WCAG 2.3.1 — which relates directly to the risk of triggering medical emergencies in users — non-compliance with this particular criterion carries heightened reputational and legal exposure, even relative to other Level A requirements.

The following entity types are explicitly covered by Presidential Circular 2025/10 and must therefore comply with WCAG 2.3.1:

• Public institutions and government agencies: All central and local government bodies, ministries, municipalities, and state-affiliated organizations operating public-facing websites or mobile applications.
• E-commerce platforms: Online retail and marketplace operators providing goods or services to consumers via digital platforms, regardless of sector.
• Banks and financial institutions: All licensed banks, participation banks, investment firms, and fintech operators providing digital banking or financial services.
• Hospitals and healthcare providers: Public and private hospitals, polyclinics, and healthcare networks offering patient-facing digital services including appointment booking and patient portals.
• Telecommunications companies with 200,000 or more subscribers: Major mobile network operators and internet service providers meeting the subscriber threshold, including their self-service portals and mobile applications.
• Travel agencies: Licensed travel and tourism agencies offering online booking, reservation, or information services.
• Private transport companies: Airlines, intercity bus operators, ferry operators, and other private transport providers with consumer-facing digital platforms.
• Private schools authorized by the Ministry of National Education (MoNE): Private educational institutions with MoNE authorization that operate websites or digital learning platforms.

For covered entities, WCAG 2.3.1 compliance requires not just a one-time audit but an ongoing operational commitment. Because flash hazards are most commonly introduced through dynamic content — video uploads, marketing animations, third-party advertising — organizations must embed flash hazard screening into their content publication workflows, not merely their initial site audit. The use of tools such as PEAT for pre-publication video screening, combined with developer training on safe animation rate limits and CSS prefers-reduced-motion implementation, represents the minimum standard of operational diligence expected of covered entities under the circular. Organizations that rely on third-party content management or advertising systems must also ensure contractual provisions requiring WCAG 2.3.1 compliance from their suppliers, as the regulatory obligation rests with the entity operating the public-facing digital service.