Hold the site to the accessibility rules the design system already states

[iderex]

The design system the site publishes makes specific accessibility commitments. No
state depends on hue alone. Focus is visible and carries a ring of a stated
width. Motion respects a reduced-motion preference. Colour-vision presets are
offered rather than a single accessible colour, on the argument that the useful
hue depends on which cone type is missing.

The site itself is the first thing anyone reads those commitments on, and it
currently gets some of them right by hand. Hand-correct is not the same as
checked, and the site is the worst place for the design system to be wrong,
because it is the document making the promise.

What is worth checking here rather than asserting: contrast ratios for the text
and background pairs in every theme and preset combination the page offers,
focus visibility on every interactive element, and that the interactive elements
are reachable and operable from the keyboard alone.

The combinations multiply, which is the argument for a check rather than a
review pass. Two brightness modes times five colour-vision presets is ten
palettes, and nobody re-reads ten palettes after a colour tweak.

Done when

A named leg checks contrast for every theme and preset combination the page
offers and reds below the stated threshold, keyboard operation of every
interactive element is covered by a test that runs headless, and a deliberately
lowered contrast value reds the check. Machine-decidable.

[iderex]

The preset half of this is done and merged. #90 adds
focus-stands-off-every-surface, a leg of the gate that judges forty
combinations of docs/design-tokens.json: the accent against ground, raise
and raise-2 in both schemes for all five presets, plus primary ink over the
soft accent. It was watched refusing the light tritan accent lightened by one
step, and the output is in that pull request.

Two parts of the done-condition are not met, and this is what stands in front of
each.

The text pairs do not come out clean

The tertiary ink misses 4.5:1 against every surface, in both schemes. Against
docs/design-tokens.json at cf74ef2, with a script that reads the file and
computes the WCAG ratio:

cat > /tmp/ink.py <<'PY'
import json
t = json.load(open("docs/design-tokens.json", encoding="utf-8"))["surface"]["tokens"]
rgb = lambda h: [int(h[i:i+2], 16) / 255 for i in (1, 3, 5)]
lin = lambda c: c / 12.92 if c <= 0.04045 else ((c + 0.055) / 1.055) ** 2.4
lum = lambda c: sum(k * lin(v) for k, v in zip((.2126, .7152, .0722), rgb(c)))
def ratio(a, b):
    a, b = sorted((lum(a), lum(b)), reverse=True)
    return (a + .05) / (b + .05)
for scheme in ("dark", "light"):
    for ink in ("ink", "ink-2", "ink-3"):
        for bg in ("ground", "raise", "raise-2"):
            r = ratio(t[ink][scheme]["srgb"], t[bg][scheme]["srgb"])
            print("%-5s %-5s on %-7s %5.2f:1  %s" % (scheme, ink, bg, r, "" if r >= 4.5 else "UNDER 4.5"))
PY
python /tmp/ink.py

dark  ink   on ground  15.85:1
dark  ink   on raise   14.38:1
dark  ink   on raise-2 12.73:1
dark  ink-2 on ground   6.87:1
dark  ink-2 on raise    6.23:1
dark  ink-2 on raise-2  5.52:1
dark  ink-3 on ground   3.71:1  UNDER 4.5
dark  ink-3 on raise    3.37:1  UNDER 4.5
dark  ink-3 on raise-2  2.98:1  UNDER 4.5
light ink   on ground  18.47:1
light ink   on raise   19.27:1
light ink   on raise-2 16.93:1
light ink-2 on ground   5.70:1
light ink-2 on raise    5.95:1
light ink-2 on raise-2  5.23:1
light ink-3 on ground   3.11:1  UNDER 4.5
light ink-3 on raise    3.25:1  UNDER 4.5
light ink-3 on raise-2  2.86:1  UNDER 4.5

The 4.5 figure is the one for text below the large-text boundary, which is
18.66px bold or 24px regular. Nothing rendered in the tertiary ink is anywhere
near it. Every use on the published page, with the size it is painted at:

grep -n 'var(--ink3)' docs/design-system.html

61:  color:var(--ink3)}                     .eyebrow, 10.5px
85:.sw .v{...font-size:10.5px;...}          the hex under each swatch
92:.row .tag{...font-size:10.5px;...}       the type-scale labels
114:.tsub{font-size:11.5px;...}             year and runtime under a tile
131:.fcap{...font-size:12px;...}            the focus row's captions
140:  color:var(--ink3);font-weight:500}    table headers, 10.5px
147:footer{...font-size:13.5px}             the footer

Run 2026-08-09 at cf74ef2.

Why this is not a value I can just move. Raising the tertiary ink to 4.5:1
against raise-2, which is the closest surface and therefore the worst case,
lands it at #8C8C9A dark and #6D6D73 light. That puts it at 5.64:1 on the
dark ground against the secondary ink's 6.87:1, and 4.92:1 on the light ground
against the secondary's 5.70:1. The three-step ink scale becomes a two-step one
with a decorative third entry, and the type scale is built on those three steps
being distinguishable. Which of the two goes is a change to the system rather
than a correction to a number, so the check landed judging the pairs a preset
moves and left these alone. The leg's own package comment says it does not reach
them, so a green is not read as covering them.

Keyboard operation has nothing to run in

Deciding whether every interactive element is reachable and operable from the
keyboard needs the page rendered and its script executed. The page's arrow-key
handling is in the inline <script> and there is no way to reach it from a Go
test.

That is the needs-browser requirement of the harness, and nothing carries the
tag:

go run . harness

needs-browser   no check carries it yet; it reaches a real render of the
                site: the numbers in the speed budget, focus behaviour, the
                accessibility rules judged against what a browser actually
                paints

Run 2026-08-09 at c75b020. Writing the first check under that tag means a
browser driver, which would be the first entry in a dependency set go.sum does
not exist for. decisions/means.md is where that is argued and
CONTRIBUTING.md spends a section on the set being empty, so it is a choice
somebody takes rather than one a check quietly makes.

Also worth knowing before that is attempted: the done-condition asks for a test
that runs headless, and a browser render under the harness is headless. Those
are compatible. What is not compatible is the gate, which
decisions/headless-and-unelevated.md keeps free of anything needing a browser,
so this half will report from a job somebody asks for rather than from a merge.