On Theme: Design Systems in Depth

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

• Elyse Holladay • Season 1 • Episode 12

Share episode

📲 Text the show your thoughts!

💖 On Theme is a brand new podcast, so if you like what you're hearing, please hit subscribe and sign up at designsystemsontheme.com!


Links & References


🎨🎟️ 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. 

Daniel Henderson-Ede:

But I've had so many conversations now, from designers to engineers to product managers, who don't understand why, when an accessibility professional or an audit comes back and identifies issues, they then blame the design system for the accessibility issues they caused. We actually end up undermining the design system because we've oversold what it can do.

Elyse:

This is On Theme, Design Systems in Depth, and I'm Elyse Holladay. Together, we'll be exploring how successful design systems get built, maintained, and deliver impact. Design systems is due for a major reinvention moment, and I want to share what's working from design system practitioners out there forging the way. As you listen, text the show with your thoughts, aha moments, and questions by clicking the text link in the show notes. Before we begin, a quick thank you and word from our generous sponsor, Into Design Systems. Into Design Systems is back with their annual virtual conference, May 28 30, 2025. Visit intodesignsystems. com slash ontheme to get your ticket to 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 at intodesignsystems. com slash on theme, and I'll see you at the conference in May. All right, let's dive into the show. Today on the show, our guest is Daniel Henderson Ede. He is the head of Design Technology and Systems at Mantis Co, and he specializes in accessible, scalable design systems, and has helped shape industry leading systems, including Pinterest Gestalt and CVS Health Design System. He's the creator of a popular accessibility annotation kit on Figma, which has been adopted by companies like GitHub. You'll also have seen him sharing his insights on accessibility and design systems at Axe Con, CSUN and Figma webinars. Daniel, I think, is one of the leading voices for accessibility and design systems, and I'm super excited to have him on the show today. Daniel, thank you.

Daniel Henderson-Ede:

Hey, great to be here. Looking forward to it.

Elyse:

I am too, and I'm really interested in our topic today. This one's kind of new to me and I'm interested, like, I want to hear what you have to say. Because we're going to talk about the pros and cons of selling a design system with accessibility in. And, Daniel, I think you have some takes on why there's maybe some more cons than pros. And I can't wait to hear, because I feel like we all do this, like, oh, the design system is going to be accessible and therefore your product is going to be accessible. It's like a huge selling point of design systems. So Daniel, let's get into it. Talk to us about this built in accessibility illusion that you're calling it. what is it? And what's the problem?

Daniel Henderson-Ede:

Every design system that I seem to talk to, they keep on advertising it to their consumers as accessibility is built in. And it's something you hear over and over again. I don't know where this term came from. But it's something that we do to sell the design system as part of the, hey, if you adopt this, you'll make your product more accessible. And I couldn't agree more. Built in accessibility into the design system seems to be the only scalable way to do accessibility consistently across an organization. And so there's no doubt about that. The problem I have specifically really is the term built in accessibility. We keep on saying it. We've not really thought about the effects of that advertising and that slogan or whatever we want to call it. Because there's two main problems with it. A, we say built in, and that itself sounds like it's binary, like it's, it's a hundred percent built in, right? Everything we need to do is in there. Which is false. And then, accessibility is a scale. There's no state of accessible and unaccessible. It's a scale that gets better and better and better. And so we're saying something is a hundred percent there, and a hundred percent accessible. When really, some of it's there and it's a kind of accessible. And that's really the reality of our design system.

Elyse:

Yeah, absolutely. I think there's no denying that if your design system components are accessible within the scope of how accessible they could be, and you use those components all over your product, you have a exponential effect of that accessibility across your product. Obviously, if you have 1000 inputs and they're all completely inaccessible, you have a much worse product in terms of accessibility, than if you have a thousand inputs and they are all accessible and have the right labels and, you know, all of that stuff. There's no denying that that's the case, but it sounds like, you're more frustrated with the, kind of cultural or organizational impact. Is that right?

Daniel Henderson-Ede:

