Can AI accessibility testing make a site WCAG compliant on its own?

No. Automated engines evaluate the criteria that reduce to measurable DOM, style or geometry properties — contrast ratios, label relationships, ARIA validity, target sizes, focus traversal. Criteria that depend on meaning, such as whether alt text is useful (1.1.1), whether focus order is logical (2.4.3) or whether an error message suggests a correction (3.3.3), require human judgment. Automation plus a short keyboard-only pass on your main conversion path is the realistic combination.

Why did my automated accessibility scan come back clean on a broken page?

Almost always because the scan never reached the broken state. Rule engines evaluate the DOM as rendered at the moment they run, so logged-in dashboards, form error states, modals and mobile breakpoints are invisible unless something drives the app into them first. Script the login, open the modal, submit the form empty and set a 375px viewport, then scan — that change usually surfaces more than swapping engines would.

Do AI coding tools produce less accessible code?

They produce code that works with a mouse, which is how it gets reviewed. Common patterns include div elements with click handlers instead of buttons, placeholders used in place of labels, icon-only buttons with no accessible name, and generated color palettes that land just under the 4.5:1 contrast threshold. None of these throw errors or look wrong in a screenshot, so they pass review and reach production.

Is there a compliance deadline agencies should know about?

Two concrete reference points. The European Accessibility Act's requirements apply to covered products and services from 28 June 2025. In the US, the Department of Justice's 2024 Title II rule adopted WCAG 2.1 Level AA for state and local government web content, which affects agencies doing municipal, transit, library or public university work. Separately, procurement documents increasingly name a WCAG level as an acceptance criterion, which makes it a contractual deliverable regardless of jurisdiction.

AI Accessibility Testing: What It Catches and What It Misses

AI accessibility testing uses automated rule engines and AI agents to check a rendered page against WCAG success criteria — contrast ratios, missing form labels, broken ARIA, unreachable focus targets — and, crucially, to drive the interface into the states where those failures actually live. It reliably catches the machine-checkable criteria, which cover a meaningful share of what breaks real keyboard and screen-reader use. What it cannot do is judge whether alt text is meaningful, whether focus order makes sense, or whether an error message tells someone what to fix — those still need a human pass or a persona-driven walkthrough.

What is AI accessibility testing, exactly?

It is two layers that get talked about as one thing. The first is a deterministic rule engine: open-source engines like axe-core, Lighthouse and pa11y walk the rendered DOM and evaluate it against a ruleset derived from WCAG. No model is involved — a contrast ratio either clears 4.5:1 or it does not. This layer is fast, repeatable and belongs in CI.

The second layer is where the "AI" earns its name, and it is mostly about reach and judgment. A rule engine only sees what is rendered at the moment it runs: if your checkout error state, cookie banner, logged-in dashboard or 375px breakpoint never render during the scan, nothing inside them is checked and the report comes back clean. An agent that can log in, open the modal and submit the form empty gets the engine in front of the states that matter, and a model can flag what a rule engine must stay silent about — alt text that exists but says nothing, a heading hierarchy that is visually right and semantically wrong.

Clean scan, broken page is the normal failure mode here. The engine is not wrong; it was pointed at the wrong three seconds of your app. It is the same reach problem described in the complete guide to AI QA: coverage is a function of states visited, not pages crawled.

What can AI accessibility testing catch reliably?

Anything that reduces to a measurable property of the DOM, the computed styles or the geometry of the page. These are worth knowing by name, because they are the ones you should never ship:

Automated check	WCAG criterion	Why it is machine-checkable
Body text below 4.5:1 contrast (3:1 for large text)	1.4.3 Contrast (Minimum)	Computed from resolved foreground/background colors
Buttons, inputs, icons below 3:1 contrast	1.4.11 Non-text Contrast	Same computation, applied to UI components
Form control with no programmatic label	1.3.1, 4.1.2	A DOM relationship either exists or it does not
Image with no `alt` attribute at all	1.1.1 Non-text Content	Attribute presence check
Interactive target smaller than 24×24 CSS pixels	2.5.8 Target Size (Minimum), WCAG 2.2	Pure geometry
Focused element hidden behind a sticky header or footer	2.4.11 Focus Not Obscured, WCAG 2.2	Geometry captured during a scripted tab traversal
Keyboard trap, or a control that tab order never reaches	2.1.1, 2.1.2	Scripted traversal of the focus order
ARIA role missing its required attributes, or in an invalid parent	4.1.2 Name, Role, Value	Validation against the ARIA specification
Missing `lang`, duplicate IDs, skipped heading levels	3.1.1, 1.3.1, 4.1.1	Document structure inspection

