Dark Mode Isn't Accessible Just Because It's Dark
The pull request was titled "Add Dark Mode Support." Someone merged it on a Friday. In the description: "Accessibility improvement — reduces eye strain for low-light users."
The team shipped it, marked the Jira ticket done, and moved on. Three months later, a user with astigmatism filed a complaint. The high-contrast text on a pure black background was causing halation — the light bleeding effect where bright text on very dark backgrounds creates halos that reduce readability. The feature built to help them made things worse.
This story isn't unusual. It's the routine outcome of treating dark mode as an aesthetic toggle rather than an accessibility system.
The Assumption Built Into Every Dark Mode PR
Dark mode became culturally associated with accessibility through legitimate research. OLED screens consume less power in dark mode. For users with photophobia — sensitivity to bright light, associated with migraines, some autoimmune conditions — reducing overall screen luminance is genuinely helpful. These are real benefits for specific users.
What happened next is that the benefits got generalized. Dark mode started appearing in app store descriptions as an "accessibility feature," full stop. Design teams shipped it with inverted color palettes and called the accessibility box checked.
The problem is that dark mode, implemented without care, trades one group's benefit for another group's barrier. The user population most commonly cited as benefiting from dark mode — people with photophobia — overlaps poorly with the user population most commonly harmed by poorly implemented dark mode: people with astigmatism and low vision.
Approximately 30-40% of the population has some degree of astigmatism, according to data from the American Academy of Ophthalmology. It's not a niche condition. And bright text on very dark — especially pure black — backgrounds is a documented halation trigger for astigmatic eyes.
The Three Failure Modes Nobody Checks
1. Halation on pure black backgrounds
WCAG 2.1 sets minimum contrast ratios — 4.5:1 for normal text, 3:1 for large text. White text on a pure #000000 background achieves a contrast ratio of 21:1. By the numbers, this passes. By lived experience for roughly a third of your users, it causes the text to appear to bleed or blur.
The recommendation from accessibility researchers including Lea Verou and the APCA (Accessible Perceptual Contrast Algorithm) working group is to use dark grey (#121212, #1a1a1a) rather than pure black as background surfaces. The contrast ratio drops slightly but the halation effect reduces substantially. Most dark mode implementations use #000000 or #0d0d0d because it looks cleaner in mockups on calibrated design monitors. It's a decision made without testing on the actual user condition.
2. Secondary text that fails contrast on dark surfaces
Light mode typically uses a high-contrast primary text color paired with a muted secondary color — dark grey on white, for example, with a lighter grey for metadata, timestamps, labels. When teams flip to dark mode by inverting the palette, the secondary text often lands in a contrast ratio below the WCAG threshold.
The BOIA (Bureau of Internet Accessibility) published a 2024 analysis finding that secondary text contrast failures in dark mode are among the most common WCAG violations in web applications — specifically because teams test primary text and assume secondary text follows. It doesn't. Every text style at every visual hierarchy level requires an independent contrast check against its dark background.
3. Data visualization losing saturation legibility
Charts, graphs, and data visualizations designed for light backgrounds depend on color combinations that become indistinguishable when rendered against dark surfaces. The red and green used in a line chart may both fade to similar apparent values in dark mode. Categorical color palettes tuned for white backgrounds routinely fail in dark contexts.
The W3C Cognitive Accessibility (COGA) Task Force guidelines specifically flag this: "Visual information used in data representations must remain distinguishable across display modes." Most teams inherit their data visualization color palettes from their charting library defaults and never audit them for dark mode legibility.
Why Your Audit Missed It
Standard WCAG audits check contrast ratios algorithmically against the baseline specification. The algorithm uses relative luminance values — a formula that treats pure black as optimal contrast when paired with light text.
The algorithm doesn't model halation. It doesn't model how different monitor calibrations affect the perception of dark backgrounds. It doesn't model how astigmatic vision processes high-contrast edges differently from typical vision.
The APCA — the new contrast algorithm proposed for WCAG 3.0, developed by Andrew Somers at the W3C — addresses some of these gaps with a more perceptually accurate model. It accounts for spatial frequency, font weight, and the directional asymmetry of polarity (light text on dark versus dark text on light behave differently even at the same numeric contrast ratio). But APCA is not yet a WCAG 2.x requirement, which means most automated accessibility tools don't flag the failure modes that APCA was specifically designed to catch.
The gap between "passes WCAG 2.1" and "is accessible for the range of users you serve" is widest in dark mode implementation. Teams that rely on automated auditing alone will not find these failures.
This is not a new problem. Stephanie Walter's detailed post "Dark Mode Accessibility Myth Debunked" has been citing these failure modes since 2021. The design industry has had the information. The practice hasn't caught up.
The EAA Changes the Stakes
The European Accessibility Act (EAA) came into force for existing products and services on June 28, 2025. As of that date, organizations operating in EU markets are legally required to meet EN 301 549 accessibility standards — which references WCAG 2.1 at Level AA for digital products.
This matters for dark mode specifically because the EAA covers all modes of use a product offers. If you ship dark mode as a user-facing option, your dark mode is in scope. A dark mode that fails contrast requirements, fails consistent text legibility, or creates barriers for users with astigmatism or low vision is not just a design problem. For companies with significant EU operations, it is a legal exposure.
Enforcement is complaint-driven, not proactive — but the complaint mechanism is now activated. Disability advocacy organizations have been building enforcement capacity throughout 2025. The pattern seen in ADA digital accessibility litigation in the US over the past decade — gradual increase in filed complaints, then rapid acceleration as legal templates and precedents established — is the likely trajectory.
The calculation that "accessibility is nice to have" has always been a cost externalization. The EAA is internalizing it.
Previous posts on accessibility gaps worth reading alongside this one: Glassmorphism Is the Best-Looking Design Trend That Fails Accessibility covers similar ground for translucent UI patterns, and WCAG-Compliant and Still Inaccessible examines the sensory layer that automated audits miss for neurodivergent users.
What a Genuinely Accessible Dark Mode Requires
Start with a surface palette that avoids pure black. Use #121212 or #1c1c1e as your darkest surface. Let your design system spec this explicitly rather than leaving it to individual component decisions.
Test every text style at every hierarchy level. Primary, secondary, placeholder, caption, label — all of them, against all background surfaces. Don't assume the math holds because the primary text passes.
Audit your data visualizations independently. Pull your color palette into a dark background and check each category color against each other and against the background. If you can't distinguish the lines in your chart in dark mode, neither can your users.
Test with actual users who have relevant conditions. Automated tools catch a fraction of accessibility failures. User testing with people who have astigmatism, low vision, and photosensitivity will surface the rest. These are not rare conditions — they're a significant portion of your user base.
Review APCA alongside WCAG 2.1. The APCA checker is publicly available. It won't catch everything, but for polarity-specific failures — the ones that disproportionately affect dark mode — it's more accurate than the WCAG 2.1 algorithm.
Dark mode done well is a genuine accessibility improvement for specific users. Done carelessly, it's a setting that harms another group while the PR description says "accessibility improvement." The distinction is in whether you tested with the range of users who will actually use it — or whether you tested with a contrast ratio calculator and a design monitor with factory calibration.
Photo by Matheus Bertelli via Pexels — a monitor interface in low light, the context where dark mode decisions matter most.