Yeah, it's definitely the sales pitch and the way that we haven't found a way to change it. I think it's a great sales pitch. Design systems, especially organizations that are older and have been through several systems, struggle with building that trust. And I, I started off myself with the built in accessibility pitch. I was, I'm one of the problems. But I've had so many conversations now, from designers to engineers to product managers, who don't understand why, when an accessibility professional or an audit comes back and identifies issues, they then blame the design system for the accessibility issues they caused. We actually end up undermining the design system because we've oversold what it can do. And then people are frustrated that they think someone else has to solve the problem. And you actually have to, you have to have this polite conversation, actually, no, the design system's done its job. You are the problem, right? You can't say, obviously, you are the problem! But you have, you have to then try and change the view of who's at fault and, and how are you going to help them? And it's a very difficult conversation. And how do we maybe just be more transparent in the sales pitch at the start? We wouldn't have had all these accessibility issues and almost carelessness of using the design system, that actually causes some issues, had we just had a proper conversation about how to develop X thing that we're building.

Elyse:

Yeah, this sounds a lot like the, the design system is a hundred percent of our front end code, problem. And I, and I think this, again, this theme of like overselling it. And I wonder, how do we talk about this a more accurate way? Because I think in a lot of cases, in some cases we've been the ones saying, yes, it's going to do everything for you. But in a lot of cases, I think what we've done is, sloppy and inaccurate selling. We're like, oh, it's going to make all of our UI consistent. What leadership hears is, 100 percent of our UI. Because we didn't do a good job of being very clear about that. What are some of the ways that you see product teams not doing accessibility well, when they don't understand what the design system can and can't bring them in terms of accessibility? Like, can you give us some examples, either some specific accessibility things or some processes or practices, that they kind of either don't do or ignore.

Daniel Henderson-Ede:

The end accessibility of a product can change depending on so many different factors, like the content you're putting in a component, the context of the component is used, the user flow itself. All of those things dramatically change the experience for a person with a disability. There's obviously the fundamental cultural issue of teams not understanding accessibility, regardless of the design system's there or not. Understanding why accessibility is important, how people with disabilities use the internet, always seems to be a common factor with those teams. But then you lay it on the design system, where they've been oversold, or they've just not understood the pitch, right? You brought up a good point maybe about leaders, they hear what they want to hear, rather than what you're saying. Yeah. We see a lot in components that are very composable— so card is a great example of something that's very composable. I've seen several cards now come through defects where there is links in the card or some, some other elements, images is a big one where there's no alt text on the image. And there's this conversation of, why is this image failed alt text? I'm like, you put the image there!

Elyse:

Yes, that design system feature that automatically understands whatever image you might possibly use here, and magically generates alt text for it. Ah, I forgot about that!

Daniel Henderson-Ede:

Yeah, I find it tough as, as someone who deeply understands how everything works on the accessibility side, why someone can come to that conclusion. And I always comes back to me as well, we told them it would be accessible. But the design systems involved, some people then blame the design system for not providing that result that they wanted.

Elyse:

I understand it too, because you have this internal tool that you think is going to take away a, I'm going to say, what seems like an incomprehensible problem, for a lot of teams and a lot of designers and engineers. You mentioned a few minutes ago, like those teams not really understanding accessibility and, you know, really the best way to understand what it is like to use the internet with a disability, is to try to use the internet that way. And that's not something that I think we tend to do as part of our software development training. We often get taught about accessibility in this way, that's very academic. But there's nothing, there's nothing like trying to navigate through a website to do a task, with your eyes closed. It gives you a whole different level of understanding of, what might it be like to try to navigate the internet if you are blind. That's just not something that I have really ever seen any company do, not even the ones that care about accessibility. And so I completely understand why any given engineer on any given product team will be like, I, I don't know how to do this right. I'm sure there are organizations that are genuinely shitty, but my experience has mostly been that, teams do care, they want to care, they want to do the right thing. And it just feels like this incredibly complicated, hard to understand problem. I understand why the WCAG docs are written the way that they are, but if you're just, again, any given engineer on any given product team, and you're like, oh, I'm going to try to check and see if this thing that I've been making is accessible, and you go read the WCAG docs and you're like, there's not a single straight answer in here about what I should be doing. And then this relief that the design system can come and say, yeah, but if you use this, it's going to be accessible. And so from that level, I completely understand why a team would be like, oh, but I thought that this was going to help me do this accessibility thing.

