Accessibility Audits

Every web run doubles as an accessibility audit. While the agent executes your test, TesterArmy scans each page it visits with axe-core — the same engine behind Lighthouse and browser accessibility DevTools — and reports critical WCAG violations as warnings on the run.

You do not write accessibility test steps, install anything, or opt in. The audit runs automatically on every web run and surfaces defects like missing image alt text, unlabeled form fields, and broken ARIA on the pages your tests already cover.

Warnings, not failures

Accessibility findings are reported as warnings and never change a run’s PASS/FAIL outcome. A passing run with accessibility warnings still passes, is not counted as a failure, and does not trigger failure notifications.

This makes the audit safe to leave on for CI and pull request testing: it adds signal without adding flakiness or blocking merges.

What gets reported

The audit checks WCAG 2.0 and 2.1 level A and AA rules and reports only critical-impact violations. These are unambiguous defects — a screen reader user cannot work around a missing form label — rather than contrast opinions or best-practice suggestions.

Findings are aggregated per rule across the whole run, so a missing-alt-text problem on 40 product cards across 3 pages shows up as one warning, not 120.

Each warning carries structured detail:

Reading findings in the dashboard

Open a run and check the amber Warnings section. Each accessibility warning expands into a purpose-built detail view:

• The axe rule and its WCAG tags as badges
• A fix-options list derived from axe’s failure summary
• CSS selectors for the failing elements
• A Fix guidance link to Deque University’s documentation for the rule

Because findings are deterministic rule checks — not agent judgment — the same page state produces the same warnings.

Fixing findings with a coding agent

Runs with accessibility warnings show a Copy prompt to fix button, even when the run passed. The prompt embeds the rule, the WCAG criteria, the affected pages, the failing selectors, and the fix-guidance URL, so you can paste it into Claude Code, Cursor, or any coding agent and it can locate the elements in your codebase directly.

Accessing findings programmatically

Warnings appear in the run output alongside regular issues, distinguished by type and category:

1
{
2
  "type": "warning",
3
  "category": "accessibility",
4
  "name": "Images must have alternate text",
5
  "accessibility": {
6
    "ruleId": "image-alt",
7
    "impact": "critical",
8
    "wcagTags": ["wcag2a", "wcag111"],
9
    "nodeCount": 12,
10
    "urls": ["https://example.com/products"],
11
    "sampleTargets": ["#catalog > div:nth-child(3) > img"],
12
    "helpUrl": "https://dequeuniversity.com/rules/axe/4.10/image-alt"
13
  }
14
}

Fetch them with GET /v1/runs/{id} (see the API Reference), the CLI (ta runs get <runId> --json), or the MCP server. Filter on type: "warning" to separate audit findings from blocking product issues.

Turning the audit off

The audit is on by default for every web project. To disable it for a project:

• Dashboard — open the project’s Settings tab and switch off Accessibility audit.
• API — PATCH /api/v1/projects/{projectId} with { "accessibilityAuditEnabled": false }.
• MCP — call the update_project tool with accessibilityAuditEnabled: false.

Coverage and limitations

• Web runs only. Mobile runs (iOS and Android) are not audited.
• Each unique page URL is scanned once per run, up to 20 pages. Coverage follows your test: pages the agent never visits are never audited.
• Only the main frame is audited; iframe content is skipped.
• Content that hydrates late may occasionally be missed or produce findings that vary slightly between runs; per-rule aggregation and the critical-only threshold absorb most of this jitter.
• A failed scan never affects the run — the audit degrades silently rather than blocking your test.