The Second Theme

When Apple shipped macOS Mojave in June 2018, it came with a system-wide dark mode. The announcement framed it as dramatic and beautiful: "a dramatic darkened color scheme where content pops and controls recede into the background." Most product teams received it as a feature request. Then they looked at what building it actually required.

A real dark mode is a parallel color system: every color decision reconsidered for a dark ground, every elevation state re-mapped, every shadow rethought because shadows do not exist on dark surfaces the way they do on light ones. The shortcut, inverting the light theme, turns blue links purple, makes white backgrounds black, and renders every photograph as a negative. The result is unusable. It is a second design, not a filter.

Where the preference came from

Dark interfaces have a long history in developer tools. Text editors, terminals, and code environments have offered dark themes for decades, and the preference for them became a marker of programmer culture, a legible signal that the person at the keyboard worked in text all day. The practical argument followed: OLED screens, which power most modern phones, turn off pixels that display black, so a dark interface consumes less power. That argument is real, though the effect is small at the brightness most people use. A 2021 Purdue study measured 3% to 9% savings at 30% to 50% brightness, small enough that most users would not notice, rising to 39% to 47% only at full brightness.

The broader demand, the one that pushed Apple to build it into the operating system, came from users who described eye strain from bright white interfaces in low-light conditions. This is a genuine experience. A bright screen in a dark room creates a contrast between the ambient light and the display that many people find uncomfortable, and reducing the screen's background brightness alleviates it. When Apple extended dark mode to iOS 13 in 2019, it added the option to schedule it automatically at sunset, acknowledging that the need was environmental.

The accessibility complication

Dark mode is often described as an accessibility feature. It is one for some users and the opposite for others.

Some users genuinely need it. Photophobia, light sensitivity severe enough to cause pain or headaches, is a real condition, and a dark interface can make the difference between using a product and not using it. UX researcher Stephanie Walter's analysis of the research documents who benefits and who does not. The users who do not are numerous. People with astigmatism, a condition a systematic review puts at around 40% of adults, experience halation when reading light text on a dark background: the letterforms appear to bleed or blur into the surrounding dark, which makes the text harder to read. For these users, a dark mode can be worse than the light default.

The implication is that dark mode helps some users and harms others, so the right answer is choice: a system that lets them set their preference and have it respected. This is what Apple built, and what the prefers-color-scheme media query enables on the web, routing the user's operating system preference to the stylesheet. The problem is that many products treated "we support dark mode" as a terminus rather than a starting point for maintaining genuine accessibility in both themes.

WCAG applies to both

The contrast requirements under WCAG 2.1, 4.5:1 for normal text against its background, 3:1 for large-scale text, do not have an exception for dark mode. The Bureau of Internet Accessibility states this directly: shipping a dark theme is not a substitute for meeting contrast standards in either theme, and the dark theme must independently meet all the same requirements. Pure black text on pure white (21:1 contrast) is technically permissible but causes halation for astigmatic users; off-white text on dark gray, around 12:1, serves most users better and still satisfies the standard.

Many dark mode implementations fail this requirement because of how they were built. A team that defined colors as absolute hex values rather than semantic tokens, where a button background was always this particular blue rather than "the interactive background color," had to reconsider every value manually for the dark version. Teams that had not built semantic token systems before dark mode was requested found themselves doing the work at the worst possible time.

What the second theme cost

Visual hierarchy works differently on a dark ground: the shadow that signals elevation on a light background disappears entirely on dark, replaced by a lighter surface color to suggest depth. Colors that read as saturated and bold on white turn harsh and glaring on dark; brand colors that work beautifully in the light theme may need to be remixed by luminance for the dark one. Every illustration needs its own dark variant or a treatment that prevents white backgrounds from becoming rectangles of light on a dark page.

Design teams that shipped dark mode well spent the time to build it as a first-class system: semantic color tokens with light and dark values, tested independently against contrast requirements, with component variants for the states that differ. The teams that bolted it on as a quick follow-up after the light theme launched spent the time twice, and often shipped a dark mode that passed the light theme's components through a filter and missed the contrast standard the second theme had to meet on its own.

Whether the investment was worth it is a question the product data would need to answer, and most teams did not instrument it. What share of any given product's user base prefers it, what share needs it for genuine access reasons, and what share simply turned it on because the toggle was there: these numbers would inform whether doubling the color system was the best use of the design and engineering time. Most teams that built dark mode did not know those numbers when they made the decision.