A team ships a dark mode toggle. Someone on the project checks a mental box marked "accessibility." The release notes mention "improved dark theme support," and everyone moves on feeling good about the work.
That box was never really accessibility. Dark mode is a visual preference feature that happens to overlap with accessibility in a few narrow, specific ways, and diverges from it in several others that rarely get discussed. It can genuinely help some users. It can also make things measurably worse for others, sometimes on the very same page, sometimes for the very same disability category under different conditions.
The uncomfortable truth is that "light background, dark text" versus "dark background, light text" is not a hierarchy with an accessible option sitting at the top. It is a tradeoff, and the direction of that tradeoff depends entirely on the specific person looking at the screen.
The Stat: Roughly 1 in 4 US adults, 28.7%, report living with a disability, and low vision and light-sensitivity conditions inside that population respond very differently to dark backgrounds, not uniformly better. (Source: CDC)
Contrast is real, but it's not this article
Contrast failure is one of the most common ways dark themes quietly break. Brand colors that pass comfortably against a white background can drop below WCAG thresholds the moment you swap in a near-black surface. That specific failure mode, and how to actually test for it, is covered in depth in Dark Mode Isn't Automatically Accessible, Where Contrast Actually Breaks. If you haven't audited your dark theme's contrast ratios yet, that is the place to start, and the WCAG contrast minimum guideline is the standard you're testing against.
This piece is about everything else. The myths that survive even after your contrast ratios are perfect.
Halation and blur: why dark mode can hurt astigmatism
Astigmatism affects how light scatters across the cornea. Put light text on a dark background and that scatter produces a visible glow, halation, around each letter. Edges blur. Thin strokes in a typeface smear into their neighbors. For someone with astigmatism, a heading that looks crisp in light mode can look genuinely fuzzy in dark mode, not because of contrast (the ratio may be fine by the numbers) but because of how the eye physically processes bright shapes against a dark field.
This is one of the more counterintuitive findings for teams building dark themes: more contrast is not automatically better for every user. A pure white headline on pure black can be harder to read for someone with astigmatism than a softer off-white on a deep charcoal, even though the softer combination technically measures a lower contrast ratio. WebAIM's guidance on designing for low vision is a useful reality check here. Low vision is not one condition with one fix, and dark mode is not a universal accommodation for it.
Photosensitivity and glare cut the other way
Flip the disability and the recommendation flips too. For people with light sensitivity or certain forms of photophobia, a bright white surface is the problem, and dark mode is genuinely protective. Glare, eye strain, and headaches from prolonged exposure to bright screens are real, documented complaints, and a dark theme option can be the difference between someone being able to use a product for an extended session or giving up entirely.
Put those two groups side by side and the pattern is clear. Dark mode helps photosensitivity and can hurt astigmatism-driven halation. There is no single toggle position that serves everyone, which is exactly why the toggle needs to exist and needs to actually work. But the existence of the toggle is the accomplishment. It is not a guarantee that either state is "the accessible one."
Focus rings that vanish the moment the background flips
Here is a bug that shows up constantly and gets missed constantly: a focus indicator that was carefully designed and tested in light mode, a visible ring or outline that meets contrast requirements against a white card, gets silently swallowed by a dark background. The same ring that stood out clearly on white can nearly disappear against a near-black surface, or against a dark-themed form field with a similarly dark border.
For anyone navigating by keyboard, this is not a cosmetic nitpick. It is the entire mechanism they rely on to know where they are on the page. If focus is invisible in dark mode, keyboard users are functionally lost the moment they switch themes, even on a site that handles focus beautifully in light mode. We've dug into what a genuinely visible, robust focus state looks like in our piece on keyboard navigation and visible focus, and it is worth checking your dark theme against that standard specifically, not just assuming that what worked in light mode carries over automatically.
Icons and screenshots that lose their meaning when auto-inverted
A lot of dark mode implementations reach for a shortcut: run a CSS filter that inverts colors, or auto-swap image assets, rather than designing dedicated dark-mode versions of every icon and graphic. It is fast to ship. It is also how you end up with icons that flip semantic meaning, a checkmark that used to read as unambiguously "good" now sits in a color relationship it was never designed for, logos that render with broken color pairings, and embedded screenshots of the product's light-mode UI that now look like a visual bug report rather than documentation.
None of that is hypothetical polish. It is a real comprehension problem. If an icon's color is carrying meaning (success versus warning, on versus off) and that color relationship breaks under inversion, you have reintroduced a barrier for the exact users dark mode was supposed to help. The fix is unglamorous but not complicated: treat every icon and screenshot as its own dark-mode asset rather than trusting an automatic filter to preserve meaning.
The prefers-color-scheme bugs that trap people in the wrong mode
The last myth is the quietest, and probably the most common. Sites read the operating system's prefers-color-scheme setting on first load, then never respect it again, or respect it inconsistently across pages. A user sets their OS to dark mode specifically because of light sensitivity, lands on a page that correctly renders dark, clicks through to a different route or a third-party checkout embed, and gets dropped back into a blinding white screen the implementation forgot to theme.
Worse is the version where the toggle exists in the UI but does not actually persist, so the user has to re-select their preference every single session. Or where a cached stylesheet serves the wrong theme on first paint before JavaScript corrects it, producing a flash of the wrong mode every time the page loads. For someone whose disability is the entire reason they set that preference in the first place, a one-second flash of blinding white is not a minor visual glitch. It is the exact harm the setting exists to prevent, happening anyway.
What this actually means for your team
None of this is an argument against dark mode. It is an argument against treating it as a checkbox instead of a real feature that needs the same rigor as anything else you ship. That means testing both themes against contrast standards, not just one. It means checking your focus states specifically in dark mode, not assuming they inherit correctly. It means building dedicated dark-mode icon and image assets instead of trusting a filter to guess. And it means testing your prefers-color-scheme logic across your actual page set, including third-party embeds, not just the homepage.
A short internal checklist worth running today:
- Test focus indicators against every background color your dark theme actually uses, not just the default surface.
- Rebuild icons and key screenshots as dedicated dark-mode assets instead of relying on an inversion filter.
- Confirm your theme preference persists across sessions and across every route, including checkout and third-party embeds.
- Check for a flash of the wrong theme on first paint before your JavaScript applies the saved preference.
- Re-run your contrast checks in both themes, since a pass in light mode tells you nothing about dark mode.
If you want a straightforward way to see where your own site currently stands on any of this, our free accessibility tools are a fast way to get a real read before you guess.
Get a second set of eyes on it
Dark mode myths are easy to repeat and expensive to leave unchecked, especially once you are relying on them as your entire accessibility answer. If you want a person, not just a scanner, to walk through your specific implementation, reach out to our team directly at experts@wcag.world, or start with our free accessibility tools to see where things stand today.