Dodging the "built-in" accessibility trap in Design Systems

In the first part of this series, I shared a guide on how to build a business case that resonates with leaders in data-driven organizations to secure accessibility buy-in. But be warned: victory comes with a risky assumption: Folks might start referring to "out-of-the-box" or "built-in" accessibility in your design system. While it sounds great, this simple statement can unintentionally shift the entire burden of compliance onto the design system team. This isn't just a misunderstanding; it's a trap. And I fell right into it.

When I sold the idea of going through our design system to ensure we were WCAG 2.2 Level AA compliant, it was easier for senior leadership to associate the effort with a term such as delivering "out-of-the-box" accessibility in the system. I didn't push back much because, in essence, it was true. Delivering accessible components would drastically reduce both the risk of introducing bugs and the effort needed by product teams to ship accessible digital products. But that also meant that the responsibility of being accessible compliant before the European Accessibility Act (EAA) deadline fell on the design system team. Learn from my mistakes, reader friend!

This trap notion really resonated with me while listening to a discussion on the Design Systems in Depth podcast by Elise Holladay.

The "Built-in" Myth: A Shared Misunderstanding

Design systems can absolutely help you deliver more inclusive experiences. If the input field in your system is accessible, the 100x input instances in your digital product will also be automatically accessible, provided that they are indeed coming from your system. Right?

But, Design Systems are no silver bullet. Mainly because the context of your organization's domain and your specific user flows, for which product teams are ultimately responsible, should be factored in. The focus order of those input fields might not match the visual layout on one screen, making it impossible for assistive technology devices to properly guide users with visual impairments, and hence, delivering a poor accessible user experience.

"Out-of-the-box" accessibility can be interpreted as: "As long as teams are adopting the DS, and since it has built-in a11y, the job is done! We are 100% compliant because the system itself is 100% accessible."

But this is far from the truth. Let's break it down.

Having a system that is 100% accessible is unattainable; the system itself will never be "done". Your DS is a living product that needs to evolve organically alongside your organization's needs. Your internal and external customer problems will change over time, and part of that evolution is adapting and responding promptly to those needs. You are responsible for putting guardrails in place to ensure accessibility is considered whenever a change is made to your system. But as new conformance laws come into effect, your design system infrastructure would need to be extremely efficient to respond to those changes on time and remain fully accessible.

Has the organization fully embraced and adopted your system? How do you define adoption? You'd be surprised at how everyone has a different understanding of this metric. I'll dive deeper into this in the future (subscribe to learn more when it comes out!), but for now, let's agree that consumers will deviate from the system, and that's okay, because they need room to experiment and play around with UI patterns not currently supported by your DS. This puts the responsibility back on those experimenters to ensure the delivery of inclusive experiences.

And finally, if an audit shows accessibility bugs, chances are some of them are specific to product feature team domains. Making a platform team responsible for bug fixing without proper context is expensive and inefficient due to the time spent trying to understand said context. And, it could have a significant impact on other key business metrics. I've seen critical bugs being caused unintentionally by "minor" UI improvements, resulting in a loss of revenue during downtime.

A New Narrative: From "Built-in" to "Accessibility as a Partnership"

Let's change the way in which we talk about accessibility from a binary setting to a scale. A design system that supports accessibility will help make digital products more accessible; however, it will not guarantee 100% accessibility compliance. This is a joint effort by everyone involved in Product Development, an effort that your design system can facilitate and amplify.

Even if your design system is widely used and loved by your internal users, there's still some work to be done on their end. You could clearly state in your documentation an SLA (Service Level Agreement) around accessibility with the following:

Use any opportunity you have to educate and set expectations: Your design system's newsletter, your Slack channels, office hours, product demos, planning meetings, PRDs, or WBDs, you name it. Your DS will make the right way the easy way, but not the only way to deliver accessibility.

Design Systems teams already have a lot on their plate, and many of them are understaffed. Overselling makes you the one to blame in case of an accessibility problem, throwing curveballs at your planned roadmap, and undermining the work your team is already delivering.

Dodging the "built-in" accessibility trap isn't about deflecting responsibility. It's about defining it. By shifting the conversation from the myth of a 'plug-and-play' solution to the reality of a powerful partnership, you empower your entire organization. Your design system becomes what it was always meant to be: not a magic wand for compliance, but a powerful engine that accelerates the delivery of inclusive, accessible experiences at scale.

This is how you build a sustainable culture of accessibility, one where ownership is clear, collaboration is key, and product teams are equipped for success.

Now that we've established the "why" and "how" to frame the conversation around the investment in accessibility. In part 3, I will close with a look into the future of the "what" in the democratization of inclusive user experiences with the introduction of agentic AI.

Mentioned in this Article

The concept of the "built-in" accessibility trap was inspired by the conversation between Elyse Holladay and Daniel Henderson-Ede in this episode of Design Systems in Depth. A highly recommended listen after you've finished here!