Inkluso opens the pages of your site in a real Chromium browser, runs the axe-core engine on each one and maps each WCAG finding to its success criterion, the EN 301 549 clause and a paragraph of the national act you select. It is an automated first-line check: it covers roughly 30 to 40 percent of WCAG success criteria, and the rest needs a person.

This page sets out the stages, the tools, what you receive and where the method stops. The facts come from our scanner code and report templates.

What are the stages of an Inkluso test?

A test has five stages: crawl, test, map, report and re-scan. Each stage has its own section below with the tool used and what it produces.

  1. Crawl. Playwright and Chromium load pages found through robots.txt, sitemaps and links on the site. Output: the list of pages to test.
  2. Test. axe-core 4.12.1 on the rendered page. Output: findings with the CSS selectors of the affected elements.
  3. Map. Each finding to a WCAG criterion, an EN 301 549 clause and a paragraph of the national act. Output: the legal reference on every finding.
  4. Report. A PDF with a timestamp, the engine version and a SHA-256 hash. Output: a dated record of one automated scan.
  5. Re-scan. A new scan of the same site after you fix things. Output: a comparison with your original audit.

What does an Inkluso scan actually do?

A scan opens each page in a real Chromium browser driven by Playwright and runs axe-core 4.12.1 on the rendered page. 4.12.1 is the version bundled in the scanner on the review date of this page, and every report prints the version that ran.

The rule sets are WCAG 2.1 A and AA, the WCAG 2.2 target-size rule, five WCAG-mapped rules that axe tags as experimental, and axe’s best-practice checks. Best-practice checks have no WCAG success criterion, so they carry no legal reference.

Where axe cannot decide a colour-contrast check, for example text over an image or a gradient, the scanner samples the rendered pixels. It issues a result only outside a 5 percent band around the threshold; inside the band the check stays marked for manual review.

On paid audits a Tab-key walk also runs on up to three pages, with 60 Tab presses and a shared budget of 90 seconds. It is a heuristic: it stays out of the grade, and its findings are marked to be confirmed by hand.

How many pages does a scan cover?

The free scan tests the homepage only, up to five scans per hour per IP address. A paid audit crawls up to 100 pages.

The scanner takes addresses from robots.txt, sitemaps and links on the site, from the same domain only and only where robots.txt allows. When the site has more pages than the audit budget, it picks pages from every page template (home, cart, checkout, search, account, contact, legal pages and others) rather than the first URLs a sitemap lists. The pick is deterministic, so a re-scan compares the same pages.

A page that cannot be assessed, for example behind a bot challenge, a single-page app that does not load in time or content inside a cross-origin iframe, is listed with an error status. If no page of a scan could be assessed, the result is N/A with the reason and never a clean score. Inkluso does not bypass bot protection; if a firewall blocks the audit, the scanner has to be allowed through.

What is automated, and what needs a person?

Automated testing catches roughly 30 to 40 percent of WCAG success criteria, not 30 to 40 percent of a site’s failures. The rest needs a human.

The report keeps the two apart. For colour contrast it states how many checks were verified automatically and how many remain for manual review. Elements the tool flagged for manual review (axe “incomplete”) are not counted in the score. Findings from the Tab-key walk are marked to be confirmed by hand and do not affect the grade.

An automated scan cannot judge whether the reading order is meaningful, whether alternative texts are good, whether a keyboard trap exists, whether captions are right or whether the language is plain. Those checks need a person.

A grade of 100 in an Inkluso report means nothing automated was found. It does not mean the site is accessible.

How are findings mapped to the law?

Each finding carries its WCAG success criterion, the matching EN 301 549 clause and a paragraph of the national act that transposes the European Accessibility Act. The act follows the jurisdiction chosen for the report, not the language of the report.

  • Germany: Barrierefreiheitsstärkungsgesetz (BFSG) and the Verordnung zum Barrierefreiheitsstärkungsgesetz (BFSGV)
  • Austria: Barrierefreiheitsgesetz (BaFG), BGBl. I Nr. 76/2023
  • Czechia: zákon č. 424/2023 Sb., o požadavcích na přístupnost některých výrobků a služeb
  • Poland: ustawa z dnia 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze (Dz.U. 2024 poz. 731)
  • Slovakia: zákon č. 351/2022 Z. z. o prístupnosti výrobkov a služieb pre osoby so zdravotným postihnutím
  • No national act: Directive (EU) 2019/882 itself, the default for English reports

A German-language report with Austria chosen as the jurisdiction therefore cites the BaFG, not the BFSG.

EN 301 549, the European accessibility standard used as the technical yardstick; no version is cited in the Official Journal under the European Accessibility Act, so it gives no presumption of conformity.

The acts do not list WCAG criteria. They set requirements in general terms, for example that information and websites be perceivable, operable, understandable and robust (Directive (EU) 2019/882, Annex I). WCAG is built on the same four principles. The national paragraph in a report therefore names the requirement a criterion relates to. It is not a finding that you broke the law.

Start with the national act of each country where you offer your service to consumers, not with the language of your site: a shop selling to consumers in Austria starts with the Austrian BaFG, a shop selling to consumers in Germany with the German BFSG, and a shop selling in both checks both. Where your company is based can matter too; for a cross-border case, ask a lawyer which acts bind you. Inkluso does not work out which law applies to you.

