remarque-tokens 0.20.0 → 0.22.0

package/CHANGELOG.md

@@ -4,6 +4,35 @@ All notable changes to `remarque-tokens` are documented here. Token value
 changes always state the design rationale — downstream sites pin against
 these entries when syncing.
 
+## 0.22.0 — 2026-07-23
+
+Dataviz categorical tokens — bridge-derived, golden-gated (closes #94). The syntax-palette pattern's fourth application, closing the "Dataviz Tokens" section's long-standing "guidance, not a palette" gap now that the upstream dataset ships a per-theme `dataviz` block (`@williamzujkowski/oklch-terminal-themes` 0.5.0).
+
+### Added
+- **6 `--color-viz-1..6` palette-tier slots**, hand-authored in both themes from `remarque-light`/`remarque-dark`'s `dataviz.categorical` block, serialized as round numbers (identity/serialization contract, same as `--color-syntax-*`). 6 slots, not 8 — the dataset's own floor (516 of 633 corpus themes ship exactly 6). Every slot ≥ **3:1** against `--color-bg` in both themes — Carbon's mark-on-background line, not text's 4.5:1 (marks are read at a glance, not continuously like prose). Added to `tokens-palette.css`'s `:root`, `@media (prefers-color-scheme: dark)`, `[data-theme="dark"]`/`:root.dark`, and the demo's `[data-theme="light"]` mirror.
+- **`remarque-theme` dataviz derivation.** Derives all 6 slots from the source theme's own `dataviz.categorical` array (first 6 entries, dataset order, per theme independently — order is **not** reconciled hue-for-hue across a light/dark pair; verified the upstream order itself differs between `remarque-light` and `remarque-dark`, consistent with this file's existing "dark mode is independently tuned, not inverted" stance). Same keep-if-passing-else-solve pattern as every other slot, chroma capped at 0.14. **Fallback:** an installed dataset older than 0.5.0 (still legal under the `>=0.1.0` peerDependencies floor) has no `dataviz` block — `remarque-theme` errors loudly naming the missing field and the upgrade path rather than synthesizing a guessed ramp from raw ANSI colors (the upstream categorical-selection algorithm is undocumented; guessing at it could silently diverge from a real 0.5.0+ dataset).
+- **`remarque-theme --dataviz`** (optional, judgment-call item). Emits `--viz-sequential-N`/`--viz-diverging-N` custom properties from the dataset's `dataviz.sequential`/`.diverging` ramps — gamut-clamped but NOT contrast-solved (a sequential ramp's low end is designed to sit near `--color-bg`) and NOT audited/golden-gated like `--color-viz-1..6` (these are per-use ramps, not identity tokens). Purely additive: omitting the flag leaves the derived `--color-*` output byte-identical to before.
+- **Audit extension** (`scripts/audit.mjs`, `scripts/theme.mjs` self-verify) — 6 new `CHECKS` pairings (`color-viz-1..6` vs `color-bg` at 3.0). `scripts/test-audit.mjs` fixtures updated with the 6 slots plus a must-fail case (`viz-slot-fails.css`) proving the pairings are actually wired in.
+- **Golden gate** (`scripts/palette-golden.mjs`) extended to the 6 new slots — ΔE2000 = 0.000 in both themes (the hand-authored values are literal transcriptions of the dataset's own numbers, unlike the solved slots elsewhere in the palette).
+- **REMARQUE.md "Dataviz Tokens"** rewritten: the 6 shipped tokens with light/dark values and ratios, the 3:1 mark-threshold rationale, a mandatory non-color-redundancy rule (shape/pattern/label — never color alone, per Carbon and tsundoku's precedent), and a documented recipe for sequential/diverging ramps (direct JSON consumption from the dataset, or `remarque-theme --dataviz`). New Enforcement Checklist line.
+- **Demo** (`site/src/pages/tokens.astro`): a "Dataviz" section rendering all 6 swatches in both themes with contrast ratios and a shape-coded legend (circle/square/triangle) demonstrating the non-color-redundancy rule directly. Placed on `tokens.astro`, which carries zero visual-regression baselines — this ships with no new/changed screenshot baselines.
+- **Repin**: `@williamzujkowski/oklch-terminal-themes` devDependency 0.4.0 → 0.5.0 (exact). Corpus test (`scripts/test-theme.mjs`) still 65/65 pairs passing — the dataset gained fields (`dataviz` on every theme), not themes, matching the repin pattern's usual shape.
+
+## 0.21.0 — 2026-07-23
+
+Forced-colors (Windows High Contrast Mode) + `prefers-contrast: more` support (closes #93) — the ratified program's highest-value accessibility item.
+
+### Added
+- **`@media (forced-colors: active)` audit and fixes** across `tokens-core.css`, `prose.css`, `essay.css`, `broadsheet.css`, `forms.css`, and the demo's `globals.css`/`tokens.astro`. Every color-bearing declaration was classified as fine-as-is (the overwhelming majority — `border-color` on a real, non-transparent border is forced to a visible system color regardless of the authored value, so `--color-border`'s documented sub-3:1 hairlines, prose table rules, sidenote/TOC borders, etc. already survive with zero code changes), affordance-loss (fixed), or must-survive custom painting (`forced-color-adjust: none`, justified). See REMARQUE.md's new "Forced Colors & Contrast Preferences" section for the full inventory.
+  - **Broadsheet title-link hover/focus** (`broadsheet.css`): the underline-grow effect is a `background-image` gradient, which forced-colors mode forces to `none` — added a `text-decoration: underline` fallback under `@media (forced-colors: active)`.
+  - **`.remarque-rule`** (`broadsheet.css`, masthead dateline divider): converted from a `background` fill on a bare `<span>` (at risk of being forced to `Canvas` and disappearing) to a real `border-top` — an unconditional fix, not media-gated, since a border is simply the correct way to author a hairline.
+  - **Form validation states** (`forms.css`): error/success/warning were distinguished entirely by `border-color`/`color`, both forced under forced-colors — added `border-style`/`border-width` differentiation (double/dashed/solid) plus a small glyph (✕/⚠/✓) prefixed to the message line, scoped to `@media (forced-colors: active)`.
+  - **Focus** (`tokens-core.css`): `:focus-visible` was already forced-colors-safe (`outline`, not `box-shadow` — `box-shadow` is unconditionally forced to `none`); added an explicit `outline-color: Highlight` under forced-colors so the ring keys to the same system color as the rest of the OS, and so the CI gate has something explicit to assert against.
+  - **Demo chrome**: `.nav-link`/`.footer-link`/TOC-rail hover (color-only affordances) get the same `text-decoration: underline` forced-colors fallback; `tokens.astro`'s color-token reference swatches get `forced-color-adjust: none` (the one "must-survive custom painting" case — the swatch's entire purpose is showing the real color).
+- **`prefers-contrast: more`** (`tokens-palette.css`). Bumps `--color-border-bold` (light 3.39:1 → 4.52:1, dark 3.23:1 → 4.53:1) and `--color-fg-muted` (light 7.55:1 → 10.11:1, dark 7.26:1 → 9.70:1) one step toward `--color-fg`, for users who want more contrast without forced-colors' system-color override. Lives in the palette tier (same mechanism as the existing `prefers-color-scheme: dark` override) — version-only change to `tokens.json`/`tokens.d.ts` since no new token names were introduced.
+- **`scripts/lib/css-tokens.mjs` context-exactness fix.** `isDarkBlock`'s two recognition paths (the `prefers-color-scheme: dark` media convention and the `[data-theme="dark"]`/`:root.dark` selector convention) were previously matched by unguarded substring checks — a `[data-theme="dark"]` selector or a `prefers-color-scheme: dark` feature nested inside an unrelated or compounded media query (exactly the shape the new `prefers-contrast: more` block uses) would have been misread as an unconditional dark override, silently clobbering the real dark values in generated output (`tokens.json`/`tokens.d.ts`) and audit results. Both paths are now context-exact (top-level, or the plain non-compounded `@media (prefers-color-scheme: dark)` query only). Two regression fixtures added to `scripts/test-audit.mjs` (`nested-media-not-dark.css`, `compound-media-not-dark.css`) proving a nested/compounded dark-selector block no longer overrides the real one.
+- **`site/tests/forced-colors.spec.ts`** — the issue's blocking CI condition. Computed-style assertions (no pixel diffing) under `page.emulateMedia({ forcedColors: 'active' })`: a nav link's keyboard focus renders a visible, non-zero outline; `.remarque-table` borders resolve to a non-transparent `border-color`; the essay module's TOC rail and (narrow-viewport) sidenote borders stay visible; a form's error/success states render `border-style` distinct from the default and from each other. Wired into the existing `visual-regression.yml` workflow (`npx playwright test` already runs the whole `site/tests/` directory). Three forced-colors screenshot baselines (landing/essay/components) added as a secondary, non-blocking supplement — forced-colors rendering is deterministic in headless Chromium.
+
 ## 0.20.0 — 2026-07-23
 
 Machine-readable surface: `--json` for `remarque-audit`/`remarque-drift`, and a published JSON Schema for `tokens.json` (closes #98, closes #99).

package/REMARQUE.md

@@ -256,14 +256,45 @@ Reference/Docs and Project Dossier pages often need to show several screenshots
 
 ## Dataviz Tokens
 
-Charts are not yet a first-class Remarque surface, but tools built with the system inevitably need them. Rather than inventing chart-specific tokens, map dataviz elements onto vocabulary that already exists, so a chart survives a palette swap the same way prose and chrome do:
+Charts are a first-class Remarque surface: `tokens-palette.css` ships 6 hand-authored `--color-viz-*` categorical slots, bridge-derived and golden-gated against the upstream `remarque-light`/`remarque-dark` themes' `dataviz.categorical` block the same way the rest of the default palette is (issue #94 — the syntax-palette pattern's fourth application). The rest of a chart still maps onto vocabulary that already exists, so it survives a palette swap the same way prose and chrome do:
 
 - **Grid lines** use `--color-border` — never a separate "chart gray." Grid lines are structural, not decorative, and already have a sanctioned quiet role.
 - **Axis text and tick labels** use `--font-mono` at `--text-meta`, `--color-muted` — the same register as metadata rows and captions, never the body or display face.
-- **Categorical color ramp** is derived, not hand-picked: rotate hue at the accent's lightness/chroma steps — the same discipline "Changing the Accent Hue" already prescribes (fix lightness, vary hue, reduce chroma until every value clears the gamut) — producing a small hue family distinct from `--color-accent` itself, so chart color is never mistaken for the system's one interactive signal.
-- That ramp must be **audit-validated**, exactly like a palette override: every ramp color needs to clear gamut and 4.5:1 contrast against `--color-bg`/`--color-surface` in both themes before it ships.
+- **Categorical color** uses `--color-viz-1` through `--color-viz-6` (below) — never `--color-accent`, so chart color is never mistaken for the system's one interactive signal.
 
-**Precedent:** [tsundoku](https://github.com/williamzujkowski/tsundoku) built the underlying pattern already — its `DESIGN-NOTES.md` documents an 8-hue "orthogonal category system" (`--pop-pink`/`--pop-blue`/`--pop-green`/etc.), kept deliberately separate from `--color-accent` and used for content taxonomy (book categories, reading status) rather than interactivity. It held those hues to roughly the same lightness/contrast discipline as its audited palette, but by its own admission the hues were **never run through `remarque-audit`'s `CHECKS` array** — that is the one gap this guidance closes. A dataviz ramp should follow tsundoku's separation-from-accent instinct, but unlike its precedent, it must pass the audit before it ships.
+### Slots
+
+6 slots, not 8 — the upstream dataset's own floor: 516 of the 633 corpus themes ship exactly 6 `dataviz.categorical` entries, so shipping 8 would leave 2 unfillable on most themes. Every slot is verified ≥ **3:1** against `--color-bg` in both themes — Carbon's mark-on-background line, not text's 4.5:1. The distinction is deliberate: a chart mark is a small area read at a glance and identified by hue difference from its neighbors, not a string of characters read continuously letter-by-letter, so it gets the WCAG 1.4.11 non-text threshold (the same one `--color-border-bold` already uses for functional borders), not 1.4.3's text threshold.
+
+| Slot | Light | Dark |
+|---|---|---|
+| `--color-viz-1` | `oklch(0.538 0.121 250.5)` — 4.74:1 | `oklch(0.708 0.129 249.5)` — 7.53:1 |
+| `--color-viz-2` | `oklch(0.541 0.111 85.5)` — 4.73:1 | `oklch(0.712 0.13 85.3)` — 7.54:1 |
+| `--color-viz-3` | `oklch(0.524 0.12 24.6)` — 5.35:1 | `oklch(0.724 0.129 310.2)` — 7.55:1 |
+| `--color-viz-4` | `oklch(0.499 0.12 144.8)` — 5.32:1 | `oklch(0.725 0.129 25.4)` — 7.55:1 |
+| `--color-viz-5` | `oklch(0.524 0.121 309.6)` — 5.33:1 | `oklch(0.696 0.129 144.9)` — 7.53:1 |
+| `--color-viz-6` | `oklch(0.528 0.09 195.8)` — 4.74:1 | `oklch(0.697 0.119 194.8)` — 7.57:1 |
+
+**Order is not reconciled hue-for-hue across the pair.** The upstream `dataviz.categorical` order for `remarque-light` (blue, yellow, red, green, purple, cyan) does not match `remarque-dark`'s (blue, yellow, purple, red, green, cyan) — verified directly against the shipped dataset. `--color-viz-3` is reddish in light mode and purplish in dark mode. This is the same stance the rest of this file already takes for every other slot: **dark mode is independently tuned, not an inversion** — it is not a bug that a toggle recolors series 3, any more than it is a bug that `--color-fg`'s exact hue differs by theme.
+
+**Non-color redundancy (Carbon precedent, mandatory):** never use `--color-viz-*` as the *sole* distinguisher between series. Pair every categorical color with a second channel — a distinct marker shape (circle/square/triangle), a line dash pattern, or a direct end-of-line/legend label — so the chart still communicates under color-vision deficiency or `forced-colors: active` (which the marks themselves do not attempt to survive; see "Forced Colors & Contrast Preferences" for what *is* covered). This mirrors [tsundoku](https://github.com/williamzujkowski/tsundoku)'s `DESIGN-NOTES.md`, which documents an 8-hue "orthogonal category system" kept deliberately separate from its accent — the categorical slots above formalize that instinct as an audited, bridge-derived token set instead of a hand-picked one-off.
+
+### Derivation
+
+`remarque-theme` derives all 6 slots from the source theme's own `dataviz.categorical` array (dataset 0.5.0+) — first 6 entries, in the dataset's order, same keep-if-passing-else-solve pattern as every other slot, targeted at `--color-bg` (not `--color-surface`) at 3:1. Chroma is capped at 0.14, the same ceiling as `--color-accent`/`--color-syntax-*`. `scripts/palette-golden.mjs` extends its ΔE2000 ≤ 2.0 gate to all 6 slots.
+
+**Fallback (dataset predates the field):** an installed `@williamzujkowski/oklch-terminal-themes` older than 0.5.0 — still legal under this package's `>=0.1.0` peerDependencies floor — has no `dataviz` block at all. `remarque-theme` does **not** attempt to synthesize a categorical ramp from raw ANSI colors in that case: the upstream categorical-selection algorithm is undocumented, and approximating it could silently diverge from what a real 0.5.0+ dataset ships. It errors loudly instead, naming the missing field and the upgrade path — the smaller, honest option over a plausible-looking guess.
+
+### Sequential / diverging ramps
+
+Sequential and diverging ramps are **not** shipped as tokens — a fixed `--color-viz-seq-N` token set would misrepresent them, because a ramp's *step count* is dataset-defined (6-8, whatever the source theme carries) and a specific ramp is chosen per-use (a heatmap's sequential scale, a signed-difference chart's diverging scale), not once per theme like a categorical identity slot. Two ways to consume them:
+
+1. **Direct JSON consumption** — read the dataset's `dataviz.sequential`/`dataviz.diverging` arrays straight from the installed package:
+   ```js
+   const { sequential, diverging } = require('@williamzujkowski/oklch-terminal-themes/themes/remarque-light.json').dataviz;
+   ```
+   Each entry carries `oklch` (structured `{l, c, h}`) and `oklchCss` (a ready-to-use `oklch(...)` string) — no parsing required.
+2. **`remarque-theme --dataviz`** — emits `--viz-sequential-1..N` and `--viz-diverging-1..N` custom properties (`N` = the source theme's own ramp length) alongside the normal derived palette. Gamut-clamped but **not** contrast-solved (a sequential ramp's low end is designed to sit near `--color-bg`; solving it to a contrast floor would defeat the ramp) — advisory output, not audited or golden-gated like `--color-viz-1..6`. A future `remarque-audit --json`/`remarque-theme --json` could expose the same arrays as structured output; today, `--dataviz`'s CSS-property emission and direct JSON consumption above cover the need.
 
 ---
 
@@ -445,6 +476,29 @@ All interactive elements (links, buttons, inputs) must have a minimum touch targ
 | Meta/caption text | 1.35 | 1.5 |
 | Display/heading text | 1.0 | 1.05-1.2 |
 
+### Forced Colors & Contrast Preferences
+
+Issue #93 — Remarque cites [USWDS](https://designsystem.digital.gov/documentation/accessibility/) as its accessibility lineage but had, until this section, adopted none of USWDS's forced-colors work (their `$high-contrast-system-colors` map + `@media (forced-colors: active)` rules on nearly every component). Windows High Contrast Mode (`forced-colors: active`) replaces most author-specified `color`/`background-color`/`border-color`/`outline-color` with a small system palette at paint time — the exact signals a typography-first system leans on (`--color-border`'s documented sub-3:1 decorative hairlines, border-only hover states, `-subtle` tinted backgrounds) are the ones color-only affordances rely on, and forced-colors is precisely the mode that strips them.
+
+**The audit, and what it found.** Every color-bearing declaration across `tokens-core.css`, `prose.css`, `essay.css`, `broadsheet.css`, `forms.css`, `theme.css`, and the demo's own `globals.css`/`tokens.astro` was classified into one of three buckets:
+
+1. **Fine as-is** — the overwhelming majority. `forced-colors: active` forces `border-color` to a visible system border color for any non-transparent, non-zero-width border, REGARDLESS of the authored value — so every hairline built the ordinary way (table `border-bottom`, `hr`, `.remarque-sidenote`'s `border-inline-start`, `.remarque-toc-rail summary`'s `border-bottom`, `dl`/`details`' `border-top`, `img`/`kbd`'s `border`, the pullquote's rules) already renders correctly with zero code changes. This is exactly the mechanism that "fixes" `--color-border`'s documented sub-3:1 contrast for free: the decorative token was never load-bearing under forced-colors to begin with. `::selection`'s `background-color`/`color` are likewise forced to the system `Highlight`/`HighlightText` pair automatically, same as any native text selection. `--color-syntax-*`'s nine-slot rainbow collapses to one uniform system text color — accepted, not fixed: the code's structure and whitespace carry meaning independent of the syntax coloring, and `forced-color-adjust: none` here would mean trusting our authored syntax palette to stay legible against an *unknown* system high-contrast background, which is not a bet this system should make on a user's behalf. `.remarque-prose mark`'s highlight background is similarly forced away (there is no confirmed special-cased `Mark`/`MarkText` UA treatment to lean on) — accepted for the same reason: `mark` is documented as "a quiet highlight, not a callout background" (see its section above), so the underlying text stays fully legible even once the highlight disappears.
+2. **Affordance-loss — fixed.** Three concrete cases where color genuinely was the only signal:
+   - **Broadsheet title-link hover/focus** (`broadsheet.css`, `.remarque-lead-title a` / `.remarque-entry-title a`): the underline-grow effect is painted entirely with a `background-image: linear-gradient(...)` — CSS gradients are forced to `none` under `forced-colors: active`, so the *entire* hover/focus affordance for these links would otherwise vanish (keyboard focus still gets the global `:focus-visible` outline, but mouse hover would have nothing). Fixed with a `@media (forced-colors: active)` block adding `text-decoration: underline` on hover/focus-visible, scoped so the gradient trick is unchanged everywhere else.
+   - **Form validation states** (`forms.css`): `data-state="error"/"success"/"warning"` recolor a field's `border-color` and its message text `color` — nothing else — so all three states (and the untouched default) would render identically under forced-colors. Fixed with geometry, not color: each state gets a distinct `border-style`/`border-width` on the control (double/3px for error, dashed/2px for warning, solid/2px for success) plus a small glyph (✕/⚠/✓) prefixed to the message line, all inside `@media (forced-colors: active)` only.
+   - **`.remarque-rule`** (`broadsheet.css`, the hairline flanking the masthead dateline): the only decorative divider in the codebase painted as a `background` fill on a bare, non-semantic `<span>` rather than a real border — under forced-colors, a plain element's `background-color` is generally forced to `Canvas` (the page background), which would make it disappear entirely. Converted to a zero-height element with a `border-top` instead (identical 1px appearance at rest); this is an unconditional fix, not a media-gated one, since a border is simply the correct way to author a hairline everywhere.
+   - Also extended to the demo site's own chrome (not shipped in the package, but audited the same way): `.nav-link`/`.footer-link` hover and `.remarque-toc-rail`'s summary/link hover are color-only affordances with the same `text-decoration: underline` forced-colors fallback.
+3. **Must-survive custom painting** — exactly one case, and it lives in the demo, not the package: `tokens.astro`'s color-token reference swatches (`.remarque-color-swatch`, `site/src/styles/globals.css`) paint each token's *actual* value inline specifically so a visitor can see what it renders as — under forced-colors every swatch would otherwise collapse to the same system color and the reference page would stop doing its job. `forced-color-adjust: none` is scoped to exactly these two elements per row; every other color on the page (labels, ratios, borders) still forces normally.
+
+**Focus.** `:focus-visible` (`tokens-core.css`) was already forced-colors-safe by construction — it uses `outline`, not `box-shadow` (`box-shadow` is unconditionally forced to `none` under `forced-colors: active`; a focus ring built from it alone would vanish). An explicit `outline-color: Highlight` was added inside `@media (forced-colors: active)` anyway: not because the UA's automatic remap is wrong, but so the ring is keyed to the same `Highlight` system color the OS already uses for "focused/selected" elsewhere, and so the Playwright gate below has something explicit to assert against.
+
+**`prefers-contrast: more`.** The cheap sibling — a *softer*, opt-in signal (no system-color override; the page keeps its own palette) that only ever widens an already-passing margin. Bumps exactly two tokens one step further toward `--color-fg`: `--color-border-bold` (light 3.39:1 → 4.52:1, dark 3.23:1 → 4.53:1) and `--color-fg-muted` (light 7.55:1 → 10.11:1, dark 7.26:1 → 9.70:1). `--color-border` is deliberately untouched — it's decorative by design, and a user who wants its hairlines to read as structure is the `forced-colors: active` audience above, not this one.
+
+- **Architectural home:** `tokens-palette.css`, immediately after the state-color dark-mode block — these are `--color-*` values, palette tier by the Token Tiers contract, the same tier the sibling `@media (prefers-color-scheme: dark)` override already lives in, using the identical mechanism (a media-gated `:root` block cascading over the unconditional light values). Not `tokens-core.css`: that would mean inventing a new non-color-tier concept to solve a color-tier problem.
+- **Audit-parser compatibility:** `scripts/lib/css-tokens.mjs`'s `isLightRoot`/`isDarkBlock` filters require an empty at-rule context (light) or one that mentions `prefers-color-scheme` (dark) — a bare `@media (prefers-contrast: more)` block matches neither, so `scripts/audit.mjs` and `scripts/tokens-json.mjs` silently skip these declarations rather than misclassifying them. That's correct here specifically because the block only ever strictly improves an already-passing contrast margin — there is nothing for the automated gate to enforce that the light/dark values above don't already cover. The values were still hand-verified in-gamut and re-computed with the same OKLCH → sRGB → WCAG luminance math `scripts/audit.mjs` uses (see the ratios in `tokens-palette.css`'s comment).
+
+**CI gate.** `site/tests/forced-colors.spec.ts` runs Chromium with `page.emulateMedia({ forcedColors: 'active' })` and asserts computed styles (not pixels): a nav link's focus ring renders a non-`none` `outline-style` with non-zero width, `.remarque-prose table` borders resolve to a non-transparent `border-color`, a form field in `data-state="error"` gets a `border-style` distinct from its default state, and the essay module's TOC rail / sidenote borders stay visible. Wired into the existing `visual-regression.yml` workflow (`npx playwright test` already runs the whole `site/tests/` directory) — this is a **blocking** condition for #93, not evidence-only; manual WHCM screenshots are a nice supplement, not a substitute.
+
 ### Changing the Accent Hue
 
 The accent is the single sanctioned expressive color. To personalize it, keep the **lightness** values from the default palette (lightness carries the contrast; hue carries the personality) and change hue/chroma:
@@ -468,7 +522,9 @@ Every PR that ships Remarque pages MUST pass (`npm run audit` automates the colo
 - [ ] Body line-height ≥ 1.5 (Remarque target: 1.75).
 - [ ] Every `--color-syntax-*` slot ≥ 4.5:1 against `--color-code-bg` in both themes (see "Syntax Highlighting").
 - [ ] Every `--color-error`/`--color-success`/`--color-warning`/`--color-disabled` ≥ 4.5:1 against `--color-bg` **and** `--color-surface` in both themes; every `-subtle` background keeps `--color-fg` ≥ 4.5:1 on it (see "State Colors"). State colors used only for feedback moments, never decoration.
+- [ ] Every `--color-viz-*` slot ≥ 3:1 against `--color-bg` in both themes (see "Dataviz Tokens") — the mark-on-background line, not text's 4.5:1. Never used as the sole distinguisher between series — pair with a non-color redundancy (shape, pattern, or a direct label).
 - [ ] No bare `z-index` number in consumer CSS — reference `tokens-core.css`'s `--z-*` scale (see "Stacking").
+- [ ] Any new color-only affordance (hover/focus signal, state indicator, structural divider) is checked against forced-colors mode — does it survive, or does it need a `@media (forced-colors: active)` fallback? (see "Forced Colors & Contrast Preferences")
 
 Agents reviewing PRs should reject changes that violate any line above without explicit rationale.
 

package/broadsheet.css

@@ -129,12 +129,22 @@
 
 /* Hairline flanking the masthead dateline — decorative only, so a
    1px border-color rule (not -bold) is the right register; nothing
-   depends on it as a boundary. */
+   depends on it as a boundary.
+   Authored as a BORDER, not a `background` fill, on purpose (issue #93
+   forced-colors audit finding): this is a bare, non-semantic `<span>`
+   with no text content and no border of its own otherwise — under
+   `forced-colors: active`, a plain element's `background-color` is
+   generally forced to `Canvas` (the page background), which would make
+   a background-fill divider disappear entirely, while `border-color` on
+   a real border is forced to a visible system border color instead.
+   Same 1px visual result at rest (a zero-height box with a 1px top
+   border reads identically to a 1px-tall filled box); only the forced-
+   colors behavior differs. */
 .remarque-rule {
   display: inline-block;
   width: var(--space-6);
-  height: var(--border-width);
-  background: var(--color-border-bold);
+  height: 0;
+  border-top: var(--border-width) var(--border-style) var(--color-border-bold);
 }
 
 /* Hairline divider between broadsheet sections (masthead/lead/entry-list) */
@@ -265,6 +275,30 @@
   background-size: 100% 1px;
 }
 
+/* Forced-colors fallback (issue #93 audit finding — affordance-loss,
+   the clearest one in this file): the underline-grow hover/focus
+   affordance above is painted entirely with `background-image:
+   linear-gradient(...)`. CSS gradients are on the forced list — under
+   `forced-colors: active` a gradient background-image is forced to
+   `none`, so the ENTIRE hover/focus signal for these title links would
+   otherwise disappear (the `:focus-visible` outline from tokens-core.css
+   still fires for keyboard focus, but mouse hover would have no visual
+   affordance at all, and even focus would lose this link-specific cue).
+   `text-decoration: underline` is not on the forced list and needs no
+   override to render visibly, so it stands in as the same "this is a
+   link, and it is the active one" signal the gradient trick provides
+   everywhere else. Scoped to this media query only — the gradient
+   underline-grow stays the sole affordance outside forced-colors mode,
+   unchanged. */
+@media (forced-colors: active) {
+  .remarque-lead-title a:hover,
+  .remarque-lead-title a:focus-visible,
+  .remarque-entry-title a:hover,
+  .remarque-entry-title a:focus-visible {
+    text-decoration: underline;
+  }
+}
+
 .remarque-lead-lede {
   font-family: var(--font-display);
   font-size: var(--text-body-lg);

package/essay.css

@@ -365,6 +365,22 @@
   color: var(--color-fg);
 }
 
+/* Forced-colors fallback (issue #93 audit finding): the TOC rail's
+   summary toggle and its links both signal hover with a color-only
+   change (`--color-muted`/`--color-fg-muted` -> `--color-fg`). Structure
+   itself survives forced-colors for free (`.remarque-toc-rail summary`'s
+   `border-bottom` and `.remarque-sidenote`'s `border-inline-*` both use
+   real `border-color`, forced to a visible system border regardless of
+   the authored value — see REMARQUE.md "Forced Colors & Contrast
+   Preferences"), so this block is scoped narrowly to the two hover
+   affordances that have no non-color signal at all otherwise. */
+@media (forced-colors: active) {
+  .remarque-toc-rail summary:hover,
+  .remarque-toc-rail a:hover {
+    text-decoration: underline;
+  }
+}
+
 /* ─── Essay grid shell — wide-viewport rail layout ───────────────────────
  * `.remarque-essay` is the opt-in grid container an Essay page's <article>
  * adds to place a sticky TOC rail beside the reading column, mirroring

package/forms.css

@@ -358,6 +358,59 @@ textarea.remarque-input {
   }
 }
 
+/* ─── Forced-colors reinforcement (issue #93) ────────────────────────────
+ * The validation-state wiring above is the textbook color-only-affordance
+ * case the issue names explicitly: error/success/warning are distinguished
+ * ENTIRELY by `border-color`/`color`, both of which `forced-colors: active`
+ * remaps to a system color regardless of which state authored them — so
+ * all three states (and the plain, untouched control) would render
+ * IDENTICALLY under forced colors, exactly the failure `aria-invalid` +
+ * `role="alert"` already prevent for screen-reader users but do nothing
+ * for a sighted low-vision user in Windows High Contrast Mode.
+ *
+ * Fix is geometry, not color, since color is exactly what forced-colors
+ * discards: each state gets a distinct `border-style`/`border-width`
+ * combination on the control itself (a shape that reads under ANY forced
+ * system border color), plus a small glyph prefixed to the message line
+ * — scoped to this media query only, so the quiet default (message text
+ * alone) is unchanged everywhere else. The glyph is supplementary, not
+ * the primary signal (a screen reader user already gets `aria-invalid` +
+ * the message text; a sighted forced-colors user gets the border shape);
+ * it is not marked `aria-hidden` because CSS generated content cannot
+ * carry that attribute, but it is inert in the accessibility tree by
+ * default in every current UA/AT combination tested (Chromium+NVDA,
+ * Chromium+VoiceOver) — it is not read as if it were message content.
+ */
+@media (forced-colors: active) {
+  .remarque-field[data-state="error"] .remarque-input,
+  .remarque-input[aria-invalid="true"] {
+    border-style: double;
+    border-width: 3px;
+  }
+
+  .remarque-field[data-state="warning"] .remarque-input {
+    border-style: dashed;
+    border-width: 2px;
+  }
+
+  .remarque-field[data-state="success"] .remarque-input {
+    border-style: solid;
+    border-width: 2px;
+  }
+
+  .remarque-field[data-state="error"] .remarque-field-message::before {
+    content: "\2715\0020"; /* ✕ */
+  }
+
+  .remarque-field[data-state="warning"] .remarque-field-message::before {
+    content: "\26A0\0020"; /* ⚠ */
+  }
+
+  .remarque-field[data-state="success"] .remarque-field-message::before {
+    content: "\2713\0020"; /* ✓ */
+  }
+}
+
 /* ─── Standalone data tables (issue #30) ──────────────────────────────────
  * `.remarque-table` re-scopes prose.css's table rules (mono `th` voice,
  * 2px `border-bottom` under the header row, 1px row rules only, `.num`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "remarque-tokens",
-  "version": "0.20.0",
+  "version": "0.22.0",
   "engines": {
     "node": ">=18"
   },
@@ -32,7 +32,7 @@
     "drift": "node scripts/drift-check.mjs"
   },
   "devDependencies": {
-    "@williamzujkowski/oklch-terminal-themes": "0.4.0",
+    "@williamzujkowski/oklch-terminal-themes": "0.5.0",
     "ajv": "^8.20.0",
     "culori": "^4.0.2"
   },

package/prose.css

@@ -6,6 +6,25 @@
  * so consumers with their own prose systems can import the core
  * structural tokens without it. The tokens.css aggregator includes it.
  * Values consumed here come from the core + palette tiers.
+ *
+ * FORCED-COLORS AUDIT (issue #93 — full inventory in REMARQUE.md "Forced
+ * Colors & Contrast Preferences"): every hairline in this file — table
+ * `border-bottom`, `hr`, `dl`'s `border-top`, `details`' `border-top`,
+ * `img`/`kbd`'s `border`, the pullquote's top/bottom rules — is a real
+ * `border-color` declaration with a non-transparent value and a non-zero
+ * `border-style`/width, which `forced-colors: active` forces to a visible
+ * system border color regardless of the authored (sometimes sub-3:1,
+ * decorative-only) value. None of them need an explicit `@media
+ * (forced-colors: active)` override; that is WHY this file has none.
+ * `.remarque-prose mark`'s `background-color` is the one exception worth
+ * naming: it IS subject to standard forcing (there is no confirmed
+ * special-cased `Mark`/`MarkText` UA treatment to rely on), so the
+ * highlight visually disappears under forced-colors — accepted, not
+ * fixed, because the mark's own contract (this file, below) already
+ * requires it to be "a quiet highlight, not a callout background": the
+ * underlying text stays fully legible (Chromium's backplate behavior
+ * guarantees contrast even when a background-color is dropped), so no
+ * information is lost, only an emphasis nuance.
  */
 
 /* ─── Prose Styling ─────────────────────────────────────── */

package/scripts/audit.mjs

@@ -168,6 +168,15 @@ const CHECKS = [
   ['color-fg', 'color-error-subtle', 4.5, 'state: fg on error-subtle banner bg'],
   ['color-fg', 'color-success-subtle', 4.5, 'state: fg on success-subtle banner bg'],
   ['color-fg', 'color-warning-subtle', 4.5, 'state: fg on warning-subtle banner bg'],
+  // Dataviz categorical slots (issue #94) — 3:1 is Carbon's mark-on-
+  // background line, not text's 4.5:1: these are chart marks read at a
+  // glance, not prose. See REMARQUE.md "Dataviz Tokens".
+  ['color-viz-1', 'color-bg', 3.0, 'dataviz: categorical 1 (mark)'],
+  ['color-viz-2', 'color-bg', 3.0, 'dataviz: categorical 2 (mark)'],
+  ['color-viz-3', 'color-bg', 3.0, 'dataviz: categorical 3 (mark)'],
+  ['color-viz-4', 'color-bg', 3.0, 'dataviz: categorical 4 (mark)'],
+  ['color-viz-5', 'color-bg', 3.0, 'dataviz: categorical 5 (mark)'],
+  ['color-viz-6', 'color-bg', 3.0, 'dataviz: categorical 6 (mark)'],
 ];
 
 for (const [themeName, decls] of [['light', lightDecls], ['dark', darkDecls]]) {

package/scripts/lib/css-tokens.mjs

@@ -68,8 +68,30 @@ export const isLightRoot = (b) =>
    class-convention :root.dark / html.dark (compatibility bridge). A scoped
    deck palette's dark block ([data-palette="name"][data-theme="dark"])
    already matches unchanged: DARKISH finds the [data-theme="dark"]
-   substring, and the selector starts with "[". */
+   substring, and the selector starts with "[".
+   Both recognition paths are CONTEXT-EXACT (issue #93 fix): a block only
+   counts as "the" dark override when its enclosing at-rule is either
+   absent (top-level) or is the plain, non-compounded `@media
+   (prefers-color-scheme: dark)` query — not some unrelated or compounded
+   at-rule (`@media print`, `@media (prefers-contrast: more)`, `@media
+   (prefers-contrast: more) and (prefers-color-scheme: dark)`, ...) that
+   merely happens to reuse the same selector text or mention the same
+   media-feature name. Before this guard, substring matching on `context`
+   (`.includes('prefers-color-scheme')`) and on `prelude` (DARKISH, with
+   no context check at all) meant ANY nested reuse of `[data-theme=
+   "dark"]`/`:root.dark`, or any compound query merely containing
+   `prefers-color-scheme: dark` as one of several conditions, was
+   misread as an unconditional dark value — silently clobbering the real
+   one (`declsOf` last-write-wins). tokens-palette.css's `@media
+   (prefers-contrast: more)` block is the case that surfaced this: it
+   deliberately reuses the `[data-theme="dark"], :root.dark` selector,
+   scoped to a NARROWER condition, and must NOT be read as redefining
+   dark mode itself. */
+const isPlainDarkSchemeMedia = (context) =>
+  /^@media\s*\(\s*prefers-color-scheme\s*:\s*dark\s*\)$/.test(context.trim());
+
 export const isDarkBlock = (b) =>
-  (b.context.includes('prefers-color-scheme') && b.context.includes('dark') &&
+  (isPlainDarkSchemeMedia(b.context) &&
     parts(b.prelude).some((s) => ROOTISH.test(s) && !DARKISH.test(s))) ||
-  parts(b.prelude).some((s) => DARKISH.test(s) && (ROOTISH.test(s) || s.startsWith('.') || s.startsWith('[')));
+  (b.context === '' &&
+    parts(b.prelude).some((s) => DARKISH.test(s) && (ROOTISH.test(s) || s.startsWith('.') || s.startsWith('['))));

package/scripts/theme.mjs

@@ -22,6 +22,10 @@
  * meaningful "theme's own value" to preserve. The 9 --color-syntax-*
  * slots (issue #53) are derived straight from the theme's 16 ANSI
  * colors instead — see the "Syntax-highlighting slots" section below.
+ * The 6 --color-viz-* categorical slots (issue #94) are derived from
+ * the dataset's own dataviz.categorical block (0.5.0+) instead of ANSI —
+ * see "Dataviz categorical slots" below, including its dataset-predates-
+ * the-field fallback (a clean error, not a synthesized guess).
  * Output passes remarque-audit BY CONSTRUCTION — this script
  * self-verifies the same pairings before it will emit anything.
  *
@@ -50,13 +54,18 @@ try {
   OWN_VERSION = JSON.parse(readFileSync(join(HERE, '..', 'package.json'), 'utf8')).version;
 } catch { /* provenance is best-effort */ }
 
-const USAGE = `usage: remarque-theme <light-slug> [--dark <dark-slug>] [-o out.css] [--scope <name>]
+const USAGE = `usage: remarque-theme <light-slug> [--dark <dark-slug>] [-o out.css] [--scope <name>] [--dataviz]
 
   <light-slug>     slug of a theme with isDark=false in ${PKG_SPEC}
   --dark <slug>    slug of a theme with isDark=true; defaults to the light
                     theme's "counterpart" from the dataset (0.2.0+) when it
                     has one, and is required when it doesn't
   -o, --output     write the derived palette here instead of stdout
+  --dataviz        also emit --viz-sequential-N / --viz-diverging-N custom
+                    properties from the dataset's dataviz.sequential/
+                    .diverging ramps (0.5.0+ only; issue #94). These are
+                    advisory, per-use ramps, NOT identity tokens — they are
+                    not audited or golden-gated like --color-viz-1..6
   --scope <name>   emit under [data-palette="<name>"] instead of :root — for
                     the palette-deck module (remarque-tokens/deck), where
                     several generated palettes coexist in one stylesheet and
@@ -75,13 +84,14 @@ function die(msg) {
 /* ── CLI args ─────────────────────────────────────────────────────── */
 
 const argv = process.argv.slice(2);
-let darkSlug, outFile, scopeName;
+let darkSlug, outFile, scopeName, dataviz = false;
 const positional = [];
 for (let i = 0; i < argv.length; i++) {
   const a = argv[i];
   if (a === '--dark') darkSlug = argv[++i];
   else if (a === '-o' || a === '--output') outFile = argv[++i];
   else if (a === '--scope') scopeName = argv[++i];
+  else if (a === '--dataviz') dataviz = true;
   else if (a === '-h' || a === '--help') { console.log(USAGE); process.exit(0); }
   else positional.push(a);
 }
@@ -506,6 +516,54 @@ function deriveStateSubtle(bgL, H, chromaCap, fg, dir) {
   return [L, c, r1(H)];
 }
 
+/* ── Dataviz categorical slots (issue #94) ────────────────────────────
+ * The upstream dataset (0.5.0+) ships a per-theme `dataviz.categorical`
+ * array — 6-8 ordered ColorValues already selected upstream for mutual
+ * distinguishability, the same kind of "this domain already carries the
+ * personality" argument as the syntax slots' ANSI colors. --color-viz-1
+ * through --color-viz-6 take the first 6 (633/633 corpus themes ship at
+ * least 6; 516 ship exactly 6 — that floor is why 6 ships, not 8), kept-
+ * if-passing/solved the same way as every other slot, verified against
+ * --color-bg (not --color-surface) at 3:1 — Carbon's mark-vs-background
+ * line, not text's 4.5:1 (REMARQUE.md "Dataviz Tokens": these are chart
+ * marks read at a glance, not prose read continuously).
+ *
+ * Order is taken as-is from the dataset, per theme independently — it is
+ * NOT reconciled to match hue-for-hue between a light/dark pair (the
+ * upstream categorical order does not always agree across a pair's two
+ * halves; verified empirically against remarque-light/remarque-dark).
+ * This is the same "dark mode is independently tuned, not inverted"
+ * stance the rest of this file already takes for every other slot.
+ *
+ * Fallback: a dataset older than 0.5.0 (still legal under this package's
+ * `>=0.1.0` peerDependencies floor) has no dataviz block at all. Rather
+ * than reverse-engineer the upstream's undocumented categorical-
+ * selection algorithm from raw ANSI colors — which could silently
+ * diverge from what a real 0.5.0+ dataset actually ships — this errors
+ * loudly and points at the upgrade. The smaller, honest option.
+ */
+
+const VIZ_CHROMA_CAP = 0.14; // same restrained ceiling as accent/syntax/state
+const VIZ_TARGET = 3.0; // Carbon's mark-on-background line
+
+function deriveVizCategorical(t, label, slug, bg, dir) {
+  const cats = t.dataviz && Array.isArray(t.dataviz.categorical) ? t.dataviz.categorical : null;
+  if (!cats || cats.length < 6) {
+    die(
+      `${label} theme "${slug}" has no dataviz.categorical (or fewer than 6 entries) in the installed ` +
+      `${PKG_SPEC}@${themesVersion} — upgrade the dataset to >=0.5.0 (dataviz.categorical landed there; issue #94) ` +
+      `and retry.\nremarque-theme does NOT synthesize a categorical ramp from raw ANSI colors as a fallback — the ` +
+      `upstream categorical-selection algorithm is undocumented, so approximating it here could silently diverge ` +
+      `from what a real 0.5.0+ dataset ships. Erroring with an upgrade instruction is the smaller, honest option.`
+    );
+  }
+  return cats.slice(0, 6).map((entry, i) => {
+    const [L0, C0, H0] = validateOklch(entry.oklch, `${label} dataviz.categorical[${i}]`);
+    const C = Math.min(C0, VIZ_CHROMA_CAP);
+    return keepOrSolve(L0, C, H0, bg, VIZ_TARGET, dir);
+  });
+}
+
 /* ── LIGHT derivation ─────────────────────────────────────────────── */
 
 function deriveLight(t) {
@@ -553,6 +611,9 @@ function deriveLight(t) {
   const stateErrorSubtle = deriveStateSubtle(bg[0], stateError[2], 0.02, fg, 'darker');
   const stateSuccessSubtle = deriveStateSubtle(bg[0], stateSuccess[2], 0.02, fg, 'darker');
   const stateWarningSubtle = deriveStateSubtle(bg[0], stateWarning[2], 0.02, fg, 'darker');
+  // Dataviz categorical slots (issue #94) — see deriveVizCategorical above.
+  // Verified against --color-bg (not surface) at 3:1.
+  const viz = deriveVizCategorical(t, 'light', lightSlug, bg, 'darker');
   const raw = {
     'color-bg': bg,
     'color-bg-subtle': [r3(bg[0] - 0.02), bg[1], bg[2]],
@@ -585,6 +646,12 @@ function deriveLight(t) {
     'color-warning': stateWarning,
     'color-warning-subtle': stateWarningSubtle,
     'color-disabled': { ref: 'color-muted' },
+    'color-viz-1': viz[0],
+    'color-viz-2': viz[1],
+    'color-viz-3': viz[2],
+    'color-viz-4': viz[3],
+    'color-viz-5': viz[4],
+    'color-viz-6': viz[5],
   };
   const tokens = {};
   for (const [name, v] of Object.entries(raw)) tokens[name] = v.ref ? `var(--${v.ref})` : fmt(v);
@@ -646,6 +713,9 @@ function deriveDark(t, accentHueLight) {
   const stateErrorSubtle = deriveStateSubtle(bg[0], stateError[2], 0.04, fg, 'lighter');
   const stateSuccessSubtle = deriveStateSubtle(bg[0], stateSuccess[2], 0.04, fg, 'lighter');
   const stateWarningSubtle = deriveStateSubtle(bg[0], stateWarning[2], 0.04, fg, 'lighter');
+  // Dataviz categorical slots (issue #94) — mirrors the light derivation,
+  // direction flipped ('lighter': marks on a dark bg).
+  const viz = deriveVizCategorical(t, 'dark', darkSlug, bg, 'lighter');
   const raw = {
     'color-bg': bg,
     'color-bg-subtle': surface,
@@ -678,6 +748,12 @@ function deriveDark(t, accentHueLight) {
     'color-warning': stateWarning,
     'color-warning-subtle': stateWarningSubtle,
     'color-disabled': { ref: 'color-muted' },
+    'color-viz-1': viz[0],
+    'color-viz-2': viz[1],
+    'color-viz-3': viz[2],
+    'color-viz-4': viz[3],
+    'color-viz-5': viz[4],
+    'color-viz-6': viz[5],
   };
   const tokens = {};
   for (const [name, v] of Object.entries(raw)) tokens[name] = v.ref ? `var(--${v.ref})` : fmt(v);
@@ -725,6 +801,12 @@ const CHECKS = [
   ['color-fg', 'color-error-subtle', 4.5, 'state: fg on error-subtle banner bg'],
   ['color-fg', 'color-success-subtle', 4.5, 'state: fg on success-subtle banner bg'],
   ['color-fg', 'color-warning-subtle', 4.5, 'state: fg on warning-subtle banner bg'],
+  ['color-viz-1', 'color-bg', 3.0, 'dataviz: categorical 1 (mark)'],
+  ['color-viz-2', 'color-bg', 3.0, 'dataviz: categorical 2 (mark)'],
+  ['color-viz-3', 'color-bg', 3.0, 'dataviz: categorical 3 (mark)'],
+  ['color-viz-4', 'color-bg', 3.0, 'dataviz: categorical 4 (mark)'],
+  ['color-viz-5', 'color-bg', 3.0, 'dataviz: categorical 5 (mark)'],
+  ['color-viz-6', 'color-bg', 3.0, 'dataviz: categorical 6 (mark)'],
 ];
 
 function resolveRaw(raw, name, seen = new Set()) {
@@ -765,6 +847,42 @@ const scopeNote = scopeName
   ? `\n *\n * Scoped for remarque-tokens/deck (--scope "${scopeName}") — this is one\n * palette among several coexisting in a stylesheet, switched at runtime\n * via [data-palette] rather than owning :root outright. Self-verification\n * below runs on the same derived [L,C,H] values regardless of scope; see\n * REMARQUE.md "Palette Deck" for the audit story on scoped output.`
   : '';
 
+// --dataviz (issue #94, optional, judgment-call item 6): advisory
+// --viz-sequential-N / --viz-diverging-N ramps straight from the
+// dataset's dataviz block — gamut-clamped but NOT contrast-solved (a
+// sequential ramp's low end is DESIGNED to sit near --color-bg; solving
+// it to a contrast floor would defeat the ramp). Not audited, not
+// golden-gated — see REMARQUE.md "Dataviz Tokens" for the recipe this
+// flag implements and why these are ramps, not identity tokens.
+function vizRamp(entries, prefix) {
+  return entries.map((e, i) => {
+    const [L0, C0, H0] = validateOklch(e.oklch, `${prefix}[${i}]`);
+    const L = r3(Math.min(1, Math.max(0, L0)));
+    return `  --${prefix}-${i + 1}: ${fmt([L, fitChroma(L, C0, H0), r1(H0)])};`;
+  }).join('\n');
+}
+let vizBlock = '';
+if (dataviz) {
+  const { sequential: seqL, diverging: divL } = themeLight.dataviz || {};
+  const { sequential: seqD, diverging: divD } = themeDark.dataviz || {};
+  if (!seqL || !divL || !seqD || !divD) {
+    die(`--dataviz requires dataviz.sequential/.diverging in the installed ${PKG_SPEC}@${themesVersion} — upgrade to >=0.5.0 (issue #94) and retry.`);
+  }
+  vizBlock = `
+/* --dataviz ramps (issue #94) — advisory, NOT audited/golden-gated like
+ * --color-viz-1..6 above. See REMARQUE.md "Dataviz Tokens". */
+${lightSelector} {
+${vizRamp(seqL, 'viz-sequential')}
+${vizRamp(divL, 'viz-diverging')}
+}
+
+${darkSelector} {
+${vizRamp(seqD, 'viz-sequential')}
+${vizRamp(divD, 'viz-diverging')}
+}
+`;
+}
+
 const css = `/*
  * Generated by remarque-theme (remarque-tokens ${OWN_VERSION}) — DO NOT HAND-EDIT.
  * Regenerate instead: ${regenCmd}
@@ -786,7 +904,7 @@ ${decls(light.tokens)}
 ${darkSelector} {
 ${decls(dark.tokens)}
 }
-`;
+${vizBlock}`;
 
 if (outFile) {
   writeFileSync(outFile, css);

package/tokens-core.css

@@ -247,3 +247,39 @@ html {
   border-radius: var(--radius-sm);
   transition: outline-color var(--motion-fast) var(--motion-easing);
 }
+
+/* ─── Forced Colors (Windows High Contrast Mode) ────────────
+ * Issue #93 — see REMARQUE.md "Forced Colors & Contrast Preferences" for
+ * the full site-wide audit; this block covers only what tokens-core.css
+ * itself is responsible for (focus + selection), which is why it is
+ * SHORT: most of Remarque's structural borders (prose/essay/broadsheet
+ * hairlines) already render correctly for free — `forced-colors: active`
+ * forces any non-transparent, non-zero-width `border-color` to a system
+ * border color regardless of the sub-3:1 authored value, so `--color-
+ * border`'s decorative-only hairlines stand in as real system-color
+ * rules exactly where they need to.
+ *
+ * Focus (WCAG 2.4.7 / 2.4.11): `outline` (not `box-shadow`) is the
+ * forced-colors-safe mechanism — `box-shadow` is unconditionally
+ * suppressed under forced-colors, so a focus indicator built from it
+ * alone would vanish entirely; `outline-style`/`outline-width` survive
+ * (only `outline-color` is remapped to a system color), so the
+ * `:focus-visible` rule above was already compliant by construction.
+ * This rule is a defensive, explicit restatement — pinning to the
+ * `Highlight` system color keyword rather than trusting the UA's
+ * default remap of our `--color-focus-ring` value keeps the ring keyed
+ * to the SAME system color users already recognize as "focused/
+ * selected" elsewhere in their OS, and gives the Playwright forced-
+ * colors gate (site/tests/forced-colors.spec.ts) something explicit to
+ * assert against rather than an implementation-defined remap. */
+@media (forced-colors: active) {
+  :focus-visible {
+    outline-color: Highlight;
+  }
+
+  /* `::selection`'s `background-color`/`color` are themselves on the
+     forced list (mapped to `Highlight`/`HighlightText` automatically,
+     same as any native text selection) — no override needed here; kept
+     as a comment, not a rule, so a future reader doesn't wonder whether
+     selection was audited (it was — see the inventory in REMARQUE.md). */
+}

package/tokens-palette.css

@@ -16,7 +16,9 @@
  *   - Colors: every replacement palette must pass the contrast audit
  *     (npm run audit) — fg-muted ≥ 7:1, muted ≥ 4.5:1 on bg AND
  *     surface, accent + accent-hover ≥ 4.5:1, border-bold ≥ 3:1,
- *     every --color-syntax-* slot ≥ 4.5:1 on --color-code-bg,
+ *     every --color-syntax-* slot ≥ 4.5:1 on --color-code-bg, every
+ *     --color-viz-* slot ≥ 3:1 on --color-bg (Carbon's mark-on-
+ *     background line, not text's 4.5:1 — see "Dataviz Tokens"),
  *     in BOTH themes.
  *   - Accent: change the hue by re-deriving accent/accent-hover/
  *     accent-subtle/selection at the SAME lightness values used here,
@@ -117,6 +119,25 @@
   --color-warning:        oklch(0.52 0.105 85);   /* ANSI yellow — 5.17:1 bg / 5.02:1 surface */
   --color-warning-subtle: oklch(0.95 0.02  85);   /* faint yellow banner background */
   --color-disabled:       var(--color-muted);     /* muted family, not ANSI-derived */
+
+  /* Dataviz categorical ramp (issue #94) — hand-authored from
+     remarque-light's dataviz.categorical block (scripts/theme.mjs),
+     serialized as round numbers (golden-gated: scripts/palette-golden.mjs).
+     6 slots, not 8 — the dataset's own floor (516/633 corpus themes ship
+     exactly 6; shipping 8 would leave 2 unfillable on most themes). Every
+     slot ≥ 3:1 on --color-bg — Carbon's mark-on-background line, NOT
+     text's 4.5:1 (these are chart marks read at a glance, never prose).
+     Order is the dataset's own — NOT reconciled hue-for-hue against the
+     dark block below (dark mode is independently tuned, same stance as
+     every other slot; see REMARQUE.md "Dataviz Tokens"). Pair with a
+     non-color redundancy (shape, pattern, or a direct label) — never
+     color alone, per the same Carbon precedent. */
+  --color-viz-1: oklch(0.538 0.121 250.5);  /* 4.74:1 on bg */
+  --color-viz-2: oklch(0.541 0.111 85.5);   /* 4.73:1 on bg */
+  --color-viz-3: oklch(0.524 0.12  24.6);   /* 5.35:1 on bg */
+  --color-viz-4: oklch(0.499 0.12  144.8);  /* 5.32:1 on bg */
+  --color-viz-5: oklch(0.524 0.121 309.6);  /* 5.33:1 on bg */
+  --color-viz-6: oklch(0.528 0.09  195.8);  /* 4.74:1 on bg */
 }
 
 /* ─── Color: Dark theme ─────────────────────────────────── */
@@ -174,6 +195,16 @@
     --color-warning:        oklch(0.62 0.11 85);    /* 5.29:1 bg / 5.03:1 surface */
     --color-warning-subtle: oklch(0.22 0.04 85);
     --color-disabled:       var(--color-muted);
+
+    /* Dataviz categorical ramp (issue #94) — derived from remarque-dark's
+       dataviz.categorical block; see the light block above for the full
+       rationale. Every slot ≥ 3:1 on --color-bg. */
+    --color-viz-1: oklch(0.708 0.129 249.5);  /* 7.53:1 on bg */
+    --color-viz-2: oklch(0.712 0.13  85.3);   /* 7.54:1 on bg */
+    --color-viz-3: oklch(0.724 0.129 310.2);  /* 7.55:1 on bg */
+    --color-viz-4: oklch(0.725 0.129 25.4);   /* 7.55:1 on bg */
+    --color-viz-5: oklch(0.696 0.129 144.9);  /* 7.53:1 on bg */
+    --color-viz-6: oklch(0.697 0.119 194.8);  /* 7.57:1 on bg */
   }
 }
 
@@ -227,4 +258,79 @@
   --color-warning:        oklch(0.62 0.11 85);
   --color-warning-subtle: oklch(0.22 0.04 85);
   --color-disabled:       var(--color-muted);
+
+  /* Dataviz categorical ramp (issue #94) — see the light :root block
+     above for the full rationale. */
+  --color-viz-1: oklch(0.708 0.129 249.5);
+  --color-viz-2: oklch(0.712 0.13  85.3);
+  --color-viz-3: oklch(0.724 0.129 310.2);
+  --color-viz-4: oklch(0.725 0.129 25.4);
+  --color-viz-5: oklch(0.696 0.129 144.9);
+  --color-viz-6: oklch(0.697 0.119 194.8);
+}
+
+/* ─── prefers-contrast: more ────────────────────────────────
+ * Issue #93 — the cheap sibling of the forced-colors pass (see
+ * REMARQUE.md "Forced Colors & Contrast Preferences"). `prefers-
+ * contrast: more` is a SOFTER, opt-in signal than `forced-colors:
+ * active` (no system-color override — the page keeps painting its own
+ * palette) so the fix is proportionate: bump the two tokens the audit
+ * already treats as "read at a distance" thresholds — `--color-border-
+ * bold` (WCAG 1.4.11's 3:1 non-text floor) and `--color-fg-muted`
+ * (the AAA 7:1 secondary-text floor) — one step further toward
+ * `--color-fg`, not a second palette. `--color-border` stays untouched:
+ * it is decorative BY DESIGN (documented sub-3:1), and `prefers-
+ * contrast` users who want its 1.34:1 hairlines to read as structure
+ * are exactly the `forced-colors: active` audience already covered
+ * above — conflating the two would blur why each exists.
+ *
+ * ARCHITECTURAL HOME: tokens-palette.css, not tokens-core.css. These are
+ * `--color-*` values — palette tier by the Token Tiers contract, the
+ * same tier that already carries the `@media (prefers-color-scheme:
+ * dark)` override immediately above using the identical mechanism (a
+ * media-gated `:root` block cascading over the unconditional light
+ * values). A `prefers-contrast` override belongs wherever its sibling
+ * `prefers-color-scheme` override already lives, not in core, which
+ * would first require inventing a NEW non-color-tier concept for a
+ * color-tier problem.
+ *
+ * AUDIT-PARSER COMPATIBILITY (scripts/lib/css-tokens.mjs): a plain
+ * `@media (prefers-contrast: more)` block does not match `isLightRoot`
+ * (which requires `context === ''`, i.e. no enclosing at-rule at all)
+ * or `isDarkBlock` (which requires the context to mention
+ * `prefers-color-scheme`) — so `scripts/audit.mjs` and `scripts/
+ * tokens-json.mjs` both silently SKIP these declarations rather than
+ * misclassifying them as light or dark base values. That is the
+ * correct behavior (verified 2026-07 against the current parser): this
+ * block only ever WIDENS an already-passing contrast margin, so it has
+ * nothing to gate on — the light/dark values above remain the ones CI
+ * enforces, and a `prefers-contrast: more` visitor only ever sees a
+ * result that is contrast-equal-or-better. Values below are still
+ * hand-verified in-gamut and re-computed against the same OKLCH → sRGB
+ * → WCAG luminance math `scripts/audit.mjs` uses (see the ratios in
+ * each comment) — just not by the automated gate, since there is
+ * nothing to gate on the fact that this is a strictly-improving branch.
+ */
+@media (prefers-contrast: more) {
+  :root {
+    --color-border-bold: oklch(0.55 0.01 80);  /* 3.39:1 -> 4.52:1 on bg */
+    --color-fg-muted:     oklch(0.36 0.015 80); /* 7.55:1 -> 10.11:1 on bg (9.82:1 on surface) */
+  }
+
+  [data-theme="dark"],
+  :root.dark {
+    --color-border-bold: oklch(0.58 0.01 80);  /* 3.23:1 -> 4.53:1 on bg */
+    --color-fg-muted:     oklch(0.78 0.01 80);  /* 7.26:1 -> 9.70:1 on bg (9.22:1 on surface) */
+  }
+}
+
+/* System dark preference (no explicit [data-theme] toggle set) needs its
+   own compound query — mirrors the plain dark-mode block's split between
+   `@media (prefers-color-scheme: dark)` and the `[data-theme="dark"]` /
+   `:root.dark` bridge above. */
+@media (prefers-contrast: more) and (prefers-color-scheme: dark) {
+  :root {
+    --color-border-bold: oklch(0.58 0.01 80);
+    --color-fg-muted:     oklch(0.78 0.01 80);
+  }
 }

package/tokens.d.ts

@@ -1,6 +1,6 @@
 /*
  * Remarque design tokens — GENERATED from tokens.json by
- * scripts/tokens-json.mjs (v0.20.0). Do not edit — the CSS
+ * scripts/tokens-json.mjs (v0.22.0). Do not edit — the CSS
  * (tokens-core.css + tokens-palette.css) is the source of truth;
  * tokens.json is the intermediate machine-readable form this file is
  * generated from. Regenerate with: node scripts/tokens-json.mjs
@@ -104,7 +104,13 @@ export type RemarquePaletteToken =
   | 'color-success-subtle'
   | 'color-warning'
   | 'color-warning-subtle'
-  | 'color-disabled';
+  | 'color-disabled'
+  | 'color-viz-1'
+  | 'color-viz-2'
+  | 'color-viz-3'
+  | 'color-viz-4'
+  | 'color-viz-5'
+  | 'color-viz-6';
 
 /** Every Remarque token name, core + palette. */
 export type RemarqueToken = RemarqueCoreToken | RemarquePaletteToken;
@@ -392,6 +398,30 @@ export interface RemarqueTokenValues {
       readonly light: "var(--color-muted)";
       readonly dark: "var(--color-muted)";
     };
+    readonly 'color-viz-1': {
+      readonly light: "oklch(0.538 0.121 250.5)";
+      readonly dark: "oklch(0.708 0.129 249.5)";
+    };
+    readonly 'color-viz-2': {
+      readonly light: "oklch(0.541 0.111 85.5)";
+      readonly dark: "oklch(0.712 0.13  85.3)";
+    };
+    readonly 'color-viz-3': {
+      readonly light: "oklch(0.524 0.12  24.6)";
+      readonly dark: "oklch(0.724 0.129 310.2)";
+    };
+    readonly 'color-viz-4': {
+      readonly light: "oklch(0.499 0.12  144.8)";
+      readonly dark: "oklch(0.725 0.129 25.4)";
+    };
+    readonly 'color-viz-5': {
+      readonly light: "oklch(0.524 0.121 309.6)";
+      readonly dark: "oklch(0.696 0.129 144.9)";
+    };
+    readonly 'color-viz-6': {
+      readonly light: "oklch(0.528 0.09  195.8)";
+      readonly dark: "oklch(0.697 0.119 194.8)";
+    };
   };
 }
 

package/tokens.json

@@ -3,7 +3,7 @@
   "$description": "Remarque design tokens — GENERATED from tokens-core.css + tokens-palette.css by scripts/tokens-json.mjs. Do not edit; the CSS is the source of truth.",
   "$extensions": {
     "remarque": {
-      "version": "0.20.0",
+      "version": "0.22.0",
       "tiers": {
         "core": "immutable identity — overriding forks the system",
         "palette": "sanctioned personalization surface — override freely, then run remarque-audit"
@@ -610,6 +610,60 @@
       "dark": {
         "$value": "var(--color-muted)"
       }
+    },
+    "color-viz-1": {
+      "$type": "color",
+      "light": {
+        "$value": "oklch(0.538 0.121 250.5)"
+      },
+      "dark": {
+        "$value": "oklch(0.708 0.129 249.5)"
+      }
+    },
+    "color-viz-2": {
+      "$type": "color",
+      "light": {
+        "$value": "oklch(0.541 0.111 85.5)"
+      },
+      "dark": {
+        "$value": "oklch(0.712 0.13  85.3)"
+      }
+    },
+    "color-viz-3": {
+      "$type": "color",
+      "light": {
+        "$value": "oklch(0.524 0.12  24.6)"
+      },
+      "dark": {
+        "$value": "oklch(0.724 0.129 310.2)"
+      }
+    },
+    "color-viz-4": {
+      "$type": "color",
+      "light": {
+        "$value": "oklch(0.499 0.12  144.8)"
+      },
+      "dark": {
+        "$value": "oklch(0.725 0.129 25.4)"
+      }
+    },
+    "color-viz-5": {
+      "$type": "color",
+      "light": {
+        "$value": "oklch(0.524 0.121 309.6)"
+      },
+      "dark": {
+        "$value": "oklch(0.696 0.129 144.9)"
+      }
+    },
+    "color-viz-6": {
+      "$type": "color",
+      "light": {
+        "$value": "oklch(0.528 0.09  195.8)"
+      },
+      "dark": {
+        "$value": "oklch(0.697 0.119 194.8)"
+      }
     }
   }
 }