Daniel Henderson-Ede:

Yeah, and I totally get your point about it feeling very academic. I actually spent a little bit of time in the Accessibility Guidelines Working Group on behalf of CVS, to try and influence the next version of WCAG, which 3. 0, whenever that comes out, you know, 5 10 years, we don't know yet. I think it's a fabulous group and the things they're doing are very important, but me, myself have been doing accessibility for a while, I felt out of place. And it was cause it wasn't how I thought. And I can see how, you know, as many as an engineer myself and how other engineers work, they probably feel the same way. And so that's why I always focus on like, understanding what a person with a disability needs, and how the platform I'm building on works. Like they're the two most important things. Don't worry about WCAG, understand those two things. And, and conformance to that comes almost naturally, because you're thinking about, hey, what the human need is, here's how I build the thing. And you'll find out that you end up ticking off those boxes without even realizing it. And I think the design system can become a translation layer between the core requirements and you as a designer, you as an engineer, consuming the system. Here's the things that you need to worry about when consuming this component, and if you follow these human readable guidelines of how to use the component, you end up getting WCAG conformance closer for free.

Elyse:

Yeah,

Daniel Henderson-Ede:

That's, I think it's a delicate conversation.

Elyse:

No, I love that. And I think you're right. And I think that's the way that the design system can, up to a point, provide accessibility because just using your very simple alt text example, if you have these guidelines in your card component, and you're like, if you provide an image like this, you need alt text. If you're going to provide an image like that, that's just, what's the word my brain is trying to come up with?

Daniel Henderson-Ede:

Decorative.

Elyse:

Decorative. Thank you. My brain was trying to say visual. If you, if you're going to put an image that's a visual, yeah, no shit. But if you're going to put an image that's decorative and you don't need alt text, there's an instruction that's like, leave the alt text blank. That's very, very straightforward, and you don't have to explain all the ins and outs of why that is. But I'm curious about the situations where the product being accessible goes beyond what the design system can help with. We just did an audit at Color last year. We worked with Homer Gaines, who was amazing. And we, I would say the majority, maybe 95 percent of the defects we got back, which I'm proud to say were not very many, because prior to my tenure at Color, we had a really really phenomenal team, with some real accessibility experts that did a lot for what was already in the system. but I digress. The things that we did get back were primarily on product pages, and it was how the whole page fit together. A really simple example would just be like, the semantic headers are out of order. Which is a really easy example to understand, because the design system doesn't provide the page. It provides bits of the page that you can use to build the page. And so then when an engineer goes and builds the page, or more realistically, the page is already built, and the engineer goes and adds some stuff or changes stuff. And they make some changes here, but that interacts with the whole page. And now you've moved some semantic headers out of order. Now suddenly the page has defects. But that just feels so removed from the work that the engineer was doing on that one little section, and so far removed from the design system. How are you talking to teams about thinking about accessibility at that level? Because that I think is where most of the problems really arise.

Daniel Henderson-Ede:

You just asked the question, how do you fix all accessibility issues? Essentially. And there's entire teams and full time jobs there, and we know we still haven't answered the question. And so I think, as a design system practitioner, that's not the question you should be asking yourself. It comes down to cultural factors, like where you grew up, like, did you have people with disabilities around you as, as a kid? And then as an adult? Like that affects how you do your job and how you understand what the needs are for a user when you're building or designing something. It's a question that we will never answer, but I think the closer design systems and accessibility teams work together, is very important to solving that. There's quite a few teams now I'm noticing where the organizational structure is where the design system and the accessibility team sit in the same sort of foundations department. And I think that's a really great step, and accessibility teams are starting to realize that design system actually is a key pillar in the success of what the accessibility team is trying to do. And so as a design system practitioner, the more you can collaborate with your accessibility people and say, don't ask the question, how do I make this component accessible? I mean, you're already asking that question, right? So I'm not saying take it away, but ask other questions like, Hey, what is the biggest priority for your accessibility team right now? Let me work out how I can do that in my design system. Is there a way I can get you closer to that goal, right? But again, you start to answer those questions maybe, Elyse, that you're asking, is, how do you make stuff accessible beyond the design system?

