How to document Shopify accessibility remediation for plaintiff's counsel

Plaintiff's counsel will re-test the store and ask what changed. The answer is an evidence package: the audit, the plan with dates, a changelog by file, before and after proof for each WCAG 2.2 criterion, a published accessibility statement, and a maintenance plan. Dated, specific, and free of claims that cannot be backed up.

By Gersen Medina. Published September 5, 2026. Updated September 5, 2026.

This article is for the defense attorney handling an ADA website matter and for the developer or agency producing the technical record. It describes what Gersen delivers at the end of a Shopify remediation and why each piece is there. It is not legal advice; what goes to the other side, and when, is your attorney's call.

What the other side will ask for

Most settlements include a remediation commitment with a date, and most plaintiff firms re-test the store around that date, with the same tester and the same tools as the first time. What they look for is simple: are the failures named in the letter gone, and are there new ones. What their expert will not accept is a statement that the store is "now compliant", a screenshot of an automated scanner's score, or the presence of a widget. What they cannot argue with is a record that shows, criterion by criterion, what was tested, what was changed, and what the result was.

The six documents

  1. Audit report

    Every failure found before the work started, mapped to a WCAG 2.2 success criterion, with the template it appears on, its severity, and how it was found (screen reader, keyboard, automated check). It includes the failures the letter named and the ones it missed, because the re-test will not stop at the letter's list. Dated, with the tools and versions used.

  2. Remediation plan with dates

    The audit ordered into work: what will be fixed, in which order, by which date, and how each fix will be verified. This is the document your attorney commits to in the response, so the dates are ones the developer can meet.

  3. Changelog by file

    Every theme file touched, with the date, the reason, and the criterion it addresses. In a theme repository this is the commit history; without one, it is a table kept by hand from the first change. It is the proof that fixes were made in the code and not by a script on top of it.

  4. Before and after evidence by criterion

    For each failure in the audit: a dated capture of the failure, a dated capture after the fix, and the test that shows the difference. For visual failures a screenshot is enough. For screen reader and keyboard failures the evidence is what the screen reader announced, captured as text or as a short recording, and the keyboard sequence that now works.

  5. Accessibility statement, published on the store

    A page on the store that states the target (WCAG 2.2 level AA), what was tested and when, the known limitations, and how to report a problem. It is public, dated, and referenced in the response. It is also the page a future plaintiff's tester reads first.

  6. Maintenance plan

    A short routine for the merchant's team: alt text on every new product image, a check before installing an app, a re-test after a theme update, and who is responsible. It shows that remediation is a state the store keeps, not a one-time event, which matters for the release language in the settlement.

Capturing screen reader evidence that survives a re-test

The plaintiff's expert usually tests with a screen reader on a desktop browser and sometimes on a phone. The evidence should be reproducible with the same setup:

  • Name the screen reader and browser pair, with versions: VoiceOver with Safari on macOS, NVDA with Chrome or Firefox on Windows, VoiceOver on iOS
  • Record the exact page URL and the theme version or the date of the theme copy
  • Write down the sequence: which key was pressed, what was announced, what happened on screen
  • Keep the announced text verbatim, "button" before and "Add to cart, button" after, rather than a summary
  • Date every capture and store it with the changelog entry it belongs to
  • For the keyboard, record the Tab order through the template and confirm that focus is visible at each stop and never trapped

A short screen recording with the screen reader's speech visible as captions is the strongest form of this evidence, and it is the easiest for a non-technical reader to follow.

Mistakes that weaken a response

  • Undated screenshots. Without a date, a before and after pair proves nothing about when the change was made.
  • A scanner score as proof. An automated tool reports the part of WCAG it can detect and says nothing about the rest. A "98 out of 100" invites the question of what the tool did not test.
  • A widget presented as remediation. The theme's code is unchanged, and the plaintiff's expert will show it in minutes.
  • "Fully compliant" or "ADA certified". Neither can be proven for a live store, and both invite a re-test designed to find the exception.
  • Fixes with no record. Changes made in a hurry, by several people, with no changelog, cannot be tied to the criteria in the letter.
  • Silence about apps. An app failure that was known and not documented becomes a finding on the re-test; the same failure documented as a known limitation with a workaround is a defensible position.

What Gersen delivers

Every remediation ends with these six documents, in the order above, written so that the attorney can attach any of them to the response without editing. The process and the deliverables are described on the Shopify accessibility remediation service page. The code behind the most common fixes is in the 10 WCAG failures in almost every Shopify lawsuit, and what the first days after a letter look like is in what happens after a Shopify store is sued.

Frequently asked questions

Who is the evidence package for?

Your own attorney first. They decide what goes to the other side and when. The package is written so that any part of it can be handed over as is: dated, specific, tied to WCAG criteria, and free of claims that cannot be backed up.

Is an automated report enough?

No. Automated tools such as axe find a part of the failures and none of the ones that need judgment, like whether an alternative text is meaningful or whether a variant picker works with a screen reader. The plaintiff's expert tests by hand. The evidence has to show the same kind of test.

Should the store say it is now compliant?

No. Write what was tested, what was fixed, what remains, and the standard that was targeted: WCAG 2.2 level AA. "Fully compliant" and "ADA certified" are claims no one can prove for a live store that changes every week, and they invite a re-test aimed at proving them wrong.

How long should the record be kept?

Keep it, and keep adding to it. With the merchant's consent, the record can also be written up in the case study format. Firms re-test, and a second letter is answered in a day when the record of the first remediation and the changes since then is at hand. The same record is the starting point for the information duty under the European Accessibility Act if the store sells into the EU.

What if the store uses apps that cannot be fixed?

Document them: the app, the failure, the criterion, what was tried (settings, theme overrides), and the decision taken (replaced, removed, or kept with a documented limitation and a workaround). A known limitation written down is defensible. An undocumented one is a finding on the re-test.

Working with counsel

Attorneys and agencies can send the letter or complaint and the store URL to gersen@gersenmedina.com. Gersen replies with the scope for the audit, the dates he can commit to, and the format of the record.

Gersen Medina, portrait

Gersen Medina is a Shopify accessibility specialist who remediates ADA and WCAG 2.2 issues on Shopify stores that have received demand letters or lawsuits. Working with U.S. companies since 2014, his remediation work has helped dozens of merchants avoid hundreds of thousands of dollars in accessibility litigation exposure. About Gersen