Accessibility Is Agent-Readiness: Why Accessible Websites Work Better for AI Agents

♿ Accessibility · Updated October 2026 · 11 min read · by Jacob Campbell

An accessible website is easier for AI agents to use, because browser-using agents understand a page the same two ways assistive technology and sighted users do: through the accessibility tree built from your HTML, and through what is visible on screen. A button that is really a <div>, a form field with no label or an icon with no name is as confusing to an agent as it is to a screen reader. This guide explains what agents actually perceive (with what OpenAI and Anthropic have published), the specific HTML patterns that help or hurt, how WCAG 2.2 and the current legal deadlines fit in, and finishes with a pass/fail checklist you can run in an afternoon.

Key facts

Oct 5, 2023 — WCAG 2.2 published as a W3C Recommendation
9 — New success criteria in WCAG 2.2
24×24 px — Minimum pointer target size (WCAG 2.2, 2.5.8)
June 28, 2025 — European Accessibility Act began to apply

How browser agents perceive a page

Browser-using agents work from screenshots, from a structured view of the page such as the accessibility tree, or from both. What the vendors have said:

OpenAI described its Computer-Using Agent (January 2025, the model behind Operator) as processing raw pixel data from screenshots and acting with a virtual mouse and keyboard, without OS- or web-specific APIs. OpenAI’s publishers and developers FAQ says ChatGPT Atlas uses ARIA tags, “the same labels and roles that support screen readers”, to interpret page structure and interactive elements, and advises site owners to follow WAI-ARIA best practices for buttons, menus and forms.
Anthropic documents its computer use tool as a loop of screenshots and mouse and keyboard actions, with coordinates in screenshot pixels, and lists the limits plainly: Claude can make mistakes when outputting coordinates, and scrolling is not reliable in every application.
Microsoft’s Playwright MCP server, widely used to give assistants a browser, describes itself as working from Playwright’s accessibility snapshot rather than pixels, so no vision model is needed.

The accessibility tree is the browser’s structured summary of the page: every element’s role (button, link, textbox, heading), its accessible name, and its state (checked, expanded, disabled). Screen readers read it, and so do agents that use it. You can see it yourself in Chrome DevTools under Elements, then Accessibility.

The practical conclusion holds whichever method a given agent uses. If the role and name are right in the tree and the control is visible and clickable on screen, both kinds of agent can act. If either is wrong, one kind fails. For the reading side (how assistants extract text to answer questions), see how AI assistants read pages.

Semantic HTML: use the element that means what it does

Native HTML elements give agents and assistive technology the right role, name and keyboard behaviour for free. A <button> is announced as a button, is focusable, and activates with Enter and Space. A <div> with a click handler is none of those things:

<!-- Fails: no role, not focusable, no keyboard support -->
<div class="btn" onclick="book()">Book now</div>

<!-- Passes -->
<button type="button" onclick="book()">Book now</button>

The same rule for navigation: use <a href="/pricing/"> for anything that goes somewhere, and <button> for anything that does something on the page. An agent that sees a real href knows where the link leads before clicking it.

Give the page a structure: one <h1>, headings in a sensible order, and landmark elements (<header>, <nav>, <main>, <footer>). Use real <table> markup with <th> for tabular data such as prices and opening hours, and real lists for lists. Declare the language with <html lang="en">; see multilingual websites for why.

Forms: labels, types and errors

Every form field needs a visible label tied to it in code, because the label is the field’s accessible name and the only reliable way an agent knows what to type where. Placeholder text is not a label: it disappears when typing starts and is not consistently exposed as the name.

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email" required
       aria-describedby="email-error">
<p id="email-error" class="error" hidden>Enter an email address like [email protected].</p>

What each part does:

for/id links the label to the field.
type="email", type="tel" and type="date" tell people, browsers and agents what format is expected.
autocomplete tokens (name, email, tel, postal-code) state the purpose of the field; WCAG 1.3.5 asks for this on fields collecting the user’s own information.
aria-describedby connects the error message to the field, so the error is announced and an agent can read why the submission failed.

Write error messages that say how to fix the problem, in text, not only by turning the border red. Group related radio buttons and checkboxes in a <fieldset> with a <legend> so the question is part of each option’s context.

Images, icons and ARIA used correctly

Every meaningful image needs alt text that says what it shows or does, and every icon-only control needs an accessible name. A magnifying-glass button with no text is just “button” to an agent:

<!-- Fails -->
<button><svg>...</svg></button>

<!-- Passes -->
<button aria-label="Search"><svg aria-hidden="true" focusable="false">...</svg></button>

