More ARIA than human

Every February, WebAIM, an accessibility research centre at Utah State University, analyses the top one million most visited homepages on the internet and publishes how many fail. For the past 8 years, it has been the largest census we have for knowing what accessibility is like in the real world. The 2026 report brings two pieces of data that are worth reading together.

The first one: 95.9% of the pages have automatically detectable accessibility issues, almost one point higher than the previous year. The number of errors per page rose from 51 to 56.1, an increase of 10%. After six years of small but steady improvements, the trend has reversed.

The second one explains much better what is going on. WebAIM counted 133 million ARIA attributes, about 133 per page. ARIA (an acronym for Accessible Rich Internet Applications) is a set of attributes added to HTML to explain to a screen reader what an element is when the HTML itself does not say so: that this div it is a button, that that panel is a dialogue or that text is an alert. It grew by 27% in a single year, and today there are six times as many as in 2019.

So in the same year we've written more code to enhance accessibility than ever, and we've published a website less accessible than last year.

The inconvenient truth

It can be refined even further. Pages with ARIA have an average of 59.1 errors, compared to 42 for those without. And the relationship is progressive: the more ARIA attributes a page has, the more errors are detected in it.

This does not mean that the ARIA attribute is wrong, it means it is being used without the judgment it needs to function. For example, a aria-label on an element that already had a correct name: now the screen reader announces the text of the attribute and not the one visible in the interface, so whoever is listening hears something different from what is on the screen. Or a role="button" in a div, which announces a button even though the element still cannot be activated with the keyboard, which breaches the criterion 2.1.1 on keyboard looking like it had been fixed. Or a aria-hidden="true" markup for hiding a decorative icon that ends up being applied to the entire container, meaning the error message inside ceases to exist for anyone who cannot see it. Each of those attributes is a broken promise made to the screen reader user.

The First rule of ARIA, written by those who designed it, is not to use ARIA. If there is an HTML element that already does what you need, that element is the answer. Well, that rule is being broken 133 million times.

None of this is a recent discovery. Andy Carter already explained it in 2024, with that year’s WebAIM report to hand: pages using ARIA had 34.2% more errors detected than those that did not, and I went through, one by one, the ways in which a aria-label Badly placed, it breaks things that used to work. Two years later that gap hasn't closed, it has widened.

Where did all that ARIA come from?

WebAIM points to two causes and does not shy away from naming them: web pages are becoming increasingly complex (a 22.5% increase in the number of elements in one year) and there is greater reliance on third-party frameworks and «AI-assisted programming practices, or vibe coding».

It is worth pausing on this last point, because the mechanism is interesting and not what we might initially suppose.

A language model learns to predict the most likely code given a context. The data from which it learnt is that website: the one with the 95% pages containing errors, the one covering the six years of div con on-click, the one with the incorrectly implemented ARIA. When it generates an inaccessible component, it’s not failing; it’s reproducing what’s out there with a fair degree of accuracy. That is to say, he was very well trained in very poorly designed places.

And there is something worse. A model knows that accessibility matters, because it also learned from the documentation, the articles and the talks where it is explained. So it adds ARIA, a lot of ARIA, without the judgment to know when it is redundant, when it contradicts the HTML and when it is covering up a problem instead of solving it. The result is exactly what WebAIM measures: more attributes, more errors.

Added to this is the fact that the flaw is invisible where we usually look. A screen reader does not read the screen, it reads accessibility tree, a structure that the browser calculates from the HTML, CSS and those ARIA attributes. Two buttons can look identical and be completely different underneath. A screenshot does not show this, and a visual review doesn't either. When a multimodal model reviews its own work by looking at an image, it is looking at the wrong artefact.

Why this is about design and not just code

This is where it stops being an accessibility issue, and starts to look like something that, I'm sure you've also noticed in your workflow.

The parts that a priori seemed most difficult come together quickly with AI. In contrast, the ones we've taken for granted for decades are getting stuck: deciding whether a screen should exist, what happens when there is no data, whether this case is a genuine exception or a pattern we've already solved elsewhere, what that state actually means for the user. Product decisions that would be hard to defend in a review.

For a while I thought the problem was the model, that it wasn't trained enough. So when I sat down to write the criteria for an LLM to be able to follow them, I discovered that they weren't sufficiently documented.

Try doing it. Take a decision you make on autopilot, when something deserves its own screen and when it's a step within another, and write the exact rule you follow. Not the theory, the rule. Within three or four lines you end up writing «it depends on the context», and that's where the document ends, because the context, the information about the product and about who uses it, is precisely what you contribute without realising and the machine doesn't have.

Nobody ever asked us to write down or verbalise these rules. We learned them by watching, correcting and accumulating decisions until we internalised them. It only works as long as the executor is you or someone who has been in the same meetings. Design systems were our attempt to fix this, and we know how that ends: they document components well and criteria badly when they live in the grey area.

Badly implemented ARIA is the visible version of that very thing. It is a half-written criterion, applied without the part that wasn't written. And as in the case of accessibility where the rules are published and verifiable, the disaster can be measured. The same thing happens with the rest of the product decisions, but there's nobody counting pages.

Previously, every variation cost time and money, so at some point the budget ran out and you went out with what you had. The concession was imposed by the schedule.

Now the cost of asking for another version has been reduced a lot, so you can keep polishing indefinitely, and as each iteration improves a little, there is never an obvious moment to stop. So the difficult decision has moved. It's no longer how to get the result I want, Or when do I accept that this piece falls below my standard and get on with something else?.

What does transfer

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

The rules have been written since WCAG 1.0 in 1999, numbered, with acceptance criteria and a clear way to check whether they are met. I don't have to justify what sufficient contrast means, because someone already did that work years ago, and it wasn't a specific product team, but people who needed it to be done right.

When the criterion is written like this, it gets transferred. You can pass it to a model the criterion 1.4.3 on minimum contrast before I write a line, and what comes out fulfils it, because there is nothing to interpret: the contrast threshold is a number. It's the reason why I started here when I built Jeikin, since the rules were already written.

It is best to be honest about the scope. Automated tools detect some of the criteria, not all, and in July the W3C put it in writing in the WCAG-EM 2.0 that no single methodology on its own allows you to declare that something complies. But look at what the WebAIM numbers say: Of all the faults detected, the 96% is concentrated in six types, which are the six most common mechanical faults. Contrast, alternative text, form labels, empty links, empty buttons. None of that requires a design decision. All of that should be sorted before the code gets to a review.

The fact that in 2026 96% will still account for the majority of faults, despite more tools being available than ever before, says something about where we’re focusing our efforts. We’ve spent the last two years wondering whether this is going to replace us; I’ve found it more useful to ask myself how much of what I know how to do – but which doesn’t add value – I’m able to explain and document, so that I can focus on what really matters.

 

More entries from Design