Validiscan
Menu

Language

The Remediation Evidence Package

The Remediation Evidence Package is a dated record of what was tested in your shop, what was found, what was changed and what a verification scan confirmed. It is evidence of an evaluation and of remediation work, not a certificate.

Request a free checkHow a project runs

Last updated:

On this page: 11 answers

What is in the package?

The Remediation Evidence Package has 7 sections, always in the same order. Validiscan builds it from the baseline scan or a later full scan of your shop, the verification scan after the fixes where there is one, and the results of the manual checks.

The seven sections of a Remediation Evidence Package, under the titles the package prints

Remediation Evidence Package

  1. 1 About this package
  2. 2 Scope and methodology
  3. 3 Results summary
  4. 4 Findings in detail
  5. 5 Manual review and excluded findings
  6. 6 Residual risk and recommendations
  7. 7 Draft accessibility statement

Conformance with WCAG 2.1 AA and WCAG 2.2 AA success criteria as evaluated on the listed pages and dates.

This package is evidence of an evaluation and of remediation work. It is not a certificate and does not state legal compliance.

Details: what the package is built from, and the languages it is written in

The Remediation Evidence Package has seven sections, always in the same order. Validiscan builds it from the baseline scan or a later full scan of your shop, the verification scan after the fixes where there is one, and the results of the manual checks. The structure below uses the section titles exactly as the package prints them.

Each package is written in one language, chosen when it is built: English, German, Danish, French or Spanish.

1. About this package

The first section says what the package covers and identifies it. It names the website and its address, your organization, the shop platform and the package version. It gives the date and time the package was generated, in UTC and in your organization’s time zone, and the language of the document. It also holds the SHA-256 of the package’s JSON data (explained under checksums below), the contact details of Validiscan, which prepared the package, and the name and version of the software that generated it.

A box titled “What this package states” holds the scope statement and the sentence saying that the package is not a certificate. Both are quoted below, under “What does the package state?”.

2. Scope and methodology

The second section records exactly what was tested and how. It lists every page the scans evaluated, with its address, its page type (the package calls it a template), the screen sizes it was checked at (desktop, mobile or both), its HTTP status and the result. It records the crawl configuration of each scan: the page limit, the number of pages sampled per page type, how the cookie banner was handled, whether robots.txt was respected, whether analytics and ad trackers were blocked, and which shopping flows were run, such as adding to the cart or the first checkout step.

It then lists the tool versions per scan: axe-core, Playwright, the Validiscan scanner and a hash of the rule set, computed from the ids of the catalogue’s rules and their fix tiers per platform. A table names the standards the package refers to, with their versions, dates and status. The method follows in four sentences: how every page was loaded in a real browser at each screen size and checked with axe-core and with Validiscan’s own checks for barriers typical of online shops; how findings are grouped by rule and element pattern, so that one defect repeated on many pages is one finding with a count; how the success criteria that automation cannot fully prove were reviewed by hand; and how the verification scan checked the fixes.

The section ends with the limitations. Four are always printed: automated checks find only part of all accessibility barriers; pages are sampled per page type; the results describe the shop on the dates of the scans; and content inside cross-origin frames and closed shadow DOM, such as payment fields and some consent tools, is not evaluated automatically. Others are printed when they apply, for example that the checkout was evaluated only up to its first step, without placing an order or entering payment data.

3. Results summary

The third section gives the results in figures. It shows the findings by impact and status in one table, without best-practice findings. It shows the remediation progress with its formula and the arithmetic behind it, as explained below. And it has two conformance tables, one for WCAG 2.1 AA and one for WCAG 2.2 AA, with a row per success criterion: its level, its EN 301 549 clause, its conformance, the basis for that conformance and the findings behind it.

Each criterion gets one of five conformance levels. The package prints the rule for each one after the tables:

