Most accessibility programs I have seen are built around the audit. A scanner or a specialist finds the problems, tickets are filed, the owning team fixes the page, and next quarter the scanner finds the same problems on the pages that shipped since. The program is permanent because the problems keep being made.
I think the audit is the wrong unit of work, because the page is the wrong unit of work.
The same five problems
Every large accessibility survey finds the same list at the top: text without enough contrast, images without alternative text, form inputs without labels, links with no text, buttons with no name. Year after year, those five account for most of what automated checks detect.
What they have in common is that none of them is a page-level decision. Each is a property of a component, made or missed at the moment the component is used. A page does not forget to label an input. A form component allows an input to exist without a label, and then a few hundred pages use it that way.
The library is where the problem cannot be made
So I think accessibility belongs in the component library, and I mean something specific by that. The button component does not render without an accessible name. The input component requires a label, and the label is part of its contract, not an optional prop. The color system exposes pairs that already pass contrast, and the raw palette is not reachable from application code. The icon component demands either a label or an explicit declaration that it is decorative.
When the library works this way, the common failures cannot be produced by an application developer in a hurry. They can only be produced by changing the library, which is reviewed by people who know what the rules are. The audit still runs, but it finds the uncommon problems, which is what an audit is for.
What this asks of the library team
It asks for the library's team to own accessibility expertise, rather than spreading it thin across every product team. I think that is the right place for it. A handful of people who know the guidelines deeply, building components that encode what they know, reach every page in the organization. A hundred product engineers each trying to remember the rules reach the pages they happen to be working on that week.
It also asks for the library to be strict in ways that will sometimes annoy its users. A component that refuses to render without a label will generate complaints the first month. I think the complaints are the system working. Each one is a label that would otherwise have been missing.
What it does not cover
The library cannot make a page's reading order sensible, decide what a link should say, or structure a document with headings that mean something. Those are content and layout decisions, and they belong to the people building the page. I think the honest division is that the library takes the mechanical failures off the table so that the page's authors can spend their attention on the judgment calls, which no component can make for them.
That division also makes the audit smaller, more interesting, and more likely to be acted on. A report with eight hundred missing labels gets filed. A report with twelve genuine reading order problems gets fixed.
Photo source: https://photos.robertstowe.com/victoria