Why Static Accessibility Scanners Miss What AI Agents Hit

This button passes every automated accessibility scan we've thrown at it:

<button class="btn-primary" type="button">
  Check availability
</button>

And it breaks every AI agent that tries to book a room through it.

The markup is clean: a real <button>, a proper accessible name from its text content, an explicit type. Nothing to flag. The failure isn't in the button, it's in what happens after the click. And no static scanner ever clicks.

What a scanner actually sees

Static accessibility scanners evaluate the DOM at a point in time. Usually the initial render: HTML parsed, framework hydrated, nothing interacted with. They check that state against WCAG rules, missing alt text, contrast ratios, label associations, heading order.

That's genuinely useful. It's also a photograph of a lobby, when the task happens in the hallways.

Here's what never appears in the initial DOM of a typical booking flow:

• The date picker that mounts when the check-in field receives focus
• The error message injected after a failed form submit
• The room-selection modal that opens on "Check availability"
• The loading state between "Book now" and the confirmation

A scanner reports zero issues on all of these, for the simple reason that at scan time, none of them exist.

What an agent actually traverses

An AI agent completing a booking doesn't evaluate a snapshot. It walks the flow: reads the accessibility tree, decides on an action, performs it, waits for the interface to respond, reads the tree again. Every state transition is a place where the tree can lie to it.

Let's look at three patterns we keep finding in real audits. All three pass static scans. All three stop an agent.

1. The modal that exists on screen but not in the tree

{isOpen && (
  <div className="modal-overlay">
    <div className="modal">
      <h2>Select your room</h2>
      <RoomList rooms={available} />
    </div>
  </div>
)}

Visually: a modal. In the accessibility tree: a div soup appended somewhere in the body, with no role="dialog", no aria-modal, no focus management. The page behind it is still fully exposed in the tree.

A sighted user sees the overlay and understands the context switched. An agent reading structure sees the entire page plus some new divs, with nothing indicating that the interaction context has changed or that everything else is now inert. It clicks on background elements. The modal never gets resolved. The booking dies here.

The fix is old news, role="dialog", aria-modal="true", move focus in, trap it, restore on close. What's new is the cost of skipping it: it used to degrade one user's session; now it also terminates every automated task, silently.

2. The status message nobody announced

const [error, setError] = useState(null);
// after failed submit:
setError("Check-out date must be after check-in date");
return (
  <>
    {error && <p className="form-error">{error}</p>}
    <BookingForm onSubmit={handleSubmit} />
  </>
);

The error renders. It's red, it's visible, a scanner running after the failed submit might even find its contrast acceptable. But it's not in a live region, no role="alert", no aria-live. Nothing announces that the state changed.

An agent submits the form, the request fails, and from the tree's perspective... nothing happened. Same form, same fields. So it does the only reasonable thing: it retries. Same data, same silent failure. Then it gives up and moves on to a competitor whose form talks back.

This one gets worse with concurrent rendering: if the state update is batched or deferred, even a well-intentioned live region can fire before the text lands in the DOM. Announcing state changes reliably is its own engineering problem — one that static analysis is structurally unable to see, because the whole bug lives in the timing between states.

3. The keyboard trap that only exists mid-flow

datePicker.addEventListener('keydown', (e) => {
  e.preventDefault();          // ← the entire bug
  handleCustomNavigation(e);
});

A custom date picker that swallows every key event, including Tab and Escape. You can get in. You cannot get out without a mouse.

For a keyboard user this is WCAG 2.1.2, a hard failure, if the auditor opens the picker. A static scan of the page never opens it, so the trap doesn't exist on the report.

For an agent operating through the accessibility tree, a trap like this is terminal. There is no "just use the mouse" fallback when your entire interaction model is structural. The task doesn't fail loudly; it hangs, times out, and the agent leaves.

The gap, defined

Put simply:

Static scanners answer "does this DOM state violate WCAG?" Agents ask "can I complete the task?" Those are different questions, and the distance between them is exactly where the expensive failures live.

The failures that block task completion share a profile: they're stateful (they only exist after an interaction), they're structural (invisible on screen, broken in the tree), and they're silent (no error, no signal, no analytics trace). A user who hits them might call your support line. An agent that hits them just leaves.

Measuring the gap

We started measuring this on real projects: run a standard static scan, then walk the same flows interaction by interaction, clicking, submitting, waiting for renders, and log what breaks the task. In our audits, interaction-level testing with A11yDetector has caught 82.4% of the real issues, against roughly 22% for typical static-only tooling. The difference isn't better rules. It's when you look.

If you want to check your own flow, don't start with a full audit. Start with one journey, say, your booking or checkout form, and test three moments: the widget that opens, the error that appears, the state that changes. If any of those doesn't reach the accessibility tree, you've found the gap.

The web is about to be navigated by a lot of things that don't look at the screen. The accessibility tree is the interface they get. It's worth making sure it tells the truth.