Scoping Accessibility Work in a Statement of Work Clients Can Sign

How agencies scope Shopify accessibility work in an SOW: named pages, standards, methods, and remediation terms a client can actually approve.

Most accessibility engagements go sideways before any code is touched, in the statement of work. A vague SOW promises 'WCAG compliance' with no pages, no method, and no definition of done, and both sides spend the project arguing about what was bought. A scoped SOW reads less like a promise and more like a map.

This guide walks through the sections that make accessibility work signable: the inventory, the standard, the method, the remediation terms, and the exclusions. None of it is legal boilerplate. It is the difference between a project that ends with a report both sides trust and one that ends with a dispute.

Start with a page and template inventory

Name what is in scope by template, not by vibes: product, collection, cart, checkout configuration, account pages, and the content templates the client publishes with. Shopify stores reuse a handful of templates across hundreds of pages, so scoping by template is both honest and efficient. A barrier fixed once in a template is fixed everywhere it renders.

List what is out of scope just as plainly: third party app interfaces the agency does not control, legacy content the client will retire, and marketing landing pages built in external tools. Clients sign faster when exclusions are written down, because exclusions are where their real questions live.

Name the standard and the conformance target

Write the target into the document: WCAG 2.2 Level AA is the working standard for most commerce work in 2026, and naming the version matters because success criteria differ between releases. 'Accessibility' without a version is a mood, not a deliverable.

Also state what conformance means in practice for a living store: the templates and flows in scope meet the criteria at delivery, verified by the agreed method. A store changes daily, so the SOW should promise a verified state at a point in time plus a monitoring or retest arrangement, not a permanent condition.

Describe the evaluation method

Clients approve budgets more easily when they can picture the work. Describe the method in plain terms: automated scanning across the template set, manual keyboard and screen reader passes on the critical flows, and a findings report graded by severity with reproduction steps. Method is what separates an audit from a screenshot of a scanner score.

Include the retest loop in the method section: who fixes, who verifies the fix, and how many retest rounds the fee covers. Retesting is where cheap audits quietly expire, and naming the rounds up front protects the agency from an endless loop and the client from paying twice for the same finding.

Put remediation terms in writing

If the agency also remediates, the SOW needs severity definitions and response times: blockers on the purchase path fixed first, cosmetic issues scheduled, content issues handed to the client with guidance. A simple severity table in the SOW prevents the first findings call from becoming a negotiation about what 'critical' means.

Close with change control. New templates, a theme upgrade, or a storefront rebuild mid engagement changes the inventory, and the SOW should say how scope changes get priced and approved. Accessibility work touches everything a store ships, so the change clause will get used. Write it like it will.

Related reading

If this topic is useful, these earlier guides go deeper on connected questions: Accessible Mega Menus and Navigation Drawers: Keyboard Paths, Focus Order, and Escape Routes, Writing an Accessibility Conformance Report a Client Can Actually Use, and Accessible Shopify Search and Filtering: Facets, Autocomplete, and Screen Readers.

Frequently asked questions

What should an accessibility SOW always include?

A template level inventory of what is in and out of scope, the named standard and version (usually WCAG 2.2 AA), the evaluation method, severity definitions, retest terms, and a change control clause. If any of those six is missing, the engagement is relying on goodwill instead of a document.

Should an SOW promise full WCAG conformance?

It should promise that the in scope templates and flows meet the named criteria at delivery, verified by the stated method. A blanket promise over a changing store, client published content, and third party apps promises what no agency controls and invites disputes neither side can win.

How detailed should the page inventory be?

Template level is the right grain for Shopify: product, collection, cart, account, search, and content templates, plus named exceptions. Auditing every URL is wasteful because templates carry the barriers. The inventory should also name who owns fixes for app rendered interfaces, which is the most common gap.

What happens when scope changes mid project?

The change clause governs: new templates or a rebuild get documented, priced, and approved before work starts. Without that clause, every store change becomes an argument about whether it was included. With it, changes are routine paperwork instead of relationship damage.