Here's a conversation we've had more than once. An e-commerce director comes to a check-in and says: "Our CFO wants to know why we spent all that money on an accessibility audit and we're still not compliant."
It's a fair question. The audit was real. The remediation was real. The Shopify store launched on time. And then, in the months that followed, the team shipped a run of new seasonal sections, published product updates across the catalog, and added several third-party scripts, none of which had been through any kind of accessibility review.
The audit wasn't wrong. It was accurate on the day it was done. But it was designed to answer a point-in-time question, and the CFO was asking a continuous one.
Why the audit feels like the finish line
The audit-and-fix model makes intuitive sense. It produces a deliverable: a WCAG violations report, a remediation checklist, a re-test confirmation. It has a beginning and an end. For a team tackling accessibility seriously for the first time, running an audit and fixing what it finds represents real, visible progress.
The problem is that this model treats accessibility the same way a brand might treat a website redesign: something you do, complete, and move on from. But your site doesn't stop changing. Features ship. Sections get added. Content editors upload assets. A new app gets installed. Every change is new surface area, and none of it was in the report.
In 2025, plaintiffs filed 3,117 website accessibility lawsuits in federal court, a 27% increase from the year before, according to Seyfarth Shaw's annual tracking. Those lawsuits don't come with grace periods for "we passed an audit at launch." And increasingly, they don't come from disabled users who were blocked from completing a purchase. They come from automated bots crawling storefronts specifically looking for WCAG violations to generate demand letters at scale.
The exposure is continuous. The one-time audit is not.
What "compliant" actually means on a living site
WCAG 2.1 AA is the practical standard that both US law (ADA) and European regulation (EAA) converge on. The EAA is more explicit about requirements and mandates an accessibility statement; its provisions apply to any brand selling into Europe, not only brands headquartered there.
But the standard itself isn't the hard part. What's hard is accepting that compliance isn't a state you achieve, it's a state your site is in or out of at any given moment.
Think about what a typical Shopify brand ships in a month: new product pages, seasonal campaign sections, an updated checkout flow, a third-party review app, a new loyalty widget. Each of those is a new set of DOM elements, a new interaction, a new potential WCAG failure. The audit covered the site that existed when the auditors logged in. It said nothing about the site you'd have sixty days later.
This is the reframe the CFO question requires. The audit was never going to keep the brand compliant. That was never its job. The question is what does.
The three-layer discipline
What did you say? "Run more audits!"? Nope, that's not the solution. It's building three overlapping layers of coverage that catch different classes of issues at different points in the workflow.
Layer one: developer-time tooling. A browser extension like axe DevTools or WAVE installed in every developer's browser catches violations during development, before anything ships. Issues found here cost almost nothing to fix. Issues found in an annual audit cost an order of magnitude more in remediation time, in blocked releases, and sometimes in legal fees.
Layer two: automated CI testing. This is where most teams have a gap, and where the choice of tooling matters more than teams usually realize. Many rely on Lighthouse, which runs accessibility checks as part of its standard audit suite. Lighthouse is useful. It is not sufficient.
The problem is that Lighthouse tests a static page state, what the browser renders on load. It cannot test a drawer that's only visible after a click, a modal that opens mid-checkout, or a navigation menu that appears on hover. A significant share of interactive e-commerce UI never appears in a static page scan. A better approach is Playwright, or similar end-to-end testing tools with the axe SDK: you script the interaction first ("open the cart drawer, then run the accessibility check"), so the test covers the actual user path rather than the idle page.
Layer three: periodic manual audits. Automated tools catch roughly a third of WCAG violations. The rest require human judgment, whether alt text is meaningful, whether reading order makes semantic sense, whether a custom widget works correctly with a screen reader. Automated tools can confirm that an alt text attribute exists; they cannot tell you whether it says "image.jpg" or something a screen reader user would actually find useful.
Manual audits run quarterly are categorically different from those run annually, not just quantitatively. The site you're reviewing is closer to what you actually shipped. Issues caught at three months are cheaper to fix than issues that have been live for twelve.
The gap no tool will find
Here's the part that gets left out of most accessibility conversations: three layers of technical tooling will still leave you exposed, because not all accessibility failures live in the code.
They live in the content.
A product image where the product name is rendered as a font inside the JPEG. A campaign banner where the call-to-action text is baked into the graphic. A blog post where every image lacks alt text because the editor who published it didn't know the field existed. No automated scanner catches any of these. They return clean. They fail WCAG 1.1.1 categorically.
Shopify's section architecture can help, but only if it's designed that way from the start. Section schemas can include required alt-text fields, mandatory aria-label inputs, and constraints that make non-compliant content harder to publish than compliant content. On projects where we've built sections with those requirements baked into the schema, content editors make fewer violations, not because they've read the WCAG spec, but because the form won't let them skip the field.
That's not a complete solution. An editor can still type "hero image" in an alt-text field and move on. Editorial guidelines and a basic accessibility orientation for anyone who publishes content are the other half. Less glamorous than CI tooling, harder to automate, and responsible for a disproportionate share of the violations that surface in real audits.
Building the model that actually holds
Getting from "we had an audit" to "we have a workflow" requires three things beyond the initial report: CI tooling in the development process, content guidelines for the people who publish, and a vendor relationship structured for ongoing coverage, not event-based reviews.
That last one deserves more scrutiny than it usually gets. Some contracts give a brand a fixed number of manual reviews per year and charge per-review after that. The effect is predictable: teams ration their reviews, save them for after major launches, and end up with months of unreviewed surface area in between. You're rationing your own safety, and the gaps happen on a schedule.
Other managed services take a different approach: they monitor your site, identify violations, and deliver pull requests with fixes on a regular cadence. The output quality is often high. But there's a window between when you publish non-compliant code and when the fix arrives, and during that window, you're exposed. Whether that gap creates real legal risk depends on your specific situation, but it's worth pricing into the decision before you sign up.
We'll be direct: building this model takes time, and most brands are already behind. The audit-first approach isn't the wrong starting point, you need to know where you stand. But it becomes the wrong approach the moment it's treated as a destination.
What keeps you compliant
The CFO question deserves a real answer, not a defensive one.
The audit was a snapshot. It told you where you were on one specific day. Everything that came after, the new sections, the content uploads, the app additions, wasn't covered, because it didn't exist yet. No audit covers a site that hasn't been built.
What keeps a brand compliant is everything that runs after the snapshot: the extension that catches an issue before it ships, the CI test that fails a PR because a new modal has no focus trap, the content editor who knows what alt text should actually say, the quarterly manual review that surfaces what automation missed.
The question worth asking isn't "have we passed an accessibility audit."
It's "would we pass one today?"
If accessibility is on your roadmap, whether as part of a Shopify replatform or as a standalone initiative, we're happy to talk through what the right model looks like for your team.