Elyse:

Yeah, I feel schooled. I love what you said a few minutes ago about, if you just think about what is it that somebody might need, you kind of naturally build things in an accessible way. And if you try to go through your product with a screen reader or with a keyboard, you suddenly are like, oh, that didn't make any sense. Or like, what the hell just happened? Or why can't I get to the submit button? And it's so obvious, that it's not accessible. And obviously that's really low hanging fruit. That's not like top tier, making things incredible. But I think sometimes we don't even do that.

Daniel Henderson-Ede:

We don't. And it's also a good reminder to celebrate the small wins. I think the culture of accessibility is often the point where you're either 100 percent compliant or you're doing a bad job, right? And there's an aspect to that of, if, if it's not 100 percent conformance WCAG, there's probably going to be a barrier there for a person with a disability. There's no doubt about it. That's why the requirements are there. But I do think we should celebrate progress. And people, as you say, there's lots of people who care about accessibility and are trying to do good things. And the fact that they've added alt text, when I see that on a team, like, stand up, hands clap, like, that's amazing. Oh, I don't care that the other stuff's not accessible yet. We'll do that another day. The fact you've done this is a step in the right direction. You know, within design systems, like, hey, even if you just adopt one component or just the tokens, like don't put them down because they didn't do the entire system, right? Reward them for the fact they've started to do the right thing.

Elyse:

Yeah, I love that. And that's also a great reminder that this is the, the value of the idea of accessibility being part of the design system. You are already using these building blocks that are getting you so much farther than if you were having to think about all of those things on your own. But what are some of the negative consequences? We touched on this early, like, just assuming that everything is going to be taken care of, like the the card component is going to generate the alt text or something like that. But what are some of the other consequences, especially on the process side, when teams really rely way too much on the design system for accessibility?

Daniel Henderson-Ede:

One of the ways is, if they rely too much on the design system, they're not necessarily understanding some of the reasons why components were built in certain ways. So an example of this is, we had a component, one was called Important Notes, and one was called Alert. Important notes and Alert. Yeah. Important Note was this component, it kind of looked a bit like a banner, where you put it on the page, and it's always there. And it may be like a reminder of something. And it's there on page load, and it's just related to the context you're in. And Alert was this component where, it may show up when you try and submit a form and there's some errors and it pops up and shows you, payment details incorrect, something like that, it was more dynamic. And that distinction of the use case is very important for accessibility. Because an Important Note, it's static on the page and so you may, the semantics of it may just be a div with a H1 or even a strong element, and that's about it. But for this dynamic thing, you have to start to think about, well, how do we announce what happens on the page? Like when it comes up, how do we make sure the user, who isn't able to see the screen, how do they know it's there? Are we shifting focus to it? Are we doing an ARIA live announcement? If we have different variants of this alert, maybe there's a warning or a super danger Alert. Maybe we're using different versions of ARIA live. There's ARIA live assertive, ARIA live polite. So polite does what it says in the name. It sits there on your, on your call stack, and whenever the screen reader's finished speaking, then reads it out. But if you say assertive, it will put off whatever the screen reader is saying and say it straight away, because obviously it's the most important thing for the user at that time. And so when I start to say about like people relying on it too much, if they don't understand maybe why components were built in certain ways, and they're not fully taking in what the use case of a component is. They're looking at, oh, look, this looks good here. They're not fully understanding why the component was built, what it's for, where it should go. You end up with this common experience where, you may set an alert in the page randomly, right? And then you end up messing up with the focus order. Or there's random alerts telling you that, it's your birthday, I don't know, something that doesn't make sense. Because you've just like, you've not read the documentation and the use case of the code that's being built, and the use case of it does not match how you as a consumer put it in your code, thinking it this look good. And there's just, there's no thought into it, because you're just assuming everything's just, it just works. Yeah.

