Journey-based accessibility testing: why page-level scanning misses critical issues

Automated scanners check one page at a time. They report color contrast ratios, missing alt text, and form label violations. That covers roughly 30-40% of WCAG 2.2 success criteria, according to the UK Government Digital Service's 2023 accessibility monitoring report.

The other 60-70% lives in what happens between pages: multi-step forms that lose focus after submission, modal dialogs that trap keyboard users, checkout flows where error messages never reach screen readers. These are the issues that generate lawsuits and block real users.

What page-level scanning actually catches

Tools like axe DevTools, WAVE, and Lighthouse scan the DOM of a single page state. They excel at:

• Color contrast: Checking text-to-background ratios against WCAG 1.4.3 (AA) and 1.4.6 (AAA)
• Missing alt text: Flagging images without `alt` attributes (WCAG 1.1.1)
• Form labels: Detecting inputs without associated `` elements (WCAG 1.3.1)
• ARIA misuse: Identifying invalid roles, states, and properties (WCAG 4.1.2)
• Heading structure: Checking for skipped heading levels (WCAG 1.3.1)

These are real issues worth fixing. But they represent the surface layer of accessibility compliance.

What page-level scanning cannot detect

1. Focus management across page transitions

When a user submits a form and lands on a confirmation page, where does keyboard focus go? If it returns to the top of the page, a screen reader user must navigate through the entire header and navigation to reach the confirmation message. WCAG 2.4.3 (Focus Order) requires logical focus placement, but no page-level scanner tests what happens after a button click triggers navigation.

2. Dynamic content announcements

Single-page applications update content without full page reloads. When a filter changes search results, screen readers need an ARIA live region to announce the update. Page-level scanners see the live region markup exists but cannot verify it announces correctly because they never trigger the filter interaction. This violates WCAG 4.1.3 (Status Messages).

3. Multi-step form state persistence

A three-step registration form may pass every automated check on each individual step. But if pressing the browser back button clears all entered data, keyboard-only users who accidentally navigate backward lose their work. This is a WCAG 3.3.4 (Error Prevention) failure that only surfaces when testing the complete flow.

4. Timeout handling across workflows

WCAG 2.2.1 requires that users can extend or disable time limits. A session timeout that fires mid-checkout is invisible to page scanners. Only a journey-based test that completes the full checkout flow at a realistic pace encounters the timeout warning and verifies that the extension mechanism works for keyboard and screen reader users.

5. Keyboard trap sequences

A modal dialog may be perfectly accessible in isolation. But if dismissing that modal opens a cookie consent banner, which opens a newsletter popup, each with different keyboard handling, the combined sequence creates a trap. WCAG 2.1.2 (No Keyboard Trap) applies to the entire user experience, not individual components.

The data: how many WCAG criteria require interaction testing

WCAG 2.2 Level AA contains 55 success criteria. Here's how they break down by testing method:

| Testing method | Criteria covered | Percentage | |----------------|-----------------|------------| | Automated scanning (DOM analysis) | 17-22 | 31-40% | | Manual single-page inspection | 12-15 | 22-27% | | Journey/workflow testing | 18-21 | 33-38% |

Source: Analysis based on W3C's WCAG 2.2 understanding documents and the Accessibility Conformance Testing (ACT) Rules Community Group's automatable criteria list.

The criteria requiring journey testing include some of the most impactful for users:

• 2.1.1 Keyboard - All functionality operable via keyboard
• 2.1.2 No Keyboard Trap - Focus can move away from any component
• 2.4.3 Focus Order - Focus sequence preserves meaning
• 2.4.7 Focus Visible - Keyboard focus indicator always visible
• 3.2.1 On Focus - No unexpected context changes on focus
• 3.2.2 On Input - No unexpected context changes on input
• 3.3.1 Error Identification - Errors described in text
• 3.3.3 Error Suggestion - Correct input format suggested
• 3.3.4 Error Prevention - Submissions can be reversed or confirmed

How journey-based testing works

A journey is a complete user path through an application. Instead of scanning individual pages, you define the steps a real user takes:

Example: E-commerce checkout journey

| Step | Page/State | What to test | |------|-----------|--------------| | 1 | Product listing | Filter and sort with keyboard, verify result announcements | | 2 | Product detail | Add to cart, verify cart count announcement | | 3 | Shopping cart | Update quantities, verify price recalculation announcement | | 4 | Shipping form | Complete with keyboard, verify error handling | | 5 | Payment form | Enter card details, verify secure input labels | | 6 | Confirmation | Verify focus lands on confirmation message |

