AI accessibility audit
Accessibility audits on every page your users actually reach
Is It Ready runs an axe-core WCAG audit on each page its AI agent visits — signed in, mid-checkout, with the dialog open — and reports every violation with its impact, location and fix, alongside the functional bugs and UX findings from the same run.
Where the audit fits in a run
Accessibility is checked as part of every browser scenario and every site exploration, not as a separate project.
- 1Agent reaches the page
Signed in, mid-flow, with the modal open — wherever a real journey goes.
- 2axe-core scan
The rendered DOM is checked against your chosen WCAG standard.
- 3UX judge
An accessibility lens scores naming, focus order and readability 1–5.
- 4Report
Violations grouped by impact with selectors, counts and fix guidance.
- 5Gate
SARIF to GitHub code scanning; regressions show up on the pull request.
Why audit during real journeys
Most accessibility checks run against a list of URLs. That finds problems on landing pages, but the barriers that stop people from completing a task tend to live deeper: in the multi-step form behind sign-in, the error state that only appears after an invalid submission, the date picker inside a modal, or the confirmation page nobody remembered to add to the list.
An AI agent testing your product already goes to those places. At the end of each scenario, Is It Ready scans the page the agent is on with axe-core, the open-source rules engine maintained by Deque, through Playwright. The audit is on by default for every application, and you can pin it to the standard you are accountable to — WCAG 2.0 A through WCAG 2.2 AA, or AAA — on the application or override it per mission.
Rules engines only see what is machine-checkable. So every scenario is also scored by a UX judge on nine usability lenses, one of which is accessibility: are controls named, is the focus order sane, is the text readable? Those observations come with evidence from the page and a concrete recommendation, which is where issues like a focus trap or an error announced only by colour surface.
For a site-wide view without writing a mission, start an exploration: the agent crawls your site read-only, collapses URLs that share a template, and records accessibility violations, console errors and failed network requests for each page it opens. When the same rule fails on page after page, that is almost always one shared component — fix the template and every page clears.
Results live with the run that found them, next to its screenshots, and export as SARIF 2.1.0 so violations appear in GitHub code scanning on the pull request that introduced them, or as JUnit and Markdown for any other pipeline.
What every violation tells you
Impact
Every violation is ranked critical, serious, moderate or minor, so the worst barriers are fixed first.
Rule and description
The axe rule id — color-contrast, label, image-alt — and a plain-language description of what failed.
Where it happens
How many elements are affected and the first matching selector, so a developer can find it in seconds.
How to fix it
A link to the rule's remediation guidance with examples of compliant markup.
Which journey
Violations are attached to the scenario and page where they were found, next to the screenshots.
Beyond axe
Responsive layout checks, visual baselines and the UX accessibility lens catch what static rules cannot.
Sample accessibility report
An illustrative excerpt from a checkout mission. Violations are grouped by rule, worst impact first, with the pages and elements affected.
Accessibility · checkout journey · WCAG 2.2 AA · 4 scenarios, 9 pages
CRITICAL button-name Buttons must have discernible text
3 elements on 2 pages · first: header > button.cart-toggle
SERIOUS color-contrast Elements must meet minimum color contrast ratio
14 elements on 6 pages · first: .price-note
SERIOUS label Form elements must have labels
2 elements on 1 page · first: #promo-code
MODERATE region All page content should be contained by landmarks
5 elements on 5 pages · first: div.cookie-banner
UX accessibility lens: 3 / 5 — "Focus jumps to the footer after
applying a promo code; the error is announced only by color."Configure and automate
Set the standard once on the application; add two steps to your workflow to publish findings to GitHub code scanning.
curl -X PUT "$UCT_BASE_URL/api/apps/<app-id>" \
-H "Authorization: Bearer $UCT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"accessibilityConfig": {
"enabled": true,
"standard": "wcag22aa"
}
}'- name: Export accessibility findings as SARIF
run: |
curl -sf -G "$UCT_BASE_URL/api/runs/$RUN_ID/export" \
-H "Authorization: Bearer $UCT_API_KEY" \
--data-urlencode "format=sarif" \
--data-urlencode "revision=${{ github.sha }}" \
-o is-it-ready.sarif
- uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: is-it-ready.sarif
category: is-it-readySecurity and trust
Domain-verified security testing
Security scans and red-team missions only run against domains your organization has verified.
Credentials never stored in evidence
Sign-in values are redacted from run evidence; only the outcome and landing page are recorded.
Configurable retention
Run evidence is redacted after 90 days by default, adjustable per organization.
Isolated workspaces
Every app, spec, run and API key belongs to one organization and is invisible to every other.
CI-native output
Exit codes for pipelines, plus Markdown, JUnit and SARIF exports for GitHub code scanning.
Accessibility audit questions
- Which WCAG versions can it audit against?
- By default the audit runs axe-core's built-in rule set: WCAG 2.0 and 2.1 Level A and AA plus axe best-practice rules. You can pin an application or a single mission to WCAG 2.0 A, 2.0 AA, 2.1 AA, 2.2 AA, or AAA.
- Does an automated audit make my site compliant?
- No automated tool can certify conformance on its own: rules engines catch a large share of common, machine-detectable failures, but criteria such as meaningful alternative text or a logical reading order need human judgment. Is It Ready narrows that gap with an AI accessibility lens that reviews naming, focus order and readability during real journeys, but treat the results as a prioritised work list rather than a certificate.
- How is this different from running axe in a browser extension?
- An extension audits the one page you are looking at. Is It Ready audits every page the agent reaches while completing real tasks — behind sign-in, after form submissions, with dialogs open — on every run, so regressions are caught when they ship rather than at the next manual review.
- Can I try it on my site for free?
- Yes. The free scan browses a sample of your public pages read-only, runs the same axe-core audit on each one, and emails you the violations grouped by impact along with console errors and UX findings.
Related features
See your site's accessibility issues in minutes
Get a free scan of your public pages, or sign up to audit the journeys behind sign-in on every release.