Elyse:

Like no matter what I do, the system will just handle it for me. Another thing that I've seen, when you do have an accessibility team— because a few minutes ago you were saying, oh, work with your accessibility team, talk to them, help them get their goals. But, sometimes we don't have an accessibility team. And that's a whole, that's a whole problem. But one thing that I have seen is when you do have someone, or a team, who is very good at accessibility, they can become like the go to. Like you just, don't have to think about it, because as soon as anything comes up, you can just go ask this person. And so we don't learn anything, because we just have the person. I'm just gonna go ask so and so, and they're going to solve it for me, or tell me the answer, or code it for me, or just fix it for me. How do we actually teach product teams to build this into their workflow? And that's really hard to do, but so important.

Daniel Henderson-Ede:

Yeah, the best learning method for that, is removing the accessibility person from the situation, and seeing what happens when they're not there. I was one of the people at an organization where they came to me for everything, and it meant that people weren't learning. Like I'd been there for a while, and they were still making the same mistakes. I was getting asked the same questions over and over again. It's like, we've talked about this before, why are we having this conversation? And there's a point where you have to kind of— there must be a kind of learning method for this already—but basically let them fail. Most of the times, it was actually me, me watching, observing, stepping in when I saw an issue before it happened. And so they were not only coming to me for all the questions. There were some teams who, they were doing their thing, and waiting for me to step in. Yeah. And so that's, that's even, even more dangerous and so it was at that point, it was like, I actually not going to step in, because you need to learn the hard way that if you don't think about it yourself.

Elyse:

The audit is going to get you. Yeah. It's so interesting that you said learning, because I think when we learn as humans, we have to have a feedback loop. We're doing something, we have to realize right up at the moment, like, oh, that didn't do what I wanted it to. That hurts. Ow, that's hot. And when it comes to accessibility, on the web, you don't see that that doesn't work for a screen reader, or that you can't do that with your keyboard, because you are not trying to use that as a tool. You are using your fully able, keyboard, mouse, shiny Apple monitor, high speed internet, all of this stuff. And so I don't think there is a learning loop, unless we literally take a lot of effort to go out of our way. And for all kinds of reasons, we are often not incentivized to do that work.

Yeah, you just keep asking all the deep dark questions that keep people up at night. Even I find myself skipping over things

Daniel Henderson-Ede:

are accessibility best practice. I'm building a website, I'm doing more than just accessibility, I'm doing branding, security, efficiency, right? And so, it's completely human nature, and dare I say, the right thing to do, to prioritise based on the things that are most important to you, at the time, right? The problem is just that, accessibility often gets pushed down, pushed down, pushed down, and then gets put under the line, right, and then nothing happens. This is where doing little bits of everything is better than focusing on one big area. When I'm putting images in, I do think about alt text, but maybe I don't think about, at the time, adding ARIA attributes when I'm hiding some of list items. Later when I realize, oh, I missed something, I should have done that. That's why I said, don't expect to be perfect. I'm definitely not perfect. And I know that. I know I'm breaking the rules. I go back and fix them later, but at the time, I know there's more important things to do. That's reality. That feedback loop is, I guess we can call it a privilege because not everyone's doing it right now. And the funding required is to be able to give your product to someone with a disability, and and get their feedback. And that's the ultimate feedback loop. When I've shown videos to executive leadership about a person with a disability unable to use our platform, it isn't a money conversation, or a, how would it increase our numbers conversation. Everyone has a heart. Even executives. Showing them a video of someone with a disability use that, actually has worked, and why people talk about empathy a lot and do the whole empathy conversation. Sometimes it can get boring and old, because it loses its value because we talk about it so much. So it's a very important tool that you use at the right time. It does work in those situations.

Elyse:

