| TL;DR: Accessibility audits have identified problems for decades without giving engineering teams a clear way to fix them. Agentic coding is now making things riskier. The faster teams ship, the more inaccessible code reaches production. Evinced launched Autopilot, Harness, and Resolve to catch and fix accessibility defects inside the development workflow itself, covering everything from pre-commit to production backlogs. |
For years, accessibility programs have relied heavily on audits that identify problems after products have already been built. A vendor would review a product, document accessibility issues against WCAG requirements, and hand those findings back to the organization. By that point, in many cases, the findings were simply ignored.
The numbers make that hard to ignore. In Evinced’s 2026 study, Fortune 500 homepages it scanned had nearly 20 accessibility issues on average, with nearly 90% of scanned sites showing at least one detectable accessibility bug. That’s not a niche compliance failure anymore. Even among some of the world’s largest companies, accessibility issues are still showing up on their most visible webpages.
Navin Thadani, CEO and co-founder of Evinced, says these reports “often arrived too late to be useful, giving developers too little help with remediation or prioritization.” That’s exactly what Evinced launched its three tools to address: moving accessibility remediation out of the audit cycle and into the development workflow itself.
A Market Built Around Reports Nobody Could Act On
The market’s structural problem, Thadani says, wasn’t just technical. It was the business model underneath it. According to him:
He believes part of the problem was the services-heavy model that traditional vendors built around. He argues that those vendors relied heavily on reports instead of tools developers could use throughout the software lifecycle. In practice, those reports often arrived after the code had already been written and gave developers limited guidance on what to fix first. Without a clear path to act, engineering teams simply moved on.
What made Evinced’s approach different from the start was the belief that meaningful change required tools inside the development process, not documents delivered after the fact.
Agentic Coding Introduced A New Risk
Agentic coding didn’t create the accessibility problem. The reality is, it introduced a new variable: development speed at a scale that could amplify existing gaps.
As teams adopt AI coding tools and ship faster, so does the risk of shipping inaccessible code. Evinced’s own benchmark data suggests that’s already happening. The company’s latest benchmark found an average of 47 accessibility defects when frontier models built a simple single-page web app, which is the simplest possible test case.
The challenge, however, is that LLMs left to their own devices tend to loop when identifying and verifying fixes. In other words, they chase their own tails without a deterministic framework to ground the process. He also warns this could create a longer-term feedback loop if future models are trained on inaccessible code generated by earlier systems.
Commonly used open-source tools have historically detected about one third of the issues Evinced can detect, Thadani states. They also miss certain interactive-role and keyboard defects: the kind that can stop assistive technology users entirely from completing a task. These functional blockers also create some of the most serious legal exposure, because they prevent users from completing core actions:
That’s an important distinction for the business case. At its core, accessibility isn’t only a compliance checkbox. It’s about whether faster development creates accessibility issues faster than teams can identify and remediate them.
What Evinced Actually Built
Each of these three new tools addresses accessibility at different points in the development cycle. Here is a brief overview:
Autopilot runs inside CI/CD systems alongside a company’s existing LLM. When code is submitted to the pipeline, Autopilot detects accessibility defects and guides the agent to fix them. It then tests the fixes, iterates until they pass, and notifies the developer that changes are ready for review. The developer can then review and approve those changes before they move forward in the cycle.
Harness operates at the pre-commit stage, sitting inside the coding agents developers already use, like Claude, Cursor, Codex, Windsurf, and others. It tests and fixes accessibility issues as developers work, before anything reaches the pipeline. The idea here is developers stay in control, choosing what to fix and in what order.
Resolve, on the other hand, works on the backlog problem. Instead of starting from scratch, it takes a list of existing accessibility issues from a manual audit or a scanning report. It then verifies which ones still exist in production, locates them in the codebase, applies fixes, and tests them against Evinced’s standards. The CEO says it’s possible to clear 100 backlogged issues in a single morning, even with full developer review in the loop.
Taken together, he calls the three tools “an accessibility security blanket”: Harness before commit, Autopilot in CI, and Resolve for existing backlogs.
Their idea is to reduce the accessibility expertise individual developers need for routine fixes. That said, no automated system catches everything, and periodic manual audits still have a role as a backstop.
Developer Control Was A Deliberate Design Choice
Automated code changes raise an obvious concern: how much control should developers and compliance teams retain over each fix?
Evinced’s answer is surprisingly simple: the pull request. Every fix the system generates comes with a detailed pull request the developer reviews and approves before it goes anywhere. Thadani frames these not just as operational checkpoints but as teachable moments: a way for developers to understand what was wrong and why the fix works.
The tools can also work with a customer’s existing LLM setup, which is intended to reduce additional security concerns for enterprise buyers.
The Market Evinced is Actually Trying to Reach
According to Thadani, “only about 3% of large companies currently have a dedicated accessibility team.” The existing accessibility tooling market has largely been built around that slice, meaning organizations already committed to the problem with dedicated resources to manage it.
He sees the remaining 97% as the bigger opportunity. Many of these organizations may have accessibility and compliance obligations without dedicated teams to operationalize the work. His tools are designed for engineering teams that have just been handed an accessibility requirement with no clear path to meet it. That’s the same situation he found himself in before starting Evinced.
As agentic coding spreads across development teams, Evinced believes this broader group becomes increasingly important. The irony is that the same tools helping teams ship faster could make accessibility gaps scale with output. That’s exactly the problem Evinced is trying to get ahead of.
For companies without dedicated accessibility teams, that makes the development workflow itself the logical place to intervene. If accessibility issues can be caught and fixed while code is being written, tested, and reviewed, teams have a better chance of keeping pace with faster release cycles without creating an equally fast-growing remediation backlog. That is ultimately what Evinced is betting on with Autopilot, Harness, and Resolve.
