fix(a11y): dark theme meets AA on brand-primary surfaces without changing the brand

[LMPrado-DZ23]

The residual

The dark theme painted white text on the brand coral — #ffffff on #e54d5e = 3.78:1, under WCAG AA (4.5:1). It was the only violation left in the accessibility matrix, and the gate never saw it: the axe e2e suite only ever measured the light theme (a fresh Playwright context has no persisted theme preference).

Approach — the brand colour is unchanged

--color-primary is still #e54d5e in the dark theme and #b83242 in the light one. Nothing repaints the brand.

What changed is the foreground on brand surfaces, through theme-aware tokens (approach 1 of the brief):

token	light	dark
--color-primary (brand)	#b83242 — unchanged	#e54d5e — unchanged
--color-on-primary (new)	#ffffff (5.9:1)	#000000 (5.6:1 on the fill, 4.7:1 on the bg-primary/90 hover fills)
--color-primary-hover	#9f2a38 — unchanged	color-mix(in srgb, var(--color-primary) 85%, #ffffff) — derived, lightens

• The dark hover shade had to lighten instead of darken: black on the old hard-coded #c93d4e is only 4.3:1. It is now derived from --color-primary with color-mix, so it follows the brand instead of drifting from it — the same pattern Phase 9 used for --color-primary-on-tint.
• No hex and no literal foreground at call sites: 113 lines moved from text-white to text-on-primary. text-primary-foreground (used at a handful of call sites with no token behind it, so it silently inherited the page text colour) is now a real alias of the same token.
• Colour presets follow the system. A preset or custom colour is written inline on <html> by themeStore and overrides both themes, so the store derives the matching --color-on-primary for that exact colour (white while it meets AA, otherwise black, which then always does) and shades hover away from that text colour.
• Testing a custom preset surfaced a second, pre-existing gap with the same root cause: --color-primary-on-tint mixes the brand with 80% black/white, a ratio tuned for coral. On another hue it lands under AA on the tints it exists for (green measured 2.95:1 on the sidebar nav item, 2.92:1 on the /dashboard/logs column pills, in the LIGHT theme). themeStore now derives that tint text per theme as well, shading away from the tint until it clears 4.5:1 on every surface × alpha the app paints (sidebar, page, card, subtle × /10, /15, /22) and keeping as much hue as contrast allows; globals.css reads it through a var() fallback so the default preset keeps the exact coral-tuned mixes.

Before / after — axe with the repo's own tag set (wcag2a, wcag2aa, wcag21a, wcag21aa)

Measured by running the product on an isolated dev server + DATA_DIR (OMNIROUTE_BOOTSTRAPPED pinned), theme pinned on both sides (persisted store + prefers-color-scheme, html.dark asserted per page), server warmed twice before each sweep. Totals are violations of any impact; critical/serious in brackets.

Dark theme — BEFORE

page	375	768	1024	1440
/login	0	0	0	0
/dashboard	0	0	0	0
/dashboard/providers	0	1 [1]	1 [1]	0
/dashboard/settings	0	0	0	0
/dashboard/analytics?tab=route-trace	0	0	0	0
/dashboard/logs	1 [1]	1 [1]	1 [1]	1 [1]
/dashboard/onboarding?rerun=1	1 [1]	1 [1]	1 [1]	1 [1]

Every one of them color-contrast, fg=#ffffff bg=#e54d5e ratio=3.78 — e.g. <button class="... bg-primary text-white border-primary">All</button> on /dashboard/logs, the "Get started" button on the wizard, and the count spans inside the active category pill on /dashboard/providers.

Dark theme — AFTER

page	375	768	1024	1440
/login	0	0	0	0
/dashboard	0	0	0	0
/dashboard/providers	0	0	0	0
/dashboard/settings	0	0	0	0
/dashboard/analytics?tab=route-trace	0	0	0	0
/dashboard/logs	0	0	0	0
/dashboard/onboarding?rerun=1	0	0	0	0

Light theme — BEFORE

page	375	768	1024	1440
/login	0	0	0	0
/dashboard	0	0	0	0
/dashboard/providers	0	0	0	0
/dashboard/settings	0	0	0	0
/dashboard/analytics?tab=route-trace	0	0	0	0
/dashboard/logs	0	0	0	0
/dashboard/onboarding?rerun=1	0	0	0	0

Light theme — AFTER

page	375	768	1024	1440
/login	0	0	0	0
/dashboard	0	0	0	0
/dashboard/providers	0	0	0	0
/dashboard/settings	0	0	0	0
/dashboard/analytics?tab=route-trace	0	0	0	0
/dashboard/logs	0	0	0	0
/dashboard/onboarding?rerun=1	0	0	0	0

Custom colour preset — #22c55e, not the default, @1440

page	dark BEFORE	dark AFTER	light BEFORE¹	light AFTER
/login	0	0	0	0
/dashboard	0	0	1 [1]	0
/dashboard/providers	1 [1] (2.27:1)	0	1 [1]	0
/dashboard/settings	0	0	1 [1]	0
/dashboard/analytics?tab=route-trace	0	0	1 [1]	0
/dashboard/logs	1 [1] (2.27:1)	0	1 [15 nodes]	0
/dashboard/onboarding?rerun=1	1 [1] (2.27:1)	0	0	0

¹ measured with the first commit applied, i.e. with --color-primary-on-tint still untouched — these are the pre-existing tint failures (fg=#1b9e4b, 2.92–2.95:1) that the second commit fixes, not a regression from this PR.

Closing the gate that missed it

tests/e2e/a11y.spec.ts now audits both themes for every page (THEMES = ["light", "dark"]): it pins the theme per document (persisted theme store + prefers-color-scheme) and waits for the store to apply html.dark before running axe. The frozen baselines are untouched and still 0 — they now hold for both themes. The nightly job budget goes 30 → 45 min for the doubled axe passes (the suite is nightly-only, so per-PR e2e shard timings are unchanged).

tests/unit/ui/on-primary-contrast.test.ts (new) holds the line statically: the dark --color-primary is still #e54d5e, on-primary meets AA at rest / on hover / over bg-primary/90 on both dark surfaces, each theme's tint text falls back to its own preset override, no call site paints text-white on a brand surface, and the e2e gate keeps auditing dark. tests/unit/ui/theme-store-default-primary.test.tsx covers the preset derivation, including a sweep over the sRGB cube (every colour gets an AA foreground) and AA tint text for every built-in preset in both themes.

Verification

• 4 typechecks (tsc --noEmit on core / api / dashboard / noimplicit-core): clean.
• eslint (--max-warnings=0, suppressions file) on all changed files: clean. Prettier: clean.
• tests/unit/ui (node:test, 189 tests) and the theme-store/providers/webhooks vitest files: pass.
• check-file-size: only the pre-existing src/lib/db/core.ts (1770 > frozen 1745), untouched here. Complexity ratchets: 2747/3218 and 1235/1437, both under baseline.
• No baseline was raised and no test was skipped or weakened.

🤖 Generated with Claude Code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: f04c95fb-66fe-4817-aef7-2e622dbc5310

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}