Putting WCAG where the code gets written

A lot of software is now written by agents, which means the place people spend their working day has quietly moved. It is not the design tool and increasingly not the IDE. It is a terminal, a prompt, and whatever the model can reach at the moment it generates.

That relocation is the whole problem and the whole opportunity. Accessibility guidance that lives in a PDF, a wiki or a senior person's head is not present at the moment code is written. So it does not affect the code. The fix is not better documentation. It is putting the guidance where the work now happens, in a form the thing doing the work can read.

Four pieces of that, all open source.

WCAG in the statusline

a11y-tips-statusline (opens in a new tab) puts all 87 WCAG 2.2 success criteria — Level A, AA and AAA — into the Claude Code statusline, rotating one every thirty seconds, with a /wcag command to search them. One line to install.

The premise is deliberately modest: nobody reads the spec, but people do read the thing at the bottom of their terminal, several hundred times a day. Ambient exposure is not a substitute for expertise. It is very good at the specific job of making someone recognize a criterion later, when it matters.

Two details I would point at, because they are the difference between a toy and a tool. The tips word-wrap to the statusline width so they stay clear of Claude Code's own right-hand messages. And when the terminal is under 120 columns, the tip is replaced by a prompt to widen the window, rather than being silently cut off. Silent truncation is how most statusline tools fail, and it is the kind of failure that hurts exactly the people this is for.

It is my most-starred repository, which tells me something about how much appetite there is for this and how little of it exists.

WCAG as something an agent can query

wcag-mcp-server (opens in a new tab) is a local server over the WCAG 2.2 criteria, speaking the Model Context Protocol — the convention by which a coding assistant reaches a source of information it does not carry itself. It works with Claude Code, Cursor, VS Code Copilot and anything else that speaks it.

It searches by keyword, by criterion number, by conformance level, and in plain language. "Color blind" expands to the criteria that actually govern it. That is the query a person types; it is not the one the spec is indexed for.

The statusline is for the human. This is for the model. An agent that can look up criterion 1.4.3 while it writes does not have to guess. An agent that guesses at accessibility requirements produces confident, plausible, wrong markup, at a speed no reviewer can keep up with.

Contrast enforcement inside a coding agent

Atomic (opens in a new tab) is an open-source coding agent runtime by Bastani.ai that turns an engineering process into explicit, checkable execution graphs. I contribute accessibility to it, so far on the interactive theme, in three passes:

A WCAG contrast helper with a report-only baseline. Report-only on purpose. Turning a new gate on hard, in a project you do not own, breaks other people's builds on day one and teaches them to resent the gate. Measure first, publish the number, let it be uncomfortable, then tighten.

Then the correction that mattered: measure the rendered foreground and background pairs rather than an artificial canvas. A terminal theme is not a set of colors in a file. It is what the terminal actually paints, once a palette, an opacity, a dim attribute and a background have been layered together. The gap between what the file says and what the eye receives is exactly where contrast failures hide.

Then a committed baseline artifact, so the measurement is a checked-in fact a change has to argue with rather than a number someone ran once.

A terminal is a user interface, and it has readers with low vision. That is barely being said anywhere, in a category of tooling about eighteen months old that is setting conventions right now.

The cockpit

Separately, I have been building my own control surface for running many agents across several projects at once. It began as something I called a harness. It is now atomic-cockpit (opens in a new tab), built on Atomic, with herdr managing sessions and Ghostty as the terminal.

It does one thing carefully: you say what you want built, an agent writes a plan, and nothing happens until a person approves it. Then it hires the agents the job actually needs, so a small job gets a small team. They build, and they talk to each other. Then a different agent, one that did not write the code, checks the result against the plan's checks. Around that sit the parts that make a team of agents legible to one person. What each agent is saying to the others. A board of work in flight. A roster of who is hired, and on what.

The case study (opens in a new tab) documents a real run rather than a demo. Nine checks, all passing, verified by an agent that did not write the code, then reviewed by a person. Fourteen minutes from approval to proof. One dollar ninety-eight. It also turned up a bug in one of the cockpit's own tabs, which I left in the write-up, because a tool that only ever demonstrates success is not being tested. The screenshots were taken every two seconds while it happened. There is a commit in the history titled "describe the screenshots accurately instead of retouching them."

Why these are one piece of work

The approval gate and the contrast baseline come from the same instinct.

As generation speeds up, the gap widens between what got built and what anyone actually verified. Everything above is a bet that the answer is not to slow generation down. It is to make verification cheap, visible and explicitly someone's job. An agent that did not write the code. A plan with checks attached. A person who has to say yes before anything starts. A contrast number committed to the repository.

Accessibility work is that same bet aimed at a different gap: the distance between software that technically runs and software a particular person can actually use.

Where this goes

Agent tooling is young enough that its conventions are still soft. Keyboard behavior, focus, contrast, how a long-running job announces that it finished: all of it is being decided right now. Mostly by people who have not been asked to think about it, in projects that would take a patch from someone who turned up with one.

So I intend to keep turning up, and to keep publishing the tools rather than the opinions. The accessibility of what we build everything else with is not a niche concern. It decides who gets to do the building.