Each step is tested for compliance against the selected standard (WCAG 2.1, 2.2, or both). But the transitions between steps receive equal attention: Does focus move correctly? Are state changes announced? Can users navigate backward without data loss?

Auditi structures accessibility testing around these journeys. You define the user flow, add steps for each page or state, and test each step against WCAG criteria. The platform tracks results across versions, so you can measure whether a new release improved or regressed accessibility for a specific user flow.

Journey testing vs manual audits vs automated tools

| Factor | Manual audit | Automated tools | Journey-based (Auditi) | |--------|-------------|-----------------|----------------------| | WCAG criteria coverage | 90-95% | 30-40% | 85-90% | | Cost per audit cycle | $15,000-$50,000 | $0-$500/month | $79-$199/month | | Time to complete | 2-6 weeks | Minutes | 1-3 days | | Reusable across versions | No (re-audit) | Yes | Yes (journey templates) | | VPAT report generation | Manual document | Not available | Automated | | Team collaboration | Email/PDF | Single user | Built-in roles and comments | | Multi-standard support | Expert-dependent | WCAG only | WCAG 2.1, 2.2, 3.0, FDA, EU Annex 11, EU AI Act |

Manual audits by accessibility consultants remain the gold standard for coverage, but the cost and timeline make them impractical for every sprint. Automated tools are fast but shallow. Journey-based platforms fill the middle ground: structured enough for consistency, flexible enough for real user flows.

Integrating journey testing into your development workflow

Journey-based testing works best when connected to your release process:

1. Define critical journeys during planning Identify the 5-10 user flows that matter most: registration, core feature usage, checkout, account management. These become your accessibility regression test suite.

2. Test journeys before each release Run the journey suite against staging. Compare results to the previous version using trend tracking. Flag any regressions for the development team.

3. Expand journeys as features ship New features mean new user flows. Add journey steps for each significant UI change. Over time, your journey suite grows into a comprehensive accessibility map of your application.

4. Generate compliance documentation automatically When a procurement team asks for a VPAT (Voluntary Product Accessibility Template), generate it directly from your journey test results. Auditi produces VPAT 2.4 reports with conformance statements mapped to your actual test data, built by the BetterQA team that has conducted over 500 accessibility assessments across healthcare, fintech, and government clients.

Frequently asked questions

What percentage of WCAG issues can automated scanners detect? Automated scanners detect approximately 30-40% of WCAG 2.2 Level AA success criteria. The UK Government Digital Service found similar results in their large-scale accessibility monitoring. The remaining 60-70% requires manual interaction testing, screen reader verification, and multi-step workflow testing.

Is journey-based testing a replacement for automated scanning? No. Journey-based testing complements automated scanning. Use automated tools (axe, WAVE, Lighthouse, pa11y) for fast detection of markup-level issues. Use journey testing for workflow-level issues that automated tools cannot detect: focus management, dynamic content announcements, timeout handling, and multi-step form behavior.

How many journeys should I test for WCAG compliance? Start with your 5-10 most critical user flows. For most applications, this covers: registration/login, the primary feature workflow, search and filtering, form submission, account settings, and any payment or checkout process. Expand as resources allow.

What is a VPAT and why does journey testing improve it? A VPAT (Voluntary Product Accessibility Template) is a document that describes how a product conforms to accessibility standards. US federal procurement requires VPATs under Section 508. Journey-based test results map directly to VPAT conformance statements because journeys test actual user scenarios, not isolated page elements.

Can journey-based testing cover FDA 21 CFR Part 11 and EU Annex 11? Yes. Auditi supports multi-standard testing against WCAG 2.1, WCAG 2.2, WCAG 3.0, FDA 21 CFR Part 11, EU GMP Annex 11, and EU AI Act requirements simultaneously. This matters for pharmaceutical and medical device software where accessibility and regulatory compliance overlap.

How does journey testing handle single-page applications? Single-page applications (SPAs) present unique accessibility challenges because page content updates without traditional navigation. Journey-based testing captures each state change as a step, verifying that ARIA live regions announce updates, focus moves correctly after client-side routing, and browser history behavior works with keyboard navigation.

Getting started

If your current accessibility testing consists only of automated scans, you are covering less than half of WCAG requirements. Adding journey-based testing to your workflow closes the gap between "no automated violations" and "actually accessible."

Auditi offers a 14-day free trial with full access to journey creation, multi-standard testing, and VPAT generation. For teams already using axe or WAVE, Auditi's API supports importing results from those tools so you can build on existing work rather than starting over.