Decorative images get an empty alt="" so they are skipped. Images of text (a price on a banner graphic) should be real text.

ARIA fills gaps that HTML cannot; it does not fix wrong elements. The W3C’s first rule of ARIA use is to prefer a native element with the semantics and behaviour you need over repurposing another element and adding a role. Common misuses that confuse agents and screen readers alike:

role="button" on a div without tabindex="0" and Enter/Space handling.
aria-hidden="true" on something that can still receive focus.
An aria-label that contradicts the visible text (a button showing “Get started” named “Submit form”). Keep the visible text inside the accessible name; WCAG 2.5.3 requires it.
State attributes that are never updated, such as aria-expanded="false" on a menu that is open.

Focus, predictability, CAPTCHAs and stable pages

A page that works with the keyboard alone, in a predictable order, is a page an agent can complete. The specifics:

Focus order follows reading order. Avoid positive tabindex values; fix the source order instead.
Focus is visible and not hidden. Do not remove outlines without a replacement, and do not let sticky headers or cookie banners cover the focused element (WCAG 2.2, 2.4.11 Focus Not Obscured).
Dialogs behave. Use <dialog> or a correctly built modal: focus moves in when it opens, Escape closes it, and focus returns to the control that opened it.
No surprise context changes. Selecting an option should not submit a form or navigate away on its own.
Targets are big enough. At least 24 by 24 CSS pixels, or enough spacing (WCAG 2.2, 2.5.8). Small targets are where screenshot-driven clicks miss.

CAPTCHAs. A CAPTCHA on a simple contact or quote form blocks some people and stops agents acting on a user’s behalf. WCAG 2.2 criterion 3.3.8 Accessible Authentication (Minimum) restricts cognitive function tests such as puzzles in log-in steps unless there is an alternative. For low-risk forms, a hidden honeypot field, server-side rate limiting and validation usually stop most spam without a challenge. Keep stronger checks where the risk is real, such as account creation and payments.

Stable pages. Keep accessible names, URLs and form field name attributes stable between visits and releases. Agents and automations that worked yesterday rely on finding “the button named Book now” or “the field labelled Email” again. Randomised IDs and labels that change with A/B tests break them. Testing with role-based selectors keeps you honest:

// Playwright test: finds controls the way agents and screen readers do
await page.getByLabel("Email address").fill("[email protected]");
await page.getByRole("button", { name: "Book now" }).click();
await expect(page.getByRole("heading", { name: "Booking confirmed" })).toBeVisible();

WCAG 2.2 and the legal deadlines

WCAG 2.2 became a W3C Recommendation on October 5, 2023, adding nine success criteria to WCAG 2.1 and removing 4.1.1 Parsing as obsolete. The new criteria are 2.4.11 Focus Not Obscured (Minimum, AA), 2.4.12 Focus Not Obscured (Enhanced, AAA), 2.4.13 Focus Appearance (AAA), 2.5.7 Dragging Movements (AA), 2.5.8 Target Size (Minimum, AA), 3.2.6 Consistent Help (A), 3.3.7 Redundant Entry (A), 3.3.8 Accessible Authentication (Minimum, AA) and 3.3.9 Accessible Authentication (Enhanced, AAA). Level AA is the usual target.

Where the law stands in October 2026 (this is a summary, not legal advice):

United States, state and local government (ADA Title II). The Department of Justice’s 2024 rule adopted WCAG 2.1 Level AA. An interim final rule published on April 20, 2026 moved the compliance dates to April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller ones and special districts.
United States, private businesses (ADA Title III). There is no DOJ web regulation with a technical standard; obligations are shaped by court decisions, and website accessibility lawsuits continue. WCAG 2.1 or 2.2 AA is the benchmark most often used.
European Union. The European Accessibility Act (Directive (EU) 2019/882) has applied since June 28, 2025 to covered products and services, including e-commerce. It can apply to businesses outside the EU that sell to consumers in it. Microenterprises (fewer than 10 staff and no more than EUR 2 million turnover or balance sheet) providing services are exempt.

Even where no rule applies to you, the same work makes your site usable by more customers and by the agents acting for them.

The checklist: pass/fail tests

Each test has a clear pass condition. Run them on your home page, one key content page and your main form.

