Accessibility statement

Built into the design

Text and surface pairs come from one semantic token system, and inverted panels (hero bands, the footer, proof sheets) reference theme-stable tokens so a dark panel stays dark in the dark theme instead of inverting into pale-on-pale text. Contrast for every shipped token pair is computed against the WCAG relative-luminance formula rather than eyeballed, including the translucent edges that tell you a rectangle is fillable — those are composited over the surface they sit on before the ratio is measured, because a hairline border is only ever seen through its background. Interactive surfaces carry their own `--control-edge` token for that reason instead of borrowing the decorative hairline. Every custom property the sheets read is also checked for a declaration: a token that is used but never set is discarded at computed-value time, which is how a theme ends up painting inherited colours in only one mode, and no build step notices.

Every interactive control has a visible focus state, primary and mobile navigation regions are separately labelled, exactly one `main` landmark is rendered per page, and a skip link lands on the content region. The mobile drawer traps focus, closes on Escape, and is marked inert while closed so its links leave the tab order.

Motion is opt-out: the pointer-reactive tilt and parallax layers disable under `prefers-reduced-motion` and can be forced off in workspace preferences. Nothing on the site communicates state with color alone — freshness, verification, and publication states are labelled in words.

Workbench behaviour

Inputs carry visible labels, invalid input explains what to change instead of failing silently, errors render in an alert region, and results render in a polite live region so a completed run is announced. Multi-line inputs provide line numbers, character counts, Tab that indents, and a size read-out so a truncated paste is visible rather than silently wrong.

The command palette opens with Command K or Control K anywhere and is operated with arrow keys, Enter, and Escape. Search suggestions, keyboard selection, and recent searches run locally; the bare-key “/” trigger can be switched off in workspace preferences, which is the escape hatch WCAG 2.1.1 asks for on single-character shortcuts.

Because every published page is server-rendered, its content is reachable without JavaScript and identical for an assistive technology reading the initial document, a crawler, and a visitor on a slow connection.

What has been checked here

The accessibility rules are code, not prose. `pnpm a11y:audit` crawls every route the site renders and checks the server-produced document: language, one `main`, skip link, heading order, page titles, duplicate ids, accessible names, label association, `autocomplete` on identity fields, label-in-name for controls, live regions, image alternatives, `rel` on external links, whether every data table is named and every scrollable region labelled, and whether the viewport can be zoomed. It then measures the design system itself — every text and non-text token pair in both themes, the focus and reduced-motion declarations across the whole stylesheet cascade, and the declared size of every control against the 24-pixel target minimum — and writes the result to `docs/ACCESSIBILITY-AUDIT.md`, including a coverage table that names which WCAG 2.2 AA criteria are automated, which are implemented but not machine-decidable, and which need a person.

The command exits non-zero when a checked rule regresses, so a claim on this page cannot quietly outlive the code that supports it; the same rules also run as unit tests against the shipped theme sheets. The arithmetic is pinned with the WCAG worked example (a mid-grey `#767676` on white measures 4.54:1, and one step darker at `#777777` fails), so a change to the formula cannot silently make the audit look greener than the site.

Around that, automated tests hold the rest of the claims honest: a truth-contract suite fails if global copy, pricing benefits, or an entitlement flag states something the software does not do, a taxonomy suite fails if the catalog is presented as more than twelve exclusive registry families, and live-data ceilings are asserted equal to the number the rate limiter enforces. Design workbenches preview only values their own runtime produced, matched against an explicit shape, so a preview can never be painted from unvalidated content.

What has not been verified

The audit above is automated. It cannot decide meaning: it checks names, order, contrast and sizes, not whether a sentence is understandable or whether a result is announced in a way that makes sense. The manual half is therefore published as a protocol rather than a result: `docs/ACCESSIBILITY-MANUAL-PASS.md` names the ten routes in the sample, the six runs (screen-reader reading order, keyboard-only focus visibility, reflow and zoom, text spacing, target sizes, and error recovery), the exact expected output each run is compared against, and an empty results table. That table is still empty. No third-party accessibility audit and no formal assistive-technology pass has been completed for this release, so the implemented behaviour and in-repository checks described above are not an externally certified conformance level, and no WCAG 2.2 AA conformance claim is made.

Known gaps we have not closed: long result tables such as amortization schedules are horizontally scrolled rather than reflowed on narrow viewports; the palette result list has not been tested for announcement behaviour with a screen reader; the registry index deliberately keeps all published records in one document, which is a long traversal; and generated documents are markup, not tagged PDF.

Where a barrier is confirmed, it is treated as more urgent than a new workbench. Reports should name the route, the assistive technology and browser, and what failed to be reachable — that is enough to reproduce and fix it.

This statement was last reviewed on 16 September 2026.