NF Accessibility Scanner
Multi-engine WCAG accessibility audit for any web page
What it is.
NF Accessibility Scanner audits a single web page against WCAG 2.x success criteria using six engines that run together by default: a full axe-core ruleset audit, a Lighthouse accessibility audit, an automated keyboard-navigation walkthrough in headless Chromium, and three no-browser TypeScript engines that check HTML structure, media captions, and viewport/zoom accessibility.
Because Chromium is bundled directly into the Actor's Docker image, there is no external API dependency and no separate browser service to configure — you pass a URL and get a structured report back, typically in 1–2 minutes for a full six-engine run.
Each run audits exactly one page — pass one URL per run rather than expecting a full-site crawl, and loop over pages (via the Apify API or a schedule) to cover a whole site. It's a floor, not a certification: automated tooling catches a large, well-defined subset of WCAG failures, but things like meaningful alt-text quality and logical reading order still need human review.
What it checks and does.
axe-core ruleset audit
Full axe-core WCAG 2.x rule engine — the same DOM-rule engine behind most browsers' accessibility dev tools.Lighthouse accessibility audit
Google Lighthouse's rendered-page accessibility score, catching some issues axe's DOM rules don't.Keyboard-navigation testing
Headless Chromium simulates Tab-key navigation, flagging focus traps and unreachable interactive elements.HTML structure checks
Native engine validating alt text, form labels, heading hierarchy, document title, and duplicate ids — no browser required.Media captions checks
Flags missing captions/transcripts on video/audio and missing titles on embedded video iframes.Viewport & zoom accessibility
Flags viewport meta configuration that disables pinch-to-zoom — a common WCAG 1.4.4/1.4.10 failure.Score, grade & SARIF + CI gating
A 0–100 score maps to a letter grade (A–F); outputFormat: "sarif" emits SARIF 2.1.0, and failOnGrade/failOnSeverity exit non-zero to fail a CI pipeline on regressions.
Where it fits.
- Gate pull requests on accessibility regressions in CI/CD
- Run a recurring WCAG audit across every page of a marketing site
- Produce an evidence report ahead of an ADA/Section 508 compliance review
- Give an AI agent or MCP tool a one-shot, structured accessibility check it can call and parse
Call it with this.
| Field | Type | Required | Description |
|---|---|---|---|
url | string | Yes | The page to scan. |
engines | string[] | No | Opt-out list — all six engines run unless explicitly excluded. |
requestHeaders / cookies | object / string | No | Extra headers or a session cookie for authenticated scanning (not carried by the Lighthouse render-audit engine). |
outputFormat | "json" | "sarif" | "both" | No | Add a SARIF 2.1.0 report alongside the JSON output. |
failOnGrade / failOnSeverity | string | No | Exit non-zero above a grade/severity threshold, for CI gating. |
Pricing:$200 per 1,000 completed scans ($0.20/scan), pay-per-event, plus your own Apify platform usage for that run.
Frequently asked questions.
What does the NF Accessibility Scanner check?
It runs six engines against a single page: an axe-core ruleset audit, a Lighthouse accessibility audit, automated keyboard-only navigation testing, and three no-browser checks for HTML structure, media captions, and viewport/zoom accessibility. All six run by default and merge into one normalized, deduplicated report.
Does it crawl a whole website?
No — each run audits exactly one URL. To cover a whole site, run the Actor once per page, looping over your page list via the Apify API or a schedule.
Can I use it to block a CI pipeline on accessibility regressions?
Yes. Set failOnGrade or failOnSeverity in the input and the run exits non-zero once a page crosses that threshold, and outputFormat: "sarif" produces a SARIF 2.1.0 file that GitHub and GitLab code scanning understand natively.
Does it need an external accessibility API?
No. Headless Chromium is bundled directly into the Actor's Docker image, so axe-core, Lighthouse, and the keyboard-navigation engine all run locally inside the Actor with no external API calls or extra accounts.
Can this replace a manual accessibility audit?
No, and it doesn't claim to. Automated tooling reliably catches a large, well-defined subset of WCAG failures (missing alt text, label associations, focus traps, contrast, etc.), but meaningful alt-text quality, logical reading order, and cognitive load still need human review. Treat a clean grade as a floor, not a certification.