ZeuZ
Accessibility testing

Automated web accessibility testing against WCAG 2.2, on every merge.

Automated accessibility testing in ZeuZ runs a WCAG 2.2 scan on the page your functional test just reached, after login and after the interaction, so Section 508 and European Accessibility Act failures surface on the merge that caused them. Three reports per run, kept as evidence.

WCAG 2.2 A/AA rulesSection 508EAAAfter loginPer-run reports
node-toronto-01atlas-crmrelease/2026.09
Test case · Account settings · WCAG 2.2 scan
3 violations
BrowserOpen account settings✓ Passed
Signed in · settings rendered
AccessibilityRun accessibility test3 violations
axe · WCAG 2.2 A/AA · this page, this session
Reports · this run
report.htmlsummary
summary.jsondashboards
results.jsonraw
Result3 violations41 passes
image-altWCAG 1.1.1
Image has no alternative text
<img src="avatar-2.png" class="profile-pic">
color-contrastWCAG 1.4.3
labelWCAG 4.1.2
Scanned after login, on the page the test reachedrelease/2026.09
In one paragraph

Automated accessibility testing checks a rendered web page against the Web Content Accessibility Guidelines, WCAG 2.2, for failures a program can detect, missing alternative text, contrast, labels, roles and keyboard traps, so Section 508 and European Accessibility Act obligations are checked continuously rather than before an audit. ZeuZ runs the scan as a step inside a functional test, on the page as the user reaches it, and keeps the report with the run.

Part of ZeuZ Test Studio · Web, in the browser session your functional tests already run
The problem

Where web accessibility testing breaks today.

The scan runs on the public homepage, and the failures live behind login, on the third screen of the flow the scanner never reaches.

Accessibility is audited once a year by a vendor, so twelve months of merges ship before anyone looks.

The report is a PDF nobody can trace to a commit, so the developer fixes it by guessing which release introduced it.

The six steps

How ZeuZ automates accessibility testing.

  1. 01Test designProposes which screens need a WCAG check from the changed templates and components, so the scan follows the change.
  2. 02Test case creationAdd the check in plain English, "then run an accessibility test on this page"; it becomes a step in the existing case.
  3. 03Test automationThe step runs an axe-based scan on the rendered page in the browser session, after login and after the interaction.
  4. 04Test executionRuns with the functional suite on every merge or on a schedule, on your own nodes.
  5. 05Reporting and analysisThree reports per run, an HTML summary, a JSON summary and the raw results, each violation with its element and WCAG criterion.
  6. 06Test maintenanceThe check lives in the case, so when the flow changes the scan moves with it and a locator break comes back as a proposed repair.

Your team reviews what ZeuZ produced. Nothing joins the suite or runs without a person accepting it.

See it in the demo lab or in your own environment

See it run on your application.

Watch a WCAG 2.2 check run inside your own functional suite, live.

What is covered

Accessibility testing tools inside the functional suite.

The ZeuZ accessibility test action evaluates the page currently rendered in the Selenium WebDriver session against WCAG guidelines using the axe engine, through axe-selenium-python. That means the scan runs after any login, navigation or interaction the test has already performed, rather than on a cold public URL, and it needs no parameters beyond an optional wait. This is where automated accessibility testing stops being a separate crawler and becomes a step in the case.

Every run produces three files, an HTML report for people, a JSON summary for dashboards and the raw results for auditors, stored with the run. Findings name the element, the rule and the criterion, which is what a WCAG 2.2 A or AA conformance record needs. Automated checks cover the portion of WCAG a program can decide; the rest, screen-reader flow, focus order judgement and meaning, is manual work ZeuZ's managed QA team performs against the same suite.

Engine
axe, via axe-selenium-python
Standard
WCAG 2.2 A and AA automated rules
Runs on
The rendered page in the test's browser session, after login
Reports
HTML summary, JSON summary, raw JSON, per run
Evidence
Element, rule and criterion per finding, pinned to the run
Manual coverage
Screen reader and focus review through managed QA services
Alt textColour contrastForm labelsARIA rolesKeyboard trapsHeading order

Runs where your code is allowed to be.

SaaS

Hosted by ZeuZ, execution on your own machines.

On-premises

Point the client at your own server.

Air-gapped

Disconnected environments, scoped per engagement.

Runs inside Jenkins, GitHub Actions, Azure DevOps, CircleCI and Bitbucket; results into Jira, Slack and Teams.

Related capabilities

Works in the same suite as.

GUI testing

The functional checks the accessibility step rides inside, on the same pages.

GUI testing →
Cross-browser testing

The same pages checked across the browsers your users run.

Cross-browser testing →
Security testing

The other compliance scan that belongs on every merge, in the same suite.

Security testing →

Read next: QA automation services →Related: Manual accessibility review →

FAQ

Questions about automated accessibility testing.

Ready to automate QA testing today?

See ZeuZ Test Studio write, run and repair tests against your own application code.

or explore our services →
Book a demo