a11y(1.4.11): focus rings — lighten dark-mode --color-border-focus-info to indigo.400 so ring-primary/70 meets 3:1 against surface-primary

[canvanooo]

Description & motivation 💭

The Tailwind class pattern focus-visible:ring-2 focus-visible:ring-primary/70 is used on 34 sites across 25 files in src/lib/holocene/ and src/lib/components/ — Button (secondary, ghost), Link, Tab, Input, Textarea, Combobox, Checkbox, RadioInput, FileInput, ToggleSwitch, Pill, navigation primitives, and more. ring-primary resolves to --color-border-focus-info, which was set to indigo.600 (#444CE7) in both light and dark modes.

At 70% alpha composited over the dark-mode surface (--color-surface-primary = #141414), the ring renders as approximately #273074. Contrast ratio against the surrounding canvas: ~1.92:1 — below the WCAG 1.4.11 Non-text Contrast floor of 3:1. Light mode passes at 3.58:1; the failure is dark-mode only, but it affects every focus-visible ring rendered there.

This PR shifts the dark-mode value of --color-border-focus-info from indigo.600 to indigo.400 (#8098F9). At 70% alpha composited over the dark surface that resolves to ~#5A6BAF, giving ~3.78:1 against the surrounding canvas. Light mode is byte-identical (still indigo.600).

The diff:

  '--color-border-focus-info': {
    light: 'indigo.600',
-   dark: 'indigo.600',
+   dark: 'indigo.400',
  },

One line in src/lib/theme/variables.ts:215.

Why a token-level change rather than dropping /70 from every consumer. The audit fix doc offered two viable options. Option A: find-replace ring-primary/70 → ring-primary across 34 sites. Simpler conceptually, but touches 25 files in the design-system layer, changes light-mode ring intensity on every consumer (3.58 → 5.27), and the resulting dark-mode contrast is 3.12:1 — sub-pixel rendering variance away from 3:1. Option B (this PR): change one CSS variable's dark-mode value. Light-mode rendering pixel-identical. Dark-mode contrast 3.78:1 with margin. Token blast radius is minimal — --color-border-focus-info has exactly two references in src/: its own definition in variables.ts:213 and the ringColor.primary mapping in theme/plugin.ts:221. Nothing else (no outline, no border, no text) consumes it. The asymmetric light/dark token pattern is also consistent with neighboring tokens — --color-border-danger is already red.500 light / red.400 dark in this same file.

Composes with PR #3477. That PR adds ring-offset to the Checkbox :checked state to fix the indigo-on-indigo problem (addresses where the ring sits). This PR changes the dark-mode token color (addresses what color it is). Together they bring the dark-mode focused-and-checked checkbox to ~8.43:1 ring-vs-canvas contrast. They're independent and can land in either order.

Screenshots (if applicable) 📸

Screenshots to be captured by the PR author from the Vercel preview build (link appears once the Vercel check passes). Include light-mode and dark-mode captures for each affected primitive.

Design Considerations 🎨

Token-color shift in one mode only. The dark-mode focus ring becomes a lighter indigo (slightly cooler / less saturated). Design team may want to confirm the perceptual change is acceptable — it's necessary for WCAG AA contrast at the current /70 opacity. If the team prefers to keep indigo.600 everywhere, the alternative is Option A (drop /70 opacity), with the tradeoffs documented in the rationale above.

Testing 🧪

How was this tested 👻

• Manual testing
• E2E tests added
• Unit tests added

Automated checks performed locally on a11y/1.4.11-focus-ring-dark-mode-opacity before pushing:

• pnpm lint — 0 errors
• pnpm check (svelte-check) — 0 errors (84 pre-existing warnings repo-wide, none introduced by this change)
• pnpm test -- --run — 142 test files / 2023 tests passed
• Pre-commit lint hooks (lint-staged: eslint --fix, prettier --write, stylelint --fix) clean
• Token reference grep confirms --color-border-focus-info is consumed by exactly one Tailwind utility (ring-primary) — no other Tailwind utility, no raw CSS reference

No new automated tests added because the change is a single CSS-variable value; existing Chromatic visual-regression coverage exercises every primitive's focused state in both modes and will produce expected dark-mode-only diffs to accept as new baseline. Manual visual testing in Storybook is the responsibility of the PR author after the preview deploy is ready (see "Steps for others to test" below).

Steps for others to test: 🚶🏽‍♂️🚶🏽‍♀️

1. Check out the branch and pnpm install if needed.
2. pnpm stories:dev — open Storybook at http://localhost:6006.
3. Toggle the theme switcher in the Storybook toolbar to dark mode.
4. Tab through these stories and confirm the focus ring is clearly visible against the dark canvas (a lighter indigo, not the previous near-black-on-near-black render):
   • Holocene → Button → Secondary variant
   • Holocene → Button → Ghost variant
   • Holocene → Link → Default
   • Holocene → Tab → Default
   • Holocene → Input → Default (click into the input)
   • Holocene → Textarea → Default
   • Holocene → Combobox → Default
   • Holocene → Checkbox → Default (Tab to it without checking)
   • Holocene → RadioInput → Default
5. Toggle back to light mode. Tab through the same stories. Confirm the focus rings render identically to current main (no visible change in light mode).
6. (Optional) Use the DevTools color-contrast inspector on a focused control in dark mode — the rendered ring color against #141414 should report ≥ 3:1.
7. (Optional) Color-blind simulator (deuteranopia, protanopia, achromatopsia): focus state still distinct from canvas.
8. Cross-browser: confirm the dark-mode improvement in both Chromium and Firefox.

Checklists

Draft Checklist

• Token-level diff verified to be 1 line in src/lib/theme/variables.ts
• --color-border-focus-info consumer audit: 2 references confirmed, both internal to the theme layer
• Local pnpm lint, pnpm check, pnpm test -- --run all pass

Merge Checklist

• PR author has walked the dark-mode Storybook sweep above
• Chromatic visual-regression diffs reviewed and accepted as new baseline (expected: dark-mode focus-ring snapshots only; light-mode snapshots should match existing baselines)
• CLA status green
• Design team sign-off on the dark-mode token shift (indigo.600 → indigo.400 in dark mode only)

Issue(s) closed

A11y-Audit-Ref: 1.4.11-focus-ring-dark-mode-opacity

Closes the focus-ring dark-mode opacity defect documented in the May 2026 audit (manifest bucket 1, severity serious, scope ui-main). See scripts/a11y/manifest.yml for the canonical entry.

Docs

Any docs updates needed?

No external docs (docs.temporal.io) need updating — this is a design-system internal token-value change with no surface change in light mode and a subtle color shift in dark mode that doesn't introduce new APIs or behaviors. If the team maintains an internal design-system change-log, an entry noting "dark-mode focus ring color shifted from indigo.600 to indigo.400 for WCAG AA contrast" would be appropriate.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
holocene	Ready	Preview, Comment	May 29, 2026 4:31pm

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[temporal-cicd]

Warnings

⚠️

📊 Strict Mode: 3 errors in 1 file (0.3% of 898 total) src/lib/theme/variables.ts (3) L223:16: Element implicitly has an 'any' type because expression of type 'string' can't be used to index type '{ readonly '--color-text-black': { readonly light: "space-black"; readonly dark: "space-black"; }; readonly '--color-text-white': { readonly light: "off-white"; readonly dark: "off-white"; }; ... 49 more ...; readonly '--color-border-focus-danger': { ...; }; }'. L224:2: Element implicitly has an 'any' type because expression of type 'string' can't be used to index type 'Record<--${string}, ${number} ${number} ${number}>'. L225:2: Element implicitly has an 'any' type because expression of type 'string' can't be used to index type 'Record<--${string}, ${number} ${number} ${number}>'.

Generated by 🚫 dangerJS against 5963eec