Act V: The Appearance of Completion
The Accessibility Audit Your CFO Will Eventually Ask About
The e-commerce director did not look defensive when she said it, which is the detail worth holding onto. She looked tired in the specific way of someone relaying a question she half-agreed with. We were a few minutes into a check-in, the usual run of metrics and small fires, and she set her coffee down and said it the way you confess something on someone else’s behalf: Our CFO wants to know why we spent all that money on an accessibility audit and we’re still not compliant.
Here is the thing nobody in that conversation was wrong about. The audit was real—a proper one, run by people who knew the standard, line-itemed against WCAG, re-tested after the fixes went in. The remediation was real; engineering did the work and the report came back green. The store launched on time. And then, across the months that followed, the team did exactly what a healthy team does: they shipped a run of new seasonal sections, they published product updates across the catalog, they wired in a couple of third-party scripts because marketing needed them by Friday. None of which went through anything resembling an accessibility review, because the accessibility review was a thing that had already happened. It was in the past tense. It was done.
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.
They were both right. That is what makes the conversation hard, and also what makes it worth having properly instead of defensively.
The reason the audit feels like a finish line is that it behaves like one. It produces a deliverable—a violations report, a remediation checklist, a re-test confirmation with a date on it. It has a shape: a beginning, a middle, a tidy end you can forward to the CFO with the subject line done. For a team taking accessibility seriously for the first time, running an audit and fixing what it surfaces is real, visible, fileable progress. We are not going to pretend otherwise, because pretending otherwise is how you end up sneering at people who did a good and difficult thing.
The trouble is what the model quietly assumes. It treats accessibility the way a brand treats a redesign—something you do, complete, and move past, the way you’d repaint a storefront and not think about the paint again for three years. But your site is not a storefront that holds still once the paint dries. Features ship. Sections get added. A content editor uploads a hero asset on a Tuesday. Somebody installs a review app. Every one of those is new surface area, and not a single square inch of it was in the report, because none of it existed when the auditors logged in.
(Head Of Digital Whose Audit Closed Out Clean Last Spring: do the arithmetic on what your team has shipped since. Not to frighten you. Just so the number is in the room.)
And the exposure on the other side of that surface area is not holding still either. In 2025, plaintiffs filed 3,117 website accessibility lawsuits in US federal court—up 27% over the year before, by Seyfarth Shaw’s count. We mention the number once and then we are going to put it down, because the temptation is to pick it up and wave it, and a chapter that waves a lawsuit number around becomes a different and worse chapter. But there is one shift inside that statistic worth naming, because it changes the texture of the risk. Increasingly the demand letters do not originate with a disabled customer who hit a wall trying to check out. They originate with bots—automated crawlers walking storefronts looking for WCAG violations to manufacture demand letters at scale. The thing scanning your site for a missing label does not get tired, does not take the holidays off, and does not care that you passed an audit in the spring. It only sees the site as it is, right now, the way it is the moment it arrives.
So if the audit was never going to keep you compliant—and it wasn’t, that was never its job—the honest next question is what does. And the honest first move is to be precise about the standard, because vagueness here is its own small liability.
WCAG 2.1 AA is the practical place American law and European regulation meet. ADA enforcement in the US points at it; the European Accessibility Act points at it too, more explicitly, and the EAA adds a wrinkle the US-headquartered brand likes to skip past: it wants a published accessibility statement, and its reach follows the selling, not the incorporation papers. If you sell into Europe, it applies to you. (If that phrasing rhymes with something from the previous chapter—the directive that follows where you market rather than where your lawyers file—that rhyme is not an accident. The platform partially handles a great many things. Accessibility is one more room with a line drawn through it, and the same discipline applies: know which side of the line is yours.)
But the standard is not the hard part. The hard part is the sentence the whole chapter is trying to get you to feel rather than merely read: compliance is not a state you achieve. It is a state your site is in, or out of, at any given moment. The audit told you where you stood on one specific day. It said nothing—it could say nothing—about the site you would be operating sixty days later, because that site had not been built yet. No audit covers a site that hasn’t been built. You cannot inspect a room before its walls go up, and you are putting up new walls every sprint.
The answer, mercifully, is not run more audits. Running the snapshot more often is still taking snapshots; it just shortens the gap between them without closing it. What actually holds is three overlapping layers of coverage, each catching a different class of failure at a different point in the workflow, none of them sufficient alone.
The first layer lives in the developer’s browser. An extension—axe DevTools, WAVE—installed in every engineer’s browser, so violations surface while the code is being written, before anything ships anywhere. An issue caught here costs almost nothing: a few minutes, a corrected attribute, a developer who learns the pattern and stops making it. The same issue caught in next year’s audit costs an order of magnitude more—remediation time, a blocked release, occasionally a letter from a law firm. The cheapest place to fix an accessibility bug is the same place it’s cheapest to fix every other kind: the keyboard it was written on.
The second layer is automated testing in CI, and this is where most teams have a gap they don’t know they have, because the gap is shaped exactly like the tool they’re already using. Many lean on Lighthouse, which runs accessibility checks inside its standard suite. Lighthouse is genuinely useful and we are not here to disparage it. It is also not sufficient, and the reason is structural rather than a matter of effort. Lighthouse tests a static page state—what the browser renders on load. It cannot see the cart drawer that only exists after a click. It cannot see the modal that opens mid-checkout, or the navigation that unfolds on hover. An enormous share of an e-commerce store’s interactive surface simply never appears in a scan of the idle page—which means the parts of your store most likely to trap a keyboard user are precisely the parts the default scanner is blind to. The better shape is Playwright driving the axe SDK: you script the interaction first—open the drawer, then assert—so the test walks the path the customer walks rather than photographing the lobby and calling it the building.
The third layer is the human one, and no amount of tooling retires it. Automated tools catch roughly a third of WCAG violations. The remaining two-thirds want judgment: whether the reading order makes semantic sense, whether a custom widget actually cooperates with a screen reader, whether the alt text is meaningful or merely present. Because that is the whole crux of the layer, and it is the line worth taping to the monitor: 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. A quarterly manual review is not a smaller version of an annual one. It is a different instrument, because the site it inspects is closer to the site you actually shipped, and a violation caught at three months is cheaper in every currency than one that’s been live for twelve.
And here is the part that gets left out of nearly every accessibility conversation, the part that survives all three technical layers intact: a good chunk of the failures don’t live in the code at all. They live in the content.
A product image where the product’s name is rendered as a font baked into the JPEG. A campaign banner where the whole call to action is part of the graphic, unreadable to anything that can’t see. A blog post where every image is missing alt text because the editor who published it never knew the field was there. No scanner flags these. They come back clean—gloriously, falsely clean—and they fail WCAG 1.1.1 categorically. The tooling is looking at the structure; the failure is in the substance, and the substance was typed in by a person who was thinking about a launch, not a spec.
Shopify’s section architecture can lean against this, but only if you build it to from the start. Section schemas can carry required alt-text fields, mandatory aria-label inputs, constraints that make the non-compliant thing harder to publish than the compliant one. On projects where we’ve baked those requirements into the schema, editors commit fewer violations—not because anyone read the spec, but because the form refuses to let them skip the field. It is the cheapest behavior change in the building: you don’t train the editor, you just make the wrong move slightly more annoying than the right one.
It is not a complete fix, and we should be honest that it isn’t. The editor can still type “hero image” into the alt-text field and tab on through, having technically satisfied the form and accomplished nothing for the person using a screen reader. The other half is editorial guidelines and a short, unglamorous accessibility orientation for anyone who publishes—the part that doesn’t automate, doesn’t demo well, and is quietly responsible for a disproportionate share of what real audits actually find.
Which leaves the vendor relationship, and it deserves more scrutiny than it usually survives, because the structure of the contract quietly decides how protected you actually are—independent of how good the vendor is.
Some contracts—Level Access is one—sell a fixed number of manual reviews per year, with per-review overages after that. Read the incentive that creates, because your team will read it for you whether or not anyone says it out loud: reviews get rationed. They get hoarded for after the big launches, spent carefully, and the stretches between them accumulate unreviewed surface area on a predictable schedule. You’re rationing your own safety, and the gaps happen on a calendar you could circle in advance.
Managed services like TestParty run the other way: continuous monitoring, violations identified as they appear, pull requests with fixes shipped on a regular cadence. The output is often genuinely good. But notice there is still a window—between the moment non-compliant code goes live and the moment the fix lands—during which the site is out of compliance and a crawler that visits doesn’t know or care that a remedy is in flight. Whether that window translates into real legal risk depends on your situation, and we won’t pretend to know your situation from here; we’ll only say it belongs in the decision, priced honestly, before you sign rather than after.
None of these is a finish line either. They are instruments for staying in a state, not events that put you permanently into one. We’ll be direct about the cost: building the whole model—the extension in every browser, the scripted CI checks, the content guidelines, the vendor relationship structured for coverage instead of for events—takes real time, and most brands reading this are already behind. The audit-first instinct isn’t the wrong place to start. You have to know where you stand before you can know what’s drifting. It only becomes the wrong approach the moment it’s mistaken for a destination.
So the CFO gets a real answer, not a flinch. The audit was a snapshot: it told you, accurately, where you stood on one specific day, and it said nothing about the sections and uploads and apps that arrived afterward, because on the day of the snapshot none of them had been born. What keeps a brand compliant is everything that runs after the picture is taken—the extension that catches the issue before it ships, the CI test that fails a pull request because a new modal has no focus trap, the editor who knows what alt text is for, the quarterly review that surfaces what the machines couldn’t judge. The audit was the photograph. Staying compliant is the act of continuing to be the kind of store the photograph would still flatter.
The e-commerce director, for what it’s worth, took this back to her CFO more or less intact, and the CFO—who was, remember, asking a completely legitimate question—funded the workflow instead of the next one-time audit. Which is the right outcome, and a rare one, and we mention it because the chapters in this part of the book have a way of ending on the things that didn’t get caught in time, and this one didn’t have to.
Because the question worth budgeting against was never have we passed an accessibility audit. You have, or you will; that part is knowable and finite and behind you. The question that actually keeps a site honest is the one the calendar keeps asking on your behalf, quietly, every day you ship anything at all: would we pass one today?