AccessMaze — Accessibility beyond checklists

Inspiration

A website can pass an accessibility audit and still be impossible for someone to actually use.

That's what got me thinking about AccessMaze.

Most accessibility testing tools are good at finding problems with individual elements, like missing labels, contrast issues, or incorrect ARIA attributes. But those checks don't always tell you whether someone can finish what they came to do.

Take something as simple as applying for a scholarship. Every page might look fine on its own, but what if the date picker can't be reached using a keyboard? What if an error message appears but focus never moves to it? Or what if someone loses everything they've entered because their connection drops?

I wanted to build something that looks at the whole experience instead of just checking individual pages.

What it does

AccessMaze is a free, open-source Windows application that tests real website workflows under different accessibility and environmental conditions.

You can define or record a journey, like filling out a form, navigating through an application, or completing a registration process, and then run it under conditions such as keyboard-only navigation, reduced motion, different viewport settings, or network interruptions.

Instead of simply returning an accessibility score, AccessMaze records what actually happened.

It can:

• Run real browser interactions and check whether a task reaches its intended outcome.
• Explore approved branches of a website and map the states it encounters.
• Detect observable keyboard navigation, focus, and accessibility issues.
• Record evidence explaining where a journey failed.
• Replay supported failures to help reproduce them.
• Compare a failed journey with a corrected version to check whether the problem is still there.
• Save investigations locally and export reports.

The goal isn't to replace manual accessibility testing or claim that software can perfectly simulate someone's disability. It's to give developers a better way to investigate problems that only become obvious when someone tries to complete an entire task.

How I built it

I built AccessMaze as a Windows desktop application using Tauri 2, Rust, React, TypeScript, Python, Playwright, NetworkX, and SQLite.

React and TypeScript handle the interface, while Rust manages the desktop application and its background worker. The Python engine controls Chromium through Playwright, runs the journeys, collects observations, and constructs graphs of the states and transitions it actually encounters.

NetworkX handles graph relationships, and SQLite stores projects, previous runs, findings, and comparisons.

I also integrated axe-core for established accessibility checks, alongside custom testing for keyboard navigation, focus handling, workflow assertions, and connection recovery.

The application runs locally without needing accounts, paid APIs, cloud services, or a dedicated GPU.

One thing I paid particular attention to was keeping the results honest. If a test runs out of time, a browser restriction changes the website's behavior, or a path hasn't been explored, AccessMaze reports that limitation instead of claiming the website passed or failed.

Challenges I faced

Getting reliable browser automation working was one of the biggest challenges. Real websites don't always behave predictably. Elements appear dynamically, navigation can change the page while it's being inspected, and the same workflow can behave differently depending on the browser state.

Keyboard navigation was another interesting problem. Just because an element exists in the DOM doesn't mean someone can reach or operate it using a keyboard. I had to work with actual focus movement and bounded interaction attempts rather than rely on element inspection alone.

Security and privacy also required considerable work. Testing external websites means handling authentication, network requests, file uploads, and potentially sensitive information. I added explicit origin permissions, action approvals, isolated browser contexts, and private evidence handling rather than letting the automation interact freely with everything.

Packaging everything into a portable Windows application was also more complicated than expected. AccessMaze combines Rust, Python, Chromium, and a React frontend, so making all those pieces work together without requiring users to install a separate development environment took additional effort.

What I learned

This project changed how I think about accessibility testing.

I learned that finding an inaccessible element and proving that a user journey is blocked are two different problems. The second requires understanding application states, transitions, interaction methods, and what counts as successfully completing a task.

I also learned a lot about coordinating different runtimes inside a desktop application, managing browser processes, keeping evidence reproducible, and designing automation that is useful without being overly aggressive.

Most importantly, I learned that a trustworthy testing tool needs to be clear about what it couldn't verify, not just what it found.

What's next

There's still a lot I want to improve.

I'm working toward broader support for complex websites, more capable journey discovery, better reproduction of failures, and stronger comparisons between application versions.

I'd also like to add guided testing with real assistive technology, support for more platforms, and eventually integrate AccessMaze into development workflows so accessibility regressions can be caught before software is released.

For now, AccessMaze is a working Windows development preview, not a fully certified accessibility testing solution. Manual screen-reader testing and independent release verification are still on the roadmap.

I want to keep it free and open source so developers, students, and smaller teams can use it without paying for another testing platform.

Built With

• axe-core
• chromium
• css3
• github-actions
• html5
• javascript
• networkx
• playwright
• pydantic
• pytest
• python
• react
• rust
• sqlite
• tauri
• typescript
• vite
• vitest
• windows