White-label accessibility remediation: how the auditor-plus-fixer model works

This guide explains how that arrangement works in practice, what each side owns, and what to agree in writing before any code changes. Tabstop Studio works this way with auditors and agencies, so we have a stake in it. We'll be specific about where it fits and where it doesn't.

Who it's for

Two kinds of firm use a remediation partner:

• Accessibility auditors and boutique audit firms that test and report but don't write production code. Their client gets a report and then often has no one to act on it.
• Shopify and WordPress agencies whose clients forward an audit or a demand letter. The agency knows the theme but doesn't have accessibility specialists free, or doesn't want to learn a niche under a deadline.

In both cases the partner already has the trust and the client. What they lack is engineering capacity for a specialist job. A remediation partner is overflow capacity, not a competitor for the account.

Who does what

The split matters for credibility. If the same person audits, fixes and signs off, nobody independent has checked the work. With a partner retest, the auditor stays the judge.

White-label vs co-branded

• White-label: the client never sees the fixer's name. Change logs and notes go out on the partner's template or unbranded. The fixer doesn't contact the client.
• Co-branded: the partner introduces the fixer as their engineering partner. It's often simpler for questions about the theme, and the partner still leads.

Either way, agree up front whether the fixer may ever mention the work publicly. Our default is no: we don't name partners or their clients unless the partner says yes in writing.

The handoff, step by step

1. Findings in

