Need for programmatic detection of flashing content in <video> elements (accessibility safety concern)

[yashrajbharti]

What problem are you trying to solve?

Problem

There is currently no way to programmatically detect if a <video> element is rendering flashing content, specifically, visuals that flash more than three times per second.

This type of content is known to trigger seizures in individuals with photosensitive epilepsy, and cause issues for people with vestibular or motion sensitivity disorders.

Use Cases

On dynamic platforms (e.g., Instagram, TikTok, YouTube), developers embedding videos or building moderation/review tools have no way to detect such flashing content, because:

• The videos are user-uploaded and unpredictable.
• There is no DOM or JavaScript-level method to analyze rendered visual frames for flashes.

Apple provides a native detection implementation in their system-level accessibility APIs:

• https://developer.apple.com/documentation/mediaaccessibility/flashing-lights
• https://github.com/apple/VideoFlashingReduction

But no web-standard method exists.

Requested Capability

A standardized way (e.g., an observer or flag) to programmatically:

• Detect whether a <video> contains flashing content that exceeds known safety thresholds.
• Optionally inspect this in real time or at load time, to give developers a chance to warn users or take action.

Why It Matters

This is important for accessibility and WCAG compliance, particularly WCAG Guideline 2.3.2 (Three Flashes) at AAA level.

I am not proposing a specific implementation, just surfacing the gap and encouraging discussion about what kind of API or exposure model would make this feasible on the web platform.

What solutions exist today?

No response

How would you solve it?

No response

Anything else?

No response

[pshaughn]

This seems desirable as a goal, but I see a potential difficulty with getting it implemented in a way people will use.

Video decoding isn't bit for bit exact, so even with an exact definition of flashing, different implementations might give different answers for the same video file. A user agent might decide that a video's safe, then send it to a server, then the server's validation might decide that it isn't safe, even when everyone's following the letter of the spec.

Without a way to be sure the server and client algorithms will agree for any given input, I think many Web authors might end up deciding not to use this feature on the client side at all.