Why We Built Auditi: The Accessibility Tool We Needed

At BetterQA, we audit accessibility for healthcare platforms, fintech applications, and government systems. We couldn't find a tool that worked the way we needed, so we built Auditi.

The Problem We Faced

Our accessibility practice grew out of necessity. Clients in regulated industries (healthcare, finance, government) came to us because they needed audits that would hold up to legal scrutiny. These weren't "nice to have" accessibility improvements. They were compliance requirements tied to FDA approvals, government contracts, and litigation defense.

We tried every accessibility tool on the market. They all had the same fundamental problem: they tested pages, not journeys. Every tool wanted us to audit the homepage, then the login page, then the dashboard. But that's not how users experience products.

Why Pages Aren't Enough

Consider a patient portal. Users don't experience it as a collection of pages. They experience it as a complete journey: logging in to view upcoming appointments, requesting a prescription refill, sending a message to their provider, and logging out. Testing each page in isolation tells you if individual elements are accessible. It doesn't tell you if a patient can actually complete their tasks.

We were finding critical issues that no tool caught. Focus would get lost between page transitions, leaving keyboard users stranded. Form errors after server validation wouldn't announce to screen readers. Multi-step wizards created keyboard traps. Modal dialogs broke screen reader navigation entirely. These weren't theoretical problems. They were blockers that prevented real users from accessing healthcare, managing their finances, or interacting with government services.

What We Needed

We sketched out requirements for the tool we wanted. It needed journey-first architecture where we could define user journeys as first-class objects and test accessibility across journey steps rather than isolated pages. It had to track state and context between steps because that's where the real issues hide.

Multi-standard support was non-negotiable. Our healthcare clients needed WCAG 2.1 and 2.2 alongside FDA 21 CFR Part 11 requirements. European pharmaceutical clients required EU Annex 11 compliance. We needed one tool that could handle all of these standards simultaneously, not separate workflows for each.

Team collaboration had to be built in from the start. Multiple auditors work on one project. Clients need visibility into progress. We needed threaded comments on specific issues, role-based access control, and activity logs that create an audit trail. Most importantly, we needed reports that non-technical stakeholders could actually understand.

CI/CD integration rounded out our requirements. Accessibility testing should be continuous, not annual. We wanted an API for automated testing that could import results from axe, pa11y, and Lighthouse, then track regression trends between builds.

Building Auditi

We started by codifying our own workflow. When we conduct audits, we map the journeys first, asking what users are trying to accomplish. Then we walk each journey with keyboard navigation, screen readers, and magnification. We document issues in context, noting not just what failed but where in the journey it happened and what the user was trying to do. We prioritize by impact, distinguishing what blocks users from what's merely inconvenient. Finally, we track remediation to verify fixes and catch regressions.

Auditi mirrors this workflow exactly. Projects contain journeys. Journeys contain steps. Each step links to specific WCAG criteria and captures pass/fail/not-applicable results. The structure emerged from how we actually work, not from abstract requirements documents.

What Makes Auditi Different

Every issue in Auditi carries journey context. Instead of reporting "Image missing alt text on /checkout," we capture "Image missing alt text on step 3 of checkout journey, after user has entered shipping address." This context helps developers understand the user impact and prioritize fixes appropriately. It transforms accessibility issues from abstract compliance requirements into concrete barriers that affect real tasks.

One journey can be tested against multiple standards simultaneously. A healthcare client sees WCAG 2.2 compliance alongside FDA 21 CFR Part 11 requirements for the same user flow. They don't need separate audits or parallel tracking systems. Everything lives in one place, mapped to the actual user journey being evaluated.

We work in teams, and our clients need visibility into our process. Auditi provides team workspaces with role-based permissions, threaded comments on specific issues, complete activity logs for audit trails, and client-facing reports that executives and legal teams can understand without technical accessibility expertise.

Auditi's API-first design enables continuous accessibility testing rather than annual compliance checkpoints. Teams can import automated scan results from CI/CD pipelines, track compliance trends over time, and receive notifications when regressions appear. This shifts accessibility from a periodic audit exercise to an integrated development practice.

Who Auditi Is For

We built Auditi for teams like ours: accessibility professionals who need to test journeys rather than pages, support multiple compliance standards without separate workflows, collaborate effectively with team members and clients, and integrate accessibility testing into development workflows rather than treating it as a final gate.

If you're doing page-by-page audits with spreadsheets, Auditi fundamentally changes your workflow. If you're already thinking in journeys, Auditi gives you the tool you've been missing.

What's Next

We're continuing to build based on what we learn from our own audits. We're developing enhanced reporting for different audiences, from developers who need technical details to executives who need compliance summaries to legal teams who need defensible documentation. We're adding automated checks that understand journey context, going beyond isolated page scans. We're building deeper integration with design tools so teams can address accessibility earlier in the development cycle.

Auditi exists because we needed it. We think you might need it too.