I think you're not just talking about having empathy in this abstract way, right? Like we should care about people. It's like academic empathy. But when you actually show somebody a video, or sit down with somebody, and you are right there, seeing it happen, you, you don't get to not have empathy. It happens to you. Like, you're watching and you're like, ooh, ooh, cringe, like, oh, that's painful. Like, they can't even fill out this form. Like, oh, it hurts me in my heart. I don't think you can avoid that when you're really confronted with it. So I think that's a really, really powerful tool. And it's not just executives, right? That's every designer and engineer. It's everybody on your team. Again, I know we talked about this a minute ago, but like the best way, if you are trying to get your engineers on your product team to care, sit down with them and turn on the screen reader, and have them go through the thing they made with just their keyboard. Like they will get it real quick if it doesn't work. They will understand. Because the empathy is right there. It's not abstract and academic anymore. It's right here in front of you and, and you can actually do something about it

Daniel Henderson-Ede:

And that's actually one of the ways I approached a delicate conversation with the consumer not thinking about accessibility, let me show you. Let me show you what it does. Let's turn on the screen reader and see. And also look at the other components in our Storybook and see how they do actually have accessible experiences. Because look, in the code, I've added this, I've done this, right? And it clearly says in our docs that you should do this. Oh, actually, my bad, it doesn't say that here in the docs. Let me add it to our docs, because it's probably our fault for not explaining how that works. There's definitely a give and take in that scenario.

Elyse:

For sure. So if we don't think about design systems as guaranteeing accessibility, right? Because we know that they don't, they can't. What role should they play in accessible product development? What else can a design system do to support developers, product designers, in thinking about and understanding accessibility, beyond just what the components will provide.

Daniel Henderson-Ede:

At an atomic level, I feel like smart defaults is something that we should consider. Like, okay, we can't build this thing in because it may change based on context. But is there something that we can put in for now that allows you to override? That's very helpful for inputs. Can we work out maybe what autocomplete attribute should be there, based on the label? That'd be quite an advanced default, but there's maybe some magic you can do there. We started to talk about patterns and pages and kind of the high level components. I think that's a space where it will really help building accessible products, because there'll be real examples of how components fit together with other components. A clear example of the code that has been added, in addition to the design system components, to make an accessible experience. I don't think it will solve the problem. I think it will just get us closer to the solution. And I don't, I don't think we'll ever solve the problem. Because it's, it's never the design system, as you say, it's impossible. The more examples that we can add, I think it's going to go a long way. I see lots of design system libraries or documentation sites where the examples of a component will not be in context. It'll be a component that you're not quite sure how to use, and it's just a picture of the component. But that's not very helpful because I'm not sure where it's meant to go on a page. And so I think the way that examples of patterns and pages will be really helpful. But also sometimes too, we don't even add real content to the example. We need real context. We also need real content. If the design system is a collection of best practices, surely somewhere in the system, there must be a best practice of our component, and is a great example of how it should be used.

Elyse:

On an earlier episode on this podcast, Noelle Lansford was talking about this too, about showing examples in context, showing pages, true usage, and I think we need both. We need, the very, very straightforward example where it's very clear, like what's a prop and what's not and like, what can you change and what can you not change, without getting it confused with a specific use case. But we also need to show the actual way that something is used because that's what helps us understand why I might use something. Like you said, where on a page does this go? Is it a important note or is it an alert? How do we actually show that to the user? How do we actually alert the user? And you can only get that through context. And I'm really interested in showing more contextual examples, because, I know this is such a cliche to say, like, people don't read docs. I don't think it's entirely true. Engineers read the docs, we read the API documentation, all the time. But, It's very easy to gloss over that, to just try to skim to the one thing that you're looking for, and miss other important things. And I think especially with accessibility, when you have your accessibility documentation on like, a separate tab, that you have to like, click into, and it's this very dry, like, accessibility is important for these reasons, and you need to do this, and that, and the other thing, it's so easy to skip that. And so, I really want to see more of that accessibility documentation just snuck into the regular documentation, right? Like, these are the things that you have to do to use this component. Don't forget this, don't forget this, if you put this label, it's going to automatically be the ARIA label, or you can make your own ARIA label, and you are going to want to do that in this situation, right, and you can write that documentation right into the main usage. And even better, then you can show an example. And I'm saying this as if, like, this is not something that I have done a good job of in our doc site, and it's something I'm really, really interested in doing more of, because I think it's so easy to just get kind of swept under the rug, or like, swept into another tab, as it were.

