Accessible design systems with Karen Hawkins

Season 3 Episode 11. My personal perspective is that everyone should be accountable for the accessibility of their output, which means that you have your responsibility to test your own work. Hello everybody, welcome to UX Podcast coming to you from Stockholm, Sweden. We are your hosts, James Royal Lawson and Pad Expo. Balancing business technology, people and society, with listeners all of the world from Sierra Leone to Gibraltar. Karen Hawkins is a human factors engineer and a certified accessibility professional with more than 15 years of experience. She's a member of multiple W3C accessibility groups, including Cocher of the W3C's accessibility roles and responsibilities mapping community group, known as ARM. I'm going to say ARM, I don't know if it's ARR, but I'm not sure I was entirely aware of ARM before. What they produced is a responsibility, so who is lead responsible for each of the criteria and who's involved in it. So it says designers, developers, tests and so on, to help you understand more how to deal with the criteria. Excellent. Yeah, it makes me aware of how little I know about all these different aspects of how the W3C is actually brought forward as well. Today, Karen leads the accessible design practice at level access, teaching customers and colleagues alike to apply accessible design thinking to all their work. I had the chance to chat with Karen at a hatch conference in Berlin and it was just ahead of her workshop, advanced accessible design system components. The accessibility, I think, has historically been something that we've struggled with, we've struggled to get into place in digital products. It's often been a bolt-on thing. Rather than something we consider from the start, with the adoption of design systems, as well as at least in larger organisations, has this been boost for accessibility, or has it created a problem for us? One would hope it's been a boost, but I think the reality is that it hasn't been as much of a boost as people have wanted it to be. Because the same thinking applies that we will bolt accessibility on later. Design systems are the perfect opportunity to do it right from the beginning. The intention, I think, is there. I think the biggest gap is that design teams don't know exactly what they're responsible for. If they don't know what those requirements are and what specifically needs to be baked into the design system, well then there's therein lies the gap. Which is always the same problem when we're creating digital things. You're starting off producing something. In this case, we're starting off at some point creating a design system. So you need to approach it the same with thinking, I guess. Correct. They're saying a design system should be considered like a product. And so, of course, bake accessibility in. Really, I think the thinking needs to be that we have accessibility requirements. And we need to consider these accessibility requirements alongside all of our other requirements, functional, non-functional, whatever, for any individual property that we're creating. And this includes design systems. If we just had that paradigm shift in thinking that they are accessibility requirements, design content, and documentation, well then that is a huge step forward. Just even knowing that there are requirements, then the next step is knowing exactly what those requirements are. That's a whole other game. But at least we're ahead of the game by doing so. Yeah. And when you say requirements, I mean there we're talking more formal ones, aren't you? We've kind of like W, G, S, H, and so on. But accessibility goes beyond that. Correct. Yeah. But I would still include some of the best practices as requirements. So good example is font size. Yeah. WCAG doesn't mention really anything about font size, but there are agreed upon best practices. Like it should be 12 point font in general. And you should select font that has high ledibility to improve the readability. Things like that. They're not baked into WCAG, but the community at large has kind of drawn a line in the sand and said, this is what we expect. Yeah. I think, yeah, because like contrast levels there, they do mention font size. Don't they? Because like certain heading is going to be 18 points or higher than one level of contrast. Yeah. There's only two levels officially. There's large text to your point. And because it's big, it doesn't have to have the same amount of contrast. It doesn't have to be a sharp. And then your smaller text does have to be much more legible. So it needs to have good contrast. But that's it. So there's, so I guess what you're saying there, this specification, this is more, you're getting almost until accessibility policy for how you're going to run your design system, aren't you? Because this one thing, yes, we're going to follow that standard. But then if we're into the things outside the standard, like font size, you see, then this is more a description of how we're going to work. Yeah, it's a matter of practice. It's a matter of understanding what the specifications are asking designers to do. Really, there's a challenge in translating those specifications into designer speak. And then incorporating that into your normal workflows. I wish more teams were doing that just incorporating more accessibility into the natural workflows. I don't want accessibility to be this big barrier for teams to overcome. It should just be this natural progression that's slowly everyone's doing it at some point. And everyone ends up getting better at doing it over time. So what, so in the team, which aspects of it do you think are the barriers or what do they kind of like don't feel as comfortable with, which is the bits that we stumble on? Well, there's a few things. I don't think teams are equipped with the right tools or enough tools. Designers, we tend to think of things like contrast. And it almost hurts my heart because of some of the other things that we need to think about. And so I'm going to go back to the big gap is lack of awareness of other responsibilities. So I would hope that teams would start to think more about technological experiences perhaps that are associated with the assistive technologies that people will end up actually using. The simple one is the keyboard. Keyboard accessibility is an absolutely massive issue. And if we only even started to think about as designers, how is this thing supposed to work with a keyboard, you know, then we don't necessarily have to do all of the work associated with it, right? We have teammates to lean on such as dev who should know how to implement it appropriately. But when you start to look at complex components like a calendar widget, well, there's variability in how you could actually design the keyboard experience. It doesn't have to be completely rigid. And I would hope that designers would take that as an opportunity. Like I do, I think it's fun. To look at a complex component and try to think about how should this work with the keyboard? What's an optimal screen reader experience? If somebody's using a single switch or like a SIP and Puff machine, then, you know, what is the the minimal experience that I can create that's still going to be as awesome as possible? Things like that. So I guess it's another shift in perspective in how one goes about tackling these types of problems. And sometimes I think you might get some kind of kick, well, some kind of pushback in situations where like, well, most of our users are using the mobile version. Like, why do they need a keyboard? Oh, great. Well, yeah, we can connect keyboards to mobile devices. And there's some people who absolutely rely on the keyboard. Yes, there's pushback. And that stabs me in the heart as well. And there's still so much pushback. There needn't be pushback. I would hope that organizations lean into their DE and I, their diversity, equity and inclusion and just embrace accessibility along with that. There's been a real push for like inclusive marketing. That includes branding and photography and voice and tone. And that kind of thing to be more inclusive. I don't think that they would want to disclose anybody in not intentionally anyway. And so I don't think accessibility should be any different. It's just some unique requirements that we need to think about. Oh, I like that. That you was zooming out a level and saying, okay, the design system for our digital products is one thing that we use when we're producing our digital products. But you then apply it to company-wide and say, yeah, all our material, whether it's marketing or documentation or manuals and so on. It's also going to be accessible. Yeah. There's lots of documents in general, PDFs, Word, PowerPoints, e-mails, just even e-mails. So if an organization was truly going to embrace diversity, equity, inclusion, and accessibility, they would have a culture of inclusivity. And that means I think three levels of it, right, from colleague to colleague. So that includes your e-mails and your Slack or Teams Messenger chats. Like all of that, you'd be as inclusive as possible. But to your communities as well, as well as your customers, whoever your customers are. That's true inclusion, like embracing the whole of all the people with whom you interact. And that can be potentially overwhelming. So we do work with a lot of organizations that are there at the accessibility program level, all the way down to what we initially started talking about, like design systems and even more nuclear than that. Nuclear as in e-mails. Smaller. Smaller, okay. Not explosion. Okay, I was thinking, it's like, where are we going here? That was the smaller level, the granular component level. What level do you get to at the bottom? You're into individual components in a design system or in smaller. No, specifically if you understand a atomic design, right, by Brad Frost. So there's the atoms, but in the last couple of years, there's the subatomic particles, right, atoms. Sorry, the protons, neutrons and electrons. Well, those are your tokens. And so there are accessibility considerations even in setting up your tokens properly because they're quite foundational for your components and making sure that your components can be as accessible as possible, specifically with respect to your state design more so than anything. Okay. So let's talk a little bit about tokens or at least, I guess there's a scale, no scale. What is, there's a progression, isn't there? Like you said, about atomic design. But in design systems, you would have tokens. There would be components. And now we're on the spot, you're going to try and list all the parts of design systems. Styles, patterns, I'm going to the wrong order, I think. Yeah, I'd start with styles and tokens. Right. And so, I think that's how I would categorize them. And I think the interesting thing that I'd, I realized personally the last couple of years is that the accessibility responsibilities that designers have at each of those levels is different. And so we get back to contrast. Like we think that, oh, we have to just consider contrast and maybe just keyboard accessibility. But that tends to be on just the component level. When we get to larger things like patterns, like carousels, in tables and like complex things like that, well, then we have to think about different things. And then at the template level, where we're throwing all of these Lego blocks together, again, they're different things. And I think the patterns and the template levels in particular are spaces where designers aren't aware of what the responsibilities are because they're at a higher level of thinking I think. So when you come to accessible tokens, how does that manifest itself in the token? I mean, we're talking about how you name the tokens or how you apply the token. Application. Yeah. So I won't get into like governance and setting up the tokens. That's definitely not my forte at all. But when you think of your typical tokens that are setting up the individual pieces of the styling of a component, let's say the component, excuse me, is a button. So let's take your typical button, this classic button. There's a lot of tokens involved in that from the font size to the font color, the padding around the font, the color of the button fill. Do you have a border or not? What do you have rounded corners, square corners, so the radius of it, do you have a shadow? And I think there's more to, you know, if there was just off the top of my head, but all of those are individual tokens. And when we talk about state design, one thing that a lot of designers aren't really aware of slash get wrong all the time is we use color alone to indicate a state change. So we move from like a medium blue to a dark blue for from default to hover. We really shouldn't just do that though, right, because there's so many color deficiencies. So I like to express we should use something structural, change something structural about the design of the button. And this is where your tokens come into play, right? So you can add an underlying, you can bold the text, you know, you can thicken the borders, you can go from square corners to round corners. So that's an example of how you actually use your tokens in your state design. Right. Yeah, exactly. That's one of those things that is often missed the kind of states like the active hover and active, for example, and what happens. Yeah. And specifically what I care is about focus states, which is for keyboard experience. Exactly. When you, yeah, you keep focused. Yeah. And now that is separate as well to go clicking and holding on something very example. Yeah. Yeah. And we can't just design hover states like in component libraries and style guides. I don't see enough focus states designed and what can't doesn't care about hover. So we should actually be putting more focus on focus. So, yeah, so that's that's a lot of tokens that we need to think about in just a component level. How do you manage the interplay them between the components? Here, I'm thinking I'm back up a little bit. One of the things that I'm doing like accessibility audits and so on, one of the kind of things often comes up is that labels don't really tie up. That maybe you've pointed to a label somewhere in a component and then when it all strings together in like a screen reader, this doesn't make sense anymore because I'm pointing all over the place or the component maybe doesn't understand what's going to be over there and IDs clash because something's generating IDs instead of it being kind of like assigned in the first place. I might have got too technical there, I don't know. But I mean, how do you manage that kind of aspect of accessibility in a design system? Well, I think that's where the design system has a benefit is because we should be documenting as much as possible at the smallest level, so at the component level. And so if all stakeholders involved in a successful design of this button have been collaborating together. And by that I mean like typical UX, UI content and dev. If all of these makers are involved in completely understanding how this thing is supposed to look and feel and how it's supposed to work, well, somewhere, all of that should be documented. So there's absolutely no questions. All the guardrails have been put in place. And then that doesn't preclude when you take an individual component from the design system and then you go up into the wilds and you end up using it. But there should still be documentation around how to use this properly in those instances to lessen the potential risk of bugs. Right. Yeah. But we still, I suppose does that mean we still end up with an auditing role at the end anywhere? I think so. It seems to be like, well, accessibility would do them to be the auditors, I guess. Yeah, but I would hope, excuse me, that when we typically talk about auditing, we're talking about on something that's live. Right. So the result we audit it, we get bugs and we have to go remediated. And I think that's where some of the tooling is failing designers. We don't have enough tools yet that can help us test our own work before we push it downstream to the next teammate. So would you be able to, is one of the things that's missing in the tools, the ability to buy context? Or is I think, you know, that's where we fall over, isn't it? We lack sufficient context on a component level or when we've kind of piece some things together. Yeah. And then in the wild, that's interesting. That's interesting. Yeah, that's interesting because I think I was just thinking at the design system level, it is almost abstracted of context by definition. Correct. By necessity. And when you're in the wilds, I think that has to be part of the documentation is the do's and don'ts or these are things you're allowed to do and things that you're not allowed to do. Watch out for this. Watch out for that kind of thing, you know? Yeah. So you document some guardrails and saying, look, if you're combining this with that, then it's probably not going to be a good experience. Yeah. So a good example is always a checkout. Most people have experience, a checkout experience. And you're filling it up a form and there's all of these edit buttons. So edit your first name, edit your last name, edit your shipping address, that kind of thing. So a screen reader experience for those is typically something like just button edit, button edit. So it lacks the context to which you refer. And so we should be documenting, well, when we use this component, we should be grabbing the label that's closest to that button, to which it refers. So then the screen reader experience is more like button edit first name, button edit last name, button edit shipping, information. Yeah. I actually had one of those kind of experiences where it was like lack of context. I was filling in a form and I was like, I was filling in a form. through some validation text. But the validation text I think had been, or the context that the design had worked on was this is going to be someone in the same country as this product or this thing. And I was, I'm, I'm business-weed and so I was filling it in and someone from overseas. And suddenly it didn't really make sense the message I was getting. It was complaining about my address. It wasn't a valid address. It wasn't a valid street name, even though it was. It was my street name. So what it was throwing back at me was kind of telling me off where I lived, even though it was completely correct. Yeah, I get that a lot because I live in Canada and a lot of forums ask for a zip code and I don't have a zip code. Yeah, that's the same thing. Yeah, that's exactly. Yeah, that's the one that we get. Postcode, English, English, you get the code postcode zip code. That's always a problem of describing. Making international. Why not, right? Yeah. Yeah. In fact, that is a challenge of, I think, of design systems full stop. It is internationalization. Now I'm wondering a little bit off from accessibility, but in some ways it is because when you fail to internationalize some of these things, you create an accessibility problem downstream, like what I've just described or you've described the zip code. It doesn't make sense to you at the end. Well, and effectively, you could be blocked. Yeah. And I think that's what an issue with accessibility is a lot of times people are just locked from doing what they need to do. So to your point, yeah, there's a parallel there for sure. Yeah, and that's, yeah, we don't want locks because generally we want people to complete the tasks they've come to us to do. Exactly. Yeah, yeah. Quickly inefficiently too. So should we move up a little bit and think about patterns? Sure. I think we've touched a little bit on patterns anywhere, some of the conversation now, but more specifically, how do they differ then to the earlier items in the time system from an accessibility point of view? Well, I think the goal of components is to design as many permutations as required by your design system. Then when you get to the patterns, you're using these individual components. And you've already thought about all the interactions, you know, how it's supposed to work, how it's supposed to look, all of that minute detail has been figured out. Now when you're using them, the thinking now has to be in what order should I use them? So we're talking reading order and focus order. In addition, if I throw all of these big things together, is the meaning clear? Does this all make sense? If there's this big chunky pattern, do people even want to get into that content? Not necessarily. So should we give them an opportunity to navigate over it, navigate away from it? For instance, I'll use an example of a carousel, right? So a carousel typically has a couple of product cards in it. It's got a heading, great. Ideally, there would be some kind of button or control, so that's not just using gestures. You've got arrows or something like that. So great. We have a well-designed carousel. But if it's something that you're not interested in digging into, we'll wind up providing a skip link. And say, hey, do you want to check out the dairy content? No. I want to go to the bread. So yeah, you would skip over that and head down to whatever's next on-screen. So as contrasting patterns to components, the idea is at a higher level. Again, that focus order, navigational strategies, that kind of thing as opposed to state design. How does this manifest yourself in the design system when you're doing that work? Because we're talking about the documentation side of things and tokens. When you're completing this disability work for your pattern, how does that look? I think it's similar with respect to the more you can document and provide guardrails, both at the design system level as well as when you're out in the wilds and you're off to use it, the better it's going to be. Because the people who are creating the design system, particularly patterns, they should be going through all the different use cases that are possible and making sure that they're designing all of the correct variations for that. If we add that extra layer of trying to think of additional navigational strategies, particularly for keyboard users, then we're really increasing the usability of that particular pattern. But to simply answer your question, I don't think it's much different. It boils down to documentation. The reality is that it takes resources, time and effort. We hear from a lot of design teams that they don't have enough time and effort to do that, specifically for accessibility, but in general, I don't think there's enough documentation done anyway. As a result, there's a reason that we end up getting bugs in the live experience. I think the experience says that there's an engineer you recognize this too, but I find that the best documentation is the documentation that's exactly where the developer's eyes or the designer's eyes are going to fall when they take the shortcut. Basically, comments in code are always going to win for developers because that's where they're going to look first. They're not going to dig through your 400-page documentation. They're going to jump straight into that JS file or whatever or HTML file and start reading that. In the learning space, I think it's considered just in time resources. The comments for the dev or for designers, it should be where they are. Again, going back to tooling and having something, let's say in Figma, just because it's the most popular tool at the moment, not necessarily that it will be forever, but we might be here to stay. A few months ago. Good footfold. Meet me where I am tends to be what the makers want. I think that's been an issue in the accessibility industry in general is that we're not doing that at all. We give them to your point, these 400-page documents, whatever. They just want this teeny tiny little thing. They have a particular problem to solve. They don't want all the hoopla around it. They want very specific guidance on just this thing. If we did a better job at that, we could make waves, I think, in actually producing accessible experiences. Going back to what we said about, I think I think, with the design systems, do definitely open a door to sewing more seeds and allowing us to access the ability to grow even better because of just that. You're creating a place, a resource that your teams do have to use. They have to use it and the thinking has been done. You've taken care of all the hard work and you've enabled the people who are going to use it to just, "Here, go." We've thought about all of these things. These are the places that you still have flexibility. That's what I don't want for design teams, though, is to feel constrained. We have to still give designers lots of space to breathe and to experiment and to still be creative. That's why those guardrails are very important in my perspective. I realize I said, "You have to use the design system." That's actually not really what I meant. I guess I should have said that you've created something that they want to use. Fair. If we've thought about being considered, consider it about accessibility, then we've made something else going to be good as well as making them feel like it's good. It's going to be really good. When you think about enterprise organizations, these large organizations have lots of different brands. If they had something like a parent design system, an individual brand would use at least portions of that parent design system and everything is inherited and it's all nested nicely. There's even less work for the individual brand teams to take care of because the stakeholders aren't necessarily just designers who are going to use like a figmophile. We've got lots of other stakeholders who have the potential. If they don't have the knowledge, the usability knowledge, the accessibility knowledge, all the more reason to be really clear about how to use this individual component or pattern. I think you've helped reassure me a little bit. I was a bit worried that design systems are actually just going to put more barriers or put more problems in our path. But I think today. No, I think the opposite. I would hope that it would clear the way for everyone to use them properly and to create wonderful digital experiences for everyone. Nothing you really showed me. Thank you. Thank you very much. I really love this interview again. I think you're doing too good of a job without me. I mean, Karen brought up so many points and so many takeaways. I think the first one I want to bring up is this. Well, idea that I completely agree with that everyone within the organization should be working with accessibility at some point. I could relate to that as she said it as well because in the project I'm currently in, I've gotten lots of buy-in for accessibility and people are extremely curious, which means I've even gotten questions around doing PowerPoint presentations. What do I need to think about to make this accessible for people? I have to write these guidelines about contrast and color and how to describe images as you're doing presentations. So people are extremely curious, which means that everyone is now doing some sort of accessibility work, which is just fantastic. And then that means everybody's thinking about it more. It's more top of mind in all meetings. Yeah, the awareness is there. And that's good. I mean, the work that Kevin's been doing as part of W3C, then there it does, they split up the responsibility or the allocate the responsibility for each criteria to business, content, visual design, UX or frontend, which helps clarify some of the responsibilities for individual criteria. But I think it's useful as well when you think about the different levels from a design system point of view. Yes, we've got responsibility from an individual criteria point of view. So we've also got the layers of a design system that Kevin talked about in the interview from components to patterns to. Yeah, so you could have someone, your response, you're responsible for the labels on web forms, you're responsible for the error messages related to that. And someone else is responsible if we're Zoom in certain contexts. Yeah, I was thinking more about how this kind of like rolls forward. So you've got the context, so the ultimate context is what's in the screen for the user, you know, it's in an app or in a browser. And with every layer, we kind of peel back from that, we lose some context. So when we're at the component level, we have very little context of how it's going to be. Yeah, I think that really came through in the podcast because towards the end you were both we're talking about how the context changes everything, which was really interesting. And it became so obvious that the design system is kind of a skeleton. When the skeleton is a full-bodied person, when it's actually done and alive, then it immediately becomes more complex as all people do and as websites do. So you don't know how the different components will actually work in interaction with all the other components that are now added to the page. So you have to make changes to the skeleton again, perhaps. Yeah, which you just classic UX design, isn't it, that we're kind of thinking about, you know, the end use of the context and then building into our designs. But in design systems, we're designing the components, the bricks that we're going to build stuff with. We've got to really be kind of using your UX brain to go, okay, what are the various contexts and ways in which this component can be used? Not just as a component, but also as part of a pattern, as part of a template, as part of a page and so on, as part of a user's experience. So you're adding more layers of contextual understanding to your design work. Exactly. So I need to understand why is the component designed like this inside the design system? And how do I know when it isn't doing its job? How do I know when I actually need to tweak it or change it? And am I allowed to? Because sometimes you come into organizations and it always has to look like this. Whereas in other organizations, it's like, yes, that's sort of a rough guideline, but of course you should make it work as best you can for the people you're designing for. Yeah. And when I've been auditing sites for accessibility and sometimes you can smell the design system components when they've not got it quite right. I mean, basically because when you want to the accessible names of things, that you kind of seeing or hearing, the name that's announced for a component through a screen reader. And you can see that maybe the slot's not being used on a design component or rather they haven't built in the right connections to allow the component to utilize, Karen mentioned this in the interview. Like, that's the label you need to use to build up a better accessible name for this component in this context. And you can see when you're auditing that, no, they've missed this. They've designed it in isolation or they've not understood where it is going to be used and how it will interact with other parts of the page. Exactly. Love that. So what recommended listening do you have for us, James? I couldn't resist pulling out two from the archive and one of them feels very relevant because Karen mentions atomic design and Brad Foss, Frost. Oh, yeah. So we did that interview long time ago. Of course, back in 2021, beginning of 2021, in episode 268, we had managing design systems with Brad Frost. So that's going to be interesting. It's kind of like, now four years on with this interview and conversation in mind, roll back a list of the bread and see if you can merge these two conversations together to get yourself a kind of like two plus two is five. Now, I feel like listening to it. You should always listen to my recommendations, Paid. Yes, I should. Don't just kind of say, "Well, that sounds good. Do it." And the other one I'm recommending is episode 253, "The State of Accessibility with Derek Featherstone." Now, I'm pulling that one out because Derek is an accessibility legend, but also Karen and Derek both work together at level access for a few years. Oh, I had no idea. Okay. Remember to keep moving. See you on the other side. Okay, there. Why did the uranium break up with the plutonium? It found some more more stable. Too geeky? No. Yeah.