Skip to content
wcagc
←Back to blog
evidenceprocurementEAAEN 301 549Section 508

What accessibility compliance evidence should you keep?

Accessibility compliance evidence: what to record after every scan, from scope and tool version to manual results, and how long to keep it.

P

Pavel Charkasau

Accessibility compliance evidence is the record that lets someone answer, a year later, what you tested, when, with what, and what was still broken. Keep six things after every scan: the exact list of URLs, the date, the tool and its version, the standard and level you tested against, the raw findings, and the results of the human checks a scanner cannot make. WCAG asks for most of that already. A conformance claim requires the date, the WCAG version, the URIs of the pages covered, the level claimed, and a description of what is in scope (W3C). The W3C's evaluation methodology adds the part teams skip: archive the screenshots, the path used to reach each sample, the settings and input, and the names and versions of the browsers, add-ons and assistive technology involved (W3C). A PDF of violation counts with no date and no URL list is not evidence of anything. It is a screenshot of a Tuesday.

What counts as accessibility compliance evidence?

Anything that lets a second person reconstruct your test without asking you.

That is the whole standard, and it is stricter than it sounds. A results table showing 43 violations tells a reviewer nothing on its own. Forty-three violations across which pages? Found by which rule set? Against WCAG 2.1 AA or 2.2 AA? Before or after the March release? Once those answers live only in someone's memory, the file has stopped working as evidence.

The US Federal Trade Commission made the point in a place worth reading. Its final order against accessiBe, approved on 22 April 2025, required a $1 million payment and barred the company from representing that its automated products can make a website WCAG-compliant or keep it that way "unless it has the evidence to support such claims" (FTC). Read that last clause as a filing instruction rather than a punishment. Whatever you say publicly about your accessibility, you should be able to open a folder and show the basis for it.

What should you record after every scan?

Seven fields, and none of them take long if you capture them at the time.

  • Scope. The URL list, written out. Not "the site" and not "main templates". If the scan covered 84 pages, keep the 84.
  • Date and time. Including the timezone, if your team is spread out.
  • Tool and version. "axe-core 4.10" is evidence. "our scanner" is not. Rule sets change between releases and results move with them.
  • Standard and level. WCAG 2.1 AA and WCAG 2.2 AA are different targets, and Success Criteria such as 2.4.11 Focus Not Obscured only exist in the second.
  • Raw findings. The full machine output, not the summary. Each finding wants its selector, its rule ID, and the failing snippet.
  • Human check results. Which manual tests were run, by whom, on what date, with what verdict.
  • What you did next. The fixes shipped, and the issues you knowingly left open.

WCAG-EM's step 5.2 goes further and asks you to archive copies of the sample files and resources, screenshots, the path used to locate each sample, the settings and actions applied, and the tool, browser and assistive-technology versions (W3C). It marks that step optional. In procurement it stops being optional the first time a buyer asks how you reached a verdict.

Here is the opinion I will put my name to: the date is the most load-bearing field in the file, and it is the one most often missing. Teams will argue for an hour about scoring methodology, then hand a client a report with no date, no URL list, and no tool version on it. That report cannot be defended, refreshed, or compared against the next one.

Why is the scan output the smaller half of the file?

Because automation decides a minority of the questions, and the rest arrive as human verdicts that need their own record.

Deque's 2021 analysis of more than 2,000 audits across roughly 13,000 pages and nearly 300,000 issues found that automated testing completely covered about 57% of issues (Deque). Counted by success criteria rather than by issue volume, the machine-decidable share is lower, which is where the familiar 30 to 57% range comes from. Either way, a scan is a partial method. Whether your focus order makes sense, whether your alt text says the right thing, whether an error message is announced at a useful moment: a person decides all of it, and that decision is evidence only if it is written down with a name and a date attached.

EN 301 549 shows what a written verdict looks like. Annex C, "Determination of conformance", is normative and "sets out the means necessary to determine conformance with the individual requirements set out in the body of the present document" (Accessibility Standards Canada, reproducing EN 301 549). Each test procedure resolves to pass, fail, or not applicable, with the pre-conditions spelled out. Three outcomes, per requirement, with a stated basis. That structure is why an Annex C table survives contact with a reviewer and a violation count does not.

