Dark mode is a user preference, not an accessibility feature — and offering one does not satisfy WCAG. Every theme your site ships must independently meet the 4.5:1 contrast minimum, and a dark theme built by eyeballing “light text on dark, looks fine” usually doesn’t. Some users genuinely benefit from dark mode; others — including the roughly 40% of adults with astigmatism — often read worse on it.

That’s the whole answer in three sentences. The rest of this post is the evidence — plus the specific mistakes that make most dark themes fail, and how to build one that doesn’t.

Is dark mode more accessible?

No — for most sighted readers, the research points the other way. Nielsen Norman Group’s review of the literature concluded that “in users with normal vision, light mode leads to better performance most of the time” (NN/g, Dark Mode vs. Light Mode). The study behind that finding — Piepenbrock et al. (2013), published in Ergonomics — tested younger and older adults on visual-acuity and proofreading tasks and concluded that “dark characters on light background lead to better legibility,” regardless of age.

The mechanism is your pupil. On a bright background it contracts, which sharpens focus — fewer spherical aberrations, greater depth of field, in NN/g’s summary. On a dark background it dilates, and a wider pupil is a blurrier lens.

But “most” is not “all,” and this is where the preference genuinely matters. Dark mode can be a real relief for people with photophobia (severe light sensitivity), and NN/g notes that in a classic study, “participants with cloudy ocular media had better reading rates with dark modes” — cataracts being the common example — because less emitted light scatters inside the eye. The Bureau of Internet Accessibility lands on the same balance: dark modes can ease photophobia for light-sensitive users, but they are not automatically more readable for everyone.

Users themselves are split down the middle, too. When Nielsen Norman Group surveyed 115 mobile users, roughly a third used dark mode, a third used light mode, and a third switched between both. No single default wins. Choice does — which is exactly why dark mode should be an option you offer, never a compliance claim you make.

Does a dark mode toggle satisfy WCAG?

No. WCAG 2.1 Success Criterion 1.4.3, Contrast (Minimum) requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, at Level AA — and it contains no exception for sites that offer an alternate theme. The Bureau of Internet Accessibility is blunt about the supposed loophole: “high-contrast settings do not satisfy WCAG 2.1 Success Criterion 1.4.3,” and to address low-contrast text, “you’ll need to change your default design to meet WCAG standards” (BOIA).

The logic is simple once you see it from the user’s side. A visitor lands on your default theme. If that theme has gray-on-white text at 3.2:1, the barrier already happened — a toggle they’d have to find, perceive, and operate doesn’t undo it.

And the requirement cuts both ways. If a user can switch to your dark theme, that theme is now content they’re reading, and every non-incidental text pair in it needs to pass on its own. Two themes means two compliance surfaces, not zero. This matters more than ever: low-contrast text below the AA thresholds appeared on 83.9% of the top million home pages in WebAIM’s 2026 Million report — the most common accessibility failure on the web, in either color scheme.

What contrast ratio does dark mode need?

Exactly the same as light mode. The WCAG contrast formula compares the relative luminance of the lighter and darker color — it’s symmetric, so it doesn’t matter which one is the text. Per SC 1.4.3:

Text typeRequired ratio (AA)Applies in dark mode?
Normal text (under 24px, or under roughly 18.7px bold)4.5:1Yes — no exception
Large text (24px and up, or roughly 18.7px+ bold)3:1Yes — no exception
UI components and graphical objects (SC 1.4.11)3:1Yes — no exception
Logos and purely decorative textExemptExempt in both themes

One detail worth knowing: the W3C’s guidance says computed contrast values should not be rounded — 4.499:1 does not meet the 4.5:1 threshold. That’s why you measure with a tool instead of trusting your eyes; our free color contrast checker gives you the exact ratio and the AA/AAA verdicts for any pair, and the color contrast guide explains where the numbers come from.

Why pure black backgrounds backfire

Maximum contrast sounds like maximum accessibility. It isn’t. White text on pure black scores 21:1 — the highest ratio possible — yet it’s one of the most complained-about reading experiences, because of an effect called halation: bright letters on a true-black field appear to glow and bleed at the edges.

Halation hits people with astigmatism hardest, and that’s a lot of people. A meta-analysis in the Journal of Current Ophthalmology estimated astigmatism in 40.4% of adults worldwide, and Level Access cites a UK study of more than 11,000 glasses wearers in which 47.4% had astigmatism of 0.75 diopters or greater in at least one eye — the same guidance describes how white text on black creates the “halation” fuzzing effect. BOIA explains the mechanism plainly: “Darker displays cause the iris to open to receive more light. For people with astigmatism, this can make focusing more difficult”.

