Every accessibility platform vendor now touts some form of AI-powered WCAG compliance, but many of them don’t go beyond the buzzwords.

We’ve been building accessibility software since 2011. We believe accessibility should be universal, and that we all still have a long way to go before we achieve that.

The field of digital accessibility testing has changed dramatically since we started, the most recent major shift now coming as a result of AI and the capabilities it unlocks.

Despite everything that’s different now, in 2026 every auditing platform still runs rules-based checks, with machine learning (and often a large language model) layered on top. The choice isn’t between approaches, but how much of each a vendor actually built, and how honestly we as the builders describe the line between what the machine decides and what a person still has to sign off on.

Automated accessibility testing has lived through three distinct eras (so far)

Every platform today runs on tech older than its marketing may suggest.

Rule-based DOM scanning came first. It’s deterministic, cheap, and CI-friendly. Deque Systems open-sourced axe-core in 2017, giving rivals a shared rule engine. Using this tech Google added accessibility auditing to Lighthouse in its early versions, well before AI entered any vendor’s pitch.

Machine learning layered on next, years before generative AI entered the picture. Generative AI-assisted interpretation is the newest and least mature layer, and neither it nor machine learning replaced what came before.

Rules-based scanners

A DOM-parsing engine doesn’t guess. It checks whether an alt attribute exists, whether a form input has a label, whether a foreground-to-background contrast ratio clears the WCAG contrast requirement of 4.5:1, whether two elements share an ID, whether an ARIA role points to something real, and so on. WebAIM’s WAVE, launched in 2001, made this kind of check public and free years before anyone was pitching AI accessibility tools. You can run a similar free accessibility checker today without installing anything.

That’s what makes the whole category CI-cheap. A contrast failure is either true or false. You don’t need a manual reviewer to weigh in on whether 2.8:1 passes. This determinism is the load-bearing wall for everything built afterward. Machine learning and generative AI still run on top of a rule layer doing the same job WAVE did in 2001, because that job never needed replacing.

Machine learning took over pattern recognition years before generative AI

Evinced launched in 2021 with a different premise: Instead of parsing static markup, its models watched the rendered DOM and visual output, catching what a rule engine physically can’t see. Visual regression tools like Applitools and Percy took a related approach, adding accessibility-aware diffing that flags when a UI update breaks a focus order or changes a widget’s behavior between builds. It was built to catch problems in JavaScript-heavy interfaces where the accessibility tree changes after the page loads, where axe-core-style scanners struggle.

By the time generative AI entered the conversation, ML-based pattern recognition had already been catching focus-trap bugs and custom-widget keyboard failures for teams who had never heard of an AI accessibility feature.

LLMs are now handling judgment calls

In the beginning, a human still reviewed AI content to decide if it was right. Not so much anymore. But that division of labor – generate first, approve second – is what separates an AI feature worth keeping from a liability.

Handed a raw violation list full of success-criterion numbers, an LLM can rewrite “2.4.7 Focus Visible: failure” as “your search button loses its outline when tabbed to, so keyboard users can’t see where they are,” something a content manager can act on without opening the WCAG spec.

That plain-language translation extends to explaining why, not just what. Say an error code says aria-hidden=”true” is present on a focusable element. An LLM can explain that a screen reader user will never learn the button exists, because the attribute hides it from the accessibility tree while leaving it reachable by tab, which is the kind of context-dependent misuse a rule engine flags but can’t narrate.

But drafting and explaining, not deciding, are an LLM’s strengths. These systems struggle when tasked with making decisions with zero human input, because as convincing as they can sometimes be, LLMs don’t actually “know” anything.

Rolling out an AI-assisted platform now takes weeks, not quarters

AI has made it so anyone can make just about any digital tool they can think up, and do it quickly without putting the proper guardrails in place. We’ve watched others in our space rush out “features” without performing what we would consider the requisite amount of testing prior to a launch.

Combine that with the aforementioned issue of LLMs now making decisions, and you can probably see why it’s so important that there’s still a degree of manual checking that needs to happen.

Automation still needs a human at the top of the org chart. Someone has to own the remediation backlog, adjudicate the edge cases the AI flags but can’t resolve, and decide when a flagged issue is a false positive versus a real one. Call that person the accessibility owner, and don’t skip naming them. Without one, the backlog just accumulates until it’s someone’s emergency.

Rolling this out across multiple product teams is a change-management project. It means aligning on shared severity definitions, getting buy-in from engineering leads who didn’t ask for another CI gate, and giving each team enough runway to fix their existing backlog before the new gate starts blocking their builds.

Screen reader behavior and cognitive load

No scanner (yet) can tell you whether an alt text description makes sense in context. It can confirm the attribute exists, but it can’t judge whether it’s adequate for users.

The same limit shows up in custom widgets: a date picker or an expandable filter panel can pass every automated check and still confuse someone using a keyboard, because keyboard expectations are learned behavior, not a fixed spec. That’s why orgs like TPGi and Deque both build real assistive-technology testing, with actual JAWS, NVDA, and VoiceOver users, into their standard practice rather than treating it as optional.

Each generation of tooling has absorbed the mechanical layer beneath it. The remaining work looks like judgment instead of detection: AI that reasons about context and task, not just pattern-matches against a rule set.

Pull up your last manual audit and check how old the average finding was by the time someone fixed it. Weeks, if you’re disciplined. Months, if you’re like most teams. A pipeline-connected platform has the potential to collapse that number to the length of a sprint, because the violation surfaces at the commit that caused it, not at the next scheduled review.

That’s what we’re working on, and we think it’s the next frontier in accessibility.