The Promise of Built-In Accessibility
Design systems are often promoted with the promise of built-in accessibility. That promise plays a major role in driving adoption, especially among product teams eager to ship faster and more inclusively.
But that promise comes with a cost.
When teams don’t fully understand accessibility, what it includes, what it impacts, and who holds responsibility, they also tend to misunderstand how we even make it happen.
This can lead to risky assumptions, like believing accessibility has already been handled by the system or that no additional work is needed.
Introducing the Systems-Accessibility Ownership Matrix
I’ll be talking more about this soon on Elyse Holladay’s On Theme podcast. But one idea from our conversation deserves a written deep dive: the Accessibility Ownership Matrix I created while working at CVS Health.
This matrix is not a service agreement (although you could make it into one if that fits your organization’s culture). It is a simple but powerful tool that makes it clear who is responsible for accessibility work at different stages of the product lifecycle, and when that responsibility kicks in.
Trust Is Easy to Break
The matrix becomes especially important when working with designers, engineers, or product managers who were led to believe that accessibility is already taken care of.
That belief may not reflect your team’s actual messaging, but it is often what stakeholders walk away with.
Addressing that misunderstanding takes care. Accessibility advocates and design system teams often share the same goals, but operate under different expectations.
If you push back too hard or too quickly, you risk damaging trust in the system. And trust is fragile. It takes years to build and only moments to lose.
A Tool for Clarity, Not Blame
That’s why we need tools like this matrix. It helps clarify responsibility without blame. It protects the design system’s reputation while helping teams understand what it really takes to deliver accessible products.
You can include this matrix in onboarding, training, stakeholder presentations, or accessibility office hours. It is straightforward and flexible.
But most of all, it is needed.
Systems-Accessibility Ownership Matrix
Every design system is structured differently and sits at a different stage of maturity. Feel free to adapt this matrix to reflect the setup, responsibilities, and expectations within your own organization.
| Responsibility Area | Design System Team | Product Team |
|---|---|---|
| Subatomic Accessibility |  Creates design tokens and guidelines that promote accessibility | Uses design tokens correctly and avoids custom styles where possible |
| Component Accessibility | Builds and maintains accessible components and related guidelines | Implements components as intended and avoids unnecessary overrides |
| Pattern Accessibility | Provides accessible design patterns with working examples | Applies patterns as intended and supports their accessibility goals |
| Page Accessibility | Not applicable | Ensures full-page layout and flow meet accessibility requirements |
| Content and Copy | Provides examples and guidance for clear, accessible content | Writes descriptive, accessible content and interface copy |
| Alt Text | Includes alt text for icons and images built into components | Writes alt text for product-level images, logos, and icons |
| Keyboard and Focus Management | Ensures components follow standard keyboard interaction and focus behavior | Maintains accessible keyboard flows and manages focus across components |
| Testing and QA | Recommends tools and defines accessibility testing strategies | Conducts product-level accessibility testing before release |
| Education and Support | Partners with accessibility teams to create training and documentation | Attends accessibility trainings and stays current with system updates |
Scaling Accessibility Starts with Clarity
Accessibility is everyone’s responsibility, but without clear roles, that responsibility gets blurred, delayed, or ignored.
This matrix doesn’t solve accessibility. But it does create alignment. It gives teams a shared reference point. And it helps avoid the finger-pointing that happens when expectations are unclear and outcomes fall short.
As design systems mature, and as accessibility becomes more central to how we work, tools like this are no longer optional. They’re how we scale clarity, not just components.
If this matrix is helpful to your team, or if you’ve created something similar, I’d love to hear from you at daniel@mantisandco.com.