Conformance levels in the Remediation Evidence Package, with the rules the package prints
Conformance level Rule, as the package prints it
Supports Automated checks fully cover the criterion and found no unresolved failure, or a manual check passed.
Partially supports Unresolved failures on half of the scanned templates or fewer, fixes awaiting verification, or a failed manual check where automated checks found nothing.
Does not support Unresolved failures on more than half of the scanned templates or without a page, or a failed manual check.
Not applicable The manual check found no content the criterion applies to.
Not evaluated Automated checks cannot prove the criterion and it has no manual result yet.

Where a failed manual check fits two rows, it gives partially supports only when a running rule tests the criterion and no unresolved failure was found; without such a rule, or with an unresolved failure, it gives does not support. “Without a page” means a finding that concerns the whole site rather than particular pages, such as one recorded in a manual check. A finding marked won’t fix remains a barrier and counts as a failure in these tables. False positives and best-practice findings never count.

Automated checks count as fully covering a criterion when a rule the scanner runs tests it and the manual checklist has no item for it. For such a criterion, among them 1.1.1 Non-text Content and 2.4.4 Link Purpose (In Context), a result of supports rests on automated checks alone: it shows that no rule found a failure, not that the criterion is met. The criteria matrix shows, for every criterion, the rules that test it and whether the checklist has an item for it.

4. Findings in detail

The fourth section has one entry per finding that was not excluded, the most severe first. Each entry gives the finding’s identifier, the rule, the impact, the status, the fix tier (AUTO, ASSISTED or MANUAL), the WCAG success criteria, the EN 301 549 clauses, and how many instances the scan and the verification scan found on how many pages. Under “What this means for customers” it explains the barrier in plain language.

Up to three example instances show the page, the element and what failed. Up to two screenshots per finding show a page before the fix. Each can be paired with a screenshot after the fix, where the verification scan loaded the same page at the same screen size. The screenshots currently show the first screen of a page, so an element further down the page may not be visible in the picture.

A table lists the fixes for the finding: their identifier, status and approach, whether they were made by a recipe, drafted with AI or edited by hand, how they were delivered (as a GitHub pull request, an unpublished copy of a Shopify theme or a patched theme zip), and when they were delivered and merged. Best-practice findings follow at the end of the section. They are not WCAG failures and never count in conformance or in remediation progress.

5. Manual review and excluded findings

The fifth section covers the checks a person made. Validiscan’s manual checklist has 35 items for criteria a person has to check, such as operating the shop with a keyboard, using it with a screen reader and zooming in. For each success criterion on the checklist, the package records the result (passed, failed, not applicable or not checked yet), the date, who checked it, notes, and any evidence file, which is included in the zip.

The second part lists the excluded findings with their justification. A false positive is a finding the scanner reported for an element that meets the criterion. A won’t-fix finding is a real barrier that you decided not to fix now. The package says where each justification was recorded, or that none was.

6. Residual risk and recommendations

The sixth section says what still carries a risk and what to do next. It rates the residual risk as High, Medium or Low and prints the rule behind the rating: High with an unresolved critical finding or a WCAG 2.1 AA criterion that does not support; Medium with an unresolved serious finding, a WCAG 2.1 AA criterion that partially supports or waits for a manual check, a gap in a criterion added by WCAG 2.2, or fixes awaiting verification; Low otherwise. Unresolved means open, fix proposed, fix delivered or won’t fix.

Recommendations follow in order of priority, for example to merge delivered fixes, to run a verification scan, to complete the manual review or to turn on regression protection. The section closes with the date by which the next verification scan is due, earlier while work is still pending, and the next regression protection run if one is scheduled.

7. Draft accessibility statement

The seventh section is a draft accessibility statement for your shop, written from the results of the package. It is in the package’s language, which can be English, German, Danish, French or Spanish. It follows the structure of the EU model accessibility statement in Commission Implementing Decision (EU) 2018/1523, which was written for public sector bodies, and adapts it to the European Accessibility Act (EAA) for an online shop. It is marked “Draft for legal review”: in a box before the statement, in a stamp beside its title, and in the header of every page of the statement in the Word document.

