01 · The Problem
An interface can pass the test and still block someone
Current interfaces accumulate animation, custom-made components, content that only appears with JavaScript and mouse-designed interactions. Each layer is a place where the keyboard, screen reader or zoom may fail without which the developing person notices.
What existed before
Fact Before the work described here, the site already ran the axe — an open engine testing a page against WCAG's automated rules, the W3C accessibility guidelines — CI, the system that performs the tests automatically at each change. But only on 14 of the 41 pages, and without WCAG 2.2 criteria.
When the measurement began to cover all the pages, on the production build (the compiled version that goes on air), found 207 occurrences in 36 pages, about 128 of them text with contrast below the minimum. Reading the code still found problems that no automatic rule pointed out. Example: a modal of cookies that was announced as a modal for the screen reader, but did not focus on it.
Evidence: initial audit (accessibility-audit.md), find G-01 · commit a5ef956.
Where the AI enters
Fact By 2026-10-05, 162 of the 352 commits of the repository register co-authorship of a Claude model (161 of the 265 that are not of merge). All the commits of the accessibility work, except those of merge, have this co-authorship, with the models Sonnet 5.5 and Opus 5.5, via Claude Code. Configuration stays in folder .claude/ from the repository.
To reproduce: git log da61b0a --format=%H%n%B and count commits with the line Co-Authored-By: Claude.
Inference An agent produces what context requires. If the context does not speak of focus, contrast or screen reader, nothing guarantees that the code will handle it. Hence the premise of the work: the accessibility requirement needs to be in the context that guides the agent, and not only in a review later. This premise was not measured in this project; it justified the decision of the next section.