Note how many of those come from the stack, not from a careless developer: icon-button components that ship without an accessible name, design tokens that produce a muted grey landing just under 4.5:1, a styled div that looks like a button and reports as a generic container.

What does AI accessibility testing miss?

Everything that depends on meaning. These criteria are the reason "we run axe in CI" is not the same sentence as "the site is accessible":

Whether alt text is useful. alt="image" passes the attribute check and fails the user. So does alt="chart.png" on a chart that carries the whole argument of the page.
Whether focus order is sensible. A page can have a complete, trap-free tab order that jumps from the header to the footer to the middle of a form. Nothing is technically broken; the form is unusable without a mouse.
Whether an error message is actionable. Criteria 3.3.1 and 3.3.3 ask that an error be identified and a correction suggested. "Invalid input" satisfies neither, and no engine can tell you so.
Whether headings describe structure. A styled div that looks like a section heading leaves a screen reader user with a page that has no outline.
Whether link text makes sense out of context. Twelve links reading "Learn more" pass every automated rule and defeat navigating a page by its link list.
Whether the task can actually be completed. This is the question clients care about, and it is not a page-level property at all. It is answered by walking the whole flow — which is what persona-driven runs in Sims are for.

Why do accessibility bugs reach the client before the agency sees them?

Three reasons, and they compound.

They are silent. An unlabeled input throws no console error, fails no unit test and looks normal in a screenshot. Your pipeline is green, your visual diff is clean, and the defect is in production. It is the blind spot covered in AI visual regression testing: a pixel comparison cannot see a missing accessible name, because accessibility lives in the parts of the DOM that never get painted.

They live in unscanned states. Most one-off audits scan public, logged-out, desktop pages. Forms in their error state, modals, multi-step flows and the mobile breakpoint are where labels, focus management and target sizes actually fail.

AI-generated UI code introduces them structurally. Ask a coding assistant for a dropdown and you may well get div elements with click handlers, a placeholder standing in for a label, and an icon-only close button with no accessible name. It works perfectly with a mouse, which is how it gets reviewed and approved. If you ship from Cursor, Lovable, v0 or Bolt you generate these faster than you can read them — how to test for accessibility bugs has the manual checklist that catches the worst of it.

Is this becoming a contractual problem?

It already is, in two concrete ways worth knowing before your next proposal.

In the EU, the European Accessibility Act's requirements apply to covered products and services from 28 June 2025, pulling many consumer-facing commerce and service sites into scope. In the US, the Department of Justice's 2024 Title II rule adopted WCAG 2.1 Level AA for state and local government web content, so any agency touching municipal, transit, library or public university work now has a named conformance target.

The practical consequence is simpler than the legal detail: procurement language increasingly names a WCAG level as an acceptance criterion. When "WCAG 2.2 AA" appears in a statement of work, accessibility becomes a deliverable you can be held to — and an automated check on every build is far cheaper than a remediation sprint after a client's legal review.

How should a small team run accessibility checks without a QA department?

Put a rule engine in CI and baseline the existing violations. Fail the build on new violations only. A gate that dumps hundreds of pre-existing issues gets switched off in a week; one that says "this PR added two" gets fixed.
Scan states, not URLs. Script the login, open the modal, submit the form empty, set the viewport to 375px wide — then run the engine. This single change usually finds more than switching engines ever will.
Tab through the primary conversion path once per release. Hands off the mouse, complete the signup or checkout. Five minutes, and it catches the focus-order problems no engine will phrase as a failure.
Check contrast in the palette, not in the build. It is decided once in your design tokens and inherited everywhere, so fixing it there fixes every page at once.
Capture evidence at the moment of discovery — the DOM node, page state, computed ratio and viewport. Accessibility bugs are state-dependent, so they are exactly the kind that come back marked "cannot reproduce", which is what right-click capture in Snap prevents.

Run the automated layer on a schedule rather than only before launch, and have AutoSim re-walk the critical flows so a refactor that quietly drops a label is caught on the commit that caused it, not in the client's acceptance review.

What is the honest summary?

AI accessibility testing is a reach-and-triage tool, not a conformance certificate. It will find the contrast failures, unlabeled inputs, invalid ARIA and tab traps across far more of your app than a human audit ever will, on every commit — but it will not tell you whether someone navigating with a screen reader can finish the job. Automate the measurable layer; spend your scarce human attention on the judgment criteria.

Scan your next client site free

Klavity runs accessibility, visual and functional checks against the states your app is actually in — logged in, mid-flow, at mobile width — and files each finding with the evidence a developer needs to fix it without asking you a question. Scan your next client site free and see what your current build is shipping.