Your Dark Mode Toggle Just Broke Contrast. Nobody Is Watching.
A dark mode toggle can push text below the 4.5:1 contrast ratio WCAG 2.2 requires, and automated scans usually only test the default theme. Monitoring has to cover both.
A store ships a dark mode toggle. The light theme passed its contrast audit at 4.5:1, the toggle looks clean, and nobody re-runs the scan in dark mode. But the muted grey helper text that passed on white now sits on charcoal at 2.8:1, and the sale price in brand red drops to 3.1:1. A low-vision shopper who prefers dark mode, the exact person the toggle was built for, is the one who cannot read the prices.
WCAG 2.2 criterion 1.4.3, Contrast (Minimum), applies to every theme a site ships, not just the default one. If your monitoring only screenshots the light theme, dark mode is an unmonitored regression waiting for a demand letter.
Where dark themes lose contrast
The usual losses are the quiet ones. Secondary text, placeholder text, disabled buttons, and link colors that were tuned for a white background all drift when the background flips. Brand colors are the worst offenders: a red or teal that reads fine on white can fall below 4.5:1 on a dark surface, and nobody notices because the brand color looks right.
Forced colors mode is the other gap. On Windows, high contrast mode overrides the site's colors entirely, and a dark theme that relies on background images or box shadows to separate sections can collapse into a flat field where boundaries vanish. If your toggle only flips CSS variables, test with forced colors on, not just with the toggle on.
What to monitor
Run the contrast scan twice per template: once in the default theme, once with the dark theme forced on. Most scanners accept a theme parameter or a cookie; set it before the crawl instead of clicking the toggle in the browser, or the scan will cover the light theme twice and the dark theme never.
Track the failing pairs by token, not by page. A single muted-text token used in twelve components produces twelve failures with one cause, and fixing the token fixes all of them. If your monitoring reports pages instead of tokens, the same defect will come back every release under a different URL.
The fix that holds
Define contrast pairs, not single colors. Every text token gets a light-theme color and a dark-theme color, each checked against its own background at 4.5:1 for normal text and 3:1 for large text. Put the check in the design token pipeline so a new color cannot ship without a passing pair, and the toggle stops being a source of regressions.
Then check the toggle itself. The button that switches themes has to announce its state, and the preference has to persist across pages. A shopper who turns on dark mode on the homepage and finds it off again at checkout has been given a feature that does not work where it matters.
Related reading: Monitoring Accessible Names After Icon Swaps, Monitoring Focus Order After a Mega-Menu Rebuild, Monitoring Skip Links After a Navigation Redesign.
Frequently asked questions
Does WCAG contrast apply to dark mode too?
Yes. Criterion 1.4.3 requires 4.5:1 for normal text and 3:1 for large text in every theme a site ships. A light theme that passes and a dark theme that fails is still a failure.
What is the most common dark mode contrast failure?
Secondary and helper text in muted grey. It passes on white and drops to around 3:1 on a dark surface. Brand colors tuned for white backgrounds are the next most common loss.
How should monitoring cover a theme toggle?
Run the contrast scan twice per template, once per theme, forcing the theme with a cookie or parameter rather than clicking the toggle. Track failures by design token so one bad token does not come back as twelve separate page failures.
Does forced colors mode matter for monitoring?
Yes. Windows high contrast mode overrides site colors, and themes that rely on background images or shadows to separate sections can collapse. Test with forced colors on as part of the same pass.