Building an accessibility scanner that balances technical precision and human needs

As I built the accessibility scanner, I wasn’t just trying to solve technical problems - I was trying to solve human ones too. The tool grew out of frustrations I face every day as a tester, but it was also shaped by how I process information.

Like many people, I find large volumes of dense, unstructured data overwhelming. As someone with dyslexia, long spreadsheets full of tiny text or scattered results can be exhausting to interpret - especially when decisions need to be made quickly. If the scanner was going to genuinely support people’s work, it couldn’t just crawl more accurately; it had to communicate more clearly too.

That insight shaped two major parts of the project: how the tool explores websites, and how it reports what it finds.

Why I started building my own scanner

Throughout my career as an accessibility tester, automated tools have acted as a vital second pair of eyes. On large accessibility audits where no individual can manually cover everything, they’re essential. But despite their importance, my colleagues and I kept running into the same problems:

• Too many false positives and time-consuming clean up
• Scanners wasting hours on irrelevant pages
• Important content never being reached
• Crashes after long scans
• Reports that were unclear, overwhelming or difficult to interpret

I wanted something better: a tool that was easier to use, more accurate, more reliable, and more human-friendly. So, I took on the challenge of building my own.

Moving beyond the standard web crawler

While developing the scanner, I quickly discovered that modern websites break traditional crawlers in countless ways. Today’s sites:

• Load key content only after user interaction
• Use security measures that block anything that looks automated
• Trap crawlers in loops or reload endlessly

To create something genuinely useful, I had to design features that handled these challenges while keeping the experience simple and predictable.

Key features inspired by real testing pain points

Every feature in the scanner was built to solve a challenge I repeatedly encountered in real projects.

1. Interaction scanning

Standard crawlers miss hidden content. This scanner scores interactive components such as accordions, tabs and modals, and clicks them automatically, rescanning only when the page actually changes.

2. Overlay dismissal

Cookie banners and pop ups can ruin screenshots and block content. The scanner identifies and dismisses common overlays across all frames to keep pages clear for analysis.

3. Hybrid login bridge

Authentication is where most automation breaks. The tool allows a human to complete complex sign-ins, including multi-factor authentication or single sign-on, and then continues the authenticated session automatically.

4. User journey recording

Some experiences cannot be found by crawling alone. A simple record-and-replay system captures multi-step processes, such as form submissions or wizard flows, so these can be audited accurately.

5. Parallel processing

Multiple workers run simultaneously, significantly reducing the duration of large audits.

6. Multi view port auditing

Mobile, tablet and desktop views are tested at the same time to catch responsive issues that only appear on specific screen sizes.

7. Long scan memory management

During long crawls, the browser instance is restarted periodically to prevent memory leaks and maintain stable performance - essential when scanning thousands of pages.

Built with neurodiversity in mind: reports that are easier to process

While the scanning features solves technical problems, the reporting system solves human ones. I wanted the results to be readable, not overwhelming. That meant:

• Clear grouping of issues
• Friendly summaries before detailed data
• Visual cues that reduce cognitive load
• Reports that work equally well for testers, developers and non-technical users
• Screenshots and context to avoid having to hunt through code

The goal was simple: results you can understand at a glance, even when you’re tired, stressed or juggling a complex audit. Designing with neurodiversity in mind didn’t just make the reports easier for me - it made them easier for everyone.

Conclusion

This tool wasn’t built for complexity’s sake. It was built to make accessibility testing easier, faster and more approachable - technically and cognitively. Every feature exists because it solved a real problem I encountered in the field.

After some encouragement, the scanner is now available for other testers and to anyone who wants to understand the accessibility of their website. It runs entirely on your own machine, keeps your data private, and is completely free.

No automated tool can replace manual testing, but the right tool can raise the baseline and help maintain a consistent standard of accessibility. By sharing this project, I hope to contribute positively to a more accessible web - and to make the process of testing a little easier for the people doing this work every day.

To find out more, explore the A11y Scanner and try it for yourself.

About Zoonou

Zoonou is a UK-based digital quality assurance company. We’re a B Corp and 100% employee owned. Combining technical delivery and advisory services, we collaborate with the private, public and third sectors to create better software, services and products.