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.

[amrouchk]

I built a simple browser-based flash detection tool using JavaScript and canvas. It analyzes real-time brightness fluctuations in video and raises an alert when rapid flashing occurs.

You can run it entirely client-side, as long as CORS issues are handled (e.g. via localhost).

This could serve as a baseline for accessibility testing (e.g., for epilepsy-triggering flashes), or be adapted into a user-uploaded video safety checker.

Here's the script:
`

<title>Flash Detection Debug</title> <style> #alert { font-weight: bold; color: gray; margin-top: 10px; } </style>

Flashing Video Detector (Debug Mode)

Waiting for video...

<script> const video = document.getElementById("video"); const canvas = document.getElementById("canvas"); const ctx = canvas.getContext("2d"); const alert = document.getElementById("alert"); let lastBrightness = null; let flashTimestamps = []; function getBrightness() { const width = 160, height = 90; canvas.width = width; canvas.height = height; try { ctx.drawImage(video, 0, 0, width, height); const frame = ctx.getImageData(0, 0, width, height).data; let sum = 0; for (let i = 0; i < frame.length; i += 4) { const r = frame[i], g = frame[i + 1], b = frame[i + 2]; const brightness = 0.299 * r + 0.587 * g + 0.114 * b; sum += brightness; } return sum / (frame.length / 4); } catch (e) { console.warn("Frame read failed:", e); return null; } } function detectFlashes() { const brightness = getBrightness(); if (brightness === null) { alert.textContent = "⚠️ Unable to read video frame (CORS or video not ready)"; alert.style.color = "orange"; return; } const now = Date.now(); if (lastBrightness !== null && Math.abs(brightness - lastBrightness) > 20) { flashTimestamps.push(now); } flashTimestamps = flashTimestamps.filter(t => now - t < 1000); lastBrightness = brightness; if (flashTimestamps.length > 3) { alert.textContent = " Flashing detected!"; alert.style.color = "red"; } else { alert.textContent = "No flashing detected."; alert.style.color = "green"; } } // Ensure playback video.muted = true; video.addEventListener("canplay", () => { console.log("Video is ready to play."); video.play(); }); video.addEventListener("playing", () => { alert.textContent = "Analyzing video..."; setInterval(detectFlashes, 100); }); </script> ` below the tested video https://www.youtube.com/watch?v=B4wSFjR9TMQ

[cookiecrook]

There’s a privacy preserving proposal for this in WebVTT:

• VTT Type Proposal for time-coded general-flash metadata  w3c/webvtt#512

Which is blocked by:

• VTT Metadata Cue format is ambiguous; some metadata may be unintentionally presented to the user in a context outside HTML w3c/webvtt#511

Which is waiting on this PR review:

• New ATTRIBUTES block w3c/webvtt#523

[cookiecrook]

I propose this be closed as a duplicate of:

• VTT Type Proposal for time-coded general-flash metadata  w3c/webvtt#512

[domenic]

That sounds reasonable to me, as that proposal is quite fleshed out and seems to have momentum behind it. If people disagree and think there's something more suitable for HTML than VTT, let us know in this closed thread.