Accessibility, after AI

Generating an interface got cheap. Knowing whether it is any good did not. Accessibility is the part of our craft that already learned to write down what good means precisely enough to test, which is exactly the skill this moment is asking for.

The cost of making moved, the standard did not

Producing an interface is close to free now. A screen that took a week of front-end takes an afternoon, and a rough version of almost anything is one prompt away. What did not get cheaper is deciding what should exist and judging whether the thing that came out is any good.

So the centre of gravity in product design moves from making to judging. Less time drawing the fourth variant, more time saying precisely what separates a good one from a bad one, precisely enough that the answer holds when a hundred variants arrive instead of four.

A model writes the median web, and the median web fails

Models learn from what has been built. WebAIM scans the top million home pages every year, and every year it finds detectable WCAG failures on about 95% of them. That is the corpus. So a model reaches for a div with a click handler as readily as a button, writes a placeholder where a label belongs, signals state with colour alone, and ships icon buttons with no accessible name. Not carelessness, an accurate average.

The defect rate per screen stays roughly what it always was. The number of screens goes up by an order of magnitude. The number of barriers shipped is the product of the two, and only one of those terms is falling.

You cannot audit a surface that is different every time

The whole audit tradition assumes a fixed screen: open the page, walk it with a keyboard, check the contrast, write the report. Generative interfaces break that assumption. The output differs per user, per run, per prompt. There is no page to open.

Accessibility has to become a property you specify and then evaluate against, run after run, the way teams already evaluate safety or accuracy. That is an evals problem, and it means the requirement has to be written down in a form a machine can check.

The new surfaces have new failure modes

None of these are covered by the habits that got us through a decade of pages and forms. They are where I would spend the audit hours now.

It is also the largest access gain in a decade

This has to be said plainly, because the criticism above is worth nothing without it. Image description on demand, live captioning, plain-language rewriting, a form filled in by describing what you want, code that explains itself back to you: these are real, and for a lot of people they are the difference between using a product and not.

The catch is structural. Assistive AI puts a probabilistic layer between a person and the truth of the interface, and the people who depend on it most are the ones least able to verify it. So the accuracy bar for an assistive feature is higher than for a convenience feature, not lower, and the honest version of it says when it is unsure.

Where accessibility sits in all this

Not as a subplot, and not as the compliance step at the end. WCAG is the industry's longest-running attempt to state what good means in terms specific enough to be tested by someone who was not in the room. Focus order, accessible name, contrast ratio, error recovery: requirements written to be checked rather than admired.

That is the same work AI product design now needs everywhere. If you have written acceptance criteria for a keyboard path, you have written an eval. Accessibility is not competing with the AI work for attention; it is the rehearsal for it.

Put the standard inside the generator, not the review. Component library, system prompt, lint in CI: producing an unlabelled control should be the harder path.
Test the generated output with the assistive technology, not the design file. The file was never the thing anyone used.
Write each accessibility requirement as something that can be run, and run it every build.