Read the transcript
The letter arrived, you treated the first hour as triage, and now the work is under way. Developers have tickets. Things are getting fixed.
This is where most teams quietly lose the thing they are working for. They fix well and record badly, and four months later the whole account of what happened is a git log and a folder of screenshots.
That is a record of changes. Nobody is going to ask you for a record of changes. What gets asked for is evidence that an evaluation happened — what was tested, against which requirement, by what method, with what result, and how somebody else could get that same result. Those are two different documents, and the second one is far harder to reconstruct after the fact than to keep as you go.
I am not an attorney and none of this is legal advice. What follows is testing and documentation practice — the technical record that sits underneath whatever position your counsel decides to take.
There is now a published methodology for this
You do not have to invent the format. On 23 July 2026 the W3C Accessibility Guidelines Working Group published WCAG Evaluation Methodology (WCAG-EM) 2.0 as a W3C Group Note — guidance from the working group rather than a W3C standard, but the most specific published description of what an accessibility evaluation report should contain.
Its Step 5 lists what a report records, at minimum:
- who evaluated, who commissioned it, and the date
- the scope, the conformance target, the accessibility support baseline, and any additional requirements
- the technologies the product relies on
- the sample of pages and views evaluated, and how that sample was selected
- the outcomes of the checks
Read that list against the notes you are keeping right now. “Fixed the button” is not on it. Neither is a ticket number. Nearly every field there is context that lives in somebody’s head during the work and nowhere at all six weeks later.
Six fields per fix
Per item remediated, record:
- The success criterion, by number. “Improved contrast on the CTA” is a sentence. “SC 1.4.3 Contrast (Minimum): primary button on the product template measured 3.1:1, now 4.6:1” is a finding.
- What was failing, in reproducible terms. Name the component and the template, not one URL. One URL invites the reply that you fixed one page.
- What actually changed — and where. The component, the theme file, the design token. If the answer is a single page, that is itself a finding you should be worried about.
- When, and by whom.
- How it was verified, and by whom. Where your team size allows it, not the person who made the change.
- What it was verified with. Browser, assistive technology, tooling — names and versions.
The first five without the sixth cannot be checked by anyone who was not in the room.
Screenshots are the weakest evidence you can keep
Everybody takes screenshots, because they are easy and they feel like proof. A screenshot shows that a state existed. It does not show how to reach that state, and it cannot be re-run.
WCAG-EM 2.0 is useful here precisely because its list of records to keep is mostly not screenshots. It suggests keeping the DOM as rendered during evaluation rather than the original source files, the path used to reach each sample, the settings and input and actions used to get there, test credentials needed to reproduce a workflow, the names and versions of tools, browsers and assistive technologies, and the methods and techniques used.
Notice what those have in common: every one of them makes the test repeatable. A screenshot of a visible focus ring proves a focus ring was visible on one page, in one browser, on one day. A saved rendered DOM plus the path — home, search, product page, add to cart, keyboard only, this browser at this version — lets a stranger reproduce your result or contradict it. Only the second one is worth anything in a dispute.
Two practical warnings. Capture the rendered DOM, not the template source — on a modern storefront those differ enormously, and the accessibility tree is built from the former. And the Note flags something teams routinely get wrong: these records can contain personal data, order contents and working credentials. An evidence folder on an open shared drive is a problem waiting to happen.
Name the test, not just the criterion
“Passes SC 1.1.1” means roughly as many things as there are testers. Two competent people can check the same page against the same criterion and record different outcomes, because they tested different things.
The W3C’s Accessibility Conformance Testing (ACT) Rules Format 1.1 became a W3C Recommendation on 5 February 2026. It defines how an accessibility test rule is written down, so that an automated tool and a human tester can refer to the same test rather than to the same criterion. Where your record can name the rule applied, do it. It converts a judgement into something a third party can run.
This also disciplines the obvious temptation, which is to re-run the scanner, get a clean report and file it. Automated tools cover part of WCAG and not the part that most often blocks a purchase. A clean scan is not an accessible store, and a clean scan filed as remediation evidence is an invitation to be tested properly by somebody else.
Where a VPAT fits, and where it does not
At some point somebody will suggest producing a VPAT. It is a reasonable instinct and a bad sequence.
An Accessibility Conformance Report is a claim you make about your product, written for buyers, summarising conformance one criterion at a time at a point in time. Nobody reviews it before it reaches the reader. It is a summary, and a summary is only as good as the record underneath it.
So the order matters. The remediation record is the working; the ACR is the roll-up. Writing the roll-up first means writing “Supports” in rows you cannot show your working for — which is what a capable reviewer goes looking for, and what turns one gap into a question about the whole document.
Once the record exists, producing an ACR from it is largely clerical. That is the right way round.
Re-test the components, not the pages
Here is the failure that brings teams back twice: the fix was made in the page, so it reappears everywhere the page was not.
Templated storefronts fail by component. One unlabelled icon button, one custom select, one modal that does not trap focus — each is broken on every view that uses it, and each is re-broken by the next theme update or app install that touches it. The patterns that regress first are predictable: custom dropdowns and selects, dialogs and their focus handling, carousels, cookie banners, and form error messaging. In WCAG terms that is mostly SC 4.1.2 Name, Role, Value, SC 2.4.7 Focus Visible, SC 3.3.1 Error Identification, and — newer, and routinely missed — SC 2.4.11 Focus Not Obscured (Minimum), where a sticky header or chat widget hides the element you have just tabbed to. I have written about how these show up in Shopify themes specifically.
WCAG-EM 2.0 is unusually concrete about re-evaluation, and the advice cuts against instinct. Keep a subset of the original sample so results are comparable, and replace roughly half of it with new views to widen coverage. Most teams do the opposite: they re-test precisely the pages they fixed. That is guaranteed to pass and tells you nothing about the templates nobody opened.
What to hand to whoever is advising you
Give counsel a factual annex, not a conclusion. Scope and dates. Method and tooling. Findings by success criterion. What changed and when. What is outstanding, with scheduled dates against it. Written so that a technical reader who was not involved could repeat the testing.
What not to include is any characterisation of whether you comply, or of what you are obliged to do. That is not your call or mine — I am not an attorney, and the technical record exists to let somebody qualified answer that question with facts in front of them. Keep your accessibility statement honest for the same reason: a dated remediation plan that names what is not yet conformant is a stronger document than a conformance claim you cannot evidence.
And do not clear out the pre-remediation state. The backups, the original captures, the history of what the site looked like when the letter landed — those establish the baseline that everything else is measured against.
The part that pays for itself
A team that keeps this record stops re-litigating its own history. New developer, new agency, next year’s audit, a procurement questionnaire, a second letter — the answer is a document rather than an archaeology project. The cost is six fields per ticket, while the work is happening anyway.
If you want that record built properly from the start: testing mapped to success criteria, evidence captured so it can be re-run, prioritised by what blocks a purchase. Remediation and ongoing testing run through EcomBack (opens in a new window), a court-approved accessibility provider. Book a consultation (opens in a new window) — if a letter has already arrived, say so in the first message and it goes to the front of the queue.
I am a web accessibility specialist and ADA compliance consultant, a participant in the W3C Accessibility Guidelines Working Group and a DHS Trusted Tester. I am not an attorney and this is not legal advice. Speak to qualified counsel about your specific situation — I work alongside legal teams and supply the technical evidence they need. More about my background.