Five engines, then a second look at the live page for the findings that change under a scanner. Every patch is re-scanned on a sandboxed copy of your page before we call it VERIFIED. No overlays. No 200-page PDFs. No “full compliance” claims.
Exhibit A · Sample scan
Sample output
▍ ap-scan · https://your-site.com
● live
Score
87/100
Verified fixes
3 copy-as-PR
Tier-1 risk
1
Engines per scan
5
axe-core, IBM Equal Access, ARC and pa11y on every page; Lighthouse on the start page.
WCAG 2.2 coverage
30 to 40%
Automated, honestly. The rest needs human review. We say so.
Rules catalogued
294
Each with its engine and where it runs; 17 seen firing in our own tests. Read the catalogue
Benchmark precision
100%
Of the defects we flag on 15 hand-annotated fixtures; 97% counted finding by finding. Read the benchmark
Section 02 · Field audits on the real web
Accessibility Pro has been built and tuned since January 2026. Since 7 September 2026, every round of accuracy fixes is measured the same way: the same sites scanned through production before and after, 5 pages each, and every finding the fixes removed sent back to the live page for a re-check. 5 dated editions so far, each published with its raw data. Fixtures tell you what a scanner can do; the real web tells you what it does.
Site scans, 5 editions
554
173 different websites, every one scanned before and after a round of fixes. 69 of them came back for a second edition, so a fix that only held once would show.
Removed findings judged live
2,154
Of 9,395 findings a fix made disappear, these could be judged on the live page. 90 of them were genuinely lost, and each edition says where and why.
Scanner defects found and fixed
224
Each one found on a real site and fixed with a regression test that fails without it. The newest edition is the September 2026 field audit V, 56 sites.
Section 03 · Capabilities
Every card below runs in production today. Most of it is what a manual tester does and a static engine cannot: press the keys, submit the forms, read the page the way a visitor gets it.
The scanner presses Tab and Shift+Tab through each page, confirms a keyboard trap by trying Escape and checks that the skip link really moves focus. On the first pages of a scan it also measures the focus indicator in pixels.
WCAG 2.1.2 · 2.4.1 · 2.4.7
It presses submit with a required field left empty, so the browser blocks sending and nothing leaves your site, then checks that each error is tied to its field, marked invalid and announced.
WCAG 3.3.1 · 4.1.2 · 4.1.3
Cookie banners dismissed in more than a dozen languages, Arabic included; bot, consent and login walls detected and named; lazy content loaded; and language versions such as /ar/ or /it/ sampled so no locale is skipped.
consent · walls · locales · right-to-left
Shadow roots pierced, axe re-run in hover, focus, dark-theme and open-dialog states, and contrast judged on the rendered pixels with APCA, not on the declared CSS.
shadow DOM · states · APCA
A patch is applied to a sandboxed copy of the page and re-scanned. It is offered as a diff only when the targeted violations clear and nothing new appears; otherwise a snippet. Alt text, aria-label and form labels today.
apply · re-scan · only-then-emit
Every finding carries its ADA litigation tier and EN 301 549 clause. On Team and above the report also drafts your accessibility statement and a VPAT 2.4, leaving blank what only a person can know.
EAA · EN 301 549 · ADA · VPAT
Section 04 · The report
On every plan, including the free one.
Findings are grouped into Quick wins, Roadmap, Polish and Backlog. A quick win has high impact and an estimated fix time of an hour or less.
The report shows what fixing the top three findings would do to your score, and each finding shows its own gain. It is an estimate from the same scan, not a new one.
Narrow the list by who a finding blocks (visual, motor, cognitive, auditory, seizure) and by who changes it: content, design or engineering.
Each finding says how it was confirmed, from verified by interaction and pixel-verified to multi-engine or single engine, and which engines detected it.
Section 05 · Mechanism
A patch isn’t a fix until the page re-renders without the violation. Our pipeline proves that before you ever see the diff.
See the GitHub ActionEngine consensus identifies a verifiable violation with stable selector + WCAG mapping.
LLM generates a unified-diff patch grounded in the captured DOM + rule context.
Patch is applied in a sandboxed clone of the page and axe-core re-runs against the patched DOM.
At least 80% of the targeted violations cleared AND no new violation introduced → emit. Otherwise: fall back to snippet + manual notes.
Surface to user with chain-of-custody: fetch timestamp, ETag, engine vote, verifier outcome.
Section 06 · Questions
Accessibility Pro is an automated web accessibility scanner. It checks a website against WCAG 2.2 Level AA with five engines, axe-core, IBM Equal Access, ARC, pa11y and Lighthouse, re-verifies the findings on the live page, and turns the ones that can be fixed in code into patches that are tested in a sandbox before they are offered as a diff. It adds no overlay script to your site and it never issues a compliance certificate.
Yes. The free checker tests one page against WCAG 2.2 with no account: you get a score, the number of issues by severity and the five issues with the most impact, up to three checks a day. A free account scans up to 30 pages at a time, five times a month, and the GitHub Action runs ten scans a day per repository with no account at all.
An overlay is a script added to every page that tries to repair the page in the visitor's browser, and your code stays as it was. Accessibility Pro reports the problems in your code and gives your developers a tested change to ship, so every visitor gets the fix and nothing breaks when a script fails to load.
Accuracy is published rather than claimed. On 15 hand-annotated WCAG fixtures, including false-positive traps, the scanner currently measures 100% precision and 88% recall. A dated field audit series also scans real websites before and after each round of fixes, and every finding the fixes removed is sent back to the live page for a re-check, with the ones it cannot judge counted as such.
Yes. The Accessibility Pro GitHub Action scans a URL on every pull request with all five engines and live-DOM verification, keeps one comment on the pull request up to date, fails the build on the severity you choose or on any Level A or AA failure, and can write SARIF for the Security tab. Ten scans a day per repository are free without an account.
Every finding is tagged with its ADA Title III litigation tier and its European Accessibility Act and EN 301 549 clause. On the Team plan and above, a Compliance tab marks each EN 301 549 criterion as supported, partial, not supported or not tested, and exports the table as JSON, as a VPAT 2.4 text document and as a draft accessibility statement. Automated testing reliably covers only 30 to 40% of WCAG 2.2 criteria, so every report names what still needs a person, and no plan issues a certificate.
A free account and the GitHub Action cost nothing. Paid plans are one flat price for the whole organisation, never per seat: Developer at 49 euros a month, Team at 249 euros a month and Business at 899 euros a month, each metered on pages scanned, with 10% off when billed annually.
Yes. The Developer plan includes five scans behind a login a month and the Team and Business plans have no cap. The scanner loads pages the way a visitor's browser does and identifies itself to your site with a per-site request header, so a security team can allow it through a firewall or bot protection without opening the door to anyone else.
Yes. The engines read the page's code, so a site in any language and any script can be scanned, including right-to-left languages such as Arabic. When a site has language versions, such as /ar/ or /it/, the scanner recognises them from the site's own language markup and checks a sample of each so no locale is skipped, or every version in full if you ask. It flags text written in a different language from its lang attribute, and it dismisses cookie banners written in more than a dozen languages. Report explanations are written in English.
Accessibility Pro is built and tested by two disability entrepreneurs and digital accessibility experts who both use a screen reader every day: its founder Hasan Tayem, a blind accessibility specialist, human rights advocate and founder of the assistive technology marketplace All Access World, and Elena Karamanska, an IAAP CPACC-certified accessibility consultant who has used screen readers for more than twenty years and reviewed more than a thousand websites for accessibility. The scanner is built by people who depend on the standard it tests against.
Section 07 · Disclosure
“We will never say full WCAG compliance.”
Automated scanning reliably covers 30 to 40% of WCAG 2.2 criteria. The rest takes human judgement, and no scanner can honestly tell you otherwise. We tell you what we detected, what we fixed, and what still requires human review. The result is a report your auditor will respect, and a diff your reviewer will merge.
Never
overlays
Never
unverifiable claims
Never
200-row spreadsheets