Why another tool?
I got fed up with the common page-scanner extensions. Tools like axe DevTools and Stark will flag some issues on a page. But they still leave you to do a separate manual audit and write up a separate report. The more complete tools, or the paid tiers of those tools, were too expensive and did not fit the way I work.
So I started coding my own manual audit workflow into a tool. I focused first on automatically finding the elements on the page that need to be checked.
Then I kept building.
How it works
The tool follows the same three steps I used to do by hand: find, analyse, report. It just does the repetitive parts for me.
Finding
First it locates every element on the page that needs to be checked, so I don't have to hunt for them. Some criteria also need a specific condition before you can test them. Text Spacing is one, error handling is another. The tool sets those up for me: it injects the Text Spacing CSS so I can see the result, and it triggers error messages so the AI can analyse them.
Analysing with AI
For anything that can be detected automatically, the tool surfaces the result automatically. For criteria that need surrounding context, it takes the element it found plus that context and asks an AI to check it against a hand-written expert knowledge base. I still do the thinking. The tool and the AI do the checking.
Reporting
Everything lands in one place. The tool generates an automated VPAT from the results. I do the manual checks in the same tool and the same workflow, and note my findings right alongside the automated ones. It also audits multiple pages at once, not just the one I have open. Scanning, auditing, and reporting, in a single tool. My efficiency is up at least 200 percent.
The honest limit
This does not replace testing the real experience of using a site. A person who uses a screen reader, a keyboard, or voice control will find things an automated check cannot. The tool makes the code and design related work far more efficient. It does not remove the need for people in the testing process.
Around 1.3 billion people, about one in five, live with a disability. Accessible websites are not a niche. For the people who rely on them, cheaper and more thorough auditing means better products get shipped.
From extension to scanner
After a while I asked myself: what if this scanner, with all its automations, could run from the command line or inside my AI tools? It already covers more WCAG criteria than axe DevTools. And I realised I had already built the scanning part. I just had to port it into a lightweight scanner.
So now I also have a scanner I fully control, covering more WCAG criteria than axe DevTools. I connected it to my AI tools through skills and an MCP server.
The outcome is that my AI can scan any HTML or live page for all but 14 WCAG criteria and tell me whether it is accessible. Because it uses the same knowledge base, it also knows how to fix what it finds. That means the AI can produce web pages that are accessible against the criteria it can check, start to finish, without me hand writing the fixes.
Availability
The audit extension isn't released yet. I use it every day, but it isn't public. You can follow its progress here: Inclusor audit extension(opens in new tab).
The web scanner is live now: Inclusor web scanner(opens in new tab).
When the extension ships, it will run on the same knowledge base as the scanner, so what they find and what they tell you to fix stay consistent. It is built for developers, agencies, and teams who need VPATs without the enterprise price tag.
Pretty neat.