EU Accessibility Scanner: WCAG 2.1 AA accessibility checker with EN 301 549 / EAA report

Not an overlay or widget. It finds issues in your actual code. This accessibility checker loads each page in a real browser, runs axe-core and reports each WCAG 2.1 A/AA failure that axe-core detects, with its CSS selector, EN 301 549 clause (the standard behind the European Accessibility Act, EAA) and fix guidance, plus an HTML and PDF WCAG audit report in English or Dutch.

No subscription, no auto-renew, no page-view tiers. $0.015 per page scanned, $0.50 per site report.

Use cases

• Agencies and freelancers: attach the audit PDF to a proposal or monthly client report.
• E-commerce and SaaS teams facing the EAA: scan every domain, then re-scan weekly for new and fixed issues.
• Consultants: screen dozens of sites in one run before manual testing.
• Developers: scan after each release via the API, n8n, Make or Zapier.

Sample output (one issue row, real run on the W3C "BAD" demo site):

{
  "type": "issue",
  "url": "https://www.w3.org/WAI/demos/bad/before/home.html",
  "ruleId": "image-alt",
  "impact": "critical",
  "wcagCriteria": ["1.1.1 Non-text Content"],
  "en301549Clauses": ["9.1.1.1"],
  "selector": "img[src$=\"border_left_top.gif\"]",
  "fixGuidance": "Images need a text alternative. Add an alt attribute..."
}

The EAA has applied to most consumer-facing e-commerce, banking, transport and e-book services in the EU since 28 June 2025. Microenterprises providing services (fewer than 10 staff and an annual turnover or balance sheet of at most €2 million) are exempt from its service requirements. Clause numbers refer to EN 301 549 V3.2.1, which maps to WCAG 2.1 AA. An automated scan alone does not make a site compliant: it finds a large share of issues, and manual testing covers the rest (see the FAQ).

What does the EU Accessibility Scanner do?

