Accessibility is not a checklist, it is an architecture
The majority of late-arriving accessibility audits I have seen shared the same root defect: accessibility had been conceived as a list of corrections, never as a design constraint.
The classic symptom
A design system that does not integrate contrast or keyboard navigation from conception will generate hundreds of non-conformities, repeated on every screen that uses it. Fixing them after the fact means revisiting each screen individually.
What an architecture approach changes
- Base components (buttons, forms, modals) are validated once, accessible everywhere thereafter
- Semantic HTML structure choices are made upfront, not retrofitted
- Accessibility tests are integrated into the development cycle, not left to the end of acceptance testing
The economic benefit
The cost of fixing an accessibility defect grows with the number of screens that depend on it. Addressing it at the design system level divides that cost by the number of screens concerned - sometimes by hundreds.
A late-project accessibility audit measures symptoms. An architecture designed for accessibility treats the cause.
Discover my tools

About the author
Delivery Manager based in Rennes, France. I lead digital transformation, SEO/GEO and web accessibility projects for major accounts. This blog reflects what I encounter in the field.