I have spent more than a decade on web accessibility, including leading WCAG compliance strategy at a public university and, more recently, getting a global platform to WCAG 2.2. In that time I have watched a lot of organizations buy the same thing: an audit.
An audit is a snapshot. Someone crawls the site, produces a spreadsheet with four hundred rows, sorts it by severity, and hands it over. Everyone agrees it is important. A ticket gets made. Six weeks later the site has shipped eleven new pages, and the spreadsheet is already wrong.
The audit is not useless. It is just answering a question nobody needed answered. You did not need to know that the site has problems. You needed to know why it keeps producing them.
The three places it actually breaks
In my experience the defects almost always originate in one of three places, none of which an audit touches.
The design system permits it. If your button component ships with a 3:1 contrast ratio on the disabled state, every team that uses the component inherits the defect, forever. Fix it once in the component and you have fixed it in every page that will ever be built. This is the highest-leverage accessibility work available to most organizations and it is usually assigned to nobody.
The CMS permits it. If an editor can publish an image without alt text, some of them will, and it is not a training problem. Make the field required. Make the heading levels constrained by the template rather than by a rich-text dropdown that offers H1 through H6 as font sizes. Most content-layer accessibility defects are really permissions defects.
Nobody owns it at the moment of the decision. Accessibility reviewed at the end is accessibility that costs the most to fix and has the least political capital behind it. Reviewed at the design stage it is a comment on a mockup. Reviewed at launch it is a release blocker, and release blockers lose.
What to do instead
Put the requirement where the work happens. Bake the contrast and focus rules into the design tokens so a designer has to actively fight the system to produce a violation. Constrain the CMS so the common mistakes are not expressible. Put a keyboard-only pass and a screen reader pass into the definition of done, not into a quarterly initiative. Then run automated checks in CI so regressions surface as build output rather than as a spreadsheet in nine months.
None of that requires a bigger budget. It requires deciding that accessibility is a property of your process rather than a property of your site.
The part that is not a technique
I served as an Inclusion Advocate for over a decade alongside this work, and the honest version of the argument is not the compliance one. The compliance argument gets you funded. It does not get you a good site. The reason to do this is that a meaningful share of your audience cannot use what you shipped, and they mostly will not tell you. They will just leave, and your analytics will record it as a bounce.
That is the number that should bother you, and it is not in the audit.