The agency playbook for keeping forty client stores accessible

The letter names the builder

Here is the sequence that worries every agency that has seen it once. You build a clean store in March. The client pastes a heading-less product description in October, installs a chat widget in November, and swaps the hero for a text-on-image banner in December. In January the demand letter arrives, and it names the store, the owner, and the people who built it.

The merchant did not break the store on purpose, and you did not build it broken. But accessibility decays from both sides: developers ship under deadline, merchants paste content without alt text, and the builders are blamed either way. Shopify was the most-sued named platform in 2025, with a third of sued sites running on it,^* and UsableNet puts 64% of defendants under $25M in revenue.^* That is the agency client base, described from the outside.

This is the routine we use across the stores we maintain. The product appears only in the last section, and a checklist and a calendar are enough to run most of it.

Split the work by who can change it

The first mistake agencies make is treating accessibility as one job. It is three, and they belong to different people.

• Code issues live in the theme: missing landmarks, no skip link, unlabeled icon buttons, broken heading order, form fields without labels, focus states removed by CSS. Only the developer can fix these, and the fixes persist across content changes if they are made in the theme files rather than in a single page.
• Content issues live in the catalog and the pages: images without alt text, descriptions pasted with their own headings, text colors chosen in the editor, link text that says "click here". Only the merchant, or whoever edits products, can fix these at the source, and they will reappear with the next import unless someone owns them.
• App issues live in third-party code: dialogs that trap focus, floating buttons with no name, widgets with low contrast. The fix is a setting in the app, a different app, or a support ticket, and the owner is whoever installed it.

Write the routing down. When a scan finds a problem, the first question is not "how do we fix it" but "whose admin does this live in". A missing alt text on a product image goes to the merchant with the product name and the image; a missing skip link goes to the developer as a pull request.

Bake it into the build

Everything that can be fixed once at the theme level should be, before handoff, so it survives the merchant's content.

• A skip link before the header, pointing at the main landmark.
• The page language set on the html element from the store locale.
• Header, navigation, main and footer wrapped in semantic landmarks.
• Every icon-only control with an accessible name: cart, search, menu, close, account, carousel arrows.
• One top-level heading per template, and section headings that step down one level at a time.
• Form fields with visible labels, including the newsletter input and the search box.
• Visible focus styles kept, even when a designer dislikes the outline.
• Color tokens checked once for contrast, so the merchant cannot pick a failing pair from the theme settings.

Then run a keyboard pass on the five pages that get tested first: home, a collection, a product, the cart drawer, and search. If you can buy something without touching the mouse, the build is in good shape.

The failures in that chart are the ones complaints cite most, and every one of them is cheaper to prevent in the theme than to chase through products later; the checklist walks through each.

Hand over a record

Tell a client where their store stands, and leave the word compliant out of it. The claim is beyond anyone's power to make, and the overlay vendors who made it were fined. Hand over a record instead:

• The baseline scan, dated, listing what was found and what was fixed.
• A short note on what is theme-level and will persist, and what is content-level and will need attention as the catalog grows.
• A draft accessibility statement for the store, with a contact path for anyone who hits a barrier.
• The routing table from the previous section, so the client knows who to call for what.

A record like this is worth more to the client's lawyer than any badge, and it is what makes the January letter a manageable conversation rather than a scramble.

The monthly rhythm

A store you are not watching is drifting. The rhythm that works:

1. Rescan each store monthly, and after any theme update or app install you know about.
2. Read only the delta. New issues since the last scan, grouped by owner. The full list exists for reference; the delta is what gets acted on.
3. Route content issues to the merchant with the exact product or page, in their language, with what to type. "Add a description to the three sneaker photos uploaded on the 4th" gets done; "fix WCAG 1.1.1 violations" does not.
4. Fix code issues as pull requests with the diff, so the client can see what changed and you can revert it if the theme update that follows disagrees.
5. Log it. Date, finding, fix, who did it. Thirty minutes a month per store, and the record builds itself.

How to price it

Clients rarely pay for accessibility work as a line item, because the risk is invisible until it is not. Two approaches work. Fold the monthly rhythm into the maintenance retainer and say so, which makes it part of what they already buy. Or price it as a small standing item against the alternative, which is a demand letter that typically settles in the five figures plus the fees to deal with it. Either way, the pitch is liability, not features.

Beyond this article

This routine catches the mechanical failures and keeps them from coming back. It does not replace a manual audit by someone who uses assistive technology, which you should still arrange for a flagship store or before a redesign ships. And none of it is legal advice; when a letter arrives, the client's counsel leads.

In short

Keeping forty stores accessible is not forty audits. It is one build standard, one routing table, one monthly scan per store, and a record that grows on its own. SiteRemora does the scanning, attributes every issue to the theme file or the product behind it, fixes what it can in the Liquid and the catalog with a diff and a revert for each change, and keeps the history per store. If you maintain stores for clients and want it running across all of them, write to us; we run an agency program for this.