In honor of Global Accessibility Awareness Day, we're thrilled to have Daniel Henderson-Ede, an accessibility specialist, here to discuss the need for and challenges of making inclusive design experiences for those with disabilities, and how design systems can help. Daniel shares why and how accessibility considerations should influence every decision in design systems to create better, more inclusive products. We get into the importance of theme management, and the latest updates in accessibility standards. Join us as we navigate the critical intersections of design, accessibility, and system thinking to shed light on how we can enhance user experiences on a grand scale.
Check out our upcoming events.
Guest
Daniel Henderson-Ede (he/him) is an Accessibility Designer for design systems at Pinterest. He loves working alongside designers, engineers, and leaders to advocate for accessibility at scale, with the aim of creating equitable experiences for disabled users. He has also previously used his design system knowledge to publish a collection of accessibility annotation kits whilst at CVS Health.
Transcript
Chris Strahl [00:00:00]:
Hi and welcome to the Design Systems Podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design code and how it relates to the world around us. As always, this podcast is brought to you by Knapsack. Check us out at Knapsack.cloud. If you want to get in touch with the show, ask some questions, or generally tell us what you think, go ahead and tweet us at thedspod. We'd love to hear from you.
Chris Strahl [00:00:21]:
Hey everyone, welcome to the Design Systems Podcast. I'm your host, Chris Strahl. Today I'm here with Daniel Henderson-Ede. He's an accessibility specialist, previously at CV's Health. He's about to join Pinterest. Very excited to have you on. Welcome to the program.
Daniel Henderson-Ede [00:00:34]:
Hi, Trace. Good to be here.
Chris Strahl [00:00:36]:
So, accessibility specialists, talk to me a little bit about what that means, what you do, your focus and design systems.
Daniel Henderson-Ede [00:00:44]:
Yeah, I mean, people ask me, how can you have a full time job doing accessibility in design systems? Surely once you've defined the solar palette, that's it, your job is done. And what I kind of say is I do very little accessibility as an accessibility specialist. I basically act as a product designer, and every single decision that a product designer makes, I make the same decision myself through the lens of accessibility, to see how it affects someone with a disability and then help make sure the decision that they're making aligns with the same thinking that I have.
Chris Strahl [00:01:13]:
I think that that is a great way of phrasing how the wrong way to think about accessibility is. This idea that accessibility is something that can be measured in terms of compliance, that you feed your site or your component into some sort of accessibility checking algorithm, and then that manages that accessibility need for you. The unique part of your role in this case is you take on a very humanistic focus on accessibility, trying to understand it really through the lens of product design.
Daniel Henderson-Ede [00:01:46]:
Yeah, that's exactly right. I mean, I've been an accessibility specialist for a while now, and we always talk about WCAG or the web content accessibility guidelines, and I've been doing this for a while. So I kind of know what the success criteria are, but I really focus on, okay, what does this person with this disability, are they going to struggle with the design that we have? And that's all I really care about. And then I can translate that to success criteria in WCAG to kind of back up those legal requirements behind it. But I really focus on those human impacts because that really travels a lot better when trying to convey the importance of it to stakeholders. Yeah.
Chris Strahl [00:02:20]:
So if you think about this in terms of design systems and grounding it there, when you think about that investment that an organization is making in you spending time designing for accessibility, when you think about how that investment at a design system level works, the idea is how do you, Daniel, then have your work support dozens or hundreds of products that ultimately consume that design system? Is that kind of how you view it, that like, hey, I work on the design system, so my focus is on creating accessible experiences that they can then go everywhere, or is it different than that?
Daniel Henderson-Ede [00:02:54]:
That's really how I think about it. I mean, accessibility is hard to do, especially at large organizations, because there is so many moving pieces, we're making so many different flows and products all over the place. At that scale, accessibility does become quite difficult because you have to constantly remind folks the same things over and over again, and you can only have so many accessibility specialists, or if any at all, to be able to communicate that. I don't think we can have a successful organization that's accessible without having a design system that's also accessible, because it really is the only way we can scale accessibility up across a large team.
Chris Strahl [00:03:30]:
When I hear that, one of the things that I think about is some experiences I've had interacting with particular large enterprises, where when you look at the design system, you're looking at components in isolation, you're thinking about the accessibility of that component, the performance of that component, the variations that that component can take on. And just by nature, most people have not built in really strong checks into their system that basically say like, no, this component can't work because there's an accessibility problem with it. There's ultimately variations of things that users can do with components that ultimately create inaccessible experiences out of what are ostensibly accessible components. When you think about that at scale in an organization, how do you kind of push back against that fragmentation?
Daniel Henderson-Ede [00:04:17]:
I try not to push back because you instantly start to play this role as the design system is the police. And so pushing back is something I avoid until I really have to kind of put my foot down because it's something that's seriously don't know effectively a disabled person being able to access what they need to do. I really took the approach of educating them. This is why we made this design system decision. This is the reason why it's the best practice and helping them understand. And often if you tell them that this is why we did it, people understand and it makes sense to them. They can build those connections other than just being a random decision that was made in a vacuum in a team somewhere. That educational part across all of design systems is really achieved to success there.
Chris Strahl [00:04:56]:
One of the things that we talked about before the show that I thought was a really interesting sort of metaphor for accessibility in design systems is you live in Texas, and Texas is famous for Tex Mex. I think that you had a really interesting take on this, and I'd love for it, like, in your own words, to hear it.
Daniel Henderson-Ede [00:05:13]:
Yeah. I mean, as someone who grew up in England, I never had Tex Mex or mexican food. I didn't know what it was. And when I first came over here to Texas, I was kind of disappointed about what was was meant to be this amazing food. And over time, I really come to appreciate it, because I kind of joked that it's the same fiber. Six ingredients used over and over again when I thought about it last night as how does this relate to design systems? Actually, it's a perfect analogy and a success story for design systems. We have no. I mean, six ingredients is obviously an understatement.
Daniel Henderson-Ede [00:05:41]:
There's lots of things that goes into tetzmaps, but there's the same core set of ingredients within tetzmeps, and they're able to change them. Like beans can be used in several different ways and are flexible, that can be used in different meals. If you go to a text message restaurant, there's sometimes 100 items. And the reason why there's so many items is there's a common set of ingredients that can be used and changed to create all these different recipes, which I think is probably why we use the term recipes, but I think it was the greatest example of that. And in terms of accessibilities, consistency is really important for accessibility. We talked about consistency a lot within design systems, but it really makes a big difference for disabled users, especially when we talked about cognitive disabilities, because we need those experiences to be similar, so the learning curves are less difficult. And so now I go to Texas restaurants at cited because actually I know what I'm doing to get. I used to be disappointed, but now I'm excited for it because I know what exactly.
Daniel Henderson-Ede [00:06:33]:
And as someone who doesn't know Spanish, I struggle with the menus because they're often in Spanish, but as things I can recognize and be able to order and get what I need, even though I really don't speak Spanish at all.
Chris Strahl [00:06:44]:
I love this because it illustrates in a very simple way how design systems function. Right. Because like you said, I think the burrito joint down the street from me, it has like 150 items on the menu, and most of them are made with, like, half a dozen ingredients. And if you think about that, like, it makes this mix and match power really easy, right? Because you have that consistency, you have that ability to make kind of a lot of things. You want. You want a burrito, you want a breakfast burrito? You want a taco, you want a breakfast taco, a quesadilla, a bowl. All this stuff is made from the same sets of ingredients. And likewise, if, for example, I'm lactose intolerant, it's pretty easy to just take the cheese out or, you know, hey, I have an allergy to beans.
Chris Strahl [00:07:28]:
Well, you just substitute something else. There's a lot of power in that and thinking about design systems in that way. And so if you think about, like, kind of harkening back to our topic earlier, where if you're creating components that are accessible, the remixing of those components into something that then suddenly becomes inaccessible, like, if all of a sudden you put shrimp and cheese on a taco, which would be hearsay in some circles, you can substitute or change those ingredients to then make an accessible experience within the boundaries of the system. And that maybe tortures that metaphor a little bit. But at the same time, the idea is, is that, like, yes, you can absolutely not follow guidance, create inaccessible experiences, but the moment you discover them, you have accessible options that are already predefined for you. You don't have to redo a bunch of work and a bunch of thinking to think about other ways or other substitutes for the decisions that have been made.
Daniel Henderson-Ede [00:08:19]:
Yeah. And that's one of the benefits of design systems and accessibility, is we spend our entire lives as accessibility professionals and as designers and engineers focusing on WCAG. We're constantly, how can we conform to WCAG? And if you looked at the web aid in 1 million, about 96% of homepages have accessibility effects. And so we're constantly being played by the same issues. But there are so many websites that you could make, and there's great examples of websites that conform to WCAG that are still inaccessible to disabled users. Because everything in WCAG isn't what you need to make something accessible. There's plenty of things that you need to think about, especially when it comes to cognitive disabilities and making sure that voice control users can use them correctly. And we've been talking about inclusive design as a larger thing beyond accessibility.
Daniel Henderson-Ede [00:09:03]:
How do you think about people who are unable to speak English as their first language? There's a lot of things that we have to do to make sure that they ought to understand the websites.
Chris Strahl [00:09:12]:
So we had a little bit of a chat about some of the pitfalls of design systems, where we didn't really talk a lot about what design systems really do to help this problem. I think that there's the clear, obvious ones of like, hey, we create consistent experiences with a set of allowable variations, most of which should create more accessible experiences. But beyond the obvious, what are design systems doing that really enhance accessibility and inclusion in our designs?
Daniel Henderson-Ede [00:09:38]:
I think what's really important about design systems is they can also highlight what is not included with the component. So let's take an input, for example. There's lots of things you can do to standardize an input, making sure the label is connected to the text input, and any error messages are connected to the error. And if there's an error icon, it's not an alt text. We can make sure that's consistent with each use case. But if we also think about inputs are very specific to their context, and so you can't define what the virtual keyboard may be or what the autofill attribute should be. And so you can actually use your design system to make it very clear that hey, these are the three or four things that you must define for accessibility. You can draw those things out because these are the things that are often missed.
Daniel Henderson-Ede [00:10:21]:
And you can use things like annotations to help make sure that actually every time you use an input, you make sure you add an input mode.
Chris Strahl [00:10:28]:
So what you're saying is that there's a richness that you can do in terms of logic or rules or best practices, and a design system that's honestly difficult to convey otherwise, it's difficult to convey in, say, a single comp, because if you have a system in place where you think about all these different things that you described with input fields, that's a little bit beneath the surface, that's more than consistency, that's about the actual application of those in a product.
Daniel Henderson-Ede [00:10:55]:
Yeah. The execution of those components inside a product is the most critical part of the design system to make sure that your end experience is accessible. And one of the things that I really try and do and I believe in is we shouldn't really have accessibility guidelines within a design system because it's very hard to say these guidelines are specific to accessibility or specific to disabled users. Like a lot of accessibility is related to content, so stick those things in the content guidelines and make sure that people understand those. Or if we're talking about colors or behavior, then they're not accessibility specific things, they affect all users. That's what's great about accessibility, is if you focus on disabled users or not focus on them, but make sure you include them. We actually make the products better for everybody, and so you don't really need accessibility specific guidelines to make accessible flows.
Chris Strahl [00:11:46]:
Yeah, I brought this up on the podcast before, but I prefer dyslexic fonts, and I've never had a diagnosis about dyslexia or anything else like that. It's just my preferred way of reading. It creates better readability and easier cognitive understanding of a page for me. And so anytime that I have the opportunity to switch a typeface to be something that's more dyslexic friendly, I usually do it largely because that's just how I have a preference for consuming sites. And I do find myself actively avoiding spending large amount of times in places where I can't have that sort of option. I also have a tendency to really despise motion in my websites, and I know, like, look, animation is cool, there's lots of neat things we can do with it. It's not just about like motions of UI controls or interfaces, there's a lot more to it than that. But like, if my button swirls around before I click it, it makes me crazy.
Chris Strahl [00:12:37]:
So the ability to turn that stuff off is also something that I personally have always really appreciated. I think that that's a part of the idea of this conversation around inclusivity, and that yes, there are people that have real, true, genuine need, but there's also a lot of this that is behavioral preference for users. And by including the folks that have that true need, you oftentimes create better experiences for people's individual preferences as well.
Daniel Henderson-Ede [00:13:05]:
Yeah, I mean, dark mode is probably the best example of this, especially when it leads to design tokens, because dark mode was created specifically for people with disabilities. And if you look at some of the stats now that it's like 30 or 40% of people use dark mode, and not all of those have disabilities, I personally use dark mode all the time, and I have no physical need for it. I just personally prefer it. And that same concept can be used for several other methods too. I mean, we think about these new support on the web for things like increased contrast or reduced contrast. Those are things that we don't really see sites use, but we actually have a web that is starting to support these things. Our browsers and our operating systems are starting to support those, and we can use the same concepts of design tokens that we use for dark mode and provide new themes for things like increased contrast, to reduce contrast so easily. And that's all because we're thinking about accessibility from the get go.
Chris Strahl [00:13:57]:
I think this is another thing that design systems can really help with, that we don't talk a lot about is the idea of how we think about theme management. So when you think about, like, how do you manage color contrast at scale, or how do you deal with things like contrast ratios or any of the other really cool things that are happening in devices right now, there's a lot of that that can be handled by collections of tokens or themes. And when we think about that, it's more than just like, hey, you know, is this the right WCAG AA contrast ratio between colors? It's actually like, how do you create a theme that can have accessibility extensions as a part of that theme?
Daniel Henderson-Ede [00:14:36]:
Yeah, and I think this is a huge area of opportunity for many systems and organizations, especially to differentiate themselves for people with disabilities, because we have all these abilities now where we can start to customize for people's preferences. You mentioned, Chris, about motion. We have in all three operating systems, Android, iOS and web, we have the ability to reduce or turn off motion. The only way for us to really consistently do that and remind people about that is to use our design systems and use our theme files to be able to support those ideas.
Chris Strahl [00:15:07]:
So I think those are two really concrete, awesome examples of where a design system really lends itself well to accessibility. We talked a little bit about pitfalls, about how the expectation of accessible components doesn't necessarily translate to the clear creation of accessible products. But what other pitfalls do you oftentimes run into in design systems where you're like, ah, if only this had been different, or if only we had thought about this as a part of the system, I would have created a better, more inclusive experience for everyone.
Daniel Henderson-Ede [00:15:40]:
One of the biggest things I kind of regret with some of the decisions and ways of working in the past is actually the contribution model that design system teams and organizations use to create the system. In accessibility, there's usually lots of folks who test components and test flows to make sure they conform to WCAG. And what happens if you're not too careful is if you don't have that communication model where everyone feels engaged and on board with the design system, you end up with people trying to test components and test flows and think they're not accessible. And by doing what they think is important, by pointing out defects and issues, you actually end up undermining your own design system by saying, oh, it's not accessible. You get this sort of hearsay around the organization that the design system's not accessible. Well, actually it is, and WCAG actually has interpretation built in, and for good reason. But it had those accessibility folks and other notes, auditing organizations been included with the creation of the design system. You get the shared understanding of this is our philosophy for accessibility, or these are the things that we believe in as an organization, and that hearsay doesn't affect your organization.
Daniel Henderson-Ede [00:16:48]:
Your design system's reputation and trust is so important for success.
Chris Strahl [00:16:53]:
So I think that's a great example where you have this idea that trust in the system becomes compromised at some point because certain experiences that you were able to create weren't accessible. Trust in the system begins to fall down largely because the contribution model that thinks about this in a way that isn't fully holistic. Is that a fair summary of what you just said?
Daniel Henderson-Ede [00:17:12]:
That's exactly right. We have to remember that the people who are using our system are also the people testing our system, and they will have views about it. Accessibility is one of those strange areas where if people say it's not accessible, it's a statement you can make. It's very rare you hear someone say the design system is not usable. That's not really a phrase that you hear, but you hear that a lot about accessibility. Making sure that you include anybody who's involved in testing for accessibility or design for accessibility within the contribution of the design system and creation of it is important for its longevity and maturity of it.
Chris Strahl [00:17:44]:
That's a really great technique to help with the contribution of componentry or themes or tokens. What about some automated things that we can do to help with this? Because I think that there's a lot beyond just the idea of let's go feed this into some sort of web accessibility standards testing. Is there a linter or a process that you think of when people are making a contribution that it should go through?
Daniel Henderson-Ede [00:18:08]:
I think there's absolutely some regular automation and unit testing that you can run with WCAG conformance that is really important, but I always hesitate to think that's something that we should rely on. I think it's certainly something that we should add because it does find the low hanging fruit that we forget about every so often. But it's really testing those components within an environment where it's in its own context is super important. People kind of get upset. Accessibility is a practice sometimes, which is a common answer you get is it depends and it does depend, and that's why testing for accessibility on components when they're just components sitting in storybook isn't a great way to test them, because the way a tabs component works is going to differ depending on where it's used. If it's used on a homepage or if you use it in a form, you could do that. There's nothing technically stopping you. But if you give that to a user, they don't want to struggle more likely with it being used in a form than they are on a homepage.
Daniel Henderson-Ede [00:19:05]:
The real value, I think, in testing is working with disabled users with your own components in real flows that your design system is consumed from. And then that's where you find out what does and doesn't work about your component and whether it really is accessible.
Chris Strahl [00:19:21]:
So I think that's really fascinating, what you just said, because the idea of a lot of teams that I talk to is like, let's go test our button, or let's go test our card, or our list, or any number of the very basic things that exist inside of the design system. And I've often wondered the value of that practice, because oftentimes, like those really, really simple things, those ingredients, the ground beef or beans, testing them is fine, but ultimately, like, what you really want to know is like, does the taco taste good? And it seems like the more complexity you have, the more testing becomes a requirement of ensuring that the system is actually accessible. It seems like the simpler stuff is pretty easy and pretty well understood. It's when you start to introduce more complex recipes of things that it becomes much more critical that you actually do that testing.
Daniel Henderson-Ede [00:20:12]:
Yeah, I mean, absolutely. I mean, how many times do we joke about creating buttons? There's only so many ways you can actually mess up a button. The color contrast is the prime example, or the content and the labels that you use inside of it. But when you start to talk about really complex components, such as maybe chips or filters, which is a great example, there's so many ways that you can fail to create that component, and you will never know about different ways that it doesn't quite work for people unless it's used in an environment it was designed to be used for.
Chris Strahl [00:20:40]:
That to me, is this really fascinating takeaway where there's probably an inverse relationship here. The more weight you put on the complexity side of the scale, the more tests, and you need to balance that weight out. And when we think about that as how do we solve for this at scale? One of the really hard parts about that complexity argument is that if you think about the atomic model of design. So like, all right, look at them is pretty easy. Molecules, doable organisms now are starting to get complex, and then you get into templates and pages. How do we fight back against the scale problems of accessibility, where the more complex or the more built up those experiences are, the more testing they require, but also the less centralized they are.
Daniel Henderson-Ede [00:21:27]:
Inside of a design system, our organisms and patterns are built up of our atoms and molecules, our smaller items. And so if we make sure we put those items through the tests, we can be much more confident that when we start to create those larger items that they'll be more accessible. There's obviously still that inherit context is important, and that's where really we need to work with our consuming teams to make sure that the things that we put into the design system really are best practice. Let the consumer product teams work out what does and doesn't work, and we can make sure that the stuff in the design system doesn't have to go through all those unique tests, because we've already seen teams fail and improve and iterate using our components, and we end up with some succinct best practices at the end of that.
Chris Strahl [00:22:13]:
Interesting. So this is another law of constraints sort of thing, where the design system constrains choice. And because that choice is constrained, ultimately when you are looking at these complex systems and looking at them from an accessibility lens, the number of variables or number of variations feels more finite. And so you're better able to determine, like this is the guidance, this is the best practice. Instead of designing a whole page and then being like, what are all the possible accessibility issues or problematic pieces of this page? You're looking at it at more of a constrained component by component assembly. Because of that, you're able to think about my constrained variables or my constrained types that represent where the issues may arise and also where you can solve them.
Daniel Henderson-Ede [00:22:58]:
Yeah, there's certainly a set of things you have to check when it comes to larger patterns. And so like making sure that the information hierarchy makes sense, that is a key one, because we know that stream reader users often can't visually perceive what's on the screen, and so making sure that programmatically makes sense to them is really important. Or even if we think about people using matrification, they don't see the entire screen in one go. They may see an 8th of maybe what I see on the screen, and they have to navigate that to whatever method they use to see the page much larger scale. And so we don't really have to worry about those things. So much for a button. A button doesn't have any sort of information hierarchy if it's a simple button and multiplication users trying to find a button when it's just a button on its own. But as soon as we start to think about where they are on the page and the way the page is built up, we start to have to look at these new guidelines and these new user needs to make sure that we're not creating any blotters for people.
Chris Strahl [00:23:56]:
Interesting. So that ability to basically focus on that hierarchy of information without having to necessarily worry about if there's the right tag in the button for a screen reader, that's where you find a lot of the value in this. You get to sit there and look at the bigger picture instead of having to dive into the minutiae of each individual component.
Daniel Henderson-Ede [00:24:16]:
Absolutely. And that's where building accessibility into the design system really gives its value, is you stop doing all those basic things and you start thinking about the actual experience and comes more into sort of service design accessibility style.
Chris Strahl [00:24:29]:
So we talked a lot about standards in this chat, and we talked a lot about adherence to standards and how there's a bit of a double edged sword there, but there is constant evolution of these standards. And I know now that there's new standards coming, why don't you talk a little bit about how this introduction of new ways of thinking in the standards that we think about for accessibility kind of change how we think about this in design systems?
Daniel Henderson-Ede [00:24:53]:
WCAG 2.2 came out actually in 2023, the end of last year. And so we have a new recommendation from the w three C about the conformance of our design systems and our experiences. And we know that this new standard is coming out with the European Accessibility act, which is going to be coming out in 2025, if I remember rightly. And so this is a really great time to start thinking about how you can invest in accessibility within your organization, specifically in the design system. If you can build 2.2 conformance into the design system and in your guidelines, you have this initiative to attach onto, and it's a great way to sell your design system, especially if you're struggling to get people to use it. Hey, our design system's going to help you get to 2.2. It won't get you there, because again, contest matters, but it will really help drive that adoption.
Chris Strahl [00:25:42]:
Awesome. Well, I really appreciate you taking the time to join us. It's been a really interesting conversation. I know I've learned a lot about how to think about accessibility at scale. And I just want to say I wish you a lot of luck joining the Pinterest team, and I'm excited to see where this all goes.
Daniel Henderson-Ede [00:25:57]:
Thank you, Chris.
Chris Strahl [00:25:58]:
This has been the design systems podcast. I'm your host, Chris Strahl. Have a great day, everyone. That's all for today.
Chris Strahl [00:26:03]:
This has been another episode of the Design Systems Podcast.
Chris Strahl [00:26:05]:
Thanks for listening.
Chris Strahl [00:26:06]:
If you have any questions or a topic you'd like to know more about, find us on Twitter thedspod.. We'd love to hear from you with show ideas, recommendations, questions, or comments. As always, this pod is brought to you by knapsack. You can check us out at Napsack Cloud. Have a great day.
