There's a question that shows up, far too often, near the end of a project: "Have we checked the accessibility stuff yet?" The phrasing says everything. "The accessibility stuff" — as if it were a last-minute checklist item, a compliance formality before shipping, something that runs parallel to the real product.
That question, and the timing of it, is a symptom of a structural misunderstanding with very concrete consequences: accumulated technical debt, expensive redesigns, broken flows for millions of users and, in regulated industries, legal exposure. It's not a lack of good intentions. It's a mental model problem — accessibility is treated as a feature when it is, in fact, infrastructure.
And the difference between the two is not semantic. A feature can be added later. Infrastructure, if it isn't there from the start, forces you to demolish before you can rebuild.
Accessibility treated as a feature shows up at the end, gets audited once, and disappears by the next sprint.
Accessibility as infrastructure is baked into tokens, components, and acceptance criteria from day one.
The cost of retrofitting it is not linear — in complex systems, it multiplies with every layer built on top.
The Problem: Why the Industry Has Been Thinking About This Wrong
The standard story in product teams goes like this: there's a design sprint, a development sprint, testing, and at some point someone remembers WCAG exists. An automated audit tool is run, the most obvious contrast and alt text errors get fixed, and the ticket gets closed with "accessibility: done." What that automated tool doesn't catch, in the best case, is around 70% of real problems.
The root cause is conceptual. When teams talk about accessibility, they tend to think of severe visual impairments — blind users with screen readers — as if it were a small niche. The numbers tell a different story. Over 15% of the world's population lives with some form of disability, according to the WHO. But if you expand the frame to situational impairments — one hand occupied, screen in direct sunlight, slow connection, cognitive stress — the percentage of users who benefit from accessible design approaches 100%.
Properly understood, accessibility is not an edge case. It's the general case.
Designing for constraint is not designing for the exception. It's designing better for everyone.
The deeper problem is that teams that do want to take it seriously don't know where it belongs organizationally. Is it design's responsibility? Development's? QA's? This ownership ambiguity means it ends up belonging to nobody. And when ownership is diffuse, accessibility always loses to the next roadmap feature.
Infrastructure: What Changes When You Build From There
Calling accessibility an "operational capability" — as increasingly mature teams do — is not motivational rebranding. It has concrete technical and organizational implications. It means accessibility is managed the way you manage security, performance, or observability: not as a user story someone writes when it's convenient, but as a quality layer the system has to maintain on every release.
Inside the design system
If you have a design system — and if you don't, that's a separate conversation worth having — accessibility has to live in base components, not in final screens. A button with correct contrast ratios, visible focus states and ARIA roles defined at the token level is accessibility that scales automatically to every screen that uses it. A button that gets "fixed" on the checkout screen fixes nothing: it leaves the problem latent in the other 40 screens where that same component appears.
This connects directly to design system maturity. The most rigorous evaluation frameworks — Nielsen Norman Group's six-dimension model among them — always distinguish between systems that document accessibility and systems that enforce it. Documentation without enforcement at component level is noise. What matters is whether WCAG criteria are codified as non-negotiable constraints at the component level, not as recommendations sitting in a Notion page nobody reads.
Inside acceptance criteria
The other critical lever is who defines "done." If the acceptance criteria for a user story don't include accessibility checks, the developer implementing that story has no obligation to consider them. It's not negligence — it's that the work system doesn't ask for it. Adding criteria like "the component is keyboard-navigable," "contrast ratio exceeds 4.5:1 for normal text," or "form errors have accessible descriptions" to the Definition of Done changes behavior without needing awareness campaigns. Incentives shift culture faster than workshops do.
Teams that have made this change — Shopify with Polaris, GOV.UK with its Design System — report a sharp reduction in accessibility bugs caught in late stages. Not because the team became more virtuous, but because the problem is intercepted earlier, when it costs infinitely less to fix.
The Real Cost: An Arithmetic Nobody Does Honestly
There's a reason business teams don't prioritize accessibility: nobody has presented the numbers honestly. The conversation stays at "it's the right thing to do" and "social impact," which are valid arguments but don't win prioritization debates against a feature promising conversion. What wins those debates is showing the cost of not doing it.
The general rule in software engineering — popularized through the concept of technical debt cost — holds that fixing a bug in production costs between 10 and 100 times more than catching it in design. With accessibility, the scale is, if anything, worse: a critical inaccessible flow discovered six months after launch can mean redesigning the navigation system, migrating color tokens across the entire system, revising HTML semantic hierarchy and retesting every affected screen.
In regulated sectors — banking, healthcare, public administration — legal exposure adds another dimension. The European Accessibility Act came into force with concrete obligations for the private sector in June 2025. Companies that haven't embedded accessibility as a process are going to find themselves doing emergency audits and expensive retrofits instead of having built correctly from the start.
The business case for accessibility isn't altruism. It's not paying three times for the same problem.
There's also an opportunity cost that gets systematically ignored. An inaccessible product excludes active users with purchasing power. More than 22% of the working-age population in Europe has some form of recognized disability. How many of those users are trying to use your product today and abandoning it due to avoidable friction is a metric almost no team measures — because measuring it first requires admitting the problem exists.
What It Looks Like in Practice: Three Surgical Changes
Converting accessibility into infrastructure doesn't require stopping the roadmap or an eighteen-month transformation project. It requires three process changes that, applied consistently, completely reposition how the team manages quality.
The first is what we've already mentioned: accessibility in the Definition of Done. Not as a footnote, but as a blocking criterion just like a failing regression test. The second is auditing base components, not screens. If you have a component system, prioritize getting the ten or fifteen most-used components — button, input, modal, navigation, error form — through a real audit with a screen reader, not just an automated tool. The surface impact is disproportionate to the effort.
The third, and perhaps the most underestimated, is including real users with disabilities in research processes. Not in a one-off session for "the accessibility sprint," but consistently. Good user research — the kind that doesn't become a dead deliverable — has to include the real diversity of who uses the product. Without that, you're designing for an imaginary user who always has both hands free, a perfect screen, and zero cognitive stress. That user doesn't exist.
These three changes are not the ceiling. They're the floor. From there, accessibility starts behaving like what it is: a property of the system, not a pending user story.
If your team is at the point of building or refactoring a design system, or if accessibility has been sitting in retrospective debt for months without anyone knowing how to tackle it, that's exactly the kind of conversation we have regularly at Room 714. Not to run a checklist audit, but to understand where the highest-leverage point is and how to integrate it without stopping what already works. The most common mistake isn't a lack of desire to improve — it's optimizing what doesn't move the needle while the real infrastructure stays cracked.
