Audit the flows static scanners can't see
Dynamic content breaks one-shot scanners. The Workflow Analyzer watches the live page as a tester clicks through a journey — login, checkout, a modal, a form in its error state — and flags new accessibility issues the moment they appear.
Free · no SDK · records from a Chrome DevTools panel
Pay button loses its focus indicator after the disabled state is cleared.
- Audits every state
- not just one URL
- Runs in your browser
- against the live document
- Findings per state
- attached to the step that caused them
- Free to start
- no SDK, no code change
Capture issues as they happen
Instead of scanning a single URL, the analyzer follows the user through the product and flags issues introduced at each step.
- Step 1
Start a session
Open your app in Chrome, open the TestKase panel in DevTools, and hit record. A baseline scan captures the starting state.
- Step 2
Walk the user journey
Click, type and submit as a real user would — login, checkout, form submit. TestKase watches the DOM in real time as state changes.
- Step 3
Review the snapshot timeline
Every state change is captured with its own accessibility report, so you see exactly which interaction introduced which violation.
What the Workflow Analyzer catches
Everything a one-off URL scan misses — the issues that only appear after user interaction.
Live DOM monitoring
Tracks mutations in real time, so dynamically-rendered components are audited the moment they appear — the states a one-shot URL scan never reaches.
SPA and React apps
Handles client-side routing, lazy-loaded components and suspense boundaries without a CI integration.
State snapshots
Each captured state gets its own audit, so you can pinpoint which interaction caused the regression.
Grouped by state
Findings stay attached to the state they were captured in, so you can see which step of the journey introduced them.
Full session timeline
Step through the entire journey with audit results attached to each point in time.
Stop and save
Stop recording when the journey is done and save the whole session to your workspace, where a teammate can open it.
It audits the page you are looking at
No configuration for private pages
Rules run in your own browser against the live document — nothing is re-fetched and no proxy sits between you and the app, so an internal environment, a staging URL behind a VPN, or a session you are already logged into all work with no setup.
A snapshot a colleague can act on
Each state you capture is saved with its audit result and an HTML snapshot of that state, so a teammate can see the markup a rule fired against without reproducing your journey, account or data — and the session is shareable with your team.
Frequently asked questions
The free TestKase Accessibility Toolkit for Chrome, and nothing else — no SDK, no code change, no CI job. The analyzer records the journey from a DevTools panel in your own browser and saves the finished session to your TestKase workspace, where the Workflow Analyzer screen lists it.
Yes. The analyzer observes DOM mutations directly, so React Router, Vue Router, Next.js App Router, Nuxt, SolidJS — all behave the same from its perspective. Lazy-loaded and suspense-bound components are audited the moment they appear.
Yes, and you do not need to configure anything. The analyzer audits the page in your own browser, so if you are signed in to the app in that tab, it walks the logged-in journey as you. Cookie, form and header auth are for the Web Scanner, which runs on our machines rather than yours.
Yes. Save the session to your workspace and share it with an accessibility team — every member can open the timeline and step through each snapshot. A snapshot is a page from your application, including any scripts it contained, so every read path returns it as opaque text rather than as HTML: the browser will not execute it. Uploads use a short-lived, single-purpose upload URL, so the credential that writes one snapshot cannot be reused for anything else. Issues can be hidden per scan before you share, which does not suppress the same finding elsewhere.
Every finding is recorded against the state it was captured in, so a violation that was present from the first state appears there and a violation introduced by an interaction appears at that step. Comparing the two states tells you which is which.
A person drives the journey — there is no recorded script that replays it on every deploy, so this is a review activity rather than a regression gate. The timeline is the states you captured, not a video of the screen. These are the same automated rules a static scan runs, so they reach the same subset of WCAG and a journey with no findings is not a journey that works. Whether the focus order makes sense, and what a screen reader actually announces, are human judgements not checked here — use the keyboard while you record.
Related
- Authenticated ScanningScan pages behind login (cookie, form, or header auth)
- Chrome ToolkitDevTools panel for one-click scans on any page
- Team SharingShare scans with the teammates who can fix them
- All of AccessibilityAutomated WCAG scanning, workflow audits, and reports
- PricingPer-seat test management and per-thread device testing, priced on the page
Find the bugs your static scanner misses
Start a recorded session in under a minute. Free — every captured state gets its own audit, saved to your workspace with the timeline.