Prakash Upadhyay

Accessibility

Comfort. Standards. Defaults.

Proposed a web standard so people can turn off sudden HDR brightness spikes, the way they can turn off motion.

Expertise

  • Web accessibility: WCAG, user preference media queries, inclusive design
  • CSS standards
  • Color and HDR imaging

Interests

  • Photosensitivity and visual comfort
  • Standards work
  • Accessible defaults

Learnings

  • Accessibility bugs can be invisible to the tools we review with
  • Harm is relative: a spike against its surroundings
  • Standards move on evidence, so lead with a real case

Featured work

October 2026AccessibilityCSSWeb standardsHDR

A "reduce brightness spikes" setting for the web

Proposed a new user preference, like prefers-reduced-motion, to stop HDR images from flashing far brighter than the page around them. Root-caused a real incident from the file's bytes, built a live demo, and filed it with the CSS Working Group.

Read the proposalLive demoCSSWG #14616

The moment

18 Oct 2026, a dim café. A LinkedIn job alert in Yahoo Mail on a MacBook Pro: one company logo glowed far brighter than anything else on screen. A screenshot of it looked completely normal.

Investigation

  • Read the JPEG's bytes: an Apple "BT.2100 PQ" ICC profile (CICP 9/16/0/1). The logo's white is PQ code 255, which means 10,000 nits, about 49x the 203 nit graphics white in ITU-R BT.2408.
  • Explained the screenshot puzzle: screenshots are tone-mapped to SDR, so the glow never appears in reviews or bug reports.
  • Found the gap: authors can cap HDR (dynamic-range-limit) and test for it (@media (dynamic-range)), and the spec says browsers "should" offer a user limit, but no user preference exists.
  • Measured adoption from Chrome Platform Status: prefers-reduced-motion on 58.3% of page loads, dynamic-range-limit on 0.66%.
  • Borrowed a precedent from audio: loudness normalization (BS.1770, EBU R128, the US CALM Act, Spotify's levels).
Bar chart of brightness in nits: graphics white 203, MacBook Pro XDR sustained 1,000, MacBook Pro XDR peak 1,600, and the logo file's white 10,000. The screen peak line clips the logo.
The logo asks for 49x the brightness of graphics white. Illustration, not a screen capture.

What I built

  • An explainer in three reading levels: technical, balanced and plain language.
  • A live demo that recreates the inbox with the original logo file, with a toggle between today's behavior, a constrained cap and "if my preference were respected".
  • Evidence that works on any screen: a brightness chart, and phone photos (since screenshots can't show HDR), as an animation that falls back to a still image for people who prefer reduced motion.
Phone photos of the demo inbox: the logo glowing far brighter than the page, then the same logo matching the page when the preference is respected.
Phone photos of the demo, since screenshots can't show HDR. A still image replaces the animation when reduced motion is on.

The proposal

  1. 01A browser or OS override that caps HDR brightness and that pages can't undo.
  2. 02A media feature (prefers-reduced-peak-brightness or prefers-dynamic-range) so authors can adapt design, not just brightness.

Outcome so far

  • Filed as w3c/csswg-drafts#14616 on 18 Oct 2026, cross-linked from the existing discussion in #11790.
  • Shared on LinkedIn with a call for use cases.
  • [Update as it happens: CSSWG replies, browser tickets, use cases collected.]

Learnings

  • Accessibility bugs can be invisible to the tools we review with. Screenshots hid this one completely.
  • The harm is relative, not absolute: a spike against its surroundings, which is why dimming the whole screen doesn't help.
  • Standards move on evidence and use cases, so lead with a real case, numbers and a demo anyone can try.
  • Practice what you propose: the explainer's own animation respects prefers-reduced-motion.