Back to Blog

Best Practices

Can AI agents actually use your website? We measured 1,556 pages

We scanned 116 European business websites to find out whether an AI agent could operate them. 114 of 116 had at least one finding that stops a machine — 4,735 links and 607 buttons with no name a machine can read.

2 August 2026

12 min read

Ravid, Webply

The short version

We scanned 116 European business websites — 1,556 pages — and counted only the failures that stop a machine, not the ones that stop a person. 114 of the 116 had at least one. Two were clean. The most common problem is not exotic: 4,735 links and 607 buttons across the corpus have no name a machine can read, and another 3,196 links are named "click here".

An AI agent that books a table, compares two products, or fills in a quote form has to do something a human never consciously does: work out, from markup alone, which thing on the page is the button, what that button does, and what happens after it is pressed.

We have been scanning European business websites for accessibility since June. That corpus turns out to answer a different question at the same time — because the structure an agent needs is the same structure a screen reader needs. So we ran the numbers.

What we counted, and what we deliberately didn't

Our scan corpus is 116 sites: hotels, online shops and service businesses in Austria, Germany and Switzerland, scanned between 5 June and 28 July 2026. After excluding pages that failed or were skipped, 1,556 pages remained.

From every automated finding on those pages, we kept only the checks whose failure means a machine cannot determine what an element is or does:

controls with no accessible name (link-name, button-name, select-name, frame-title, the ARIA name rules)
form fields with no programmatic label (label, label-title-only)
missing document structure (region, landmark-one-main, document-title, html-has-lang, page-has-heading-one)
images carrying meaning with no text alternative (image-alt, role-img-alt, svg-img-alt)
names that exist but carry no information (link-text-generic, button-name-generic, img-alt-quality)
ARIA that misreports the element it is attached to (aria-required-children, aria-allowed-role, aria-valid-attr-value)

And we deliberately excluded the rest of the accessibility surface. Colour contrast is the clearest example: text at 3:1 against its background is a genuine barrier for a person with low vision, and it is completely irrelevant to an agent reading the accessibility tree. Same for disabled zoom, motion, and timing. Those matter enormously — they are just not what this measurement is about.

This is not a repackaged accessibility score. It is a narrower, harder question: can a machine operate this page at all?

The result

114 of 116 sites had at least one agent-blocking finding. 1,441 of 1,556 pages — 92.6% — had at least one. Two sites in the whole corpus were clean.

The shape of the failures is more interesting than the headline. The three most common categories are all about legibility, not features:

Structure is missing on 111 of 116 sites (95.7%). On 105 sites, at least one page had content sitting outside any landmark — 12,805 elements across the corpus. On 68 sites, at least one page had no <main> at all. An agent that cannot tell the navigation from the main content has to infer the page's shape from raw DOM order, which is exactly the guesswork that makes agent behaviour unreliable.

Names that say nothing appear on 104 of 116 sites (89.7%). 3,196 links across the corpus are named "click here", "more", "read more", or "here". These pass a naive check — the link has a name — and tell a machine nothing whatsoever about where it goes. A human reads the surrounding sentence and infers the destination. An agent working from the accessibility tree gets a list of links, most of which are called "more".

Controls with no name at all appear on 102 of 116 sites (87.9%). This is the sharpest one: 4,735 links and 607 buttons in the corpus have no accessible name of any kind. Typically these are icon-only controls — a magnifying glass, a hamburger, a cart, a close X — implemented as an icon font or an inline SVG with no label. To an agent, the cart button on those sites does not announce itself as anything.

Below those, the numbers drop but stay substantial: ARIA that misreports itself on 57 sites, images with no text alternative on 52 sites (781 of them failing image-alt alone), and form fields with no label on 46 sites (420 fields failing label alone).

Why 420 unlabelled form fields is the expensive number

Most of the findings above degrade an agent's understanding. Unlabelled form fields stop it.

An agent filling in a booking or checkout form has to map "the customer's postcode" to a specific input. The only reliable way to do that is the field's programmatic label. Without one, the agent is reduced to guessing from placeholder text, adjacent DOM text, or visual position — all of which are brittle, and all of which fail differently on every site.

Form fields cluster in exactly the places where a completed task is worth money: checkout, booking, quote request, sign-up. 46 of our 116 sites have at least one page where an agent would be guessing.

The uncomfortable part: this is your template, not your content

Across the corpus, the failures are not distributed the way genuinely independent mistakes would be. They repeat.

We found the same pattern in our study of 51 Austrian hotel websites, where four checks accounted for 73% of 37,802 findings. The explanation there was shared templates and booking widgets — sites failing together because they were built on the same components.

