AI interfaces meet 29% of accessibility requirements

How accessible is an interface that AI builds for you?

Twenty-nine percent accessible. That is not an estimate but a measurement: in a comparative study published on 13 April 2026 at the ACM Web for All conference, 54 designers first built interfaces by hand in Figma, then generated comparable designs with six AI tools. Across five WCAG success criteria the researchers assembled 21,880 individual accessibility assessments. The AI output reached 29.0% compliance.

The striking part is not the headline number but which criteria scored worst. Colour contrast, the single most mechanically checkable criterion in the entire specification, landed at 26.8%. The criterion covering colour as the only carrier of information landed at 19.2%. The rules a computer can verify in milliseconds are precisely the rules the generator breaks most often.

Then comes the finding that dismantles the fix most teams reach for. The researchers report that explicitly specifying accessibility requirements in generation prompts decreased rather than improved compliance. Writing "make it accessible" into your brief does not make the output better.

This article is about the cause, not the law. What the European Accessibility Act has required since 28 June 2025, who is exempt and how the Dutch regulator enforces it sits in our piece on the accessible webshop and the WCAG law. Here we look at something else: why the web is measurably getting worse for the first time in seven years while building gets cheaper, what exactly breaks in the generation layer, and what you do instead of installing a widget.

What the W4A study measured, and what it did not

The design of the study is why it is worth more than another tool shootout. The same 54 designers did both tasks. Manually in Figma first, then generating with six AI tools. That makes it a controlled comparison of the same craft in two modes, rather than a comparison between good designers and a bad robot.

The result goes beyond the compliance score. Participants reported that 39% of the violations in AI output required a major redesign to remediate, against 22% for the manual work. That is the sentence that hits a project budget. Hours saved during generation come back as rework almost twice as often, and reworking a structure costs more than getting the structure right the first time.

There is an effect on the people, too. Designers' trust in AI to deliver accessible outputs stayed low, averaging 3.60 on a five-point scale. More importantly, their confidence in evaluating that output fell from 3.8 to 3.2. The generator does not only produce weaker interfaces; it also makes the reviewer less certain about what they are looking at.

Be honest about the limits of this source. The paper sits behind a wall we could not pass; we verified the abstract word for word through two independent scholarly indexes that return exactly the same text. Every number above comes from there. Which six tools were tested is not stated, so we do not name them. Which five success criteria were assessed is not stated either. A five-criterion sample from WCAG is not a full audit, so the conclusion is more precisely phrased as this: on the criteria that are easiest to check, these tools perform worst.

That is still a hard point. If a machine fails the rules a machine can verify, the problem is not the difficulty of the requirement but what is being optimised. A generator trained on aesthetics produces what looks good on the trainer's screen. Grey on white looks calm. It simply does not clear the contrast threshold.

Why does "make it accessible" in the prompt make things worse?

The study reports the effect without explaining it, so neither will we. What we can do is describe what we see in our own work, because this pattern is familiar.

A prompt is a request to produce something, not a specification to test against. Adding "make sure this is accessible" asks a generator to bake in a property it cannot measure. The result is what you would expect from a system optimising for plausibility: it delivers the signs of accessibility. More ARIA attributes. A skip link. An alt value that exists. Visible evidence that someone thought about it, without anything having been calculated.

WebAIM measures that this is not harmless, at the other end of the same pipeline. Pages with ARIA averaged 59.1 errors in the 2026 analysis, pages without ARIA 42. More accessibility markup goes together with more barriers, not fewer. ARIA is a precision instrument that breaks when you scatter it.

There is a deeper layer. Accessibility is mostly a property of relationships between elements, not of elements themselves. Whether a contrast ratio holds depends on the background the text lands on. Whether a label works depends on the field it is bound to. Whether a focus order makes sense depends on the whole page. A generator reasoning component by component cannot see those relationships, no matter how many times the word accessible appears in the brief.

This is exactly why we draw the line at evaluation rather than at generation when AI enters the design process. Generating is fine. What is not fine is the generator also acting as the judge. The same principle applies to AI product visualisation: the output becomes usable the moment there is a control layer underneath telling you when it is not.

Is the web really getting worse, or does it only feel that way?

It is getting worse, and it is measurable. WebAIM scans the home pages of the million most popular websites every year. In the February 2026 analysis, 95.9% of those home pages had automatically detectable WCAG 2 A/AA failures, up from 94.8% in 2025. WebAIM itself calls that a reversal of a six-year trend of small improvements.

The average number of errors per page rose 10.1% to 56.1. Of all page elements across that million home pages, 3.9% carried a detected error, which works out to a barrier on one in every 26 elements a user encounters.