The partner sends the findings that are candidates for fixing: ID, WCAG success criterion, page or template, severity, and ideally the expected behavior and the retest check. (There's a separate guide on writing findings developers can fix fast.) A confidential report should go through a secure share, not an email attachment.

2. Triage and quote

The developer maps each finding to where it lives:

• Theme or template code (Shopify sections and snippets, WordPress templates and child-theme hooks): in scope.
• Third-party app code (reviews, popups, chat, upsells): usually only partly fixable. Options are app settings, a theme-side override if the app allows one, swapping the app, or a ticket to the vendor.
• Content (product image alt text, headings typed into the editor): often the merchant's job, unless it's quoted.
• Platform-owned code: on Shopify, checkout. Checkout is Shopify-hosted on every plan. On non-Plus stores we report checkout issues to Shopify rather than fix them. On Shopify Plus, custom checkout extensions can be in scope.

The quote should list the agreed findings by ID, the exclusions and the pass criteria. Ours turns around in 2 business days after receiving findings and read access.

3. Access without passwords

On Shopify, the fixer requests a collaborator account with only the permissions the job needs (usually themes). The store owner approves it, and nobody shares a password. On WordPress, a staging copy with its own login is the equivalent. Shopify's Partner Program Agreement also limits how partners may handle merchant data. Our scope says so in writing: we use AI-assisted tooling under strict data controls, the client's code and customer data are never used to train AI models, and every change is engineered, reviewed and tested by people.

4. Fixes on a duplicate, never live

All changes go into a duplicate theme or a staging site. On Shopify that's an unpublished copy of the live theme, previewed through a share link. Nothing reaches shoppers until the retest passes.

5. Self-check before handoff

Before the partner sees anything, the fixer should run the same kinds of checks the partner will: an automated scan of the changed pages, a keyboard-only pass, a screen reader pass, 400% zoom and reflow, contrast on changed elements, and a regression pass on add to cart, the checkout path, forms and search. Automated tools alone aren't enough. WebAIM notes that automated tools cannot detect every WCAG failure, so a page with no detected errors is not necessarily accessible (WebAIM Million 2026).

6. Change log out

One entry per finding: ID, success criteria, files changed, what changed, how it was checked, and a status. You can see the format in our demo change log (a fictional store, built to show the process).

7. Retest, rework, publish

The partner retests against the pass criteria in the quote. Anything that fails gets reworked. Once the agreed fixes pass, the staging theme is published.

Pass criteria: write them down

A retest is only fair if both sides agreed what it tests. Each quote should define:

• The issue list: finding IDs, not "fix accessibility".
• The standard: WCAG version and success criteria (we target WCAG 2.2 Level AA, which covers 2.1 AA).
• The test environment: browsers, devices and assistive technology the retest uses.
• Retest rounds: how many are included. Ours is up to two, with failed items reworked free within 14 days.
• Exclusions: the audit itself, checkout on non-Plus Shopify stores, third-party app internals, catalog content unless listed.

This also keeps a retest from turning into a fresh audit. New issues the partner finds are logged for a separate decision, not added silently.

How remediation partners price

The common models:

• Hourly. Simple, but the client carries all the estimating risk.
• Monthly retainer. Good for ongoing work and monitoring after the first round of fixes.
• Fixed price per fix list. The developer inspects the code first, then quotes a fixed amount for the agreed findings. The developer carries the estimating risk.

We use the third, with one more condition: pay on pass. If the agreed fixes fail your retest, you don't pay for them. That puts the payment decision with the party doing the independent check. It's a payment term on an agreed list, not a promise about the whole site or about legal outcomes.

What a remediation partner can't promise

Be wary of anyone who says otherwise:

• Legal outcomes. No developer can promise that a lawsuit gets dismissed or that a demand letter won't come. Questions about legal risk belong with the client's lawyer. We don't give legal advice.
• A "compliant" site. Fixes cover the agreed findings at handoff. Theme updates, new apps and new content can introduce new issues.
• Fixes to code nobody on the job controls. App internals and Shopify's own checkout are the usual examples.
• Automation doing the whole job. In April 2026 the US Justice Department wrote that generative AI "does not yet reliably automate the remediation of inaccessible content at scale" (DOJ interim final rule, 91 FR 20902). That's why every change needs manual keyboard and screen reader testing, and why the partner's retest is the independent check.

Overlays deserve a separate line. A widget that runs on top of the page doesn't change the theme code, so it doesn't fix the findings in an audit. In April 2025 the FTC finalized an order requiring overlay vendor accessiBe to pay $1 million and barring it from claiming, without evidence, that its automated tool can make any website WCAG-compliant (FTC).

Questions to ask any remediation partner

1. Do you fix the code, or add a script on top? (Only the first fixes audit findings.)
2. Will you work on staging only, through a collaborator or staging login?
3. Do you map every change to a finding ID in a change log?
4. What checks do you run before handoff, including manual keyboard and screen reader passes?
5. What happens if a fix fails our retest, and how many rounds are included?
6. What do you exclude, and how do you handle third-party apps?
7. Will you ever contact our client directly or name them publicly?
8. Are our client's code and customer data ever used to train AI models?
9. Who actually does the work? Is it subcontracted again?
10. Can we see a sample change log?

When this model is the wrong fit

• No findings yet. A remediation partner works from findings. If there's no audit, start with one: an independent auditor, or an accessibility review like ours, which produces a prioritized issue list mapped to theme files. (Ours is not a certified audit or a VPAT.)
• A rebuild is cheaper. If a store runs a heavily modified, outdated theme, fixing it line by line can cost more than moving to a current theme and fixing what's left. A good partner will say so.
• The problems are mostly content. Hundreds of product images without alt text is a content workflow for the merchant's team, with the developer making sure the template outputs alt text correctly.
• The client wants a legal guarantee. No honest partner can offer one.

How we run it

Tabstop Studio is new and has no past clients yet, which is exactly why the payment term exists: you judge the work by your own retest. Our demo store (fictional) shows the full process on 30 mock findings, including the change log, scan results and keyboard checks. The scope page has the payment terms in plain English.

Sources

• Shopify Help Center, Collaborator accounts
• Shopify, Partner Program Agreement
• WebAIM, The WebAIM Million (2026)
• US Department of Justice, Interim final rule, 91 FR 20902 (April 20, 2026)
• US Federal Trade Commission, FTC approves final order requiring accessiBe to pay $1 million (April 22, 2025)
• W3C WAI, WCAG 2.2

---

Have one client's audit on your desk? Send us one client's audit findings. We review the findings and the code, then quote a fixed price for an agreed list of fixes. Your team retests. If the agreed fixes fail your retest, you don't pay for them. Send findings.