There's a pattern we see in almost every product audit we run at Room 714. The team has a design system. They have tokens. They have components with elegant names. And buried somewhere in Jira or Notion, there's a column called "accessibility" with tickets that haven't moved in months.
This isn't negligence. It's a direct consequence of how accessibility has been sold for years: as a final layer, a compliance checklist, something to "fix before launch." The problem is that layer never quite arrives. And when it does, it arrives as a patch.
The real tension isn't technical. It's a mental model problem. As long as teams treat accessibility as an optional feature rather than a structural contract, every new component they build accumulates silent debt — the same kind as technical debt, but with consequences that never show up in error logs.
SVG icons without labels,
.activestates that communicate nothing to screen readers, and contrast ratios that "almost" pass WCAG are all symptoms of the same underlying issue.A design system without accessibility baked into its core isn't a system — it's a component library with an expiration date.
The solution isn't an accessibility sprint. It's rethinking which layer of the design architecture owns these decisions.
The Symptom: Layers That Don't Talk to Each Other
When we dissect a design system with "accessibility problems," we rarely find deliberate negligence. We find disconnected layers. The design team defines color in Figma with a trained eye. Development implements it in the token. QA checks it visually. Nobody, at any of those steps, has run a real screen reader over the component.
The result is predictable: a button that looks accessible has a contrast ratio of 3.8:1 instead of the required 4.5:1 for normal text. A close icon in a modal has an <svg> with no aria-label or title. An error state in a form uses only red as its signal — invisible to the 8% of men with color blindness. None of this surfaces in the "component ready for production" ticket.
This has a precise name: accumulated accessibility debt. It works exactly like technical debt — it grows with interest, becomes more expensive to settle the longer it sits, and at some point collapses into an urgent redesign or, worse, a legal claim in markets with active legislation (the European Accessibility Act has already started to have real consequences for digital products).
There's also a cognitive problem that's hard to solve from the inside: the team building the product knows too much. They know that icon means "close" because they designed it. A screen reader user arrives at that same point without that map. This connects directly to what Nielsen Norman Group has documented on dogfooding: using your own product internally helps catch bugs, but it can never substitute for someone who arrives without the context.
The Origin: Where Design Systems Break Down
Modern design systems have achieved remarkable things: visual consistency at scale, faster prototyping, a shared language between design and development. But most have optimized for what can be seen on screen and in Storybook. Accessibility — which largely operates in what can't be seen — has been left as an afterthought.
The failure has three common origin points:
1. Color tokens don't include the accessibility semantic layer
A token called color-primary-500 describes a hex value. It says nothing about whether that value meets WCAG 2.1 AA contrast requirements against light backgrounds, dark backgrounds, or in a disabled state. For a token to be useful from an accessibility standpoint, it needs semantic metadata: against which backgrounds can it be used? Does it meet AA? AAA? At what text size?
Systems like IBM Carbon or Adobe Spectrum have baked this logic in for years. Most mid-market design systems haven't — because nobody put it in the definition of "complete token."
2. Components are tested visually, not functionally
Standard QA flow for a UI component is visual: "does it look right on mobile, tablet, and desktop?" Sometimes it includes a responsiveness check. It rarely includes navigating the component with keyboard only, activating VoiceOver or NVDA, or validating that the DOM accessibility tree reflects the correct semantic state.
This isn't about adding four more tests per component. It's about defining those tests as acceptance criteria before the ticket moves to "done." If the criterion doesn't exist, the component never fails — even if it's broken for a meaningful percentage of users.
3. Accessibility is delegated to the end of the chain
In many teams, "accessibility" is the last review before launch, performed by someone who had no part in the design decisions. This role, however well-intentioned, is structurally doomed to patching: it arrives when the component is already built, integrated, and sometimes in staging. Changing the semantics of a component at that point has a real cost in development time.
The security analogy is apt here. No reasonable product team leaves security to the final QA sprint. It's thought about from the architecture up. Accessibility deserves the same treatment — and it's starting to get it in mature teams, though it remains the exception.
A design system without accessibility at its core isn't a design infrastructure. It's a component library with deferred debt.
The Strategy: Four Layers to Integrate, Not Patch
The good news is the problem has a structural solution. It doesn't require a dedicated accessibility team (though that helps). It requires inserting the right decisions at the right layer of the process. Here's the model we apply at Room 714 when auditing or redesigning design systems with this problem.
As we argued when writing about accessibility as infrastructure rather than a feature, the mindset shift has to precede the process change. Without that first step, any technical strategy remains cosmetic.
Layer 1: Decisions at the token level
The token is the lowest and most powerful level of the system. If accessibility doesn't enter here, everything built on top starts with inherited debt. Color tokens must be validated against WCAG ratios at the moment of definition. Typography tokens must include minimum sizes for readable text. Spacing tokens must guarantee minimum touch targets (44x44px per Apple and Google guidelines) for interactive components. This isn't extra work. It's adding one more column to the token table that already exists.
Layer 2: Acceptance criteria at the component level
Each system component needs, alongside its visual variants, an explicit "accessibility criteria" section: documented keyboard navigation, required ARIA roles, semantic states (focus, error, disabled) with their expected implementation, and screen reader test cases. This can be integrated into Storybook as an accessibility addon (axe-core is available natively) or as part of the library documentation.
Layer 3: Automated testing in CI/CD
Axe, Lighthouse, or Pa11y can run in the CI pipeline and block a merge if they detect critical accessibility violations. This doesn't cover 100% of real problems — automated tests catch roughly 30-40% of actual accessibility issues — but it covers the most frequent and avoidable cases: empty alt attributes, insufficient contrast, forms without associated labels.
Layer 4: Manual testing with real users
This is the layer that's most uncomfortable because it has a real cost and can't be automated. But it's also the only one that catches what no tool can: whether the complete experience of a flow — not an isolated component, but the registration, purchase, or onboarding flow — is navigable and understandable with a screen reader or keyboard alone. Connecting with disability organizations to participate in testing sessions is not utopian; it's something teams like Microsoft and the BBC have normalized for years.
The question isn't whether your team can afford it. It's how much it will cost you not to have done it when the European Accessibility Act starts being enforced in your sector.
The Business Case: Accessibility as Economic Argument, Not Just Ethics
The moral argument for accessibility is sufficient. But in product decisions at mid-market companies, the economic argument is what moves budget.
First, the ignored market. People with some form of disability represent 15-20% of the world's population according to the WHO. In Europe, that's over 100 million people. A product that isn't accessible is actively excluding that segment — not by strategic decision, but by omission.
Second, the umbrella effect. Well-implemented accessibility improves the experience for all users, not just those with a permanent disability. Subtitles created for deaf users get used by everyone in noisy environments. High contrast works better in direct sunlight. Generous touch targets reduce form errors for any finger on any phone. This is what designers call the "curb cut effect": the ramp built for wheelchairs is also used by cyclists, people with strollers, and delivery workers.
Third, the incoming legal cost. The European Accessibility Act (EAA) came into force on June 28, 2025 for most digital products and services in the EU. This isn't a recommendation. It's a legal obligation with enforcement capacity. The cost of adapting now, from the design system level, is a fraction of the cost of doing it under regulatory pressure or after a complaint.
If your company operates in the European market and your digital product isn't at WCAG 2.1 AA level, you already have a compliance problem. The good news is that fixing it from the design system — before it escalates — is still manageable. This connects to something we've seen repeatedly: as we noted when examining experiences that are technically correct but experientially broken, the gap between "works in QA" and "works for real users" is where the most expensive problems hide.
Accessibility isn't the coat of paint you apply at the end. It's the material the wall is made of.
We've seen teams freeze a product launch after catching these gaps too late. And we've seen others that, with a two-week audit of their design system, closed 80% of the most critical vulnerabilities before reaching that point. The difference isn't team size or budget — it's when the decision gets made.
If you want to understand which layer holds your biggest accessibility debt — and what would change in your design system to resolve it structurally — that's exactly the kind of conversation we like having. The diagnosis is usually faster than expected. So is the savings.