The draft states the shop’s compliance status in the wording of the EU model (fully, partially or not compliant), worked out from the conformance results, and says that this status describes conformance as evaluated on the pages and dates it names. It lists the content that is not accessible, in plain language per success criterion. It describes how the statement was prepared: as a self-assessment by your organization, based on an evaluation carried out by Validiscan, and not a certification. Then come the contact details for feedback and the enforcement procedure. For an organization in Germany, the draft names the market surveillance authority, the MLBF, and the conciliation body, the Schlichtungsstelle BGG, each with its provision in the BFSG; for other countries, the authority is a field you complete. The next part holds the information about the service that Annex V of the EAA asks for: what the service is, how it is used and how it meets the accessibility requirements. A part with further information follows, and a box titled “Before publishing” closes the section with the steps that turn the draft into a published statement.

Text in square brackets marks information only your organization can provide, such as the email address for accessibility feedback. Every such field must be completed, or deleted where it is optional, before the statement is published. Validiscan does not give legal advice: your legal counsel must review the statement before you publish it, and whether, where and in which languages it must be published depends on the law that applies to you. The guide What an accessibility statement for an online shop must contain explains the requirements.

What does the package state?

The Remediation Evidence Package reports, for each WCAG 2.1 AA and WCAG 2.2 AA success criterion, its conformance as evaluated on the pages and dates it lists: supports, partially supports, does not support, not applicable or not evaluated. It does not certify the shop.

Details: the scope sentence and the not-a-certificate sentence the package prints, and where else they appear

The package reports, for each WCAG 2.1 AA and WCAG 2.2 AA success criterion, its conformance as evaluated on the pages and dates it lists: supports, partially supports, does not support, not applicable or not evaluated. It does not certify the shop. In the first section, its scope statement opens with this sentence: “Conformance with WCAG 2.1 AA and WCAG 2.2 AA success criteria as evaluated on the listed pages and dates.”

The same box says: “This package is evidence of an evaluation and of remediation work. It is not a certificate and does not state legal compliance.”

Both sentences also appear, in English, in the README file of the zip.

When does a finding count as verified?

A fixed finding counts as verified when the package’s verification scan loads every page the finding was on and no longer finds it. Its status then moves to verified when the package is issued; nobody sets the status Verified by hand.

The package verifies a fixed finding when three things hold
  1. The finding had instances in the full scan the package is built from.
  2. The verification scan found none.
  3. The verification scan loaded every page the finding was on, without an error at any screen size.
Details: when a finding is fixed, the three conditions, and a package without a verification scan

A fixed finding counts as verified when the package’s verification scan loads every page the finding was on and no longer finds it. Its status then moves from Fixed to Verified at the moment the package is issued. Nobody sets the status Verified by hand.

A finding is fixed when a fix for it was delivered and a later scan that loaded every page the finding was on no longer finds it. The package verifies a fixed finding when three things hold:

  1. The finding had instances in the full scan the package is built from.
  2. The verification scan found none.
  3. The verification scan loaded every page the finding was on, without an error at any screen size.

Each verified finding carries the note “Verified by this package” in the findings section. A fixed finding that the package cannot verify this way stays fixed and is listed as awaiting verification, with a recommendation to run a verification scan. A package built without a verification scan verifies no fix, and its limitations say so.

How is remediation progress calculated?

Remediation progress is the sum of the impact weights of findings that are fixed, verified or resolved externally, divided by the sum of the weights of all findings, leaving out false positives, won’t-fix and best-practice findings. It is the package’s only single score; there is no compliance percentage.

Weight of each impact in remediation progress
Impact Weight
Critical 10
Serious 5
Moderate 2
Minor 0.5
Details: the formula as the package prints it, why it counts per finding, and two points that are easy to miss

Remediation progress is the share of the work that is done, weighted by how much each problem affects customers. It is the only single score in the package: there is no compliance percentage.

