> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://tester.army/docs/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tester.army/_mcp/server.

# 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](https://github.com/dequelabs/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:

| Field           | Meaning                                                    |
| --------------- | ---------------------------------------------------------- |
| `ruleId`        | The axe-core rule that failed, e.g. `image-alt`, `label`   |
| `wcagTags`      | The WCAG success criteria the rule maps to (`wcag2a`, ...) |
| `nodeCount`     | Total failing elements across all audited pages            |
| `urls`          | Pages where the rule failed                                |
| `sampleTargets` | CSS selectors pointing at example failing elements         |
| `helpUrl`       | Deque University fix guidance for the rule                 |

## 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`:

```json
{
  "type": "warning",
  "category": "accessibility",
  "name": "Images must have alternate text",
  "accessibility": {
    "ruleId": "image-alt",
    "impact": "critical",
    "wcagTags": ["wcag2a", "wcag111"],
    "nodeCount": 12,
    "urls": ["https://example.com/products"],
    "sampleTargets": ["#catalog > div:nth-child(3) > img"],
    "helpUrl": "https://dequeuniversity.com/rules/axe/4.10/image-alt"
  }
}
```

Fetch them with `GET /v1/runs/{id}` (see the [API Reference](/api-reference)),
the [CLI](/cli) (`ta runs get <runId> --json`), or the
[MCP server](/cli/mcp). 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.