It holds here too, and it is good news. 4,735 unnamed links across 79 sites is not 4,735 separate mistakes. It is a much smaller number of components — a header, a card, an icon button, a slider — each shipped across many pages and often across many clients of the same agency. A name added once to a shared component fixes it everywhere it renders.

That is why the fix list is short even though the finding count is large.

What to actually do

In rough order of payoff per hour:

Name every icon-only control. Search your codebase for buttons and links whose only child is an <svg> or an icon component. Add aria-label. This alone addresses the single largest category.
Replace "click here" and "read more". The link text should describe the destination — "Read the cancellation policy", not "read more". This is the same edit that helps a screen-reader user scanning a link list, and the same edit search engines have wanted for twenty years.
Label every form input. A real <label for="…">, or aria-label where a visible label genuinely doesn't fit. Placeholder text is not a label — it disappears on focus and is not exposed as one.
Add landmarks. One <main>, one <nav>, one <header>, one <footer>, per page. This is usually a handful of wrapper elements in one layout file.
Set lang on <html>. 55 sites were missing it. It costs one attribute and it tells any language model which language it is reading, which matters more in multilingual markets than in English-only ones.

If you want to see which of these apply to your own site before changing anything, our Instant Check runs the same checks on your homepage without a signup.

The part that changes the business case

For three years, the argument for accessibility work in Europe has been legal: the European Accessibility Act applied from 28 June 2025, and non-compliance carries penalties. That argument works on the companies that believe enforcement is coming, and it visibly does not work on the ones that don't.

This measurement offers a second argument that does not depend on anyone's enforcement forecast. If a growing share of your visitors arrive as software — an assistant comparing prices, an agent booking on someone's behalf, a model deciding what to cite — then the accessibility tree stops being a compliance artifact and becomes the interface. A site that a machine cannot read does not get recommended, quoted, or completed.

Both arguments point at the same fix list. That is unusual, and it is the reason to do the work now rather than when either pressure becomes acute.

Method and limitations

Stated plainly, because a number without its caveats is not evidence:

The corpus is not a random sample of the web. These are 116 businesses we selected for accessibility outreach — hotels, online shops and service SMBs in the DACH region. They skew toward small and mid-sized companies on agency-built or platform templates. A sample of large enterprise sites would likely look different, and a sample of hand-built modern React apps would look different again.
These are automated checks only. Automated testing catches somewhere around a third to a half of real accessibility issues. Everything reported here is a finding a machine could verify; nothing here is a manual judgement.
A finding is not a guarantee of failure. An agent may still complete a task on a page with unnamed controls, by falling back on vision or DOM heuristics. What the finding means is that the reliable path is missing and the agent is guessing.
Site-level and page-level numbers differ, on purpose. "111 of 116 sites" means at least one page of that site failed. "78% of pages" is the page-level rate. Quoting one as the other overstates the case, so both are given throughout.
No site is named. The corpus is prospect data; we publish the aggregate, never the individual scores.

Frequently asked questions

What makes a website readable to an AI agent?

An agent needs to know, for every control on the page, what it is and what it does. That information lives in the accessibility tree — the role, name and state the browser exposes for each element. A button with a real accessible name is legible to a machine. A styled div with an onclick handler is not: the agent sees a box with text and no indication that clicking it does anything. Structure matters just as much — landmarks tell an agent which part of the page is navigation, which is the main content, and which is the footer.

How did you measure this?

We took our own deep-scan corpus — 116 European business websites, 1,556 successfully scanned pages, scanned between 5 June and 28 July 2026 — and counted only the automated checks whose failure means a machine cannot determine what an element is or does. Colour contrast, for example, is excluded: it is a real barrier for people but an agent reading the accessibility tree is unaffected by it. Failed and skipped pages were excluded from every denominator.

Is this the same as an accessibility score?

No, and that distinction is the point. An accessibility score covers everything that blocks a human, including contrast, zoom, motion and timing. This measurement covers only the subset that blocks a machine — missing names, missing labels, missing structure, missing text alternatives, and ARIA that misreports itself. The two overlap heavily but they are not the same number, and a site can score reasonably on accessibility while still being close to unusable for an agent.

Does fixing this help with anything other than AI agents?

Yes — that is what makes it worth doing. Every check in this measurement is also a WCAG 2.1 requirement or an established best practice, so the same work makes the site usable for screen-reader users and moves it toward European Accessibility Act conformance. It is unusual to find a fix list that serves a legal obligation and a commercial opportunity with the same edits.

Which single fix helps the most?

Give every link and button a real accessible name. Across the corpus, 4,735 links and 607 buttons had no machine-readable name at all, and a further 3,196 links had a name like "click here" that carries no information about the destination. Unnamed and uninformative controls are the failures that most directly stop an agent from completing a task, and they are usually concentrated in a handful of shared template components.