How it works · Methodology

Methodology

How Paperfort’s automated WCAG 2.2 AA scan works

This page describes exactly how Paperfort produces its documentation: how the automated scan runs, what it covers, where it stops, and what each output document is. We keep it specific so merchants and their attorneys know precisely what they are getting.

1. What we scan

We fetch the publicly-available pages of a storefront (the same pages a customer or a search-engine crawler would see). We do not log into the Shopify admin, we do not access order or customer data, and we do not crawl authenticated or checkout-only pages. The scan runs against a representative set of storefront templates, including the home page, a collection page, a product page, the cart, and key content pages.

2. The automated engine

Paperfort runs axe-core version 4.12.1, the open-source accessibility testing engine, against each page after it has fully rendered (HTML, CSS, and the JavaScript-applied DOM). The ruleset is configured for WCAG 2.2 Level AA. Because the engine and version are fixed, two scans of the same unchanged storefront produce the same findings, and every report is timestamped so you can show when it was run.

3. What the scan covers

Automated checks reliably catch a defined set of machine-detectable WCAG 2.2 issues, including:

  • Images and non-text content missing text alternatives (alt text).
  • Insufficient color contrast between text and its background.
  • Form inputs without programmatically-associated labels.
  • Missing or out-of-order document landmarks and heading structure.
  • Links and buttons without an accessible name.
  • Missing page language, duplicate IDs, and invalid ARIA usage.
  • Tables, lists, and frames that are not marked up correctly for assistive technology.

For each finding, the report records the WCAG success criterion, the element selector, the severity, and a plain-English description, so the findings double as a prioritized remediation plan.

4. The honest limit

Automated scans catch only a portion of WCAG issues. Many success criteria require human judgment: whether alt text is meaningful, whether the reading and focus order makes sense, whether the site is fully operable by keyboard, whether content works with a screen reader, and whether error messages are understandable. Manual review and assistive-technology testing are still required to evaluate a storefront completely. Paperfort documents what the automated scan finds and flags where a qualified professional should review further. It does not certify full conformance, and it does not guarantee ADA compliance or lawsuit prevention.

5. What you receive

Paperfort turns the scan results into three documents:

  • Audit report (PDF). A timestamped, paginated WCAG 2.2 AA report listing every finding with its success criterion, severity, location, and remediation note. This is the prioritized to-do list a developer or theme builder can work from.
  • Hosted accessibility statement. A public /accessibility page published on the merchant’s own domain, stating the conformance target (WCAG 2.2 AA), the date last assessed, that assessment was automated, and how to report a barrier. The EU’s European Accessibility Act expects e-commerce services to publish an accessibility statement.
  • VPAT 2.5Rev (ACR). A completed Voluntary Product Accessibility Template in ITI format, covering WCAG 2.2, Section 508, and EN 301 549. Once filled in with test results it is called an Accessibility Conformance Report (ACR), the document procurement and enterprise buyers request.

6. Re-scans

Storefronts change. On subscription plans, Paperfort re-runs the same automated scan on a schedule and updates the audit report and the hosted statement’s last-assessed date, so the documentation reflects the current state of the storefront rather than a one-time snapshot.

Questions about the methodology? Email support@paperfort.app. For more on who stands behind the documentation, see About Paperfort.