Developers: Map Accessibility Testing API Results to WCAG 2.2 and ACT

An accessibility testing API automates checks against a website or document, returning machine-readable results mapped to standards like WCAG and ACT Rules so teams can catch barriers before release. It fits naturally into CI pipelines, pre-release QA gates, and document workflows where PDFs need PDF/UA validation. Use it for shift-left testing on every pull request or nightly build, but always pair it with manual review for the judgment calls automation cannot make.

TL;DR:

• Accessibility testing APIs primarily target WCAG 2.1 and 2.2 at the AA level, with rules mapped to specific success criteria for precise violation identification.
• Most APIs support input types such as URLs, raw HTML, or uploaded files, and include scope controls to target specific page components or entire sites for faster, less noisy scans.
• Automated results are not proof of compliance; manual review is essential for nuanced issues like reading order or meaningful alt text, especially for “can’t tell” outcomes.
• Integration with CI workflows typically involves delta scans for pull requests and scheduled full-site crawls to track regressions over time, with results normalized into familiar formats like ACT or SARIF.
• Turning findings into fixes requires prioritizing critical issues, maintaining detailed records, and conducting manual audits to address complex or ambiguous cases.

Table of Contents

• What accessibility testing APIs do: capabilities, common endpoints, and output types
• Standards and rule formats these APIs report against
• Key API features and payloads developers should expect
• Integration patterns: CI/CD, Playwright, and test-runner workflows
• Interpreting API results and building a remediation workflow
• Where automation helps and where manual testing is still required
• An honest read on API-driven accessibility testing
• AccessWiser: a practical path from API results to permanent fixes
• Sources
• FAQ

What accessibility testing APIs do: capabilities, common endpoints, and output types

Most accessibility testing APIs follow a familiar shape once you have used a handful of REST services. Authentication typically happens through an API key in the request header or a Bearer JWT tied to a session, and providers vary on whether keys are scoped per project or per organization.

The core endpoints tend to cover the same territory across vendors:

• A scan endpoint that accepts a URL, raw HTML, or an uploaded file and kicks off the evaluation.
• A status endpoint for polling long-running crawls, since a full-site scan rarely finishes instantly.
• A report export endpoint that returns findings as JSON, sometimes in an ACT-style schema, alongside SARIF for build tooling or CSV for spreadsheets.
• A document-specific endpoint for PDFs, checking against PDF/UA criteria separately from HTML rules.

Single-page checks and site-wide crawls are usually distinct request types, since crawling costs more compute and time than testing one rendered page.

Standards and rule formats these APIs report against

WCAG 2.1 and WCAG 2.2 at the AA level are the baseline most accessibility testing APIs target, and each API rule generally traces back to one or more success criteria. That mapping matters because it tells you not just that something failed, but which specific requirement it violates and why that requirement exists.

The ACT Rules Format gives the industry a shared structure for writing these rules, with atomic and composite rules that each resolve to a passed, failed, or inapplicable outcome. Adopting tools that publish ACT-formatted rules matters if you ever plan to compare or combine output from more than one scanning engine, as it removes the ambiguity of proprietary rule naming.

A clean automated report is not proof of compliance. The U.S. Department of Justice’s web accessibility guidance is explicit that automated tools cannot replace manual evaluation, and a passing scan does not by itself establish ADA compliance. PDF/UA checks follow a similar split: some requirements are machine-verifiable, others need a human to confirm reading order and textual meaning make sense.

Key API features and payloads developers should expect

Before wiring an API into a pipeline, it helps to know what the request and response bodies actually contain. Most providers converge on a similar set of fields, even when naming conventions differ slightly.

1. Input type: a url, raw html, or uploaded file, plus a scan profile that selects the ruleset (WCAG 2.1 AA, WCAG 2.2 AA, or a custom set).
2. Scope controls: include and exclude selectors so you can test a single component, a modal, or an entire rendered page.
3. Delivery options: a callback or webhook URL so results arrive asynchronously instead of holding a connection open.
4. Result schema: each finding carries a rule ID, a DOM selector or location, an outcome of passed, failed, inapplicable, or can’t tell, a severity level, and remediation text.
5. Operational limits: rate limits, batch size caps, and pagination for large result sets, plus retry behavior on webhook delivery.

Scoping matters more than it sounds. A scan that targets a specific component after a deploy runs faster and produces far less noise than a full crawl on every commit.

Pro Tip: Scope your automated scans to the pages or components that actually changed in a pull request, and reserve full-site crawls for a nightly job.

Integration patterns: CI/CD, Playwright, and test-runner workflows

Where you run the check depends on what you are optimizing for. A remote API suits centralized reporting, document checks, and cases where you want one dashboard across many projects. A local engine, run inside your own test suite, suits fast per-PR feedback where a few extra seconds matter.

Playwright’s accessibility testing documentation shows integrations with @axe-core/playwright for scanning full pages or a scoped part of the DOM, then attaching the results directly to the test run as an artifact. That pattern works well for pre-merge checks:

• Run a delta scan on changed pages or components for every pull request.
• Run a full-site crawl on a nightly schedule to catch drift across pages nobody touched directly.
• Feed results into CI as SARIF so failures show up alongside other build annotations.
• Automate ticket creation for new findings, and suppress issues that are already tracked so the same failure does not block every subsequent build.

Treat the API output as an input to a remediation pipeline rather than a pass or fail gate alone. Normalize rule IDs across tools if you use more than one, map severity to your existing triage priorities, and attach the selector and a screenshot to whatever ticket gets filed.

