The flaws of the “accessibility is built in to the design system” argument, with Daniel Henderson-Ede

Author

Elyse Holladay
April 07, 2025 • time to read: ~6 minutes

Read on for a peek into the episode.

Daniel Henderson-Ede joins Elyse to unpack a spicy myth in design systems: that accessibility can be fully "built-in." Daniel explains the common pitfalls of overselling accessibility, how teams often mistakenly assume the system handles everything, and why simply relying on components isn't enough. They dive into common accessibility missteps by product teams, the crucial role of documentation and annotations, and why contextual examples beat abstract guidelines every time. Plus, Daniel shares his Systems-Accessibility Ownership Matrix with us.

p.s. speaking of accessibility, did you know that On Theme provides transcripts for every episode? You can follow along in real-time on Apple Podcasts as you listen!

💖 On Theme is a brand new podcast, so if you like what you're hearing, please hit subscribe on your favorite podcast platform, leave a rating or review, or share the show with someone! I love hearing your thoughts and questions, so to text the show or message me on LinkedIn and let me know what you think!

Elyse:

What do you think are some ways that design system teams specifically can sell accessibility as part of the design system, or talk about accessibility as part of the design system, in a way that's more accurate, that doesn't give this idea that it's just going to be handled for you?

Daniel:

I think always talking about it as a scale is an important thing to do, right? Say, we're going to help make your product more accessible. Just like we say we're going to make it more consistent, or less defects, not no defects, right? I think using the slight change in words helps you realize, it's better than it was, it's not perfect.

Another thing that we can do is make it clear what is part of a component, what you still need to decide as a consumer.

In the past I've created a matrix, which has like, things the design system is responsible for, things you as a consumer is responsible for. There'll be things like color contrast inside the component, tick for the design system. It's responsible for that. Using the components in the right place, not the design systems fault, your responsibility.

And having that clear almost like an SLA, like, here's what we're responsible for, here's what you're responsible for. And that way you can just point to that and say, here's some examples. Here's kind of what you agreed when you signed up. Make that part of your onboarding documentation or something. That's been really helpful.

I also found that providing accessibility annotations has been immensely helpful at a component level about what is and isn't included. And just again, writing the content in a way where it backs up that idea of, only some accessibility is built in, and you still have to do some work.

Elyse:

What are some of the things that you would be annotating at a component level, like within the design system?

Daniel:

So for example, anything that you can't visually see, but is part of the component. So for example, if you have a modal, I would annotate the close button in a modal, it's just like an X icon, I would annotate what the accessible name is, or the alt text of the image. And that way it's in the documentation that this is always in every situation, every instance, going to be close.

Elyse:

That's a great example of a smart default, like you were talking about earlier. Like the component can provide that, unless you provide something else. And that's, A) a smart default, but B) also documenting that there is a smart default, and that is something that you can actually change and should think about, if you need that close button to do something different.

🎨🎟️ Into Design Systems is May 25-28. Get your ticket at intodesignsystems.com/ontheme

Into Design Systems is back with their annual virtual conference, May 28-30, 2025. Get your ticket now for three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. Get your ticket and support the podcast by supporting our generous sponsor!

See you next episode!,

Reply

or to participate.