2.3.1 Three Flashes or Below Threshold
- Level A
- Operable
- Since WCAG 2.0
Summary
This criterion protects people with photosensitive epilepsy and other photosensitive conditions, for whom flashing content is not an annoyance but a medical hazard: content that flashes rapidly enough, over a large enough area, can trigger a seizure within seconds of appearing on screen. Unlike almost every other criterion, the harm happens before the user has any chance to react, so it is graded as a safety criterion. Treat any suspected fail as a blocker and escalate it, rather than logging it alongside routine findings.
The auditor's mental model has two parts. First, the bright line: nothing may flash more than three times in any one second period. Second, the escape hatch: content that does flash faster can still pass if it stays below the general flash and red flash thresholds, which conceptually cover flashing that occupies only a small area of the visual field or involves only a low change in brightness or contrast. Saturated red flashing has its own, stricter threshold because red light is a particularly potent seizure trigger. The thresholds are precise photometric definitions; in a manual audit you will rarely be able to compute them, so the working posture is conservative: if content visibly strobes and you cannot show it is below threshold, grade it as a fail.
Official wording
Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.
EN 301 549 mapping
- Web pages
- Clause 9.2.3.1
- Software and native apps
- Clause 11.2.3.1 (via Table 11.6)
Clause 9.2.3.1 applies this criterion to web pages unchanged. For software, clause 11.2.3.1 carries the requirement through a word-substitution table (Table 11.6) that restates it for application user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Start by listing everything on the page that could flash: videos (hero backgrounds, embedded players, autoplaying previews), animated GIFs, canvas and WebGL effects, CSS and JavaScript animations, celebratory effects such as confetti or strobing "success" states, glitch-style text treatments, and rapid flickers caused by loading states or re-render bugs. Let each page settle, then interact with it: some flashing only appears on hover, on submit, or when a component mounts.
For anything suspicious, review it frame by frame. Record the screen or download the video, then step through it in a player that supports frame stepping, counting brightness reversals within any one second window. A flash is a pair of opposing changes (dark to light and back), so rapid alternation racks up flashes quickly. Watch particularly for strobe sequences inside video content, where a two second clip buried in a longer film is easy to miss on a casual viewing.
Be honest about the limits of manual testing: the general and red flash thresholds are defined in terms of luminance change and the proportion of the visual field affected, and verifying them precisely requires specialist video analysis of the rendered output. Where the flashing area is tiny (a small status indicator, a caret) or the brightness change is visibly slight, you can reasonably judge it below threshold. Anything larger or brighter that exceeds three flashes per second should be graded as a fail unless specialist analysis proves otherwise.
iOS
The European standard carries this criterion through to native apps by restating it for application user interfaces, so the same rule applies inside an iOS app: no part of the UI or its media may flash more than three times per second unless below threshold.
The content risks are the same as on the web: video played through AVPlayer or embedded web views, Lottie and other vector animations, particle and celebration effects, custom loading indicators, and flicker introduced by buggy view updates. Exercise each screen, including transient states (pull to refresh, error banners, success animations), and use screen recording on the device, then step through the recording frame by frame on a Mac to count flashes in any one second window.
One boundary to hold: features that fire the device's camera flash or torch (for example a "flash on incoming call" alert or a torch toggle) are hardware behaviour, not screen content, and are out of scope for this criterion. The criterion covers what the app draws on screen.
Android
The European standard applies the same restated requirement to Android app UIs. Audit the same content classes: ExoPlayer or WebView video, animated drawables and GIFs, Compose and View animations, celebration effects, and rapid flicker from recomposition or loading-state bugs.
Screen record on the device and step through the footage frame by frame, checking any suspect sequence against the three flashes per second line. Splash screens and interstitial ads deserve specific attention, as both are common carriers of strobing effects that no one on the product team has watched closely. As on iOS, camera flash and torch features are hardware, not content, and are graded here only in respect of what appears on the display itself.
Pass and fail examples
Passes:
- A hero video with fast editorial cuts between scenes of similar brightness: cuts are not flashes unless they produce rapid opposing brightness changes.
- A notification dot that pulses twice per second: at or below three flashes in any one second period.
- A single simulated camera flash effect when the user captures a screenshot in-app: one flash, well under the limit.
- A tiny recording indicator that blinks rapidly: the flashing occupies a very small area of the visual field, so it sits below the general flash threshold.
- A subtle skeleton loader shimmer with a gentle brightness change: the contrast change is low, not a strobe.
Fails:
- A strobe sequence in an autoplaying full-viewport background video, flashing white many times per second: the classic case, and a blocker.
- A glitch-effect heading that alternates between light and dark states in rapid succession: decorative intent does not exempt it.
- A celebratory strobing overlay on order confirmation that flashes the whole screen faster than three times per second.
- A large alert region that flashes saturated red rapidly: red flashing has a stricter threshold and a large red strobe fails it.
- A loading state that flickers rapidly across most of the screen because of a re-render bug: unintentional flashing counts exactly like designed flashing.
Not a fail under this criterion:
- A smoothly scrolling ticker or auto-advancing carousel with no brightness strobing: moving content without flashing belongs under SC 2.2.2 Pause, Stop, Hide.
- Slow blinking content used to draw attention (for example, once per second): review it under SC 2.2.2 Pause, Stop, Hide, not here.
- A torch or camera-flash feature: hardware light output is not screen content.
- Motion effects such as parallax or zoom triggered by interaction with no flashing: consider SC 2.3.3 Animation from Interactions (Level AAA) as guidance instead.
Commonly confused with
- SC 2.2.2 Pause, Stop, Hide. That criterion covers moving, blinking, scrolling, and auto-updating content and asks for user control. Motion without flashing files there. Crucially, a pause control is not a cure for a 2.3.1 fail: a flashing animation that auto-plays and crosses the thresholds has already done its damage before the user can find the pause button. Grade it as a 2.3.1 fail even if it is pausable.
- SC 2.3.2 Three Flashes. The Level AAA sibling removes the threshold escape hatch entirely: any flashing above three per second fails, however small or dim. If a finding cites a tiny below-threshold flicker as a Level A fail, the auditor is applying the AAA rule.
- SC 2.3.3 Animation from Interactions. That Level AAA criterion is about motion animation (parallax, zooming, sliding) triggered by interaction, which affects people with vestibular disorders. Motion sickness findings go there; seizure-risk flashing goes here. The two harms and the two tests are different.
- Blinking versus flashing. Slow blinking to attract attention is a distraction issue under SC 2.2.2 Pause, Stop, Hide; flashing is rapid alternation posing a seizure risk under this criterion. The dividing line in practice is rate and abruptness: three or fewer flashes per second is at worst a blinking finding, more than three is a flashing one.
How AUDITSU tests this
AUDITSU's audit walkthrough asks about flashing content on every screen you review: whether any video, animation, or transient effect flashes, whether anything exceeds three flashes in any one second period, and whether fast flashing could plausibly claim the small-area or low-contrast escape. Each question records a pass, fail, or not applicable result per screen with evidence attached, and because this is a safety criterion the walkthrough treats suspected fails as blockers rather than ordinary findings.
The walkthrough is deliberately conservative here. Precise threshold measurement needs specialist frame-by-frame video analysis, so where content visibly strobes and cannot be shown to be below threshold, the guidance is to grade it as a fail and recommend the flashing be removed or slowed, which is almost always the cheaper fix than proving compliance photometrically.
For the full guided workflow, see the audit platform.