Website Accessibility Checker

Audit rendered public webpages and export machine-readable WCAG findings with the Website Accessibility Checker Actor.

It loads each supplied URL in Chromium, runs the industry-standard axe-core engine against the rendered DOM, and returns one structured page record containing violations, impacts, affected CSS selectors, HTML evidence, rule references, and pass summaries.

Use the results for one-time accessibility reviews, release checks, scheduled regression monitoring, spreadsheets, dashboards, and automated data pipelines.

What does this Actor do?

The Actor performs an automated accessibility audit of each submitted public webpage.

For every successfully rendered page, it:

1. validates that the URL resolves only to public network addresses;
2. renders the page in a real Chromium browser;
3. waits for the selected page-readiness milestone and render delay;
4. injects axe-core into the final DOM;
5. runs the selected WCAG rule tags;
6. groups failed rules by impact;
7. records affected selectors, bounded HTML evidence, and fix summaries;
8. returns pass and manual-review counts;
9. optionally includes detailed passed and incomplete rules.

The Actor does not treat a browser challenge or navigation failure as a clean accessibility result.

Who is it for?

Accessibility and compliance teams

Export stable rule IDs, WCAG criteria, impact levels, selectors, and references for triage and recurring reviews.

Developers and QA engineers

Add rendered-page accessibility checks to release workflows and compare structured results between versions.

Agencies and consultants

Audit batches of client-owned public pages and deliver machine-readable evidence alongside human review.

Data and automation teams

Send dataset rows to spreadsheets, databases, webhooks, or BI tools without parsing a visual report.

This is an automated testing aid, not a certification service or legal opinion.

Why use this website accessibility checker?

• Rendered DOM: audits JavaScript-generated interfaces, not only source HTML.
• Structured evidence: outputs rule IDs, WCAG criteria, CSS selectors, HTML snippets, and failure summaries.
• Repeatable fields: suitable for schedules and regression comparisons.
• Explicit uncertainty: axe-core incomplete checks can be retained for manual review.
• Pass summaries: always returns the pass count and can include compact passed-rule records.
• Batch safe: one failed page does not erase successful results from other pages.
• SSRF protection: rejects local, private, reserved, and credential-bearing destinations, including redirect and subresource hops.
• No automatic paid proxy: costs do not silently change because a target blocks Chromium.

Website content accessibility guidelines covered

By default, the Actor selects these axe-core tags:

• wcag2a
• wcag2aa
• wcag21aa
• wcag22aa

You can also select wcag2aaa, wcag21a, or best-practice.

Rule tags describe the automated checks to run. Automated tools cannot verify every Web Content Accessibility Guidelines requirement, user journey, assistive-technology behavior, or legal obligation.

Use incompleteRules as a manual-review queue rather than treating it as a pass or failure.

Input

Field	Type	Default	Description
startUrls	array	required	Up to 100 public HTTP(S) webpages to render and audit.
maxItems	integer	submitted URL count	Maximum submitted pages to process, from 1 to 100.
wcagTags	string array	WCAG A/AA set	Supported axe-core WCAG and best-practice tags.
includePassedRules	boolean	false	Include compact detail for rules that passed.
includeIncompleteRules	boolean	true	Include rules and nodes that need manual review.
waitUntil	string	domcontentloaded	Browser readiness milestone: domcontentloaded, load, or networkidle.
renderDelayMs	integer	500	Extra post-navigation render delay, from 0 to 30,000 ms.
navigationTimeoutSecs	integer	45	Per-attempt navigation timeout, from 5 to 120 seconds.

Small input example

{
  "startUrls": [
    { "url": "https://www.python.org/" }
  ],
  "maxItems": 1,
  "wcagTags": ["wcag2a", "wcag2aa", "wcag21aa", "wcag22aa"],
  "includePassedRules": false,
  "includeIncompleteRules": true,
  "waitUntil": "domcontentloaded",
  "renderDelayMs": 500,
  "navigationTimeoutSecs": 45
}

Output fields

The default dataset contains one row per requested page.

Field	Meaning
requestedUrl	Validated submitted URL.
finalUrl	Final URL after public redirects, or null on failure.
status	succeeded or failed.
statusCode	Main-document HTTP status when available.
title	Rendered page title.
wcagTags	Rule tags used for this audit.
violationCount	Number of distinct failed rules.
affectedNodeCount	Total affected DOM nodes across failed rules.
violationsByImpact	Rule counts for minor, moderate, serious, critical, and unknown impacts.
violations	Failed rules with references and affected-node evidence.
passedRuleCount	Number of rules with passing nodes.
passedRules	Optional compact passed-rule summaries.
incompleteRuleCount	Number of rules requiring manual review.
incompleteRules	Optional manual-review rules and affected nodes.
inapplicableRuleCount	Number of selected rules not applicable to this page.
testEngine	axe-core.
testEngineVersion	axe-core version used by the run.
runtimeMs	Render and audit duration for the page.
auditedAt	ISO 8601 audit timestamp.
error	Bounded failure reason, or null after success.

