Accessibility testing
without the compliance headache
Automated WCAG scans for any URL — public pages, pages behind a login, and live user workflows. Get severity-graded reports with element selectors and suggested fixes in seconds.
header > img.logonav a.mutedform#search > inputThree steps to WCAG compliance
No setup, no CI pipeline required. Run a full accessibility audit in under a minute.
Point at your target
Paste up to 10 URLs, record a live workflow, or attach auth details for pages behind a login screen.
Run the scan
TestKase audits every page against WCAG 2.0, 2.1, or 2.2 at Level A, AA, or AAA — plus best-practice and review rules.
Fix with confidence
Severity-graded issues come with the exact element, a unique CSS selector, and a suggested fix. Share the report with the right team.
Everything you need to ship accessible products
Five focused modules — from quick URL audits to deep workflow analysis — that cover the full accessibility testing lifecycle.
WCAG reports for any URL, in seconds
Paste up to 10 URLs. TestKase audits every page and returns severity-graded findings with element selectors and fixes.
- WCAG 2.0, 2.1, 2.2 — Levels A, AA, AAA
- Best-practice and review rules
- Advanced axe-core rules toggle
Audit dynamic flows, not just static pages
Watch the live page as a tester clicks through a journey. Catch issues introduced by JavaScript, modals, and state changes.
- Real-time monitoring during interaction
- Snapshots of each application state
- Works with SPAs and complex React flows
Audit the pages behind your login screen
Cookie, form, or custom header auth — dashboards, settings, and admin panels finally get audited.
- Cookie-based — paste session cookies
- Login-form — URL, selectors, credentials
- Header-based — Authorization or API keys
A DevTools panel for on-demand scans
Free Chrome extension. One-click accessibility scans on the active tab, auto-sync to your TestKase workspace.
- One-click scans from DevTools
- Element inspector integrates with DevTools
- Auto sign-in from your TestKase session
Route scans to the engineers who can fix them
Group people by feature area or ownership. Share reports with the right team instead of a global dump.
- Unlimited accessibility teams
- Bulk-invite existing workspace members
- Inline comments and resolution notes
Severity-graded reports, not walls of rule codes
Every finding is classified so you know what to fix first — with the exact DOM element, a unique selector, and a suggested remediation.
Blocks access for users with disabilities — must fix before release.
Significant barrier — breaks WCAG conformance at the targeted level.
Usability issue that should be addressed in the next fix cycle.
Nice-to-fix improvement — low impact but worth tracking.
Built for the laws your team actually needs to pass
Every one of these laws points at WCAG, and WCAG is what TestKase tests. Findings carry their WCAG success criterion, which is the reference each of these frameworks is written against — there is no separate per-framework mapping.
Designed for the audits your team has to pass
Every major accessibility framework. Data handled the way regulators expect. The guardrails you need to ship in regulated industries.
All versions. All levels.
Mapped to the laws you care about
Per-tenant keys protect every credential and scan artefact stored in TestKase.
Auth values are held only in memory for the crawl and discarded after. Never logged.
Scan history retained per plan with exportable trails for compliance filings.
What automation is good for, and what it is not
Automated rules reach under half the WCAG 2.2 AA success criteria. That is the honest headline, and most of this category is built to avoid saying it — because the faults a machine can find are not the faults a user notices, and a tool that reports a clean page has told you something much narrower than it appears to.
What automation is genuinely excellent at is volume and repetition. The faults it finds are the ones generated by shared code, so they appear tens or hundreds of times and clear in a single change. Finding those by hand is slow, boring and error-prone; finding them with a scan takes a minute and costs nothing. That is a real and large win, and it is the entire job.
What it cannot do is judge. Whether alt text describes the image, whether focus order follows the reading order, whether an error message tells someone how to fix the error, whether a flow can be completed without a drag — these need a person, and no amount of engine quality changes that. So our reports mark criteria nothing checked as not checked rather than as passed, and the tools below are arranged around getting a person to the places that need one.
Which part to use, and when
Nine capabilities, one product. They are not alternatives — each answers a question the others cannot.
Audit a set of URLs
The web scanner runs the rules against pages you list, in a real desktop browser you choose. Start here — it is the broadest answer for the least effort.
Decide what to fix first
Fix plans rank the work by how many issues each change clears, with running totals, so a report opens with a plan instead of a score.
Check a journey, not a page
The workflow analyzer audits each state you reach while walking a flow — modals, validation errors, wizard steps — and keeps the findings attached to the state.
Reach pages behind a login
Cookies, HTTP headers or a scripted form login. The application most people never audit is the one their colleagues use all day.
Scan before you merge
A DevTools panel that audits the tab you are looking at, including localhost and anything else nothing outside your machine can reach.
Keep checking without remembering
Daily, weekly or monthly runs in your own timezone, held as a booking on the scan so a missed run is late rather than lost.
See what a release changed
Fixed, introduced and unchanged against the previous run, compared by issue identity rather than by totals — so a regression cannot hide behind a falling count.
Get findings to the right people
Scope a scan to the team that owns the code, with members told when they gain access and when they lose it.
Understand what the report actually proves
The criterion counts for WCAG 2.0, 2.1 and 2.2, which of them automated rules reach, and the four statuses a report uses — including the one that says a criterion was never measured.
A first month that actually changes something
Scan ten templates, not ten pages
One page per distinct layout, plus everything with a form on it. Faults come from shared markup, so scanning forty pages built from one template finds the same fault forty times.
Clear the top of the fix plan
Read down until the running total flattens. Everything above that line is cheap, and clearing it usually removes most of the findings on the site.
Put the same scan on a weekly schedule
From then on, each report tells you what the week introduced. That number is what stops the work you just did from quietly reversing.
Walk your two most important journeys
Sign-up and checkout, or whatever your equivalents are, with the keyboard. This is the half a scanner cannot do, and it is where the failures users actually hit tend to be.
About compliance, briefly and carefully
WCAG is the technical standard that most accessibility law points at, directly or by reference — the European Accessibility Act in the EU, EN 301 549 for European public procurement, Section 508 in the United States, and the ADA as applied to websites. The level almost always cited is AA.
What a scan can contribute to that is evidence of diligence and a record over time: a dated set of runs, what was found, what was fixed, and what remains. What it cannot contribute is a conformance claim, because the criteria that require judgement are exactly the ones a machine skipped.
We do not issue certifications, produce a VPAT, or offer legal advice, and we do not sell an accessibility overlay — the widgets marketed as installable compliance, which do not deliver it and which feature heavily in accessibility litigation. If you have a specific obligation with a specific date attached, that is a conversation with counsel. This is a tool for doing the work, not for declaring it finished.
Frequently asked questions
Common questions about TestKase Accessibility scanning.
TestKase supports WCAG 2.0, 2.1, and 2.2 at conformance levels A, AA, and AAA. You choose the level when creating a scan.
Yes. Three authentication methods are supported: session cookies, login form automation (username + password), and custom HTTP headers.
Up to 10 URLs per scan, and you can create as many scans as you like — pages and re-scans are unlimited for every account. Accessibility testing is free; scans run on real desktop browsers from the TestKase Device Farm.
The Workflow Analyzer records a live user session in Chrome and runs accessibility checks across every state of the UI — including modals, dropdowns, and dynamic content that static scanners miss.
Yes. The TestKase Accessibility Chrome extension is free and available on the Chrome Web Store. It adds a DevTools panel for one-click scans on any open tab.
Scan reports can be exported as PDF or CSV, and scan history as CSV. Both formats are included on every plan.
Yes — accessibility testing is completely free for every account, with unlimited pages and unlimited re-scans. Scans run on real desktop browsers from the TestKase Device Farm, and scan history is kept for 90 days on every plan.
Start scanning for accessibility free
Unlimited pages, unlimited re-scans and every WCAG level included. No credit card required.