No Flashing Over Threshold
Group: animation-and-movement • Guideline: avoid-physical-harm
Summary in Plain English
Anything that flashes has to stay under the general flash and red flash thresholds, unless the flashing is essential to what the content is.
Why It Matters
Flashing above these thresholds can trigger seizures in people with photosensitive epilepsy. This is one of the few accessibility failures that can cause immediate physical harm.
Scope: When This Applies
The draft's own conditions, quoted from guidelines/groups/animation-and-movement/avoid-physical-harm/no-flashing-over-threshold.md.
Applies when
- Content includes flashes.
Except when
- The flashing is essential.
Notes in the draft
If there is an accessibility supported method of setting a user-preference to prevent flashing, the content can be considered to avoid flashing if that preference is respected.
Test Procedure from the W3C Draft
Quoted from the provision's informative document, informative/guidelines/animation-and-movement/avoid-physical-harm/no-flashing-over-threshold.md. It is the group's own procedure, not an editorial testing guide.
Procedure
For each instance of flashing:
- Check if the flashing is essential.
- Check that the flashing is below the thresholds defined by the general flash and red flash thresholds.
Expected results
- #1 or #2 is true.
Methods Suggested Upstream
Implementation methods listed in the informative document.
- Consider if flashing is essential and, if it is not, remove it.
- Ensure that an accessibility supported user setting to avoid animation and flashing is respected.
- Ensure that any flashing is below [X] size in the users’ view.
Intent (Upstream)
Some people with seizure disorders can have a seizure triggered by flashing visual content. Most people are unaware that they have this disorder until it strikes. In 1997, a cartoon on television in Japan sent over 700 children to the hospital, including about 500 who had seizures. Warnings do not work well because they are often missed, especially by children who may not be able to read them.
The objective of this requirement is to ensure that content avoids the types of flash that are most likely to cause seizures when viewed even for a second.
W3C Working Group Status
Open Questions Recorded in the Draft
The editors' own notes (:::ednote) in
guidelines/groups/animation-and-movement/avoid-physical-harm/no-flashing-over-threshold.md.
These are the questions the group has written down as unresolved —
not a summary of discussion written here.
There is research into the size and frequency metrics underway. The exact values are likely to change before WCAG3 is published.
W3C Threads on This Provision
4 GitHub threads carrying 22 comments, fetched from w3c/wcag3 by the tracker. Titles, numbers and states are the threads' own.
What the Argument Is About
Whether the flash size threshold has to hold under magnification, and whether user preferences or warnings can stand in for the requirement.
Positions taken in the thread
WCAG's philosophy is that criteria hold simultaneously, so a user who needs magnification must still be protected from seizure triggers; on a phone, 470 CSS px is most of the screen already. WilcoFiers proposes splitting the requirement in two — full-screen content such as video and games, where magnification is not expected, and everything else, where it is. mraccess77 adds that browser zoom is not assistive technology and that authors can read viewport scale.
GreggVan, who drove flashing into WCAG originally, states the intent was never that content be safe at arbitrary zoom — people with low vision also lean toward the screen, and no requirement can survive unbounded magnification. His central argument is cost: a 400% allowance would make the provision more than 10 times harder to pass while still not protecting every user, a rule that draconian would not be adopted by standards and regulatory bodies, and the real solution is display-time detection and prevention tools. alastc opened #631 saying that accounting for zoom removes all sizing assumptions, leaving only contrast and frequency, while acknowledging this misses the low vision plus epilepsy need; asked why GreggVan advised against shrinking the area, he named false positives: failing content that harms nobody, which may be an acceptable trade against seizures but is the main cost. bruce-usab doubts zoom can be factored in, and questions how a full-screen exception could be worded without being too broad to be useful.
GreggVan's reductio — that WCAG could otherwise be replaced by a single site-wide "this site may not be suitable or safe for anyone with a disability" notice — drew a reply from patrickhlauke that the idea was a scoped exemption, not a carte blanche; GreggVan then allowed that content could meet a minimum standard by warning first, provided it is not called accessible. nattarnoff, who experiences these effects, says a warning makes them leave and look for an alternative rather than granting access. mraccess77 notes timestamps on a flashing video still do not deliver the missed information.
In #632 alastc relays Bruce's view that the common YouTuber protocol of a warning plus timestamps addresses the need and satisfies No Flashing through the user-preference note, and expects an exception or applies-when for flashing preceded by a warning. patrickhlauke reads this as an exemption for flashing often outside the author's control, conditional on a warning. In #631 bruce-usab agrees a generic up-front warning is not enough, but argues that a warning at the start and shortly before the flash, in educational content where the flashing is essential and audio description is provided, should be sufficient for WCAG3.
Agreed
- The flashing requirements and the separate flash-and-motion warning requirement have to be reconciled — #632 exists specifically to do that.
Still open
- Whether the size threshold accounts for zoom, and whether to split full-screen from inline content.
- Whether a user preference to prevent flashing can be relied on. alastc raised it, saying he does not think such a method is accessibility supported now, and relayed julierawe's comment that relying on it seems dangerous; the draft note applies only if such a method exists.
- Whether responsibility for detecting and suppressing flashing sits with authors or with browsers — nattarnoff raised it; alastc noted the animation requirements are affected by the same user-preference question.
- Whether a warning can count toward meeting the requirement or only supports a scoped exception — bruce-usab, patrickhlauke and alastc see a role for it, while GreggVan, nattarnoff and mraccess77 say a warning does not make the content accessible.
- Whether flashing should be ruled out more broadly — WilcoFiers and detlevhfischer see little loss in avoiding it, while mraccess77 notes some users, such as a deaf user wanting audio alerts mirrored visually, may want safe flashing on purpose.
- #629 Can user-preferences be relied on for "No flashing"? open 4 comments · updated 2026-06-15
- #631 Can flashing requirements account for zoom? open 14 comments · updated 2026-08-03
- #632 Relation from Flashing/motion requriements to the warning requirement open 4 comments · updated 2026-04-07
- #733 Concerns about the "Avoid Physical Harm" guideline name and description open 0 comments · updated 2026-06-26
WCAG 2.2 Criteria That Map Here
From this site's reviewed WCAG 2.2 → WCAG 3 map. The map is an interpretation, not a W3C mapping: W3C has not published one yet.
W3C Raw Source Text
Verbatim from guidelines/groups/animation-and-movement/avoid-physical-harm/no-flashing-over-threshold.md · informative document: informative/guidelines/animation-and-movement/avoid-physical-harm/no-flashing-over-threshold.md
Flashes are below the general flash and red flash thresholds. :::applies-when - Content includes flashes. ::: :::except-when - The flashing is essential. ::: :::note If there is an accessibility supported method of setting a user-preference to prevent flashing, the content can be considered to avoid flashing if that preference is respected. ::: :::ednote There is research into the size and frequency metrics underway. The exact values are likely to change before WCAG3 is published. :::