Each finding counts with the weight of its impact. Remediation progress is the sum of the weights of the findings that are fixed, verified or resolved externally, divided by the sum of the weights of all findings. Findings marked as a false positive or as won’t fix, and best-practice findings, are left out of both sums. The package prints the formula as: “Σ weight(impact) of findings fixed, verified or resolved externally ÷ Σ weight(impact) of all findings, excluding false positives, won’t-fix and best-practice findings.”

Progress is counted per finding, not per instance: a missing label repeated on many product pages is one finding with one fix. A critical finding weighs more than a minor one, so fixing a critical finding moves the number more than fixing a minor one. Next to the percentage, the package prints the weighted findings that are done, out of the total, so the figure can be checked by hand. The customer portal shows the same number, with its own explanation of how it is calculated.

Two points are easy to miss. A fixed finding counts as done before it is verified, while in the conformance tables a fix that awaits verification keeps its criterion from counting as supported. And a won’t-fix finding is left out of remediation progress but still counts as a failure in conformance, because a barrier that stays is still a barrier.

Why does the package evaluate both WCAG 2.1 AA and WCAG 2.2 AA?

The Remediation Evidence Package evaluates each success criterion once and reports the results against both: WCAG 2.2 AA is the target of every finding and every fix, and WCAG 2.1 AA is the level that EN 301 549 V3.2.1 adopts in its requirements for web content.

EN 301 549 versions as of 6 October 2026
Version WCAG it adopts Reference in the Official Journal of the EU
EN 301 549 V3.2.1 WCAG 2.1 AA, in its requirements for web content Published under the Web Accessibility Directive (Directive (EU) 2016/2102), by Commission Implementing Decision (EU) 2021/1339
EN 301 549 V4.1.1, published by ETSI in September 2026 WCAG 2.2, according to AccessibleEU None found by Validiscan

Source: W3C, WCAG 2.2; Commission Implementing Decision (EU) 2021/1339; ETSI, EN 301 549 V4.1.1; AccessibleEU

Details: what WCAG 2.2 adds and removes, the status of EN 301 549 as of 6 October 2026, and how each package records the standards

The package evaluates each success criterion once and reports the results against both WCAG 2.1 AA and WCAG 2.2 AA. WCAG 2.2 AA is the target of every finding and every fix. WCAG 2.1 AA is the level that EN 301 549 V3.2.1 adopts in its requirements for web content. At levels A and AA, WCAG 2.2 adds six success criteria to WCAG 2.1 and removes one, 4.1.1 Parsing, so the two tables differ.

As of 6 October 2026:

Each package records the standards, with their versions and status, as they were when it was built. A later change in the status of a standard does not rewrite what an issued package says. Which standard and which law apply to your shop is a legal question. The guide to the European Accessibility Act for online shops covers it.

Which files make up the package?

The Remediation Evidence Package consists of four files: a PDF report, a Word document, a JSON data file and a zip archive that holds the other three, the JSON schema, the screenshots and manual-check evidence files the report refers to, a README and the checksum file SHA256SUMS.

The four files of a Remediation Evidence Package
File What it is for Details
PDF report The report to read, print and share. A4. A tagged PDF printed by Chromium, with the document language, title and bookmarks set. No claim of PDF/UA conformance is made.
Word document (DOCX) The same report to edit, for example the accessibility statement. Each section starts on a new page. On the pages of the draft statement, the header repeats “Draft for legal review”.
Data file (JSON) The data behind the report, for your developers or an auditor. Codes, identifiers, counts, times in UTC and the texts recorded during the project; no labels and no formatted dates. It follows the published JSON schema.
Complete archive (zip) Everything in one file. The PDF, the Word document and the JSON file, the JSON schema, the screenshots and manual-check evidence files the report refers to, a README and the checksum file SHA256SUMS.
Details: the zip’s entries in order, and what happens when a file is missing

The zip contains these entries, in this order:

  1. README.txt: what the package is, what each file holds and how to verify it, in English.
  2. The PDF report.
  3. The Word document.
  4. The JSON data file.
  5. schema.json: the JSON schema the data file follows.
  6. assets/: the screenshots and manual-check evidence files the report refers to.
  7. SHA256SUMS: the SHA-256 checksum of every other file in the zip.

