feat(theme): make the high-contrast toggle visibly transform the page in light mode #95

Merged
YousifShkara merged 1 commit from feat/bunyip-upgrade-08-high-contrast into main 2026-06-10 07:36:32 +02:00
Owner

The toggle button at views/layout.rs::theme_controls and its JS
counterpart bunyipToggleContrast() correctly flipped a .high-contrast class on <html>, and the corresponding CSS rules existed - so the WIRING was fine. But the auditor reported "didn't produce any visible change in light mode" and the diagnosis at docs/bunyip-upgrade/08-high-contrast-toggle.md confirms why:

  • Default light --background is already 120 21% 96% (a pale reed pastel) and high-contrast was 0 0% 100% (pure white). A ~4% lightness delta plus a hue drop is below most users' perceptual threshold on a typical monitor.
  • The handful of tokens that DID move noticeably (--border: pale reed → pure black) were neutered by Bunyip's pervasive use of border-border/50 (50% opacity), which resolved to half-strength black i.e. mid-gray. Borders never "thickened" visually.
  • No font-weight bump meant the page felt identical even when the colours did shift.

This commit rebuilds the LIGHT .high-contrast palette to push every token to its maximum-contrast B&W endpoint and defeats the border-opacity neutering:

  • All token greens drop to pure black/white. --primary, --ring, --border, --input all become pure black; --muted-foreground goes from 25% gray to pure black so secondary copy is as readable as primary copy.
  • A new .high-contrast [class*="border-border/"] rule forces opacity to 1 on every border-border/<n> Tailwind variant. The pure-black border tokens above can finally render as pure black, so card outlines stand crisp instead of fading into half-gray.
  • A .high-contrast { font-weight: 500; } rule bumps body text one notch (from regular 400 to medium 500) for the a11y win that pairs with the colour change.

DARK .high-contrast is unchanged - the auditor explicitly noted dark mode "produced a visible change", and the deltas there are already at the perceptual ceiling.

Closes finding 12 (high-contrast toggle no-op in light mode) from the Claude-for-Chrome audit. See docs/bunyip-upgrade/08-high-contrast-toggle.md for the full spec.

The toggle button at `views/layout.rs::theme_controls` and its JS counterpart `bunyipToggleContrast()` correctly flipped a `.high-contrast` class on `<html>`, and the corresponding CSS rules existed - so the WIRING was fine. But the auditor reported "didn't produce any visible change in light mode" and the diagnosis at `docs/bunyip-upgrade/08-high-contrast-toggle.md` confirms why: - Default light `--background` is already `120 21% 96%` (a pale reed pastel) and high-contrast was `0 0% 100%` (pure white). A ~4% lightness delta plus a hue drop is below most users' perceptual threshold on a typical monitor. - The handful of tokens that DID move noticeably (`--border`: pale reed → pure black) were neutered by Bunyip's pervasive use of `border-border/50` (50% opacity), which resolved to half-strength black i.e. mid-gray. Borders never "thickened" visually. - No font-weight bump meant the page felt identical even when the colours did shift. This commit rebuilds the LIGHT `.high-contrast` palette to push every token to its maximum-contrast B&W endpoint and defeats the border-opacity neutering: - All token greens drop to pure black/white. `--primary`, `--ring`, `--border`, `--input` all become pure black; `--muted-foreground` goes from 25% gray to pure black so secondary copy is as readable as primary copy. - A new `.high-contrast [class*="border-border/"]` rule forces opacity to 1 on every `border-border/<n>` Tailwind variant. The pure-black border tokens above can finally render as pure black, so card outlines stand crisp instead of fading into half-gray. - A `.high-contrast { font-weight: 500; }` rule bumps body text one notch (from regular 400 to medium 500) for the a11y win that pairs with the colour change. DARK `.high-contrast` is unchanged - the auditor explicitly noted dark mode "produced a visible change", and the deltas there are already at the perceptual ceiling. Closes finding 12 (high-contrast toggle no-op in light mode) from the Claude-for-Chrome audit. See `docs/bunyip-upgrade/08-high-contrast-toggle.md` for the full spec.
feat(theme): make the high-contrast toggle visibly transform the page in light mode
All checks were successful
Create release / Create release from merged PR (pull_request) Has been skipped
Check / fmt / clippy / build / test (pull_request) Successful in 1m1s
d7ad944a76
The toggle button at `views/layout.rs::theme_controls` and its JS
counterpart `bunyipToggleContrast()` correctly flipped a `.high-contrast` class on `<html>`, and the corresponding CSS rules existed - so the WIRING was fine. But the auditor reported "didn't produce any visible change in light mode" and the diagnosis at `docs/bunyip-upgrade/08-high-contrast-toggle.md` confirms why:

- Default light `--background` is already `120 21% 96%` (a pale reed pastel) and high-contrast was `0 0% 100%` (pure white). A ~4% lightness delta plus a hue drop is below most users' perceptual threshold on a typical monitor.
- The handful of tokens that DID move noticeably (`--border`: pale reed → pure black) were neutered by Bunyip's pervasive use of `border-border/50` (50% opacity), which resolved to half-strength black i.e. mid-gray. Borders never "thickened" visually.
- No font-weight bump meant the page felt identical even when the colours did shift.

This commit rebuilds the LIGHT `.high-contrast` palette to push every token to its maximum-contrast B&W endpoint and defeats the border-opacity neutering:

- All token greens drop to pure black/white. `--primary`, `--ring`, `--border`, `--input` all become pure black; `--muted-foreground` goes from 25% gray to pure black so secondary copy is as readable as primary copy.
- A new `.high-contrast [class*="border-border/"]` rule forces opacity to 1 on every `border-border/<n>` Tailwind variant. The pure-black border tokens above can finally render as pure black, so card outlines stand crisp instead of fading into half-gray.
- A `.high-contrast { font-weight: 500; }` rule bumps body text one notch (from regular 400 to medium 500) for the a11y win that pairs with the colour change.

DARK `.high-contrast` is unchanged - the auditor explicitly noted dark mode "produced a visible change", and the deltas there are already at the perceptual ceiling.

Closes finding 12 (high-contrast toggle no-op in light mode) from the Claude-for-Chrome audit. See `docs/bunyip-upgrade/08-high-contrast-toggle.md` for the full spec.
YousifShkara deleted branch feat/bunyip-upgrade-08-high-contrast 2026-06-10 07:36:32 +02:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/bunyip!95
No description provided.