How accessibility remediation works, step by step

Validiscan needs three answers before it starts: your permission to scan, how the changes should reach your code, and whether AI may draft some of them.

• Permission for a full scan. A full scan goes further than the free check: it puts a product in the cart and opens the first checkout step. Validiscan runs it only after the shop owner has agreed in writing. Validiscan records the permission in its system, with the time and the name of the person at Validiscan who recorded it. Without that record, no full scan starts.
• Access to your code. One of three ways, explained below: access to the GitHub repository that holds your theme, a Theme Access password for your Shopify store, or no access to your systems, in which case your developer uploads a copy of your theme’s files and the changes come back as a patch bundle. That is also the way when your theme is kept somewhere other than GitHub, for example on GitLab or Bitbucket.
• Your answer on AI drafting. AI is used only to draft fixes of tier ASSISTED, and only if you agree. It is off until you do. How Validiscan handles your data

The baseline scan checks the pages of your shop against WCAG 2.2 AA and lists every failure it finds, with what it means for your customers.

The scan loads a sample of each type of page in your shop, among them the home page, product lists, product pages, the cart, the first checkout step, search results, the login page, the contact page and legal pages. How many pages of each type it loads, and the page limit, are set for each shop; by default the limit is 150 sampled pages, and search results, the login page, the contact page, legal pages, the cart and the first checkout step can come on top. By default each page is loaded at desktop size (1440 by 900 pixels) and at phone size (390 by 844 pixels). To reach the cart and the checkout, the scan adds one product to the cart and opens the first checkout step. It never completes a purchase and never enters payment data.

The scanner runs 102 automated rules: axe-core rules and Validiscan’s own checks for problems typical of shops, such as cookie banners, carousels, checkout forms and price updates. A scan cannot prove everything. Validiscan also works through a checklist of 35 manual checks, which covers every WCAG criterion that no rule tests, and records each one as passed, failed or not applicable, with notes.

Before anything is delivered, Validiscan goes through the findings. This is called triage. The same failure on many pages, such as an unnamed button in the header, is one finding with a count of the pages and elements where it occurs. A finding that turns out not to be a failure is marked as a false positive, with a written justification. The Remediation Evidence Package lists these as excluded findings.

Validiscan reviews every change before it is delivered: the diff, the result of the automatic validation, and the explanation of what changed and why. The validation checks each changed Liquid, Twig, PHP, HTML, XML, JavaScript or JSON file for errors with a parser or syntax check for its type, and each changed CSS, SCSS or LESS file with a structure check for an unclosed brace, string or comment, which does not compile it; none of these checks runs your theme’s code. Only changes that passed the validation and that Validiscan has approved are delivered. A rejected change gets a written reason and is not delivered.

Your developer then reviews the change again, as an ordinary pull request or patch, or you preview the theme copy on Shopify. The checklist in each pull request asks them to try the branch outside the live shop, check the affected pages, operate the changed elements with the keyboard alone and, where they can, with a screen reader.

At Validiscan, the person who reviews the changes is William Quaade Rasmussen, who runs the company alone. Because the changes are in your code and the package is your file, nothing in your shop depends on Validiscan afterwards; regression protection is cancelled to the end of any month. About Validiscan

Once the changes are live on your shop, a verification scan checks that they work. It covers the page types the changes affect and every page where a delivered finding was last seen. A finding with a delivered change that the verification scan no longer finds, on every page where it was last seen, is marked fixed. A finding that was fixed and shows up again is open again.

What you do: put the changes live, by merging and deploying the pull request, publishing the theme copy or applying the bundle. Then ask for the verification scan: an admin of your organization requests it in the customer portal, or you tell Validiscan by email.

After the verification scan, Validiscan builds the Remediation Evidence Package: a dated record of what was tested, what was changed and what the verification scan confirmed. It is built from the baseline scan, the verification scan and the manual checks. It comes as PDF, DOCX and JSON in a zip with SHA-256 checksums, and includes a draft accessibility statement for your shop, marked as a draft for legal review. A finished package does not change; a correction is a new version. You download it from the customer portal.

Its scope statement says: “Conformance with WCAG 2.1 AA and WCAG 2.2 AA success criteria as evaluated on the listed pages and dates.” It also says: “This package is evidence of an evaluation and of remediation work. It is not a certificate and does not state legal compliance.”

A project covers one shop: one domain and one theme. It includes the baseline scan, the manual checks, the AUTO and ASSISTED fixes delivered in one of the three ways above, one verification scan and the Remediation Evidence Package.

Regression protection is the optional last step, billed monthly. Validiscan re-scans your shop every week and compares the result with the verified baseline. Fixed problems can come back, for example after a theme or app update. A problem that came back is open again.

Validiscan sends at most one email per re-scan: when the re-scan found a fixed problem that came back, a new problem, a problem that is no longer found or a change in the pages covered, and when the re-scan could not finish. A re-scan with none of these sends no email, unless you asked Validiscan for one. The customer portal shows every re-scan on a timeline. Fixing what a re-scan finds is not part of regression protection.