Skip to main content
Ihr Browser ist zu alt, um diese Website korrekt anzuzeigen. Bitte aktualisieren Sie auf die neueste Version von Chrome, Edge, Firefox oder Safari.
Zurück zum Blog
AIWCAGDevelopers

AI-built websites and AI agents depend on the same thing: accessible markup

AI coding tools are adding ARIA that breaks pages, and AI agents now navigate the web the way screen readers do. Why the accessibility tree has become your interface for both, and what to check.

AccessiSight team
Accessibility engineering
2. Oktober 2026

Two things everyone is talking about, AI-generated websites and AI agents that browse for people, meet at a part of the web most teams never look at: the accessibility tree.

AI-built pages are adding errors

The WebAIM Million 2026 found that home pages using ARIA averaged 59.1 errors, against 42 for pages without it, and WebAIM named AI-assisted coding as one factor behind the year's rise in errors.

A vendor test points the same way. AudioEye, which sells an overlay product, had five AI tools build 15 sites and reported that all 15 failed WCAG Level A, with 55 issues per page on average. Treat that as vendor research, published in VentureBeat by the company's CEO, but it matches what independent data shows.

The pattern is familiar: generated code adds role, aria-label and aria-hidden attributes that look helpful and contradict the HTML underneath, or puts click handlers on <div>s that keyboards and screen readers can't use.

AI agents read pages like screen readers do

Cloudflare reported on 30 September 2026 that more than half of internet traffic it sees is no longer human, and that daily requests from AI agents grew more than 1,700% in a year. An agent that books a table or fills a form needs to know what each element is and what it does. Many agents get that from the same place a screen reader does: names, roles and states in the accessibility tree.

So a button that a screen reader announces as just "button", or doesn't announce at all, is a button an agent may not find either.

What to check

  • Use native elements first. <button>, <a href>, <label>, <select> come with the right role, keyboard behavior and states for free. ARIA is for the gaps.
  • Give every control a name (WCAG 4.1.2). Icon buttons need an aria-label or visible text.
  • Review AI-generated markup like any other code. Look for ARIA that repeats or contradicts the HTML, and remove it.
  • Look at the accessibility tree, not just the screen. Browser dev tools show it, and AccessiSight's scan report includes a tree view of the page as assistive technology receives it.

Sources: WebAIM: The WebAIM Million, VentureBeat, 30 Sep 2026 and Cloudflare blog, 30 Sep 2026.