WebAIM also offers a cause analysis, and for this article that is the most interesting part. The average number of elements per home page rose to 1437, an increase of 22.5% in a single year. ARIA attributes passed 133 per page, 27% more than a year earlier. Pages are getting bigger and more technically complex at a rate WebAIM itself calls alarming. Then follows the sentence that ties this article together: these trends likely reflect broader shifts in web development including increased reliance on third-party frameworks and libraries and automated or AI-assisted coding practices, quote, "vibe coding".

Two independent measurements, two ends of the same pipeline. On the design side, a controlled experiment landing on 29.0%. On the production side, a field measurement across a million pages showing the first deterioration in seven years and pointing at the same cause.

The Netherlands does relatively well and still badly. Domains on .nl came in at 45.5 errors per home page across 12,660 measured pages, 18.9% below average. Above average here means 45 barriers on your front page.

Which six failure types make up 96% of the problem?

Here is the good news, and it is concrete enough to turn into a sprint. Six failure types account for 96% of all detected errors, and according to WebAIM they have been the same six for seven years. The problem is not diffuse. It is a short list you can work through.

Look at the last column. All six sit in the layer an agency can reach without rebuilding your store. The missing document language is literally one attribute, and yet 13.5% of the web still leaves it out. That is not a technical problem but an attention problem.

For online stores the premium on top of the average is steep. WebAIM measured an average of 75.1 errors across 42,516 Shopify home pages, 33.9% above the overall average. Magento landed on 75.8, Prestashop on 143.2. The Shopping category as a whole sat at 71.0, 26.6% above average.

This is not an attack on Shopify. We build on it and will keep doing so, and which platform suits which brand is covered in our piece on Shopify versus WooCommerce. It is a statement about what gets layered on by default: a theme from the store, eight apps each injecting their own markup, and a banner someone added quickly on a Thursday afternoon. Every layer adds elements, and every added element is a chance to fail.

Why does an accessibility widget not solve this?

Because a widget does not touch the failures in the table above, and because the three parties with the most evidence all say the same thing about it.

The legal evidence comes from the United States and that belongs in the sentence. UsableNet tracks US ADA cases and counted 831 lawsuits in the first half of 2026 against companies that already had an accessibility widget installed, spread across January through a partial month of June. For the full year UsableNet projects roughly six thousand cases. Companies with under fifty million dollars in revenue made up over two-thirds of defendants, so this reaches mid-market businesses and not only household names. UsableNet writes in the report itself that the presence of a widget does not, by itself, prevent a lawsuit or demonstrate that a website is accessible.

Those figures are American and do not transfer to the Netherlands. The European parallel is the European Accessibility Act, in force since 28 June 2025, and our legal overview covers it. How many European or Dutch proceedings there have been, we do not know, so we do not claim it. As of September 2026 there are no publicly known penalty decisions from the Dutch regulator on this subject.

The practitioner verdict is older but unambiguous. In WebAIM's third survey of web accessibility practitioners, run in January 2021 among 758 respondents, 67% rated overlays not very or not at all effective. Among respondents with a disability that figure was 72%, and only 2.4% called them very effective. That number is from 2021 and we always name the year.

The third piece of evidence is consensus. The Overlay Fact Sheet has now been signed by more than a thousand people, among them co-authors of the WCAG, ARIA and HTML specifications and code contributors to the JAWS and NVDA screen readers. Their core statement: no overlay product on the market can cause a website to become fully compliant with any existing accessibility standard and therefore cannot eliminate legal risk.

A widget sells peace of mind. That is precisely what you lose the moment somebody knocks.

Where is the blind spot in Dutch online stores?

In the standard components almost everyone builds on and almost nobody has checked. That comes from research Motivaction carried out for the Dutch regulator ACM, with a report date of 16 December 2025 and publication on 24 March 2026.

Methodology first, because it belongs here. The questionnaire was completed by 108 people, of whom 63 turned out to fall inside the target group: Dutch online stores excluding micro-enterprises. Only those 63 are reported on. Fieldwork ran from 13 to 30 May 2025 and participants were recruited through trade associations. That makes it indicative and not representative. It is also the only nationwide measurement that exists, and it comes from the regulator itself.

Among respondents who do part or all of the design themselves, 53% use standard components from companies such as Shopify, WooCommerce and Magento. Among the group that has engaged with accessibility at all, 30% has ever checked whether those standard components are accessible. And 16% has written policy to make sure the store stays accessible.

Set that next to the WebAIM measurement and the gap is the story. More than half build on platform components, fewer than a third have ever tested them, and the most cited accessibility research in the world measures that this exact base scores a third worse than the average web.

