6 min read · Oct 2026
Dark Mode: Change the Colors, Keep the Meaning
Dark mode requires more than replacing a white background with black. Explore a practical approach to semantic color roles, text contrast, user preferences, and component review, keeping tables, alerts, and dialogs understandable across both themes without treating either as an afterthought.
Imagine a service center scheduling dashboard where waiting and cancelled requests are easy to distinguish during the day. Switching to dark mode makes borders and messages disappear. The problem is more than background styling: color helps people interpret priorities. A useful dark theme begins with the meanings that must survive the change.
01-Start with color roles
Separate page background, card surface, primary text, supporting text, borders, and alert states. Choose a value for each role in each theme rather than asking components to select black or white directly. The purpose remains understandable when the shade changes.
In our illustrative dashboard, a cancelled request needs an explicit status label, optionally supported by an icon and color. Avoid making color carry the whole message. Review the alert in cards, dialogs, and tables, where surrounding surfaces differ but its importance should remain understandable.
02-Measure contrast in context
WCAG 2.2's text contrast criterion specifies minimum ratios of 4.5:1 for ordinary text and 3:1 for text meeting its large-text definition, with defined exceptions. These are text contrast requirements, not a complete assessment of accessibility.
Check foreground colors against their actual backgrounds, including transparency and selection states. For the hypothetical dashboard, inspect search-field guidance, error descriptions, and dialog headings. Record approved pairs rather than treating one color as suitable everywhere. Recheck the pairing whenever either side changes, even if the new shade looks close.
03-Respect preference and provide choice
The CSS prefers-color-scheme feature detects a light or dark preference expressed through operating-system or browser settings. A product can use this as its starting point while offering a clear choice for someone who prefers a different appearance.
Decide how manual selection takes priority, how it persists, and what happens when the user returns to following the device setting. These behaviors require implementation; a switch alone does not provide them. Test a theme change during an open request without losing entered information or altering its operational status.
04-Review the overlooked states
Go beyond a clean dashboard screenshot. Build a review set containing a dense table, expanded menu, error message, focused field, and empty state. Inspect icons and images too: an asset created for a light surface may bring an unwanted rectangle into the dark interface.
Keep examples of both themes for each component and assign ownership of shared color changes. Do not invert every value mechanically. Heading, content, and action should retain a clear relationship, while supporting information remains readable without competing with the primary message.
Your next step
Treat dark mode as a considered theme within the same system. Begin with color roles, then examine contrast, preference, and realistic states. Preserving what the interface communicates comes before judging its appearance.