The fix costs you nothing in compliance. Google’s Material Design dark-theme guidance sets the baseline surface at a dark gray: “the bottom-most layer of the interface is typically a dark gray with the hex value #121212” (Google Material codelab), and Smashing Magazine’s 2025 guide agrees — “instead of pure black, which can cause harsh contrast and eye strain, use dark gray shades like #121212” (Smashing Magazine, April 2025). White on #121212 still measures 18.73:1 by the WCAG formula — four times the AA minimum — with noticeably less glow. Dimming the text slightly helps too: an off-white like #e5e7eb on #121212 still passes at 15.13:1.

Your brand colors probably fail on dark

Here’s the trap that catches most DIY dark themes: colors that pass beautifully on white often fail on dark backgrounds, because their luminance sits too close to the dark surface. We ran the numbers with the WCAG formula:

ColorOn white (#ffffff)On dark slate (#0f172a)
Tailwind Red 700 (#b91c1c)6.47:1 — passes AA2.76:1 — fails AA
Crimson (#dc143c)4.99:1 — passes AA3.58:1 — fails for normal text
Google Blue (#1a73e8)4.51:1 — passes AA3.96:1 — fails for normal text

A deep, rich brand red that’s perfectly compliant on your light theme becomes an instant failure the moment you drop it onto a dark card. The standard remedy is to lighten and desaturate accents for the dark theme rather than reuse the light-theme palette: Tailwind’s lighter Red 400 (#f87171) on that same dark slate passes at 6.45:1. Saturation is its own problem — Google’s Material guidance warns that “more saturated colors tend to visually ‘vibrate’ against darker backgrounds, making them harder to read” (Material codelab).

Practically, that means a real dark theme is a second palette, not a CSS invert filter. If you’re building one from scratch, start with our walkthrough on building an accessible brand color palette, then verify every dark-theme pair individually — we publish precomputed verdict pages for hundreds of common combinations, like the ones linked in the table above.

How to respect prefers-color-scheme

prefers-color-scheme is a CSS media feature “used to detect if a user has requested light or dark color themes” via their operating system or browser settings (MDN). Per MDN it has been supported across major browsers since January 2020, so there’s no compatibility excuse for ignoring it.

/* Default: the light theme — this must pass AA on its own */
body { background: #ffffff; color: #1a1a1a; }

/* Honor the user's OS-level preference — this must ALSO pass AA */
@media (prefers-color-scheme: dark) {
  body { background: #121212; color: #e5e7eb; }
}

This matters because of how people actually think about the setting. NN/g’s research found that “users think about dark mode at the operating-system level, not at the individual application level” (NN/g) — they set it once and expect your site to follow.

So, two rules of respect. First, let the OS preference set the starting theme instead of forcing your favorite. Second, if you also provide a manual toggle, let it override the OS setting and remember the choice — a user who flips to light mode on your site has told you something; don’t reset it on the next page load. Note that a toggle is itself an interactive control, so it needs a visible focus state and a proper accessible name, the same bar as any control in our keyboard accessibility test.

A dark theme checklist that actually passes

If you’re adding a dark theme this quarter, here’s the order of operations:

  1. Fix your default theme first. WCAG judges the theme users land on. If your light theme has contrast failures, no toggle repairs that.
  2. Build a second palette, don’t invert. Swap pure black for a dark gray such as #121212, dim pure white text slightly, and lighten/desaturate brand accents.
  3. Measure every text pair in both themes. 4.5:1 for normal text, 3:1 for large text and UI components — no rounding up. Check the real values from your CSS, not what the mockup looked like.
  4. Check the in-between states. Placeholder text, disabled-looking buttons that are actually active, focus outlines, chart colors, and form borders fail most often in dark themes.
  5. Wire up prefers-color-scheme, then a toggle. OS preference sets the default; the toggle overrides it and persists.
  6. Audit images and embeds in dark mode. Transparent logos, screenshots with white backgrounds, QR codes, and third-party widgets are the classic breakage points NN/g documents.
  7. Test with real content. Long paragraphs reveal halation that a button label never will. If the text seems to glow, your background is too black or your text too bright.

The bottom line for your site

A dark theme is worth shipping — plenty of your visitors want it, and some need it. Just ship it for the right reason: it’s a comfort feature you offer, not a compliance box you check. The moment it exists, it doubles the surface you have to keep passing WCAG, and contrast is only one of the checks; heading structure, focus visibility, and link styling all have their own rules in both themes.

If you’d like to know where your current theme actually stands — light, dark, or both — our free accessibility scan flags contrast failures on your live pages. And when the list is longer than a quick fix, a manual accessibility audit measures every state a scanner can’t reach, in whichever themes you ship.