Accessibility

What is enforced, not just intended

The build fails if any token misses the threshold it claims. That is the difference between an accessibility statement and an accessibility guarantee: this page cannot describe a passing system unless the system passes, because the same function produces both the gate and these tables.

The contrast matrix

Every text and UI token against every surface it could be placed on — including combinations the system does not currently use, because the question a person adopting this asks is "can I put X on Y", not "did you". Ratios are for the active theme; switch it and the numbers change.

Each cell states its ratio as text. The dot is redundant reinforcement — remove it and the table still says everything it needs to.

Focus

The focus ring is the one signal in the system that is never subtle. It uses a dedicated token checked against every surface it can land on rather than just the page canvas — a ring that clears 3:1 on the canvas and fails on a raised panel is not a passing ring.

Focus management rules

• Focus is never removed, only restyled. outline: none without a replacement is the single most damaging line in a stylesheet.
• Order follows the DOM. No positive tabindex anywhere — it creates an order nobody can predict from reading the markup.
• Anything that traps focus restores it. The Modal returns focus to the element that opened it, after making the page interactive again. Restoring while the trigger is still inert silently fails.
• Roving tabindex for composites. Tab reaches a tab list once; arrows move within it.
• Nothing steals focus on load. Not the search field, not a tab, not a toast.

Motion policy

Every animation resolves to its end state under prefers-reduced-motion, never to a shortened version. The theme flip is never animated at all. The full argument, with demonstrations, is on Motion.

Keyboard contract

How this is verified

Against the built output, not the dev server, on every page of this site:

• axe-core, WCAG 2.1 A and AA — every route × both themes × 375/768/1440, plus the states that only exist after interaction: modal open, playground toggled, sidebar drawer open, islands hydrated.
• Open states are audited separately, because a closed dialog is display: none and axe skips it entirely — passing there proves nothing.
• The keyboard contracts are driven in a browser, not asserted. Tab cycles counted, Escape pressed, focus target checked after close.
• No-flash is proved under the opposite OS preference, so a pass means the stored choice won rather than the default happening to match.
• Zero horizontal overflow, exactly one <h1>, no console errors.

What is not claimed

This has not been tested with real assistive technology users, which is the only test that finds the problems automated checking cannot. axe catches perhaps a third of WCAG issues in practice; the rest need a human. Halbton is a concept project, and saying it is "accessible" full stop would be exactly the kind of unearned claim the rest of this site is built to avoid.

What is true: every published colour pairing is measured and enforced at build time, every interactive component has a keyboard contract exercised in a browser, and every page passes axe in both themes at three viewports.