If a screenshot or evidence file is missing when the package is built, it is left out of the zip and the README lists it under the heading FILES NOT INCLUDED. In place of a missing screenshot, the report shows a text description.

How can you check that a file has not been changed?

By comparing SHA-256 checksums, fingerprints that change if a single byte of a file changes. The customer portal shows one next to each file of the Remediation Evidence Package, and the zip’s SHA256SUMS lists those of the files inside it. A matching checksum does not show who made the file.

How to check the unzipped files
System Command Result
Linux sha256sum -c SHA256SUMS Every line must end in “OK”.
macOS shasum -a 256 -c SHA256SUMS Every line must end in “OK”.
Windows PowerShell Get-FileHash -Algorithm SHA256, for each file Compare the result with that file’s line in SHA256SUMS.
Details: the three places checksums are used, the commands, and what a checksum does not show

Every file of the package has a SHA-256 checksum: a fingerprint that changes if a single byte of the file changes. The package uses checksums in three places.

  • Each file. The PDF, the Word document, the JSON file and the zip each have their own SHA-256, recorded when the package was built and shown next to each download in the customer portal.
  • Inside the zip. The file SHA256SUMS lists the SHA-256 of every other file in the zip. A zip cannot contain its own checksum, so the zip itself is checked against the checksum shown next to its download.
  • The data. The first section of the package gives the SHA-256 of the JSON file’s content. It is computed over the canonical JSON of that file (RFC 8785, the JSON Canonicalization Scheme), with that one field left out. Canonical JSON does not depend on whitespace or the order of keys, so anyone with the JSON file can compute the same value.

To check the unzipped files, open a terminal in their folder. On Linux, run:

sha256sum -c SHA256SUMS

On macOS, run:

shasum -a 256 -c SHA256SUMS

Every line must end in “OK”. In Windows PowerShell, run this for each file and compare the result with that file’s line in SHA256SUMS:

Get-FileHash -Algorithm SHA256

A checksum shows that a file is exactly the one recorded when the package was built. It does not show who made the file: the package carries no digital signature and no timestamp from a third party.

Which JSON schema does the data file follow?

The Remediation Evidence Package’s JSON data file follows a published JSON Schema (draft 2020-12), also in every zip as schema.json. The schema is strict: a key it does not know fails validation, except in one open field for the versions of further tools.

Details: where to find the schema, and how its version changes

The JSON data file follows a published JSON Schema (draft 2020-12): the package’s JSON schema. The same schema is in every zip as schema.json, so a package can be checked without this website. Any JSON Schema validator that supports draft 2020-12 can check a data file against it.

The schema is strict: a key it does not know fails validation, except in one open field for the versions of further tools. Validiscan builds a package only from data that passes the schema and matches the SHA-256 recorded in its first section. The schema has version 1. A change that an older reader would reject gets a new version number, and an issued package stays readable at its version.

Can a package be changed after it is issued?

No. A ready Remediation Evidence Package never changes: when something has to be corrected, Validiscan builds a new version, and the earlier versions stay listed. Once a package is ready, the database refuses any change to its file paths, checksums, version, language, record of the standards or date of generation.

Details: how versions are numbered, and what the database refuses to change

Packages are numbered per shop: version 1, version 2 and so on. Each package Validiscan builds for your shop, from the scans and in the language chosen for it, is the next version. Only a ready package reaches the customer portal.

Once a package is ready, the database refuses any change to its file paths, its checksums, its version, its language, its record of the standards or its date of generation. Because the checksums are fixed, a file changed afterwards would no longer match the checksum recorded for it.

What does the package not claim?

The Remediation Evidence Package is a record of what was tested, found, changed and verified, and claims no more. It is not a certificate and does not state legal compliance: whether your shop meets the EAA, the BFSG or another law is a legal assessment, for you and your lawyer.

