Contrast & WCAG conformance

Every contractual token pairing, the WCAG 2.1 level it is held to, and its measured sRGB ratio per theme. Generated from the resolved token model (tokens/resolved.json) so it cannot drift from the palette, and gated: npm run check fails if any pairing drops below its floor.

Guaranteed level

• Body / UI text pairings are guaranteed WCAG 2.1 AA — 4.5:1 (1.4.3). This covers --text, --text-soft, --text-dim, --accent-text, neutral text on soft accent-tint components, and the primary-button label.
• Non-text UI (focus ring, accent fill, status colour) is guaranteed 3:1 (1.4.11 non-text contrast / the large-text bar). These are deliberately not held to 4.5:1 — a focus ring is a UI boundary, not body copy, and WCAG agrees.
• Hairlines (--line, --line-strong) are a deliberate identity choice and are reported but not gated: WCAG 1.4.11 exempts decorative borders that are not the sole identifier of a control. Where a boundary must be perceivable, the forced-colors / data-contrast="high" paths re-assert it (see theming.md). The low hairline ratio is published here on purpose — hiding it would defeat the point of a gate.
• AAA (7:1) is not guaranteed; the high-contrast preset (data-contrast="high" / prefers-contrast: more) raises ratios further but is out of scope for this gated baseline.

Translucent foregrounds (soft fills) are alpha-flattened over their background before measuring. When a translucent background is a component tint, the table names the neutral base it is composited over.

Overall: all contractual pairings meet their floor ✅.

Light theme

Dark theme

Display colorways (skins)

The opt-in data-bronto-skin colorways (@ponchia/ui/css/skins.css, authored in tokens/skins.js) re-point the one accent to a different single hue. Because a shipped colorway is part of the framework — not an arbitrary consumer re-brand — its accent is gated to the same floors as the core: the primary-button label, accent-as-text, and the focus ring/accent fill. Only the accent-touching pairings are shown (a skin leaves the canvas and status palette untouched). Accents are authored in OKLCH; --accent-text is the color-mix-derived --accent-strong, exactly as in the core palette.

Amber CRT — light

Amber CRT — dark

E-ink — light

E-ink — dark

Phosphor Green — light

Phosphor Green — dark

Data-viz palette (advisory)

The opt-in Tier-4 categorical palette (@ponchia/ui/css/dataviz.css, authored in tokens/charts.js) is gated differently: each slot sits inside the theme's OKLCH lightness band and above the chroma floor, and adjacent slots stay apart under simulated protanopia/deuteranopia and in normal vision (check:charts, OKLab ΔE). Colour is never the sole signal — each series ships a matching --chart-pattern-* dot-matrix fill. So the WCAG ratios below are advisory (a chart fill is not body text); for thin lines, points or text use the slot's --cat-N-ink, which check:charts holds to 4.5:1. No slot is the accent.

Light theme — categorical vs --bg

Dark theme — categorical vs --bg

Scope & caveats

• This gates the framework token contract (core palette and every shipped colorway), not arbitrary consumer re-brands. Re-accenting via --accent yourself is your contrast obligation (see Re-brand obligations); this table is the guarantee for the shipped palettes and skins only.
• Status colours (--success / --warning / --danger) are gated as indicators (3:1). If you set status text as body copy on a surface, verify 4.5:1 yourself or pair it with an icon/label.
• The gated Ratio is sRGB WCAG 2.1 AA — the testable legal / axe-compatible baseline the e2e suite also asserts. The APCA column (APCA-W3 0.1.9 Lc) is advisory only: a perceptual cross-check that, unlike WCAG 2.1's symmetric ratio, accounts for polarity and is the WCAG 3 candidate. It does not gate the build while WCAG 3 is a Working Draft — use it to tune quality, not to override the WCAG 2.1 floor. As a rough read, body text wants Lc ≥ 75 and non-text/large ≥ 45–60.