Where should accessibility live architecturally so it is not a remediation project every year?

Why remediation cycles repeat

Accessibility treated as an audit finding is fixed page by page, and the next release reintroduces the same issues because nothing changed structurally. The knowledge lives in an audit report rather than in the components people build with.

Where it belongs instead

• In the design system's components. Keyboard interaction, focus management, roles, labels and contrast implemented once and inherited by every consumer. This is the single highest-leverage placement, because it converts an ongoing per-team obligation into a solved dependency.
• In the design tokens, so contrast ratios are satisfied by using the palette rather than by remembering to check.
• In automated checks in CI, which catch the mechanical subset — missing labels, contrast failures, invalid roles — reliably and cheaply.
• In the definition of done, so keyboard navigation and screen reader behaviour are part of building a feature rather than a later phase.
• In manual testing with assistive technology, because automation catches perhaps a third of real issues and the rest require someone using the product the way an affected user would.

The architectural decisions that matter

Semantic markup as the default, since a native control brings behaviour that a rebuilt one must reimplement completely and usually incompletely. Focus management on route change in client-rendered applications, which is invisible to sighted mouse users and completely breaks keyboard navigation. Announcements for dynamic content, since a screen reader user is otherwise unaware that content changed.

The framing that gets it funded

It is a quality property with legal exposure, not a feature. And the practical argument is that fixing it in components costs once, while fixing it in pages costs every year — which is the same argument used for any platform investment and is more persuasive than compliance framing alone.