What the package does not claim

  • It is not a certificate.

  • It does not state legal compliance.

  • It does not test everything automatically.

  • It describes the shop on the dates of the scans.

  • It makes no PDF/UA claim.

  • The draft statement is not ready to publish.

Details: each point in full

The package is a record of what was tested, found, changed and verified. It does not claim more.

  • It is not a certificate. It is evidence of an evaluation and of remediation work.
  • It does not state legal compliance. Whether your shop meets the EAA, the BFSG or another law is a legal assessment, for you and your lawyer. The compliance status in the draft statement is a draft in the wording of the EU model, for that review.
  • It does not test everything automatically. Automated checks find only part of all accessibility barriers. Criteria with an item on the manual checklist are checked by hand, or are marked “Not evaluated” until they are. A criterion without a checklist item, such as 1.1.1 Non-text Content, counts as supported on automated checks alone, although a rule cannot judge whether a text alternative describes its image. Pages are sampled per page type, not checked one by one.
  • It describes the shop on the dates of the scans. Later changes to the theme, apps or content are not covered. Regression protection checks them on a schedule.
  • It makes no PDF/UA claim. The PDF is tagged, with real headings and text alternatives, but Validiscan does not claim that it conforms to PDF/UA.
  • The draft statement is not ready to publish. It needs your organization’s details and a review by your legal counsel.
The method, the standards and the limits of automated testing

How do you get the package?

You get the Remediation Evidence Package in the customer portal: once a package is ready, Validiscan emails you a link to it, and the email never carries a file. The portal lists every version, newest first, with each file and its SHA-256 checksum.

The email
A link to the portal, never a file
Versions
Every version listed, newest first, with the date it was issued
Download links
Created when you click; each expires after one minute and is never stored
Archived sites
Their packages stay listed and downloadable
Draft statement
A portal page with the statement from your latest package, to copy or download as an HTML file
Details: the portal’s version list, download links, archived sites and the draft statement page

In the portal, every version of the package is listed, newest first, with the date it was issued. For each version you can download the PDF report, the Word document, the JSON data file and the zip archive. Each file is shown with its SHA-256 checksum, which you can copy. A download link is created when you click it and expires after one minute; no download link is stored. If your shop’s site is later archived and leaves the portal, its packages stay listed and downloadable. The portal also has a page with the draft accessibility statement from your latest package, which you can copy or download as an HTML file.

Keep every version for your records. The Remediation Evidence Package is part of every project; the page on how a project runs lists what else a project includes.

Sources

7 sources, each checked for this page on 6 October 2026.

EU law 3
  1. Commission Implementing Decision (EU) 2021/1339 amending Implementing Decision (EU) 2018/2048 as regards the harmonised standard for websites and mobile applications · EUR-Lex ·  · checked
  2. Commission Implementing Decision (EU) 2018/1523 establishing a model accessibility statement · EUR-Lex ·  · checked
  3. Directive (EU) 2019/882 on the accessibility requirements for products and services · EUR-Lex ·  · checked
Standards 4
  1. EN 301 549 V4.1.1 (2026-09) · ETSI · checked
  2. The European accessibility standard EN 301 549 has been updated · AccessibleEU (European Commission) ·  · checked
  3. Web Content Accessibility Guidelines (WCAG) 2.2 · W3C · checked
  4. RFC 8785: JSON Canonicalization Scheme (JCS) · RFC Editor · checked

Start with a free check of your shop.

Send your shop’s address. Validiscan scans it and replies with every failure the scan can prove, with the page and the code.

Request a free check

Or write to info@validiscan.com.

What the free check covers, and what it leaves out
You send
your shop’s address
Pages scanned
up to 15
You get
every failure the scan can prove, with the page and the code
On your shop
public pages only; no login, nothing bought, no forms sent
What it is not
a full audit

Write to Validiscan

For a free check, give the address of your shop and its platform.

Validiscan uses what you send to answer you. Privacy notice