On implementation the picture matches. Only 13% of respondents had implemented full keyboard operation of their store. That is exactly where checkout breaks, and checkout is where a failure costs you most. We mapped that anatomy in our piece on checkout optimisation across 32 points.

One thing we will not claim here. No Dutch research exists that measures what accessibility returns in revenue. In that same ACM study, on the statement that making their store accessible generates more revenue, 3% strongly agreed and 11% agreed. Anyone telling you accessibility pays for itself is selling you a number that does not exist. The reasons to do it are that it is required, that it is measurable, and that it makes your store usable for more people. That is enough.

What do you do instead of installing a widget?

You move evaluation in front of generation instead of behind it. In practice that means four things, and all four can be introduced without changing your stack.

One: fix the four values before anything gets generated. Contrast ratios per colour pair, focus style, minimum target size and the heading structure. These are design decisions, not technical settings, and they belong in the brand system. A generator handed tokens where contrast already holds cannot invent a worse ratio. A generator allowed to pick its own colours will pick on aesthetics. How we build a brand system that machines can actually use sits in our article on the brand system in the AI era.

Two: pull the six failure types into the definition of done. Not as a recommendation but as a delivery condition. Contrast, alternative text, form labels, filled links, filled buttons and the document language. An automated scan catches these six and together they are 96% of all errors. That is a check measured in minutes that you can attach to every build.

Three: test with the keyboard, not with the scanner. Unplug your mouse and try to buy one product. From the search bar to the filter, to the product page, to the variant picker, to the cart, to the delivery address, to payment. Can you see where you are at every step, and can you get through? This takes half an hour and it finds precisely the failures no automated scanner sees, because a scanner checks markup and not sequence.

Four: put the final judgement with a human. This is where the W4A study bites hardest: designers' confidence in their own evaluation dropped after working with AI. Which means the review step has to get stronger as you generate more, not weaker. The pattern we describe in the last stretch of an AI-built store is the same here: the first eighty percent goes faster than ever, and the last twenty percent is the work.

What this buys you is not only compliance. It is the same gain as speed and clarity: fewer people stuck on a screen that will not cooperate. We describe that link in our piece on why a web store does not convert, and it is why we treat accessibility as a design question rather than a compliance question.

How we handle this at Oase Creative

We use AI in our work daily, and that will not change. What we do not do is let the generator judge its own output. Across six years and more than 500 delivered projects, that is the single rule that has survived every technology wave: the creative idea and the final verdict come from a person, the execution may come from a machine.

In practice that shows up in how we deliver a store or a website. Colour tokens come out of the brand system and are checked on contrast before a screen exists. The six failure types sit in the delivery check. The keyboard route through checkout is walked by hand, every time, even when the scanner is green. And for stores we maintain, that is not a one-off action but a recurring check, because a store that holds today will have four new apps in three months.

That last point is where the ACM figures point. Sixteen percent of the surveyed stores have written policy to stay accessible. In this file, the difference between a project and a process is the difference between complying once and continuing to comply. An audit that runs once a year measures the year that is already over.

If you want to know where your store stands, the first step is small: scan for the six failure types and walk your checkout once without a mouse. That produces a list within a day that you can work through. If you want us to do it, start at web design and development.

Frequently asked questions

How accessible are interfaces generated by AI tools? Poorly. In the W4A study of April 2026, AI-generated interfaces reached 29.0% of the measured WCAG success criteria, with colour contrast at 26.8% and the use-of-colour criterion at 19.2%. The basis was 21,880 individual assessments of work by 54 designers.

Does putting accessibility requirements in the prompt help? No. The study reports that explicitly specifying accessibility requirements in generation prompts decreased rather than improved compliance. Test after generation instead of asking during it.

Is the web really getting worse on accessibility? Yes. WebAIM found automatically detectable WCAG failures on 95.9% of the million most popular home pages in February 2026, up from 94.8% in 2025. The average number of errors per page rose 10.1% to 56.1.

Does an accessibility widget solve this? No. UsableNet counted 831 US ADA lawsuits in the first half of 2026 against companies that already had a widget. In WebAIM's January 2021 survey, 67% of practitioners rated overlays not very or not at all effective.

Which failures should I fix first? The six that together account for 96% of all detected errors: low contrast text, missing alternative text, missing form labels, empty links, empty buttons and a missing document language. All six are fixable in the theme layer.

Is my Shopify theme inaccessible by default? Not by default. But WebAIM measured an average of 75.1 errors per page across 42,516 Shopify home pages, 33.9% above the overall average. That rarely comes from the platform and almost always from the stack of theme, apps and one-off edits on top.