More ARIA than human

Every February, WebAIM analyses the million most-visited home pages on the internet and publishes how many of them fail. It is the largest census we have of how accessibility is doing in the real world, and it has run with the same methodology for eight years, so the numbers can be compared.

The 2026 report contains two findings worth reading together.

The first: 95.9% of home pages have automatically detectable WCAG failures, up from 94.8% the year before. Errors per page went from 51 to 56.1, roughly 10% more. After six years of small but steady improvement, the trend reversed.

The second explains the first much better. WebAIM counted 133 million ARIA attributes, about 133 per page. ARIA (short for Accessible Rich Internet Applications) is the set of attributes you add to HTML to tell a screen reader what an element is when the HTML itself does not say: that this div is a button, that this panel is a dialog, that this text is an alert. ARIA usage grew 27% in a single year, and there is now six times more of it than in 2019.

So in the same year, we wrote more accessibility code than ever and shipped a less accessible web than the year before.

The uncomfortable number

It gets more specific. Pages that use ARIA average 59.1 errors. Pages without it average 42. And the relationship is progressive: the more ARIA attributes a page has, the more errors it turns out to have.

This does not mean ARIA is bad. It means it is being applied without the judgement it requires to work. An aria-label on an element that already had a correct name, so the screen reader now announces the attribute text instead of what is visible, and the person listening hears something different from what is on screen. A role="button" on a div, announcing a button that still cannot be operated with a keyboard, which is a failure of 2.1.1 Keyboard dressed up as a fix. An aria-hidden="true" added to hide a decorative icon that ends up applied to the whole container, so the error message inside it stops existing for anyone who cannot see it.

Each of those attributes is a promise made to a screen reader and then broken.

The first rule of ARIA, written by the people who designed it, is not to use ARIA. If an HTML element already does what you need, that element is the answer. ARIA is for when there isn't one.

That rule is being broken 133 million times.

None of this is a recent discovery. Andy Carter wrote it up in 2024, using that year's WebAIM report: pages with ARIA averaged 34.2% more detected errors than pages without it, and he walked through the specific ways a misplaced aria-label breaks things that already worked. Two years on, that gap has not closed. It has widened.

Where all that ARIA came from

WebAIM points at two causes and does not hedge about naming them: pages keep getting more complex (22.5% more elements in a single year) and there is more reliance on third-party frameworks and on "automated or AI-assisted coding practices ('vibe coding')."

The second one is worth sitting with, because the mechanism is not the one most people assume.

A language model learns to predict the most probable code given a context. The material it learned from is that web: the 95% of pages with failures, six years of div with onclick, all that misapplied ARIA. When it generates an inaccessible component it is not malfunctioning. It is reproducing, quite faithfully, what is actually out there. It was very well trained on very badly built sites.

And there is a worse part. A model also knows accessibility matters, because it learned from the documentation, the articles and the conference talks where people explain it. So it adds ARIA. Lots of ARIA. Without the judgement to know when it is redundant, when it contradicts the HTML, and when it is covering a problem instead of solving it. The result is exactly what WebAIM measures: more attributes, more errors.

On top of that, the failure is invisible where we usually look. A screen reader does not read the screen. It reads the accessibility tree, a structure the browser computes from the HTML, the CSS and those ARIA attributes. Two buttons can render identically and be completely different underneath. A screenshot will not show it, and neither will a visual review. When a multimodal model checks its own work by looking at an image, it is inspecting the wrong artifact.

Why this is a product problem, not a markup problem

This is where it stops being an accessibility story and starts resembling something I have been noticing in our own workflow.

The parts that looked hard up front come out fast with AI. The ones we have taken for granted for decades are the ones that stall: deciding whether a screen should exist at all, what happens when there is no data, whether this case is a genuine exception or a pattern we already solved somewhere else, what a given state actually means for the person using it. Product decisions, not layout, and none of them hard to defend in a review.

For a while I assumed the problem was the model, that it had not been trained enough. Then I sat down to write our criteria out so a machine could follow them, and found they had never really been documented.

Try it. Take a decision you make on autopilot, when something deserves its own screen and when it is a step inside another one, and write down the exact rule you follow. Not the theory, the rule. Three or four lines in, you end up writing "it depends on the context," and that is where the document stops, because the context, everything you know about the product and the people using it, is precisely what you supply without noticing and the machine does not have.

Nobody ever asked us to write these rules down or say them out loud. We learned them by watching, correcting, and accumulating decisions until they stopped feeling like decisions. That works while the executor is you, or someone who sat in the same meetings. It stops working when the executor was in none of them.

Design systems were our attempt to fix this, and we know how that goes: they document components well and criteria poorly, especially the criteria that live in the grey area.

Misapplied ARIA is the visible version of the same thing. It is half-written criteria, applied without the half that never got written. And because accessibility rules are published and checkable, the damage can be counted. The same thing happens with the rest of our product decisions. There is just nobody counting pages.

The bottomless pit

There used to be a natural brake on chasing perfection in implementation: time. Every variation cost money, so at some point the budget ran out and you shipped what you had. The compromise was imposed by the calendar.

Now the cost of asking for another version has dropped enormously, so you can keep polishing indefinitely, and because each iteration is slightly better, there is never an obvious moment to stop.

So the hard decision moved. It is no longer how to get the result I want. It is when to accept that this piece stays below my standard and move on to something else.

Nobody trained us for that. People in design and product were trained to defend the criteria, and stopping short looks a lot like giving up.

What actually transfers

With accessibility, this conversation does not happen, which is why it is a good place to learn from.

The rules have been written down since WCAG 1.0 in 1999, numbered, with acceptance criteria and a clear way to check whether they are met. I do not have to excavate from my own head what sufficient contrast means. Somebody already did that work, and it was not a product team. It was people who needed it done properly.

When criteria are written that way, they transfer. You can hand a model 1.4.3 Contrast (Minimum) before it writes a line, and what comes back complies, because there is nothing to interpret: the contrast threshold is a number. That is the reason I started there when I built Jeikin, and not with the rest of design. The rules already existed.

For visual hierarchy or consistency across sections, they don't.

Worth being honest about scope. Automated tools detect some of the criteria, not all of them, and in July the W3C put it in writing in WCAG-EM 2.0 that no methodology on its own lets you make a conformance claim. But look at what the WebAIM numbers say: 96% of all detected errors fall into six categories, and they are the six most mechanical ones there are. Contrast, alternative text, form labels, empty links, empty buttons. None of that needs design judgement. All of it should be handled before the code reaches a review at all.

That these still account for 96% of failures in 2026, with more tooling available than ever, says something about where the effort is going.

We have spent two years asking whether this is going to replace us. I have found a different question more useful: how much of what I know how to do, and that adds no value in my doing it, can I explain well enough to hand over, so I can put the attention on what actually matters.