Daniel Henderson-Ede:

That's one of my mini hot takes is, I'm definitely anti accessibility page slash content slash tab. Get rid of it and embed it in. It already is the case, like, the fact that if someone's consuming a component, right? They're already consuming the colors, which you've probably made accessible for color contrast. You're probably using the right semantic marker. So we already have this precedent of embedding accessibility into it just by consuming it, and following the guidelines, you get accessibility. So I think we should make the most of that precedent and do it as much as we can do.

Elyse:

Yeah, definitely. So, to kind of come full circle to our original question about, does the design system have accessibility built in? It sounds like the answer is kind of yes, and. Like, yes, it's going to have accessibility built in, in a lot of ways, but we need to be explaining that differently, talking about that differently, selling that differently. 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 like be handled for you?

Daniel Henderson-Ede:

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. I think people will still hear what they want to hear. But I think it's a step in the right direction. 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, 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? Just out of curiosity.

Daniel Henderson-Ede:

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:

And 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. So, I love that. Well, Daniel, thank you so much for walking us through all of that. So as you know, I ask every person who comes on this podcast to give us a spicy take on design systems. So excited to hear yours. So Daniel, what is it?

Daniel Henderson-Ede:

We shouldn't do accessibility audits on component instances.

Elyse:

Ooh, interesting. Say more.

Daniel Henderson-Ede:

If we sell ourselves as design systems, as reusable components, there is accessibility built into some things. Why do we spend the time and resources to audit every single piece of accessibility when we're using instances of components. Like, for example, if the close button is standardized in our components, and it always has a name, it's always there, it's built correctly. It's already probably being tested at component level. It may be tested a hundred times already, by a hundred different people, why do we waste people's time?

Elyse:

So basically, of course, we're testing the components themselves, like as we build them, or maybe we have AXE tests, whatever, on the components. But if we're going to say when we put this in the design system, it's going to be accessible for you, then we shouldn't need to be testing that part of the like audit of the entire flow. Like we should just assume we know that that's going to be getting the right thing. Is that, did I understand that right?

Daniel Henderson-Ede:

That's right. And whenever I say that, like, it's more nuanced than that for sure. This hot take is definitely unrealistic. But like at a base level, like that's right. Cause as we already said, like context, content is important, and that changes the accessibility. But there are things that are always the same in every component there has to be a way where we can only test the things that need to be tested, to help people be more efficient in the QA stage.

Elyse:

I'm thinking about our product at Color, and so much of it is forms. And I can tell you, on that page what's coming from the system and what's not, and it's 90 percent from the system, and if one of those inputs or radios or checkboxes is not accessible, it's all going to be the same defect on every single one of them. And the parts that aren't, is completely outside of the control of the system. And that's what needs to be tested when we're testing an audit in a flow. So if you figure out a way to do that programmatically, report back because I, I think you're totally right, we can spend a lot of time doing that when we don't necessarily need to.

Daniel Henderson-Ede:

I think we're a long, long way away from getting that. I mean, there's still some instances in our component that aren't being used in the system, and there's still good reason to override things. And so I, I would never want to attempt it anytime soon, because it would undermine all of accessibility testing and the reason why it exists. But one day, I think there's going to be a time where we're able to just escape certain things, because we can rely that the system's done its job and people have used it correctly.

Elyse:

I love that. Well, Daniel, it was a pleasure. I really appreciate your expertise and your thoughts. And I hope that everybody listening who's thinking about accessibility on their system and especially how to sell accessibility to their organization through their system had some really good takeaways. So thanks for coming on the podcast. Thanks for listening to On Theme. This is a brand new podcast, so if you like what you're hearing, please subscribe now on your favorite podcast platform and at DesignSystemsOnTheme. com to stay in the loop. See you next episode!