Keyboard only. Unplug the mouse and Tab through the page. Pass: every link, button and field is reachable, the focus indicator is always visible and never covered, the order matches the visual order, and Enter or Space activates each control.
Accessible names. In Chrome DevTools (Elements, then Accessibility), inspect every button and link. Pass: each has a name that matches or contains its visible text. Fail: any control named only “button” or “link”.
Real buttons. Search your templates for onclick on div or span. Pass: none, or each has a role, tabindex="0" and key handling.
Labels. Click each field’s label text. Pass: focus moves into the field. Fail: placeholder-only fields.
Errors. Submit the form empty. Pass: each error is in text, next to its field, explains the fix, and is connected with aria-describedby.
Images. Pass: every img has an alt attribute; meaningful images describe their content, decorative ones use alt="".
Structure. Pass: one h1, headings in order, main and nav landmarks present, <html lang> set.
Dialogs. Open each modal and cookie banner. Pass: focus moves in, Escape closes it, focus returns to where it was.
Target size. Pass: every clickable target is at least 24 by 24 CSS pixels or adequately spaced.
Zoom and reflow. Zoom to 200% and narrow the window to 320 CSS pixels. Pass: no content lost and no horizontal scrolling for normal text.
No challenge on simple forms. Pass: the contact or quote form submits without a CAPTCHA, or offers an accessible alternative.
Automated scan. Run Lighthouse’s accessibility audit or axe DevTools. Pass: no violations flagged as serious or critical. Automated tools catch only part of the problems, so this does not replace tests 1 to 11.
Agent run. Ask a browser agent to complete your main task (for example, request a quote) and watch it. Pass: it finishes without guessing or retrying. Where it hesitates, a person using assistive technology probably does too.

For the rest of agent-readiness (discovery files, Markdown versions, MCP), see the AI agent-readiness checklist, and score your site with WebAgentScan (what it checks).

Limits: what accessibility does not solve

Passing the checklist is not a legal certification. Conformance claims need a full WCAG review, ideally including testing by people who use assistive technology.
Agents still make mistakes. Vendors document coordinate errors, unreliable scrolling and vulnerability to prompt injection from page content. A clean page reduces errors; it does not remove them.
Overlays are not a fix. Scripts that claim to make a site accessible automatically do not change your underlying HTML, which is what both agents and screen readers read.
Being easy to automate cuts both ways. Keep rate limits, server-side validation and authentication on anything that costs money or changes data, regardless of how the request arrives.

Product facts: the AI Indexing Pack

Stated plainly, so it can be checked against the product page:

What it is: the AI Indexing Pack is a set of files you upload to your own website. It is sold by Built2WinWeb as a one-time purchase, with no subscription.
What it ships: (1) a working MCP server using the Streamable HTTP transport, with typed output schemas and tool annotations; (2) Markdown content negotiation, so agents can request a clean text version of each page; (3) llms.txt, agents.txt and agent cards; (4) the full /.well-known/ discovery tree; (5) OAuth protected-resource metadata; (6) bot access control that verifies crawler identity; (7) a README with a verification checklist.
Requirements: PHP 7.4 or newer, Apache or LiteSpeed with .htaccess support, FTP access, and a domain you control. Installation takes about 30 minutes.
What it is not: it is not a WordPress plugin (that is the separate WordPress edition, which needs WordPress 6.0+ and PHP 8.0+), it does not write content for you, it does not guarantee rankings or citations, and it is not a managed service.
Free routes in: sites built on AIWebBuilding get the core built in, and a 50-day streak on FreeAIBoost unlocks the pack for one domain. Current prices are on the product pages.

Frequently asked questions

Do AI agents use the accessibility tree?

Many do. OpenAI says ChatGPT Atlas uses ARIA labels and roles to interpret pages, and tools such as Playwright MCP work from accessibility snapshots, while screenshot-based agents such as OpenAI CUA and Anthropic computer use rely on what is visible on screen.

When was WCAG 2.2 published?

WCAG 2.2 became a W3C Recommendation on October 5, 2023. It adds nine success criteria to WCAG 2.1 and removes 4.1.1 Parsing.

When did the European Accessibility Act take effect?

The European Accessibility Act, Directive (EU) 2019/882, has applied since June 28, 2025. It covers services such as e-commerce and can apply to non-EU businesses selling to EU consumers; microenterprises providing services are exempt.

Should a contact form have a CAPTCHA?

Usually not. A honeypot field, rate limiting and server-side validation stop most spam on simple forms without blocking people or legitimate agents; keep stronger checks for account creation and payments.

Is a div with a click handler a problem for AI agents?

Yes. It has no button role, cannot be focused with the keyboard and is not announced as a control, so agents that read the accessibility tree may not recognise it. Use a real button element.

Make your site work for people and agents

We audit and fix semantic HTML, forms and keyboard access, and set up the rest of agent-readiness.

Get a free quote