WCAG Accessibility & Release Gate Auditor

Audit public web pages in a real Chromium browser and export structured axe-core evidence for automated WCAG 2.0, 2.1, and 2.2 Level A/AA checks. Each completed page receives a deterministic score, grade, and conservative PASS, REVIEW, or BLOCK release-gate signal. No external API key is required.

What it returns

Every successfully audited page includes:

• an automated score from 0 to 100 and grade from A to F;
• a BLOCK signal when axe reports critical or serious affected nodes;
• a REVIEW signal for other violations or incomplete/manual checks;
• a PASS signal only when axe reports no violations and no incomplete checks;
• violation rule and affected-node totals;
• critical, serious, moderate, minor, and unknown impact counts;
• sanitized CSS targets and short failure summaries;
• page title, final public URL, HTTP status, viewport, and rule-set label;
• an explicit manual-review boundary on every row.

Node HTML is intentionally not stored. A result can identify a public selector and remediation summary without copying form values or full page markup into the dataset.

Input

Choose exactly one source:

{
  "urls": [
    "https://example.com",
    "https://www.w3.org/WAI/demos/bad/before/home.html"
  ],
  "maxItems": 50,
  "concurrency": 2,
  "timeoutMs": 45000,
  "settleMs": 1000,
  "viewport": "desktop",
  "includeBestPractices": false,
  "deduplicate": true
}

Or use items / datasetId with urlField, including a nested dot path such as page.canonicalUrl. Run the same URLs once with desktop and once with mobile when both viewport experiences matter.

Bare domains are interpreted as HTTPS. Identical normalized URLs can be emitted as uncharged duplicate records instead of being opened twice.

Release-gate meaning

Signal	Automated meaning	Required next action
BLOCK	One or more critical or serious affected nodes were detected.	Fix and rerun before release.
REVIEW	Other violations or incomplete rules need review.	Review evidence and perform manual checks.
PASS	No axe violations or incomplete checks were returned for this run.	Still perform manual assistive-technology and human testing.

The score is a transparent triage aid: 100 - (critical nodes × 10 + serious × 6 + moderate × 3 + minor × 1 + unknown × 2), with a zero floor. It is not a standard-defined conformance score.

Example result

{
  "inputUrl": "https://example.com",
  "status": "audited",
  "viewport": "desktop",
  "score": 94,
  "grade": "A",
  "releaseGate": "BLOCK",
  "violationRules": 1,
  "violationNodes": 1,
  "impactCounts": {
    "minor": 0,
    "moderate": 0,
    "serious": 1,
    "critical": 0,
    "unknown": 0
  },
  "charged": true,
  "manualReviewRequired": true
}

Browser and network boundary

• Only public HTTP and HTTPS targets are allowed.
• Local/private hostnames, credentials in URLs, and private, loopback, link-local, reserved, multicast, test-network, or otherwise non-unicast IP addresses are blocked.
• DNS answers are checked before the connection and the approved public IP is pinned.
• Every redirect is independently checked before it is followed.
• Hosts referenced by static HTML are separately resolved and pinned before Chromium opens.
• Browser requests to dynamically introduced, unapproved hosts are blocked. Pages that depend on such hosts may produce conservative or incomplete results.
• Initial HTML size, redirects, browser time, post-load settling, concurrency, and source rows are bounded.
• Full HTML, node HTML, screenshots, form values, cookies, and request bodies are not stored in the dataset or logs.
• Logs contain aggregate settings and counts only.

Accessibility evidence boundary

Automated axe-core checks find many detectable accessibility issues, but cannot prove WCAG conformance, legal compliance, or usability. A PASS applies only to the selected page, viewport, content state, axe version, and automated rule set at the time of the run. Keyboard navigation, screen-reader behavior, cognitive usability, content quality, alternate states, authentication flows, and jurisdiction-specific legal duties require appropriate manual and professional review.

Pricing behavior

The Actor uses pay-per-event pricing:

• one small run-start event;
• one page-audited event for each public page that completes browser rendering and axe analysis;
• invalid, blocked, failed, spending-limited, and duplicate rows are not charged the per-page event.

Apify enforces the caller's maximum total charge. If the remaining spending limit cannot cover another page event, unopened rows are returned with SPENDING_LIMIT_REACHED rather than silently overspending.

Common uses

• block critical and serious automated findings in release workflows;
• audit public landing pages or sitemaps exported to a dataset;
• compare desktop and mobile accessibility evidence;
• triage affected selectors for remediation teams;
• feed structured results into Apify schedules, webhooks, APIs, or MCP workflows;
• monitor public-page regressions while preserving an explicit manual-review requirement.

Only audit pages you are authorized to test, and keep request volume appropriate for the target site.