Every dark mode article written in 2024-2026 is some version of the same earnest guide: use dark gray instead of pure black, meet WCAG contrast ratios, respect prefers-color-scheme, and you're done. These guides are technically correct and miss most of the hard parts. This is a different kind of article. It's the honest version — the one that admits dark mode is genuinely harder than it looks, that it's not universally more accessible, and that for many products shipping it is the wrong call.
If you're about to start a dark mode project, or you've shipped dark mode and noticed something feels off, this is for you. The goal isn't to argue against dark mode. It's to separate the dark mode hype (a strong 2020s visual trend) from the actual design work (harder than the hype suggests).
TL;DR — Key Takeaways
- Dark mode is not universally more accessible. Users with astigmatism, low vision, or light sensitivity often prefer light mode. The "dark mode = accessibility" claim is oversimplified.
- Color inversion fails. Every color has to be re-designed for a dark background — brand colors that pop in light can feel toxic in dark.
- Elevation systems are genuinely harder in dark. The shadow tricks that work in light don't work in dark. You need a whole different surface system.
- WCAG contrast is necessary but not sufficient. Technically-compliant dark mode can still fail real users because of halation, glare, and overall visual fatigue.
- Brand color behavior breaks. The vibrant red that defines your brand in light mode becomes a halo-glowing problem in dark.
- Sometimes the right answer is not shipping dark mode. If your product is used in bright environments, has heavy imagery, or serves users who don't need it, skipping dark mode is a valid call.
- Real products have seen dark mode regressions — shipping dark mode and then seeing metrics worsen is more common than the hype suggests.
The Accessibility Claim That Deserves Pushback
"Dark mode is more accessible" is a sentence you've read a hundred times. It's not quite right.
Dark mode helps some users. For users with light sensitivity, photophobia, or migraine triggers, dark interfaces reduce strain. For users working in low-light environments, dark mode reduces glare. These are real benefits for real people.
But dark mode makes things worse for other users. People with astigmatism often experience a phenomenon called halation — the white or light-colored text on dark backgrounds appears to "glow" or "bleed" around its edges, making reading slow, tiring, or painful. Users with low vision sometimes find dark mode harder because the contrast between text and background, while technically high, produces a starker visual field that strains reading. Older users, whose eyes process contrast differently, often prefer light mode.
Research from the Nielsen Norman Group has found that reading comprehension and speed are often better in light mode than dark mode for sustained reading tasks. This is the opposite of the common claim.
The right framing: dark mode is an accommodation for some users, not a universal accessibility improvement. If your product supports diverse users, you should offer dark mode — and a light mode, and ideally automatic switching based on system preferences. What you shouldn't do is claim dark mode is inherently more accessible; it's only more accessible for users whose specific needs it serves.
Why Color Inversion Fails
Most teams approach dark mode as a color inversion problem. White backgrounds become black. Black text becomes white. Primary blue stays primary blue.
This is where dark mode breaks. Colors behave differently on dark backgrounds than on light backgrounds. The blue that felt crisp on white feels neon on black. The subtle warmth of an off-white background becomes a harsh yellow on a dark base. The red that signaled urgency becomes alarmist. The green that signaled success becomes radioactive.
Two specific problems.
Saturation shifts. Saturated colors appear more saturated on dark backgrounds because the contrast differential is higher. That vibrant brand red that reads as energetic on white reads as aggressive on black. The fix is desaturating colors specifically for dark mode — typically by reducing saturation 10-30% and adjusting lightness.
Lightness perception. Our eyes compensate for ambient light. In a dark interface, colors need to be perceptually lighter to read the same way. A 50% gray that reads as a mid-tone on white reads as nearly black on dark. Lightness values need to be remapped, not inverted.
The practical implication: a proper dark mode isn't one step (invert colors). It's a full second color system designed from scratch, with every color remapped for dark-background perception. This is why good dark mode is expensive — it's effectively designing your visual language twice.
Elevation and Depth Break in Dark
In light mode, elevation — the visual sense that a card floats above a background — is communicated through shadows. Drop shadows, box shadows, inset shadows. The visual vocabulary is decades old and works well.
In dark mode, shadows mostly disappear. A shadow on a dark surface is still dark — you can't see it. The elevation system has to work differently: surfaces that should appear elevated are made lighter than the background, not shadowed below it. Material Design formalizes this: Surface 1 is slightly lighter than the base background, Surface 2 is lighter than Surface 1, and so on.
This is a complete rethink. You can't port your light-mode elevation system to dark mode. You need a parallel system — typically five or six surface levels from the base background up to the highest elevation, each with a specific lightness value that creates the illusion of depth.
Most teams skip this work. They keep the light-mode shadow system in dark mode and wonder why cards feel flat. The solution is usually a design system refactor: formalize surface levels as tokens, define them for both light and dark, and bind components to surface tokens rather than specific colors.
WCAG Is Necessary But Not Sufficient
Web Content Accessibility Guidelines require a contrast ratio of 4.5:1 for normal text and 3:1 for large text. This applies equally in dark mode.
Many dark mode guides stop here: hit 4.5:1, you're compliant, ship it. But compliance doesn't mean usable. Three specific ways technically-compliant dark mode can still fail users.
Halation. As mentioned above, users with astigmatism experience light text on dark backgrounds as glowing or bleeding. This happens even when the contrast ratio is technically compliant. The fix isn't more contrast — it's sometimes less contrast (using a slightly off-white text instead of pure white reduces halation without failing WCAG).
Long-session fatigue. High-contrast dark mode is fine for short interactions. For sustained reading or work, the contrast can feel aggressive. Users leave the product faster or take more breaks. The fix is softer contrasts — dark-gray backgrounds (not pure black) and off-white text (not pure white) — which sit more comfortably over long sessions.
Secondary text contrast. Designers hit the 4.5:1 target for primary text and skip auditing secondary text (placeholders, captions, helper text). In dark mode, secondary text often falls below compliance without anyone noticing. A full dark-mode audit should check every text element against its background, not just the primary body text.
The upshot: WCAG is a floor, not a goal. Dark mode that barely meets WCAG is table stakes. Dark mode that's actually comfortable to use requires going beyond.
The Brand Color Problem
Every product has a brand color. Blue for Facebook, Spotify green, Stripe purple. These colors work in light mode because the brand teams that chose them tested them against light backgrounds.
In dark mode, brand colors break in predictable ways. Saturated primary brand colors become visually dominant — they glow on dark backgrounds in a way they don't on white. The subtle brand accent that felt refined in light feels cartoonish in dark.
The fixes all involve compromise.
Option 1: Desaturate the brand color for dark mode. Keep the hue, reduce saturation 15-30%. The brand still feels like itself but without the visual aggression. Linear does this well — their signature purple is tempered in dark mode without losing identity.
Option 2: Define two brand colors — primary and dark-primary. Document both in the design system. The dark variant is used everywhere the primary would appear on dark backgrounds. This is more rigorous but adds complexity.
Option 3: Let the brand color fade into a neutral role. Some products use their brand color only in marketing and lean on neutrals for UI. This sidesteps the dark-mode problem entirely but sacrifices brand presence.
There's no universally correct answer. But "use the same brand color in both modes" is almost always wrong — it creates the exact visual discomfort dark mode was supposed to solve.
When Not to Ship Dark Mode
The underrated move: not shipping dark mode.
Dark mode is expensive. It's a parallel visual system, a parallel design token set, a parallel testing matrix, a parallel accessibility audit. It slows every design decision because every decision has to work in both modes. And for many products, the value doesn't justify the cost.
Three scenarios where not shipping dark mode is defensible.
Your product is used primarily in bright environments. Outdoor work software, retail POS systems, warehouse management tools. The ambient light context makes dark mode counterproductive. Light mode is objectively better for these contexts.
Your product is heavily image-dependent. Photo editing tools, video tools, visual portfolios. Image colors render differently against dark vs light backgrounds, and the inconsistency between the image area (which should preserve color fidelity) and the surrounding UI (which adapts to mode) creates awkward visual seams. Some image tools ship dark mode anyway; others (like some professional video tools) stick with dark UI only because it's expected, not because it's better.
Your product is used in short, task-focused sessions. Banking apps, forms, checkouts. Users aren't spending hours. They want to complete a task. Dark mode doesn't meaningfully improve their experience and costs you engineering resources.
Your users don't actually ask for it. Run a survey. Check support tickets. If fewer than 15-20% of users request dark mode, you're shipping something most users won't use. Those resources could go to features they actually want.
Shipping dark mode because competitors have it is the wrong reason. Ship it when your users need it, your context supports it, and your team can afford to maintain it.
The Dark Mode Implementation Checklist
If you've decided dark mode is right for your product, here's the minimum discipline that separates good implementations from bad ones.
Design tokens, not colors. Never reference specific colors in components. Reference tokens (--color-bg-primary, --color-text-primary). The mode switch just changes what the tokens resolve to.
Surface levels defined as tokens. Don't use shadows to indicate elevation in dark mode; use surface-level tokens. Define 5-6 levels (base, surface-1, surface-2, surface-3) with specific lightness values for both modes.
Semantic color tokens. Token names describe role, not appearance. --color-danger not --color-red. This makes mode-aware theming work — the "danger" token can resolve to different reds in light vs dark.
Explicit brand color variants. Document --color-brand-primary for both modes. Don't let a single hex code be used in both contexts.
Respect system preferences. Use the prefers-color-scheme CSS media query to default to the user's system choice. Allow manual override.
Smooth transitions. When users toggle between modes, the transition should be instant or smoothly animated — not a jarring flash. A 200-300ms transition on background and text colors feels polished.
Image and icon adaptation. Check that all images, illustrations, and icons work on both backgrounds. Light-mode PNGs with white backgrounds become visible white squares in dark mode. Use SVGs where possible; adapt assets explicitly where not.
Contrast audit on both modes. Don't assume light-mode contrast carries over. Audit every text element and interactive element in dark mode specifically.
User override that persists. If a user toggles modes, remember their choice. Don't revert to system preference on next visit.
What Actually Works in 2026
The dark mode implementations that feel effortless in 2026 share a few characteristics.
They use dark gray backgrounds (typically #0F0F0F to #1A1A1A range) rather than pure black. They use off-white text (typically #E0E0E0 to #EEEEEE) rather than pure white. They define 5-6 surface levels to replace shadows. They desaturate primary brand colors 10-20%. They reduce contrast slightly from the WCAG floor for sustained readability. They allow users to toggle and remember the choice. They test with actual users who have vision differences, not just design tool simulators.
The ones that feel wrong share different characteristics. Pure black backgrounds. Pure white text. Unchanged brand colors. Shadows used for elevation. WCAG-minimum contrast assumed sufficient. No consideration for how images render. No option to override system preferences.
Frequently Asked Questions
Is dark mode better for accessibility?
Not universally. Dark mode helps users with light sensitivity, photophobia, migraine triggers, and those working in low-light environments. It can make things worse for users with astigmatism (halation), users with low vision (starker contrast can fatigue), and many older users. The right framing is that dark mode is an accommodation for specific users, not a blanket accessibility improvement. Products that serve diverse users should offer both light and dark modes with easy switching.
What is the best dark mode background color?
Dark gray rather than pure black. Common values are #0F0F0F to #1A1A1A. Pure black (#000000) creates harsh contrast that can fatigue users and makes halation worse for those with astigmatism. Dark gray also allows you to define multiple surface elevations (surface-1 slightly lighter than base, surface-2 slightly lighter than surface-1) which is how dark mode elevation systems work in the absence of shadows.
Should I use pure black for dark mode?
Usually no. Pure black backgrounds have two problems: they create harsh contrast that strains users over long sessions, and they don't allow for elevation systems based on lighter surface levels. One exception is OLED displays, where pure black pixels are actually turned off and save battery — some products ship a "pure black" option specifically for this. For most products, dark gray (#121212 or similar) is the better default.
How do I design dark mode in Figma?
Set up color tokens as Figma Variables with two modes (light and dark). Reference tokens in your components rather than specific colors. Define surface-level tokens (surface-1, surface-2, surface-3) with different values for each mode. Create component variants that work across both modes. For testing, toggle between modes to verify every component still works. Never paint specific hex colors directly onto components — everything should be token-referenced.
What contrast ratio do I need for dark mode?
WCAG 2.1 AA requires 4.5:1 for normal text and 3:1 for large text — these apply equally in dark mode. But hitting the minimum isn't sufficient for good dark mode. Sustained-reading comfort often requires softer contrasts than the WCAG floor (off-white text on dark gray rather than pure white on pure black). Users with astigmatism specifically benefit from slightly reduced contrast to minimize halation. The target: meet WCAG, then tune down slightly for comfort.
The 2026 Additions (Liquid Glass, APCA, Radix)
Three 2026-specific considerations that didn't exist in the dark-mode playbooks from a few years ago.
Liquid Glass complicates dark mode on Apple platforms. Apple's Liquid Glass design language, introduced at WWDC 2025, is translucent by default — controls float on glass layers that refract content behind them. In dark mode, these translucent surfaces behave differently than in light mode because the underlying content is darker. Apple has responded with system-level controls: Reduce Transparency (refined), Reduce Bright Effects (added in iOS 26.4), and Reduce Motion now more reliably dampens Liquid Glass animations. If you're building an iOS app in 2026, test dark mode with and without these accessibility toggles — default Liquid Glass dark mode can fail legibility tests that solid-background dark mode passes.
APCA (Accessible Perceptual Contrast Algorithm) is the emerging alternative to WCAG contrast math. APCA is under consideration for WCAG 3 and produces more perceptually accurate contrast measurements than the WCAG 2.1 relative luminance formula, especially for dark mode. The WCAG 2.1 calculation can rate dark-on-darker combinations as passing when they're hard to read, and can rate some readable dark combinations as failing. APCA results correlate better with actual reading comfort. If you're building a design system in 2026, you should probably calculate both — meet WCAG 2.1 as the legal baseline, but use APCA as the design guide.
Radix Colors has emerged as the de facto dark-mode scale reference. It provides 12-step alpha and solid scales for light and dark modes, with each step calibrated to a specific UI use case (step 1: app background, step 12: high-contrast text, etc.). Using Radix Colors as a starting point eliminates most of the "how do I remap saturation for dark mode?" work. For teams building color systems from scratch in 2026, start with Radix and customize rather than inventing — the scale is rigorously thought through.
OLED pure-black battery note. Google's 2018 OLED energy research documented that pure-black pixels on OLED displays save significant battery compared to white or light gray — Google measured up to 60% power savings on YouTube's dark mode on OLED. If your app is primarily mobile and your users have OLED devices (most recent flagship phones), a "pure black" mode option is a battery feature, not just a visual preference. The caveat above about halation still applies; offer it as an option, don't default to it.
For related design system practices, read [The Color Systems Guide: How Stripe, Linear, and Radix Scale Color in 2026](https://mantlr.com/blog/color-systems-that-scale) — the definitive 2026 color systems playbook. See [The Spacing System Cheat Sheet](https://mantlr.com/blog/spacing-system-cheat-sheet) for the spacing equivalent. And [Liquid Glass vs Material Expressive](https://mantlr.com/blog/liquid-glass-vs-material-expressive) covers the broader 2026 visual design shift, including how dark mode is handled across the major design systems.
Browse Mantlr's curated [color palette tools](https://mantlr.com/categories), [design system resources](https://mantlr.com/categories/design-systems), and [accessibility tools](https://mantlr.com/categories) for building dark mode implementations that actually work.
Primary source references (all retrieved April 24, 2026):
- Apple: Liquid Glass Developer Documentation
- Apple: Human Interface Guidelines on dark mode
- Material Design 3: Dark theme documentation
- APCA (Accessible Perceptual Contrast Algorithm) — emerging WCAG 3 standard
- WCAG 2.1 contrast requirements
- Radix Colors — de facto dark-mode scale reference
- Google: Chrome DevTools Dark Mode energy research — OLED battery savings
- WebAIM Contrast Checker
- Nielsen Norman Group: Dark Mode vs Light Mode research