• Crawls a site automatically. It reads robots.txt and sitemap.xml (including sitemap indexes and .gz sitemaps) and falls back to following links. Sitemap pages are interleaved across sections, so the first 50 pages are not all blog posts.
• Skips duplicate templates. It scans a few pages per URL template (/product/*, /p/<slug>/<id>) and spends the page budget on distinct templates. You can switch this off.
• Tests rendered pages. axe-core runs after JavaScript has rendered, so React, Angular and Vue sites and shops work.
• Maps every issue to WCAG 2.1 success criteria (for example 1.4.3 Contrast (Minimum)) and EN 301 549 clauses (for example 9.1.4.3).
• Explains the fix in plain English or Dutch for about 50 common rules: contrast, alt text, form labels, link names, ARIA, landmarks and more.
• Generates an HTML and PDF report with a score, a criteria table (WCAG SC × EN 301 549), issues grouped by severity and rule, page results, the method and an honest disclaimer.
• Monitor mode remembers the previous run and outputs only new and fixed issues.
• Several sites per run, with a combined report plus one per site. Export results to CSV, Excel or JSON.

Input

Field	Description	Default
startUrls	One or more websites or pages. Several start URLs on one domain are treated as one site.	–
maxPages	Max pages scanned per site	50
language	Report and fix-guidance language: en or nl	en
useSitemap	Discover pages from sitemap.xml before link crawling	true
crawlScope	site = whole domain, path = only below the start URL's folder	site
dedupeTemplates / maxPagesPerTemplate	Scan at most N pages per URL template	true / 2
monitorMode / monitorStoreName	Output only new and fixed issues compared with the previous run that used the same store name	false
includeBestPractices	Also report axe best-practice rules, flagged isBestPractice (not WCAG failures)	false
viewport	desktop (1366×900) or mobile (390×844)	desktop
generateReport / generatePdf	HTML / PDF report in the key-value store	true
maxConcurrency, pageTimeoutSecs, maxIssuesPerRulePerPage, proxyConfiguration	Advanced settings

Output

Dataset: one row per failing element (type: "issue", full fields include wcagLevel, html, helpUrl and changeType) plus one row per site (type: "site-summary") with score, pagesScanned, issuesByImpact, criteriaFailed and needsManualReview.

Key-value store: report.html and report.pdf (plus report-<host>.html/.pdf per site when you scan several), SUMMARY (per-site JSON) and OUTPUT (run overview with report links and events charged).

The score (0–100) is the share of applicable axe rules a page passes, weighted by severity (critical 10, serious 7, moderate 3, minor 1), averaged per site. It is a progress indicator, not a compliance percentage.

Schedule recurring accessibility scans

A theme update or a new product template can add issues at any time. A schedule turns a one-off WCAG audit into monitoring.

1. Save your input as an Apify Task (for example one task per client, each with its own monitorStoreName).
2. Turn on monitorMode.
3. In Apify Console, open Schedules, create a schedule with a cron expression (for example 0 6 * * 1 for Mondays at 06:00, in your time zone) and add the task.

Each run then returns only issues marked new or fixed, and the report gets a "Changes since previous scan" section. See Apify schedules.

Use it from n8n, Make and Zapier

Apify has official integrations for all three tools. Connect your Apify account with an API token, then use the Apify app or node to run an Actor or Task and fetch its dataset items, or use a trigger that fires when an Actor or Task run finishes.

Typical workflows:

• Weekly client report: a schedule runs the task; when the run succeeds, n8n, Make or Zapier fetches the site-summary row and posts the score and new issue count to Slack, or emails the report.pdf link to the client.
• Ticket per new issue: with monitorMode on, send each changeType: "new" issue to Jira, Linear, Trello or a Google Sheet. Skip the first run: with no baseline yet, every issue comes through as new (the site summary's monitor.previousRunAt is null). An issue is identified by page, rule and selector, so a changed selector shows up as a fixed + new pair.
• Post-deploy check: your pipeline calls the Apify API to scan the changed pages.

Guides: n8n, Make, Zapier.

Pricing (pay per event)

No subscription, no auto-renew, no page-view or traffic tiers. You only pay for what is scanned:

Event	Price
Page scanned (page-scanned)	$0.015 per page
Report generated (report-generated)	$0.50 per site report (HTML + PDF)

Examples: a 50-page scan with a report costs $1.25. 20 sites × 25 pages with reports cost $17.50. A weekly 50-page monitor scan with a report costs about $5 a month.

Apify's free plan includes $5 of monthly platform credit, enough for about four 50-page audits a month. Set Maximum cost per run in the run options to cap spend; the scanner stops cleanly at the limit. Failed pages are not charged.

FAQ

Does a clean report mean my site is EAA or WCAG compliant? No. Automated tools reliably check only part of WCAG, an estimated 30–50% of real-world issues. Meaningful alt text, keyboard use of complex widgets and clear error messages need manual testing. Use it as a prioritised fix list and monitoring tool, not as a certificate or legal advice.

Is this an accessibility overlay or widget? No. Nothing is added to your site. It is an external scan that reports problems in your HTML, CSS and ARIA so they can be fixed in your code. It tests the page as a visitor's browser loads it, including any overlay script on the page. It does not detect or switch off overlays.

Which standard is used? WCAG 2.1 level A and AA rules from axe-core (tags wcag2a, wcag2aa, wcag21a, wcag21aa), mapped to EN 301 549 V3.2.1 clause 9, where clause 9.x.y.z corresponds to WCAG success criterion x.y.z. ETSI published EN 301 549 V4.1.1, based on WCAG 2.2 AA, in September 2026. Until the European Commission cites it in the Official Journal, V3.2.1 remains the reference version.

Can it scan pages behind a login? Not in this version. It scans public pages.

Can I get the report in Dutch? Yes. Set language to nl and the report ("Toegankelijkheidsrapport"), criteria names, rule titles and fix guidance are in Dutch.

How do I get only changes each week? Turn on monitorMode, keep monitorStoreName the same between runs (one name per client) and schedule the Actor or Task.

Why was a page reported as failed? The site returned an HTTP error (404, or 403 from bot protection) or timed out. Failed pages are listed in the report and not charged. For sites with aggressive bot protection, try Apify Proxy (residential) in proxyConfiguration.

Limitations

• Automated testing only. No manual checks, screen-reader testing, or PDF/document accessibility checks.
• Template de-duplication is heuristic. If it skips pages you need, raise maxPagesPerTemplate or turn it off.
• Results reflect the page after load (cookie banners included). Open menus, modals and checkout steps are not exercised.
• Single-page apps that never expose links or a sitemap may need several start URLs.
• WCAG 2.2-only criteria (for example 2.5.8 Target Size) are not checked yet. They are in EN 301 549 V4.1.1 but not in V3.2.1.

Keywords

accessibility checker, WCAG checker, WCAG audit, WCAG 2.1 AA, EAA accessibility check, European Accessibility Act, EN 301 549, accessibility audit report, bulk accessibility scanner, axe-core, toegankelijkheid scan, toegankelijkheidsrapport.