Pro Tip: Fail the build on new critical issues only, and let known, tracked issues report as warnings so the pipeline stays useful instead of noisy.

Interpreting API results and building a remediation workflow

An outcome of “failed” means the rule found a concrete violation, such as an image missing alternative text. “Can’t tell” means the engine could not determine compliance automatically and a human needs to look, for example when checking whether alt text is meaningful rather than merely present. “Passed” means the rule’s conditions were satisfied for that element.

Turning that into a working remediation process takes a few deliberate steps:

• Assign severity levels so critical barriers, like a missing form label, get priority over cosmetic contrast issues.
• Route each finding to a code owner using the DOM selector and page location the API returned.
• Keep dated records of every scan and every fix, since that history becomes evidence for a broader compliance program rather than a one-time claim.
• Schedule manual audits and user testing on a recurring basis for anything automation flags as “can’t tell,” particularly complex widgets and custom components.

An accessibility statement that references dated scans and remediation notes gives that documentation somewhere to live beyond a spreadsheet.

Where automation helps and where manual testing is still required

Automated checks are a quality-assurance aid, not a compliance certificate. The DOJ’s guidance and W3C materials on evaluation both frame automated tools as one part of a larger process, never the whole of it. Use DevTools’ accessibility inspection features, which expose the accessibility tree and computed properties, to validate flagged elements by hand alongside tools like ANDI.

AccessWiser’s own approach reflects that division: WCAG 2.2 AA mapping with Section 508 and EN 301 549 references, plain-language code fix guidance, scheduled re-checks, and dated records, built to support a compliance program rather than replace human judgment.

An honest read on API-driven accessibility testing

The industry’s advice on this topic tends to oversell automation’s reach. Vendors market “compliance scanning” when what they are actually selling is a fast, repeatable first pass that catches a meaningful slice of barriers and leaves the rest to a person. That distinction is not a technicality. Teams that treat a clean scan as a finish line end up with sites that pass automated checks and still fail real users who rely on screen readers or keyboard navigation.

What actually works is treating the API as infrastructure, not a verdict. Wire it into CI so every pull request gets checked automatically, use ACT-formatted rules so your results stay comparable across tools, and budget time for manual review on anything the API marks as “can’t tell.” The teams that get this right prioritize consistency over cleverness: the same ruleset, the same severity mapping, the same triage process every single sprint, rather than a one-time audit followed by silence.

If you take one thing from this, prioritize the habit of re-checking over the initial scan. A single clean report tells you almost nothing about a site six months from now.

— The AccessWiser Team

AccessWiser: a practical path from API results to permanent fixes

Running the checks is only half the job. Turning findings into fixed code, and keeping proof that you did it, is where most teams lose momentum. AccessWiser handles that second half directly, scanning against WCAG 2.2 AA with Section 508 and EN 301 549 mappings and tying every finding to the specific element and criterion it affects.

Rather than a runtime patch, each finding comes with plain-language guidance for fixing the issue in your own code, which means the fix stays fixed. AccessWiser pairs that with:

• Scheduled re-checks that catch regressions after a deploy.
• Dated records of scans and fixes for compliance documentation.
• An accessibility statement generator to formalize your public commitment.
• A visitor-facing widget with contrast, text, and reading aid options for people who need them right now.

Plans start with Starter at $24 per month, scaling up through Basic, Pro, and Business for larger teams. Check pricing and plan details to find the right fit, or explore the full solution overview before you commit.

Sources

For rule definitions, consult WCAG and ACT Rules directly. For legal context, see the DOJ’s ADA guidance. For manual inspection, Playwright’s documentation and Section 508’s DevTools guide cover both automated and hands-on methods, and assessment frameworks like the one covered in this accessibility overview offer a useful complementary lens.

• Web Accessibility and the ADA (U.S. Department of Justice)
• Accessibility testing (Playwright docs)

FAQ

What does an accessibility testing API actually check?

It evaluates a page, component, or document against rules tied to standards like WCAG 2.1/2.2 AA and returns a pass, fail, or inapplicable outcome for each rule with a location and remediation note. Document-specific endpoints check PDFs against PDF/UA requirements separately from HTML rules.

Can an accessibility API replace manual testing?

No. The DOJ’s guidance states plainly that automated tools cannot replace manual evaluation, and a clean automated report does not guarantee ADA compliance on its own. Automation catches a useful first layer of issues, but judgment-based problems like alt text quality or reading order need a human reviewer.

How do I add accessibility checks to a CI pipeline?

The most common pattern uses @axe-core/playwright inside your existing test runner to scan pages or components on every pull request, exporting results as test attachments as shown in Playwright’s documentation. Pair that with a remote API or nightly crawl for full-site coverage and centralized reporting.

What does a “can’t tell” result mean?

It means the automated rule could not determine whether the element passes or fails and needs a human to check it, common for things like alt text meaningfulness or complex widget behavior. Treat these results as a queue for manual review rather than ignoring them.

Does AccessWiser offer a free trial?

Yes, AccessWiser offers a free trial period before any paid subscription begins. Plans start at $24 per month with the Starter tier, scaling through Basic, Pro, and Business for larger sites.

Recommended

• Accessibility Solutions for Every Website

Articles on this blog are general information about web accessibility, not legal advice. Laws change and their application depends on your specific situation — for decisions with legal consequences, consult a qualified legal professional.