What does the PDF contain, and what do its trust signals mean?

The PDF is a dated record of one automated scan: a grade out of 100, the findings with their legal mapping, a fix block per rule and a draft accessibility statement. Its timestamp, engine version and SHA-256 hash show when and with what the scan ran; they do not show that a site conforms to WCAG, EN 301 549 or any law.

  • Cover: the grade out of 100, the legal framework, the standard and the test scope.
  • Summary, severity overview and the list of scanned pages with their status and the colour-contrast coverage.
  • Issue list: WCAG criterion, EN 301 549 clause, legal basis and the number of instances with the page they were found on.
  • A block per rule: what is wrong, who it affects, how to fix it, a caveat against over-correcting, an effort estimate and the affected elements with their selectors.
  • Screenshots of representative failing elements.
  • A draft accessibility statement, to review before you publish it.
  • A closing block with the disclaimer and the scan record.

A developer JSON export comes with the report. The sample report shows the structure for a fictional shop.

  • Timestamp: when the report was generated.
  • Engine version: the engine and version that ran (axe-core 4.12.1 on the review date).
  • SHA-256 hash: computed over the scan results, that is the site address, the score and the findings, and printed on the PDF. It ties the report to the data it was built from. Compared with a separately kept copy of the value, it makes a later change to the results detectable; on its own it is neither tamper protection nor a signature.

None of the three proves that a site conforms. They record which result was captured and when.

What does the fix-verification re-scan do?

The fix-verification re-scan runs a new automated scan of the same site and compares it with your original audit, so you can see which findings are gone. It is a one-time purchase at EUR 49.

To order it you give the report token of your original paid audit and the same site address; a different site is refused. The re-scan crawls at the same depth as the original audit, so the comparison is like with like, and it keeps the legal mapping of the original unless you choose another jurisdiction.

The comparison runs per rule and per page, counted in instances: resolved (gone), remaining (still present), worsened (more instances of a rule on a page that already had it) and new (a rule on a page where it was not found before). You receive a new report and an email that summarises these counts. If the original scan cannot be read, you receive a standard report instead.

A resolved finding means the automated check no longer flags it. It does not confirm that the fix works for people, and the checks that need a person stay open.

What does Inkluso not do?

Inkluso does not test with disabled users, does not run a manual expert audit and does not give a legal verdict. It is an automated check with a legal mapping; the rest is for you and your advisers.

  • It does not test with users who have disabilities.
  • It does not run a manual expert audit. A complete WCAG evaluation needs one.
  • It does not give a legal verdict and does not decide which law applies to you.
  • It does not bypass bot protection.
  • The accessibility statement it drafts is a draft to review, not a filing with an authority.

How often is this page and the legal mapping reviewed?

Every legal instrument in the mapping is re-verified against its primary text at least every 90 days, and sooner when we learn that its text has changed.

  • Change review: a reported change opens a review. A report never edits the mapping by itself.
  • Release check: an automated test fails the build when this page names a different axe-core version, page limit or re-scan price than the scanner code.

How are corrections handled?

If you find an error on this page or in the legal mapping, write to hello@inkluso.eu with the page and the sentence. We check it against the primary text. If the page is wrong, we correct it and add the correction to the log below with its date.

Corrections log

  • : Review cadence, sign-off and corrections sections added.
  • : Sign-off section removed.

Short answers about the method

Five short answers. They repeat the sections above.

Which tool does Inkluso use to test?

Inkluso renders pages in Chromium through Playwright and runs axe-core 4.12.1, the version bundled on the review date. Each report prints the version that ran.

How much of WCAG does an automated scan cover?

Automated testing catches roughly 30 to 40 percent of WCAG success criteria, not 30 to 40 percent of a site's failures. The rest needs a human.

Does the SHA-256 hash in the PDF prove my site conforms?

No. The hash is computed over the scan results and printed on the PDF. It ties the report to the data it was built from. It does not show that a site conforms to WCAG, EN 301 549 or any law.

What does the fix-verification re-scan cost and compare?

It costs EUR 49, one time. It scans the same site again at the depth of the original audit and compares instances per rule and page with that audit.

Which law does a report cite?

The act of the jurisdiction chosen for the report: the BFSG, the BaFG, zákon č. 424/2023 Sb., the ustawa of 26 April 2024 or zákon č. 351/2022 Z. z. A report with no national act cites Directive (EU) 2019/882. Inkluso does not decide which law applies to you.

Where do these facts come from?

Facts about the scanner and the report come from Inkluso's scanner code, its bundled axe-core 4.12.1 and its report templates as of 2026-10-20. Legal references link to primary sources.

Want to see a scan of your own homepage?

The free scan tests your homepage against WCAG 2.1 AA with axe-core and shows the first findings with their reference. No account, no card.

Run the free scan

Related: Sample report · Accessibility statement generator

Orientation, not legal advice. An Inkluso report is a record of an automated scan. Automated testing catches roughly 30 to 40 percent of WCAG success criteria. The rest needs a human.