How should an agency build accessibility into client onboarding?

Build accessibility into client onboarding by doing three things in the first 30 days: run a baseline accessibility scan and share it in plain language, agree in writing which standard the build will target, and name one person on each side who owns it. Most accessibility debt is not a coding problem. It is an onboarding problem, because nobody set the bar before work started.

Start with a baseline scan, not a lecture

Agencies often open the accessibility conversation with education: a slide deck about WCAG, a warning about lawsuits, a list of best practices. Clients nod and forget it. A baseline scan lands differently. Run the client's current site, or the theme they plan to use, through an accessibility check before any build work starts, and share the results in plain language. Concrete findings on their own store do more than any generic presentation.

The baseline has a second job. It gives you a before-and-after story. Six months later, when the client asks what the accessibility retainer bought them, you point at the baseline scan and the launch scan. Agencies that skip the baseline end up arguing about value with nothing but vibes.

Agree on the standard in writing

"Accessible" is not a standard. Before design starts, write down which standard the build targets: WCAG 2.2 AA is the sane default for a Shopify storefront. Put the standard in the statement of work, not just the proposal, because proposals expire and statements of work survive. Name what is in scope: which templates, which apps, which languages.

This conversation also surfaces the uncomfortable cases early. If the client plans to rely on an accessibility overlay widget, now is the moment to explain why that will not meet the standard, while there is still time to plan real remediation. Having the standards talk at onboarding avoids the worst agency conversation of all: telling a client at week 10 that the thing they already paid for does not count.

Name one owner on each side

Accessibility fails in agencies for the same reason it fails everywhere: it is everyone's job and nobody's job. At onboarding, name the owner on the agency side, usually the lead developer or QA lead, and insist the client names theirs. The client owner does not need to be technical. They need to be the person who approves content changes and app installs, because that is where most regressions enter.

Both owners should know what a keyboard test is, how to run a contrast check, and where the evidence lives. Ten minutes of training at onboarding beats ten hours of remediation at launch.

Put accessibility in the content workflow now

Content teams introduce more accessibility regressions than developers do. Alt text, heading order, link text, and color choices on promotional banners are all content decisions. At onboarding, hand the client's content owner a one-page checklist: every image gets meaningful alt text, headings stay in order, links describe their destination, and sale banners pass contrast before they ship.

If the client has no content process at all, this is also the moment to create one. A shared checklist with a named approver is a process. It does not need to be fancy. It needs to exist before the first product launch, because the first product launch is when the bad habits form.

Plan the app policy before the first install

Shopify apps are the most common source of accessibility regressions on client stores. Popups, review widgets, upsell drawers, and loyalty panels all inject code the theme team never wrote. At onboarding, set the policy: every app gets an accessibility spot check before install, and the agency re-verifies after every major app update.

Clients will push back on anything that slows them down, so frame it as risk management. One inaccessible app can undo a fully accessible theme, and the agency is the one the client calls when the demand letter arrives. A short app policy agreed at onboarding is the cheapest insurance an agency can buy.