Fields can be null when the browser cannot obtain the corresponding value.

Example WCAG audit result

This shortened record reflects the current output shape:

{
  "requestedUrl": "https://www.python.org/",
  "finalUrl": "https://www.python.org/",
  "status": "succeeded",
  "statusCode": 200,
  "title": "Welcome to Python.org",
  "wcagTags": ["wcag2a", "wcag2aa", "wcag21aa", "wcag22aa"],
  "violationCount": 5,
  "affectedNodeCount": 103,
  "violationsByImpact": {
    "minor": 0,
    "moderate": 0,
    "serious": 3,
    "critical": 2,
    "unknown": 0
  },
  "violations": [
    {
      "id": "aria-required-children",
      "impact": "critical",
      "wcagCriteria": ["1.3.1"],
      "help": "Certain ARIA roles must contain particular children",
      "helpUrl": "https://dequeuniversity.com/rules/axe/4.13/aria-required-children?application=axeAPI",
      "affectedNodeCount": 4,
      "nodes": [
        {
          "selectors": [".meta-navigation > ul[role=\"tree\"]"],
          "html": "<ul class=\"menu\" role=\"tree\">",
          "failureSummary": "Fix any of the following: Element has children which are not allowed: li",
          "impact": "critical"
        }
      ]
    }
  ],
  "passedRuleCount": 22,
  "passedRules": null,
  "incompleteRuleCount": 1,
  "inapplicableRuleCount": 48,
  "testEngine": "axe-core",
  "testEngineVersion": "4.13.0",
  "error": null
}

Page content and accessibility findings change over time, so counts are examples rather than guarantees.

How to run your first audit

1. Open the Actor in Apify Console.
2. Add one or more public webpage URLs under Public webpage URLs.
3. Keep the default WCAG tags for a standard A/AA check.
4. Enable Include passed-rule details only when you need full pass metadata.
5. Click Start.
6. Open the Dataset tab.
7. Review impact counts first, then expand violations and incompleteRules.
8. Export JSON, CSV, Excel, XML, or connect the dataset to another system.

Start with one representative page before increasing a batch.

How much does it cost to audit a webpage for WCAG issues?

Pay-per-event pricing has two events:

• Accessibility audit started: $0.005 once per run.
• Page audited: charged only for each page successfully rendered and audited.

Current page-audit prices are:

Apify tier	Price per audited page
FREE	$0.0391
BRONZE	$0.0340
SILVER	$0.02652
GOLD	$0.0204
PLATINUM	$0.0204
DIAMOND	$0.0204

At BRONZE, approximate totals are:

• 1 successful page: $0.039 including the start event.
• 10 successful pages: $0.345 including the start event.
• 100 successful pages: $3.405 including the start event.

A failed page produces a diagnostic dataset row but no page-audit event. Passed rules, incomplete rules, selectors, and evidence are included in the page event and have no separate charge.

Recurring accessibility regression checks

Apify schedules can run the same input daily, weekly, or before a release.

A practical workflow is:

1. keep the URL list and WCAG tags stable;
2. schedule the Actor;
3. store each dataset ID and run timestamp;
4. compare violations[].id, affectedNodeCount, and violationsByImpact;
5. notify the owning team when new serious or critical findings appear;
6. preserve incomplete checks for human review.

This Actor reports the current page. It does not maintain cross-run history or send alerts by itself.

CI and release-gate pattern

Call the Actor from CI with release-candidate URLs.

After completion, fetch dataset items and apply your own policy, for example:

• fail when status is failed;
• fail when critical violation count increases;
• warn on new serious rules;
• create tickets from affected selectors;
• require review of incompleteRules.

Avoid treating violationCount === 0 as legal certification.

cURL API example

Replace YOUR_APIFY_TOKEN with an Apify token stored in your secret manager.

curl -X POST \
  "https://api.apify.com/v2/acts/automation-lab~website-accessibility-wcag-audit/runs?token=YOUR_APIFY_TOKEN&waitForFinish=120" \
  -H "Content-Type: application/json" \
  -d '{
    "startUrls": [{"url": "https://www.python.org/"}],
    "maxItems": 1,
    "wcagTags": ["wcag2a", "wcag2aa", "wcag21aa", "wcag22aa"]
  }'

Fetch the resulting dataset with the defaultDatasetId returned by the run.

JavaScript API example

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });

const run = await client.actor('automation-lab/website-accessibility-wcag-audit').call({
  startUrls: [{ url: 'https://www.python.org/' }],
  maxItems: 1,
  includeIncompleteRules: true,
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(items[0].violationsByImpact);

Python API example

import os
from apify_client import ApifyClient

client = ApifyClient(os.environ['APIFY_TOKEN'])

run = client.actor('automation-lab/website-accessibility-wcag-audit').call(run_input={
    'startUrls': [{'url': 'https://www.python.org/'}],
    'maxItems': 1,
    'includeIncompleteRules': True,
})

items = client.dataset(run['defaultDatasetId']).list_items().items
print(items[0]['violationsByImpact'])

Use with Apify MCP

Add this Actor to Claude Code:

claude mcp add --transport http apify \
  "https://mcp.apify.com?tools=automation-lab/website-accessibility-wcag-audit"

Claude Desktop setup

Add the following remote MCP server configuration in Claude Desktop.

Cursor setup

Use the same remote MCP server JSON in Cursor's MCP settings.

VS Code setup

Add the same server URL through your VS Code MCP extension or workspace MCP configuration.

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=automation-lab/website-accessibility-wcag-audit"
    }
  }
}

Example prompts:

• "Audit Python.org against WCAG A and AA and summarize critical selectors."
• "Check these three staging pages and return rule IDs that fail on more than one page."
• "Run an accessibility regression audit and format serious findings for our issue tracker."

Limits and reliability

• A run accepts at most 100 submitted URLs.
• Pages are processed sequentially to keep browser memory predictable.
• Only anonymous public HTTP(S) pages are supported.
• URLs with credentials, non-web protocols, private addresses, or reserved addresses are rejected.
• Redirect and subresource requests are checked against the same public-network policy.
• Login walls, CAPTCHA pages, and anti-bot interstitials are not bypassed.
• A transient timeout, network error, 429, or 5xx receives one retry with a fresh context.
• Stable 4xx responses and detected challenges are not blindly retried.
• The Actor does not automatically enable residential proxies.
• Dynamically changing pages can produce different findings between runs.
• axe-core covers automatable rules; manual evaluation remains necessary.

If every page fails, the Actor run fails after storing diagnostic rows.

Tips for useful results

• Audit the same URL, viewport assumptions, tags, and render delay when comparing runs.
• Use load if the DOM-ready state is too early for a page.
• Use networkidle cautiously; analytics and live connections can prevent it from settling.
• Increase renderDelayMs for late client rendering, not as a substitute for a correct readiness milestone.
• Keep includePassedRules off for compact regression datasets.
• Keep includeIncompleteRules on when a human reviewer will triage uncertain checks.
• Group findings by violations[].id before opening one ticket per affected selector.
• Follow each helpUrl for rule context and remediation guidance.

Troubleshooting

Why did the page fail with a private or reserved address error?

The submitted hostname, redirect, or subresource resolved to a non-public network address. The Actor rejects it to prevent server-side request forgery. Use an anonymously reachable public URL.

Why did the Actor report a challenge instead of violations?

The target returned an anti-bot or verification page. A challenge is not the page you intended to audit, so the Actor records a failure rather than a misleading clean result.

Why are some rules incomplete?

Some checks require visual or contextual judgment that axe-core cannot determine automatically. Review incompleteRules[].nodes, the selectors, and the linked rule reference.

Why do violation counts differ from another tool?

Tools can use different engine versions, rule tags, render timing, browser state, viewport assumptions, and custom rules. Compare like-for-like settings and inspect stable rule IDs rather than only a total score.

Does a zero-violation result prove WCAG compliance?

No. It means no selected automated axe-core rule failed on the rendered page at that moment. Manual testing, keyboard navigation, assistive technology, content review, and applicable legal analysis may still be required.

Legality and responsible use

Audit only pages you are authorized to test.

Respect website terms, rate limits, copyright, privacy obligations, and organizational policies. Do not submit private intranet URLs, authenticated pages, personal data, or secrets.

The output is technical evidence for review. It is not a guarantee of conformance with WCAG, ADA, EAA, Section 508, or any other legal standard.

Related Automation Lab Actors

• Lighthouse Website Audit — use when you also need performance, Core Web Vitals, best-practice, and SEO scores.
• Sitewide Broken Link Checker — use for bounded link discovery and broken-link status checks.
• Website HTML & Text Change Monitor — use when the buyer job is content-change detection rather than accessibility testing.

Choose this Actor when detailed axe-core WCAG rules and affected DOM evidence are the primary output.

FAQ

Can I audit multiple pages?

Yes. Add up to 100 public URLs and set maxItems to the desired processed count.

Can I crawl an entire site automatically?

No. This version audits supplied page URLs. Provide a bounded list from your own sitemap, crawler, or release manifest.

Are passed rules available?

Yes. passedRuleCount is always returned. Set includePassedRules to true for compact metadata about each passing rule.

Are incomplete checks charged separately?

No. Violations, pass summaries, and incomplete checks are included in the successful page-audit event.

Can it audit authenticated applications?

No. The Actor supports anonymously reachable public pages and does not accept cookies, passwords, or account sessions.

Which browser does it use?

It uses the maintained Playwright Chromium runtime in the Actor container.

Does it fix accessibility problems?

No. It exports evidence and remediation references. Your development or content team applies and validates fixes.

Can I export the data?

Yes. Apify datasets support JSON, JSONL, CSV, Excel, XML, RSS, and API access. Nested violation details are richest in JSON or JSONL.