We built our own conformance mapping around the same asymmetry. A detected failure moves a clause to not met on its own; marking a clause met requires a human check recorded as passed, because clean automated output is not the same as a satisfied requirement. Clauses with no signal stay not assessed rather than quietly passing. Our scanner will not tell you whether your checkout is usable with a screen reader, and the file should say so out loud instead of leaving a blank.

How long do you have to keep it?

Long enough that the retention question has a legal answer, at least in the EU.

Under the European Accessibility Act, a service provider prepares information explaining how the service meets the accessibility requirements and keeps that information "for as long as the service is in operation" (EUR-Lex). Manufacturers keep the technical documentation and the EU declaration of conformity for five years after a product is placed on the market. If you rely on the disproportionate burden exemption, the assessment must be documented and all relevant results kept for five years, calculated from the last time the product was made available or the service was last provided, and services must reassess at least every five years.

Notice the shape of that. The statement on your website is the summary; the retained file is the thing the summary rests on. An accessibility statement documents effort and known limitations, and it ages badly without the underlying records, since "we tested this" invites the question "show me". Automated tools find issues, and a conformance claim still needs human review behind it.

In the US the instrument is different but the discipline matches. An Accessibility Conformance Report explains how ICT conforms to the Revised 508 Standards (Section508.gov), and it is written on a VPAT, with any VPAT 2.x accepted for federal procurement. Every criterion gets one of four terms: Supports, Partially Supports, Does Not Support, or Not Applicable. Where the answer is Partially Supports or Does Not Support, the guidance is explicit that you explain further in the remarks column (Section508.gov). Those remarks are only writable from a real record. Consult your own counsel on retention beyond what the ADA and Section 508 programmes require, since neither sets a scan-retention clock the way the EAA does.

What does an auditor or a buyer actually ask for?

Four questions, in roughly this order.

What was in scope, and what was excluded. When was it tested, and has anything shipped since. What was found, and what remains open. Who confirmed the parts a tool cannot decide.

A monthly folder per site answers all four: the URL list, the raw scan export, the manual test results with dates and initials, and a short note on what changed. Keep the old ones. Trend evidence, showing that a criterion moved from not met to met on a specific date, is more persuasive than any single snapshot, and it is the only way to demonstrate that a fix held.

One thing to avoid: overwriting your last report. A statement or report that mutates in place destroys the history that made it useful. Ours are versioned snapshots for that reason, each pinned to the standard version it was generated against, with the assessment dates on the human checks carried through and marked when they go stale.

Frequently asked questions

Is a scan report enough evidence of accessibility compliance?

No. A scan report covers the machine-decidable subset, which Deque measured at roughly 57% of issues by volume and which is lower when counted by success criteria (Deque). It becomes usable evidence when you pair it with the scope, the date, the tool version, and the recorded results of the human checks the tool could not make.

How long should accessibility evidence be kept?

Under the EAA, service providers keep the information explaining how a service meets the accessibility requirements for as long as the service is in operation, manufacturers keep technical documentation for five years after placing a product on the market, and a disproportionate burden assessment must be retained for five years (EUR-Lex).

What should a WCAG conformance claim include?

Five components: the date of the claim, the WCAG version, the URI of the pages covered, the conformance level claimed, and a concise description of which parts of the success criteria are in scope (W3C). Conformance claims are optional in WCAG, but if you make one it needs all five.

Do I need to keep screenshots?

They help. WCAG-EM's optional step 5.2 lists screenshots alongside copies of the sample files, the path to each sample, the settings and input used, and the versions of tools, browsers and assistive technology (W3C). Screenshots matter most for manual verdicts, where the finding lives in behaviour rather than in the markup.

What evidence does a procurement team usually want?

In the US, an Accessibility Conformance Report on a VPAT, with Supports, Partially Supports, Does Not Support or Not Applicable against each criterion and remarks explaining anything short of Supports (Section508.gov). In the EU, an EN 301 549 clause table plus the accessibility statement, both of which need a dated record behind them.

Start the file with your next scan

You cannot backfill a scan you never recorded, so begin with the one you run today. Run a free scan and keep the export together with the URL list and the date, then work through the WCAG checklist for the criteria a machine cannot decide and write down who checked what. Once the human results are recorded, our accessibility statement generator will draft a statement from them that you can review and publish. Do that twelve times and you have a year of defensible history rather than twelve disconnected PDFs.

Pavel Charkasau, founder, wcagc.com. Last updated 29 August 2026.

Sources