Skip to main content

Accessibility is where 'looks done' and 'is done' come apart

Sergi Sánchez Mancha

AI collapsed the cost of producing software that looks finished. A component that renders, a page that lays out correctly, a form you can fill in and submit: all of that is now close to free to generate. What it did not lower is the cost of the thing being correct underneath, in the places a quick look does not reach. For most kinds of code those two costs used to move together, because the effort of making something look right was roughly the effort of making it work. AI broke that link. Looking done and being done are now separately priced, and the gap between them is where the interesting failures live.

Accessibility is the property where that gap is widest, and there is a concrete reason why. A model generates the visual layer, the HTML and CSS a person sees. It does not generate the layer assistive technology actually reads: the accessibility tree, the structure of roles, names, and states that a screen reader and the operating system's accessibility API consume. Those two outputs are only loosely coupled, and nothing on the visual side forces the other to be right. A container wired up with a click handler looks like a button and passes every glance a human gives it, while the accessibility tree records nothing a keyboard or screen reader user can reach. The cheap correctness AI now produces in abundance, the kind that survives a look, is precisely the kind that says nothing about the layer accessibility lives in.

Cross-section diagram of two layers. The top layer is a smooth carpet-like surface marked with a green check mark and labelled "What the eye sees — looks finished." Directly beneath it, hidden under the surface, is a raised lump marked with an X. The bottom layer is a recessed, hatched grey slab labelled "What assistive tech reads — the accessibility tree." The visible surface looks complete while the defect sits concealed in the layer underneath.

So it is worth taking seriously that this year the measured accessibility of the web went backwards. WebAIM tests the top million home pages every February, and for six years the error rate drifted slowly downward. This year it reversed: 95.9% of pages failed a check, up from 94.8%, with about ten percent more errors per page than the year before. WebAIM names several causes, and one of them is worth pausing on, because it is the plausibility trap in miniature. Misused ARIA was up. ARIA is the vocabulary you use to describe a control to the accessibility tree, and a model reaching for it produces attributes that read as diligent and frequently make things worse: a role="button" on something that still cannot be focused, an aria-hidden that quietly removes real content from a screen reader while leaving it visible on screen. It scans as accessibility work. It registers on a linter as an attribute present. It can leave a disabled user worse off than the plain markup would have. WebAIM also names, in its own words, "automated or AI-assisted coding practices." You do not need to settle the exact share to see the shape of it: the reversal lands in the year the cost of plausible code fell furthest, in the property where plausible tells you the least.

Why the tooling didn't catch it

The obvious objection is that this was also the year the industry put accessibility inside the coding loop. Editor plugins, MCP servers, agents that notice a missing label as you work: help arrived in the place code is written, at scale, for the first time. If the tools were there, why did the number climb anyway?

Because most of that help operates at the same layer as the problem, and the very smoothness of the loop is part of why it fails. When an inline assistant flags an issue and offers a one-click fix, the cheapest way to clear the warning is to accept the suggestion, and the suggestion is an edit to the same visual layer that was already convincing. The label goes green. Almost nobody then presses Tab to check that focus actually moves where the fix implies, because the workflow never asked them to and the tool already said it was handled. Frictionless feedback produces frictionless acceptance, and an ARIA attribute accepted to clear a warning is not the same event as a control a keyboard user can operate. A suggestion nobody confirmed leaves the same trace on the shipped page as a suggestion never made. The tooling made the awareness of accessibility cheap, which is real progress, but awareness sits on the plausible side of the divide. It does not, on its own, buy back the correctness that the cheap-plausibility trade gave away: the tools moved the cost of noticing, not the cost of being sure.

What that means for the person accountable for it

For years the distance between "we work on accessibility" and "we can show it is accessible" was a private quality concern you could hold inside the team and mean well about. This year the law started asking the question the plausible layer cannot answer. In France's first ruling under the EAA this spring, a large retailer was found non-compliant at 71% conformance against the national audit standard. That figure came from a manual evaluation, not a scanner, which makes the outcome sharper rather than softer: even a mostly-passing human audit did not satisfy the obligation. It is worth being clear about why, because it is the same divide again. Automated checks reach only about a third of WCAG; the rest is judgement about whether a real person can actually complete the task. A court does not grade code coverage. It asks whether a disabled citizen can finish the checkout, and that is a question no linter score answers. A court is, in the end, an institution built to refuse plausibility and demand the thing underneath. It does not ask what you adopted. It asks what you can show, and "we had accessibility in our workflow" is an answer at exactly the layer it is designed to look past.

Buying back the correctness

None of this argues against the tooling. Cheap awareness is worth having, and a model that raises an accessibility issue while you write is better than silence. The point is narrower: if AI lowered the cost of looking done without lowering the cost of being done, then the work worth investing in is the part that closes that specific gap. It helps to name the two activities separately. Generation produces a hypothesis, a plausible fix that might be right. Verification is a distinct act: checking that the fix does the thing it was meant to do, and leaving a record that it was checked. AI made generation nearly free and left verification exactly as expensive as it always was, which is why a workflow that only generates drifts toward plausible and away from correct. The W3C's own conformance guidance is organised around that record for the same reason a court is: it is what turns a claim into something you can stand on.

This is the reason Jeikin is built the way it is, and I say that having felt the friction of it in my own work. It refuses to treat the generated fix as the end of the job. Each issue is tracked, each fix is checked against the specific criterion behind it, and that trail is the actual output of the review, so that "we handled accessibility" arrives attached to evidence of how each fix was verified rather than a claim that it was. The generation is the cheap part now; AI made sure of that. Verification is the part that was always the job, and it is the part the cheap-plausibility year quietly skipped.

The web got less accessible in the year its tooling improved most, and that is not a paradox once you see what got cheaper and what did not. Plausible became free. Correct did not. Accessibility is simply the place you notice the difference first, and increasingly the place someone else will notice it for you.