In short and in plain language
Many teams let AI tools write code. The code often looks good. But it can still shut out people with a disability.
A large study counts more errors on home pages than the year before. The authors think AI tools may be one reason. They do not know for sure.
These errors are common: a button is not a real button. A button has no name. A menu only opens with a mouse. You cannot see where you are when you press the Tab key.
A test tool finds only part of this. A person must also test the page with the keyboard and with a screen reader.
The law does not ask who wrote the code. The firm must make sure that people with a disability can use its site.
A team asks an AI assistant for a product card, a disclosure menu or a form, drops the result into the template and sees exactly what it asked for in the browser. Whether a screen reader announces the button as a button, and whether the menu opens with the keyboard, is not something the browser view reveals. The WebAIM Million 2026 counts an average of 56.1 (WebAIM Million 2026) automatically detected errors on the home pages of the top one million websites, up from 51 (WebAIM Million 2026) the year before. WebAIM suspects that AI-assisted coding practices, known as “vibe coding”, are among the reasons for the increase. This article shows which patterns accessibility testing typically finds in generated code and where testing belongs in the development workflow.
Key takeaways
- The WebAIM Million 2026 counts 56.1 automatically detected errors per home page, 10.1 percent more than in 2025; WebAIM names AI-assisted coding as one possible reason without measuring it (WebAIM Million 2026).
- Language models often handle contrast and alternative text well but struggle with ARIA attributes (Suh et al. 2025); in a formative study with 16 developers without accessibility training, there was no way to verify the result (Mowar et al. 2025).
- Four patterns typically show up in audit logs for generated markup: div with a click handler instead of a button, controls without a name, ARIA state without keyboard support and removed focus outlines (W3C, WCAG 2.2, SC 4.1.2, 2.1.1, 2.4.7).
- Automated tests catch only part of the problem: of 143 barriers on a test page built by the UK Government Digital Service, ten tools combined missed 42, or 29 percent (GDS 2017).
- Testing belongs in three places in the workflow: acceptance criteria in the specification and the prompt, an automated test before merging and a manual pass with keyboard and screen reader before sign-off; every finding feeds back into the specification.
- The BFSG does not ask how code was produced: offering a service in breach of Section 14(1) BFSG can lead to a fine of up to 100,000 euros (BFSG, Section 37).
What the WebAIM Million 2026 shows
Every year, WebAIM runs an automated evaluation of the home pages of the top one million websites (WebAIM Million 2026). The 2026 edition counts an average of 56.1 errors per home page (WebAIM Million 2026). The year before, the figure was 51 (WebAIM Million 2026), which amounts to an increase of 10.1 percent (WebAIM Million 2026). WebAIM only counts barriers that the testing engine detects automatically and that have a very high likelihood of failing WCAG 2.2 at Level A or AA. Anything that can only be checked with a keyboard, a screen reader or human judgment is not part of these numbers.
The second figure is even clearer. On 95.9 percent (WebAIM Million 2026) of home pages, the evaluation found at least one detected WCAG failure. In 2025, the share was 94.8 percent (WebAIM Million 2026). That ends a period in which the value had improved slightly for six years in a row (WebAIM Million 2026). Because only automatically detectable failures count, WebAIM concludes that the share of fully conformant home pages was certainly lower than 4.1 percent (WebAIM Million 2026).
WebAIM names two developments as a primary concern, both of which correlate with more detected errors: home pages are getting more complex, and they carry more ARIA code. The average home page had 1,437 page elements, 14.3 percent more than a year earlier (WebAIM Million 2026). The evaluation also found more than 133 ARIA attributes per home page on average (WebAIM Million 2026), an increase of 27 percent in one year (WebAIM Million 2026). Pages with ARIA averaged 59.1 detected errors, pages without ARIA 42 (WebAIM Million 2026). WebAIM stresses that ARIA did not necessarily introduce these errors, because pages with a lot of ARIA are also more complex.
In the conclusion of the report, WebAIM puts the figures into context. The trends likely reflect broader shifts in web development, including increased reliance on third-party frameworks and libraries and automated or AI-assisted coding practices known as “vibe coding” (WebAIM Million 2026). That is an assessment, not a measurement: the report does not identify which of the evaluated pages were built with AI assistance. Still, the assessment is reason enough to act. Anyone who ships generated code should test it like any other code, specifically for the errors that this way of working makes likely.
What research says about generated code
Research on the accessibility of AI-generated code is young, and its results do not fit the simple story of bad machine code. A comparative study published in 2025 set web code from two language models against code written by human developers (Suh et al. 2025). The language models often produced more accessible code, especially for basics such as color contrast and alternative text, but struggled with more complex issues such as ARIA attributes (Suh et al. 2025). According to the study, advanced prompting strategies brought some gains, but those gains were limited.
A second paper looks at the person operating the tool. In a formative study with 16 developers without accessibility training, the research team observed three key issues in AI-assisted coding (Mowar et al. 2025): participants did not prompt the AI for accessibility, they skipped crucial manual steps such as replacing placeholder attributes, and they had no way to verify the compliance of the result. The second point is treacherous in daily work. A generated suggestion may contain an alt="image" or an aria-label="Button" that satisfies the structure and leaves the content open.
The tools themselves are part of everyday development now. In the Stack Overflow Developer Survey 2025, 84 percent of respondents said they use or plan to use AI tools in their development process (Stack Overflow Developer Survey 2025). At the same time, 46 percent distrust the accuracy of the output, while only 33 percent trust it (Stack Overflow Developer Survey 2025). The biggest single frustration, named by 66 percent, is AI solutions that are “almost right, but not quite” (Stack Overflow Developer Survey 2025). For accessibility, that describes the typical situation: the result looks right, but operation without a mouse and the screen reader output are wrong.
A duty to test, not a question of tools
Four patterns in generated markup
The following patterns are typical findings when generated components are tested. None of them is new, and none is a quirk of a particular tool. They appear when a description such as “product card with a buy button and expandable details” turns into markup that looks right, and nobody checks it afterwards with a keyboard and a screen reader. The illustration above shows all four in a single product card.
Pattern 1: Click target instead of a button
A div with onclick responds to a mouse click and, with a little CSS, looks like a button. To a screen reader, however, it is a text container without a role, and it cannot be reached with the Tab key. That fails two Level A success criteria: SC 4.1.2 requires that the name and role of every user interface component can be programmatically determined, and SC 2.1.1 requires that all functionality is operable through a keyboard interface (W3C, WCAG 2.2). Adding role="button" only does half the job. The ARIA Authoring Practices Guide calls a role a promise: whoever sets it announces that the expected keyboard interaction has been built in with JavaScript, because unlike HTML controls, ARIA roles do not make browsers provide keyboard behavior (W3C, ARIA Authoring Practices Guide). In 2026, home pages averaged 4.8 role="button" attributes, up from 3.6 in 2025 (WebAIM Million 2026).
<!-- Generated: looks like a button, is a text container -->
<div class="btn" onclick="addToCart()">Add to cart</div>
<!-- Reviewed: native element, focusable, Enter and Space included -->
<button type="button" class="btn" onclick="addToCart()">Add to cart</button>Pattern 2: Controls without a name
The second pattern affects icon buttons: a cart icon, a heart for the wish list, an X for closing. Generated markup often uses a button element with an embedded SVG for these, but without visible text, without aria-label and without a title in the SVG. A screen reader then just says “button”, and nobody learns what it does. The WebAIM Million 2026 found empty buttons on 30.6 percent of home pages and empty links on as many as 46.3 percent (WebAIM Million 2026). Both fall under SC 4.1.2 (W3C, WCAG 2.2). How to assign names properly, and why the visible label should be part of the name, is covered in the article on empty links and buttons.
Pattern 3: ARIA state without keyboard support
Expandable details, accordions and menus often come with ARIA attributes in generated code. That looks diligent: aria-expanded="false" is in the markup, perhaps aria-controls as well. But if the attribute sits on a div without focus and without a response to Enter and Space, only a mouse can open the element. If the script also forgets to toggle the state on opening, the screen reader keeps announcing “collapsed”. A related pattern shows how risky ARIA without matching interaction is: 22 percent of ARIA menus on home pages introduced barriers because the necessary markup or interactions were missing (WebAIM Million 2026).
The ARIA Authoring Practices Guide describes which keys do what for each pattern, and it opens its guidance with the statement that no ARIA is better than bad ARIA (W3C, ARIA Authoring Practices Guide). For expandable details, a native details element or a button whose aria-expanded the script updates on opening and closing is often enough. More on this in the article on ARIA roles, states and live regions and in the hands-on guide to keyboard navigation.
Pattern 4: Invisible focus, faint text
The fourth pattern lives in the CSS. Generated style sheets fairly often contain a rule such as outline: none that suppresses the focus outline on click without providing a replacement. Keyboard users then no longer see where they are. SC 2.4.7 requires, at Level AA, a visible focus indicator for any keyboard operable user interface (W3C, WCAG 2.2). Next to it sit faint grays for hints, delivery times or placeholders. SC 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text (W3C, WCAG 2.2). Low text contrast was found on 83.9 percent of home pages in 2026, which made it the most commonly detected error (WebAIM Million 2026).
| Finding | Typical code | WCAG 2.2 | Detected automatically? |
|---|---|---|---|
| Click target without a role | div with onclick | 4.1.2, 2.1.1 | partly, keyboard test is manual |
| Button without a name | button with SVG, no text | 4.1.2 | yes, empty name is reported |
| Name without meaning | aria-label="Button" | 4.1.2 | no, meaning is checked manually |
| ARIA state without keyboard | aria-expanded on a div | 2.1.1, 4.1.2 | no, operation is tested manually |
| Focus outline removed | outline: none | 2.4.7 | partly, visual check with Tab |
| Faint hint text | gray on white | 1.4.3 | yes, contrast is calculated |
What automated tests find, and what they miss
Automated testing tools belong in every workflow that uses generated code, because they are fast, inexpensive and cover many pages. The publishers of the guidelines name their limits themselves: tools cannot check all accessibility aspects automatically, human judgment is required, and they cannot determine accessibility, they can only assist in doing so (W3C WAI). WebAIM also writes that the absence of detected errors does not indicate that a page is accessible or conformant (WebAIM Million 2026).
The UK government's Government Digital Service measured how large the gap can be. The team built a test page with 143 barriers and ran ten commonly used testing tools against it. 42 of the barriers were found by none of the tools, which is 29 percent (GDS 2017). Together, the tools found 71 percent; the rest would only have been caught by manual checking (GDS 2017). The test is a snapshot from 2017. That changes little about the core message: whether a name matches the purpose, whether the focus order follows the interaction logic and whether a menu can be fully operated by keyboard is something a person judges.
- Easy to detect automatically: missing alternative text, empty links and buttons, missing form labels, missing document language and low text contrast.
- Flagged automatically only as a hint: click handlers on non-interactive elements, ARIA attributes without a matching role, removed focus outlines and suspicious placeholder names.
- Testable only by hand: whether a name matches its purpose, whether every function can be reached and triggered with the keyboard, whether states are announced correctly during use and whether focus returns to the right place after a dialog closes.
Which testing methods exist and how they work together is explained in our overview of accessibility testing. It also explains why a score of 100 only shows that no automatically detectable error was found. As with overlays, automation that promises accessibility does not replace testing the delivered markup, as the article on accessibility overlays explains.
Building testing into the workflow
A test that only happens shortly before launch often finds the same patterns in many components of generated code, and each fix then costs a separate round. It is more effective to place testing where code is produced and adopted. Four steps have proven useful for this:
- Specification: The requirement for a component names accessibility explicitly, as an acceptance criterion and as a fixed building block of the prompt. Instead of “accordion for the product details”, it says: native
buttonelement witharia-expanded, operable with Enter and Space, visible focus, text contrast of at least 4.5:1. - Merge: Before merging, an automated test runs against the rendered component. It catches the obvious errors before they spread through the template into many pages.
- Sign-off: Before release, a person tests the component with a keyboard and at least one screen reader. Because the test questions are fixed, the effort per component stays manageable.
- Feedback loop: Every finding goes back into the specification, for example as a rule in the design system or as a sentence in the prompt building block, so that the same error does not come back in the next component.
In our experience, the third step is the one that most easily gets dropped in teams working with AI assistance. The generated code runs, the automated test is green, the component looks like the design. That is exactly where the four patterns slip through: they are visually inconspicuous and only show up when someone operates the page without a mouse. The formative study by Mowar et al. names the inability to verify the compliance of the result as the third key issue (Mowar et al. 2025). Acceptance criteria close this gap if they are concrete enough for anyone on the team to tick off.
## Acceptance criteria: component "Expand product details"
- [ ] Trigger is a native <button type="button">
- [ ] aria-expanded changes on opening and closing
- [ ] Operable with Tab, Enter and Space
- [ ] Focus outline visible, no outline: none without a replacement
- [ ] Screen reader name contains the visible label
- [ ] Text reaches a contrast of at least 4.5:1
- [ ] Automated test without findings, manual pass documentedTesting pays off most where generated code meets existing building blocks. If the design system provides a tested button, a tested accordion and a focus style, the instruction to the tool can be to use these building blocks instead of creating new ones. How to set up such a system is shown in the article on the accessible design system. For existing code, our accessible web development service handles the move to native elements and properly maintained states.
The test question before adopting any component
What this means for BFSG obligations
The German Accessibility Strengthening Act (BFSG) applies to e-commerce services provided to consumers after June 28, 2025 (BFSG, Section 1(3)). It does not distinguish by how the code was produced. Whoever runs an online store within the scope of the act is responsible for the button in the cart regardless of whether a person or a tool wrote it. If a service provider offers its service in breach of Section 14(1), this can be punished as an administrative offense with a fine of up to 100,000 euros (BFSG, Section 37).
The exemption for third-party content does not help here either. It only covers content that the economic operator concerned neither funds nor develops and that is not under its control (BFSG, Section 1(4) No. 4). Code that a team generates with a tool and adopts into its own site is, as a rule, the team's own code. Our overview of BFSG requirements summarizes which requirements apply in detail. Anyone sourcing components from an agency or service provider should write the acceptance criteria into the contract; how to do that is covered in the article on accessibility in contracts and acceptance.
Behind the criteria are people who rely on a keyboard, a screen reader or sufficient contrast. At the end of 2025, a good 7.8 million people with severe disabilities lived in Germany (Destatis). Not all of them use assistive technology, and many barriers from the four patterns also affect people without a recognized disability: someone who avoids the mouse because of tendinitis, someone looking at a display in sunlight or someone who is simply faster with the keyboard.
How an audit handles generated code
An audit against WCAG 2.2 treats generated code like any other code. It tests representative pages and components automatically and manually, by keyboard and in the screen reader output, and maps every finding to a success criterion. For teams that work heavily with AI assistance, it pays to take a second look at where the findings come from: if the same patterns show up in many components, the cause usually lies in the specification rather than in the individual component. In that case, a tested building block with an adjusted specification is more effective than a long list of individual fixes. Our WCAG audit provides a list of findings with criterion and remediation path, and the screen reader test shows what the components pass on to screen readers.
After the audit comes daily work, and with generated code the codebase often grows faster than before. Ongoing BFSG monitoring combines automated scans with manual spot checks and reports when new components bring back old errors. And because a specification is only as good as the knowledge of those who write and test it, training for development teams belongs in the plan as well. Our services give an overview from testing to implementation.
Sources
div with a click handler instead of a button, controls without an accessible name, ARIA states such as aria-expanded without keyboard support, and removed focus outlines along with faint text. They affect success criteria 4.1.2, 2.1.1, 2.4.7 and 1.4.3 (W3C, WCAG 2.2). On the home pages of the top one million websites, low text contrast tops the list, detected on 83.9 percent of them (WebAIM Million 2026).Related Articles
Accessible Customer Portals: Auditing the Login Area
Automated scans stop at the sign-in form. How a WCAG audit covers the protected area: scope, test accounts, session timeouts and screen reader testing.
Accessibility Audit Cost 2026: Prices, ROI, Funding
What a WCAG 2.2 audit costs in 2026: prices by scope, sampling versus full audit, monitoring, the BFSG fine ceiling, conversion ROI and funding at a glance.
Screen Reader Optimization: Making Your Website Readable
Screen reader optimisation for websites: ARIA landmarks, roles, live regions, semantic HTML and screen reader testing on Windows, macOS and mobile devices.