Embedding Accessibility in your Design System

Karen Hawkins at UXDX EMEA. Video: https://youtu.be/HDJytxjJYqY

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction: human factors and proactive accessibility

[00:00:07] Karen: All of you excited to talk about accessibility? I'm excited, I hope you are too. This is fantastic. Thanks, Katherine, for the warm welcome. I am super excited to be here. Normally I live in Toronto, Canada, so I came all this way to talk to you about accessible design, and specifically in the context of design systems.

[00:00:30] A little bit about me. Firstly, I am a human factors engineer. I'm an industrial engineer, which is systems engineering, process logic, a lot of statistics, that kind of thing. And there was a sub-specialty around human factors, which is really about understanding people and how we interface with technology. It's really about designing people first, making sure that we don't conform to the technology, but rather that the technology conforms to us. That led to a career as a user experience designer, but at some point in my career I found accessibility and I just became really passionate about it.

[00:01:11] I have the privilege of being the principal of accessible design at a company called Level Access. We're the world's largest accessibility-focused company. We help our customers with manual evaluations of their websites and apps and that kind of thing, but that's very reactive in the process. You already have something built, you've got to test it, make sure it's accessible, you've got to fix some stuff. But I come into the process ideally a lot earlier. I'm all about proactivity in accessibility, specifically in design and content creation, and I work with my customers a lot on design systems, making sure that their design systems are as accessible as possible.

Polls and the biggest challenges: color, content and testing

[00:01:52] Here we are today. What we've got for you is a forum where I'm going to be asking you a number of questions. I've got some polls, but we would love to hear from all of you. I think that's one of the wonderful things about UXDX and how they've put this all together: they really want to hear from the community and hear your voices. So grab the mic. We have the lovely Emily, I believe, running around with the microphone. We've got 30, 35 minutes here. And I also want to mention, because the room is really loud, most people do have headphones, and if you're in the back, there are a couple of seats still up front if you wanted to grab one. Even with the microphone, if you don't mind, it would be really great if you tried to speak into it, because some people have headphones and some people don't.

[00:02:43] We're actually going to start with a poll. Now, in the spirit of inclusive presenting, we have that QR code, but I'm also going to explain the text version, the alternative way that you can access the AhaSlides. Most of you are aware we're using AhaSlides. That's ahaslides.com, then forward slash, and then the keyword for this room today is capital K as in koala, capital K as in koala, capital A as in apple, the number five, and then capital Y as in Yukon, because I'm from Canada.

[00:03:17] The first poll is a question I'm very interested in hearing from you on. At what stage do you typically consider accessibility in your process? If you're like me, I'm guessing that it's later in the process. Maybe dev is doing some testing, maybe we've got some QA going on and we're checking out a couple of accessibility things. So the poll, what does it show us? Yeah, it's in line with my gut. From the very beginning, we've got 1.5%. I love it. I'm so glad we got 1% going there.

[00:04:01] Then we have a discussion question, which is not showing up here, so I apologize, I have to turn my back. What are some of the biggest challenges that your teams are facing today in applying accessibility in your design systems? We'd absolutely love to hear from you. Type in some answers. If you're going through some challenges in applying accessibility in your design systems, hold up a hand, hold up a foot if you don't have a hand, shout, scream. If you would like the microphone, I would love to hear from you.

[00:04:32] Don't say colors. Colors, colors. Really, the biggest challenge: colors, colors, colors. It's a pet peeve, personally, because as designers we're responsible for contrast, and it pisses me off day in and day out that I see digital experiences practically everywhere that still have poor contrast. Gray on gray, gray on white. It's really hard to see. That's something that we have to fix. Is there anybody here who has their hand raised, foot raised, shouting, that would like the microphone? It's just a little hard to see up here with the lights, to be honest.

[00:05:14] We got another one: budget, and getting people to embrace UX writing that's accessible. Well, that's actually really interesting, because when we talk about content, there's actually a ton in the content space that we can be responsible for. We talk about plain language. Ideally we're aiming for an eighth grade reading level with all of our writing, but the community at large is asking more for a sixth grade reading level. If you consider plain language in your writing, even your microcopy, it's going to make a huge difference, because all you're doing is simplifying the process with your copy.

[00:05:55] There are a lot of comments here. Lack of testing with real users. Now, that's a struggle that we have in general. It's really hard to find meaningful representation with all of your user groups, but when you add the accessibility lens, and now we're talking about people with disabilities and actually trying to get their feedback, that brings a whole other level to it. I would highly encourage you to just aim for meaningful representation of your entire user group, put it that way. That includes people with disabilities and people without disabilities. You can cut the swath, or the tapestry, of humanity in lots of different ways. So yes, we should be including people with disabilities.

[00:06:42] It's pretty hard to find easy step-by-step instructions to implement accessibility properly. I want to talk about that for a sec, because it's not one-size-fits-all when it comes to accessibility. There's just no way. There really are a lot of requirements, and it's up to us to take ownership of what those requirements are and to understand at what point in the process we're responsible for implementing each of those requirements. And I will say, in the context of a design system, there are different requirements at the different levels of a design system.

Where in the process accessibility happens

[00:07:18] I've lost my timer here as well; I don't know if we can get the timer back. But we're going to move on to another question. It's a poll. How about this: in which phase have you actually incorporated accessibility? I've got a lot of phases up there, starting from requirements gathering, through the design process or testing, and even visual QA. I'm curious to see which phases you're having problems with.

[00:07:56] Okay, so we've got accessibility in the design system. That's great to see. And in user research, persona creation. I'm really glad to see that. Has anybody heard of Whitney Quesenbery? She talks about the five Es of usability, which is the same thing as the Nielsen Norman Group's five quality attributes: ease of learning, ease of memorability, efficiency, error tolerance and enjoyment. She qualified it as the five Es, and she's got this really great work [?] about accessible personas, so check that out if you haven't done that before.

[00:08:37] What is that? Creating mockups. We're incorporating accessibility when we're creating mockups. That's great. As well as the design system; those seem to be the highest. And then visual QA. Well, if the rest are almost on par across the board, I hope you can appreciate how this feels unbalanced. Yes, we should be considering accessibility across the entire process, but the fact that we have a spike for visual QA is no good. We should be doing it a lot earlier. And we've got a spike at creating mockups, and design system creation is supposed to be in the middle, so you can see there would really be a big spike in the middle there.

[00:09:21] We need to plan for accessibility. We need to budget for it. We need to have goals, we need to have requirements, we need to have a definition of done that includes accessibility. Only when we set the team up for success can we actually start the design process.

Making accessibility a core component of your work

[00:09:38] Here's another question, then. What have you done to ensure that accessibility is a core component of your work? I didn't make up this question without intent, and the word core is actually at the core of the question. My goal in working with customers is that I want accessibility to just be a thing that you do. It's just a natural thing, just like we now design responsive. Back in the day, 10 years ago, it was really stressful trying to make everything go from desktop to mobile, but now we just do it. It's the same thing with accessibility. Emily, we have a hand here.

[00:10:24] Audience: We're using the Stark Figma plugin. But I find even with that, we're actually in delivery on a project at the moment, and we've gotten to the QA stage, and it's almost like the development team have just ignored some of the stuff that we have in Figma. We have to go back, and we've got to the stage where we're testing with screen readers, and it's not working. So sometimes you don't get buy-in even when you try. We'll have to rethink that the next time we're going into delivery: how we can really communicate to the development teams that it's not something that we're just doing, you actually have to do it as well.

[00:11:08] Karen: Yeah, it's one thing for your team in design to do your work with respect to accessibility, but if all the other stakeholders or participants aren't doing their work, then of course you're going to fail. Of course there are going to be issues or bugs. I think what's interesting is that the Stark Figma plugin is amazing, by the way. However, I think the problem with it is that it doesn't cover all of the requirements. There's a gap there as well. So it's a matter of understanding what your tools are, what they're good at and what they're not good at, and still trying to fill some of those other gaps. One thing a lot of our customers do is annotate. In the design space we annotate anyway, but there are certain things around interaction and behavior and intent that are really important to document in the design system. So thanks for that. Anyone else want to comment on anything?

[00:12:00] Okay, so we'll go here for a sec. Oh, who brought up the EU legislation? We had a panel on that yesterday. It's helping stakeholders, forcing them to care. I would agree with that sentiment. But admittedly, with any of the laws that have been implemented in the last 30 years or so, that is the intent. We're forcing organizations to care more about accessibility, but for good reason. What we're trying to do is create amazing experiences. The laws are just helping us to make amazing experiences for everybody. It should be that simple, and that should be our intent: to make sure that everyone has an amazing time, they can do whatever they want to do quickly and easily and efficiently, and they get delight and enjoyment out of it as well.

[00:12:52] Education. There are a couple of comments about education. It's key. There are a lot of good courses out there, a lot of good training, and I think, just like in the design space, the accessibility space is a matter of continuous education. There's always something new to learn. You put yourself in your swim lane and learn as much as possible, but accessibility is so diverse that it can be really important to understand somebody else's swim lane with respect to accessibility. The broader your perspective about other people's responsibilities, the better you're going to be able to collaborate, in my opinion.

[00:13:36] Yeah, so Figma again. Trying to get participants with disabilities, again. Talking to dev, again. There are so many parallels between how we work just in design and working with dev, and the accessibility space. We need to break down our silos, we need to collaborate, we need to work together, so that we wouldn't have this situation where dev isn't aware, or they don't have the requirements, or whatever the problem was over here. We bring dev up into the design process and include them in our design reviews, or actually even before that. I always need to talk to my dev. I need to problem solve with them because I don't know everything. Sometimes there are dev constraints I have absolutely no clue about, and so we need to work together.

[00:14:27] And it's not even just UX and dev. Sometimes we need to bring content into the conversation, because we want to make sure that we're templatized. Say there's a button, but it just says edit, and we can templatize it so that we have context for our screen reader users. Edit what? Oh, edit the product name. So that requires a couple of different functions working together.

Who is responsible for accessibility in the design system

[00:14:51] Okay, so moving on, we have another poll. Yes or no, if you can let us know: have you personally... it disappeared here, sorry... I've personally contributed to the success of my design system. Does anybody feel really confident that you've had a strong hand, or finger, or toe, in making that design system accessible? We have a lot of yeses. I'm really glad to see that. I didn't have a follow-up on this, but it'd be interesting to know what your function is: design, content, dev. More yeses than nos, and I'm actually really glad to see that.

[00:15:36] One more discussion question, then. Who should be responsible, who is responsible, for maintaining the accessibility standards within your design system? Does that mean design files? Does that mean dev's coded components in Storybook or whatever? Does that mean your governance and your documentation? I ask you this because I think it's probably all of the above, and probably more. Is there anybody that wanted to comment here? We got some. "Everyone's not a software engineer." I think that's funny. Yeah, we have a question here. Thanks, Emily.

[00:16:21] Audience: I'd be really interested to know if anyone else has looked at bringing in a corporate legal team. We're a big corporate, and we're actually using our legal team to start looking at accessibility, almost taking it out of design. As there's new legal stuff coming in, getting actual legal people to look at it puts it more on the map. I don't know if that's something you've looked at or anyone else has looked at. I'd be really keen to learn if they have, but that's something we're looking at right now, what that could look like.

[00:16:51] Karen: Can I ask you a question? How specifically are you engaging that legal team? Are they looking at your design files, or other?

[00:17:01] Audience: A lot of it: we brought them in initially around all of the new legal stuff coming in, because we were basically trying to justify: we need to do this, because if we don't, we'll get sued. So we brought them in on that side, and because we then had actual lawyers in our corporate legal team talking, who are very respected, versus us, that really helped us. So we're looking at how we can lean on that more and bring them in more. They won't be doing the reviews, we'll be doing all of that, but it will almost be partnering with legal: this is legal requirements, versus this is just the design team wanting to help people.

[00:17:40] Karen: What's nice about that, if I may comment, is that it seems like bringing the legal team in, in this case, you're working more as partners, as opposed to what we hear a lot. Again, I'm in Canada, and we do a lot of work in the States, and there's a lot of suing with respect to accessibility. With a lot of our customers, it is legal mandating; they're being told what to do, as opposed to what it sounds like here, that partnership. That's really the way it should work. Everybody, again, is responsible for accessibility. Everybody has a role to play. So if we're collaborating and pulling legal in to be a teammate, that's actually the best way to go about doing it, because everybody's on board and everybody is working towards the same mission. That's lovely to hear, thanks for that.

[00:18:25] Sorry, I just looked: "the intern". The intern's responsible. Actually, that's funny, because it could be true. I had an intern. It's a great way to bring juniors on board: to say, hey, you're responsible for making sure that we're documenting all the teeny tiny, nitty-gritty things. It's the grunt work, which juniors are good at, but at the same time they learn a ton. You're growing them, and they go off somewhere else and bring that passion for accessibility into whatever else they do. It's actually an excellent way to grow an intern.

[00:19:02] Anyone involved in the design system, everybody on the product team. I do think that everybody has a responsibility, but it's also possible to have one or two people who have the responsibility, or are decision makers, with respect to governance, if that makes sense. There are some specialties where we need that additional help. As in design, it depends. The answer is everybody, but sometimes you need some specialty as well.

Setting developers up for success and documenting accessibility

[00:19:32] Okay, so we have another poll. How confident are you that your team's output is going to set developers up to do their best work with respect to accessibility? I'm talking to the creatives and the content people in the room. How confident are you that whatever you're outputting, the accessibility is totally amazing, so that dev can just grab it and run with it and do whatever they've got to do? Because, to this person's point before, they have their own responsibilities with accessibility. They have to code it properly. But we have our responsibilities in the design and content creation space. So how confident are we that we've set dev up for success?

[00:20:15] Somewhat unsure, somewhat confident. Okay, I'll take both of those. My guess, and I don't want anyone to take this the wrong way, is that you haven't been enabled with understanding the full set of your accessibility responsibilities. That's very commonplace. I'm known in the industry as being very opinionated as to who's responsible for what in the accessibility space. And in addition to that, I don't think that we've enabled the design and content community with understanding even that full set of requirements, let alone who's responsible for them.

[00:20:59] How about another discussion question, if my slides will advance. What are some of your best practices for documenting accessibility in design systems? I bring this up because the poll question was in regards to whether we are setting dev up for success. One of the ways that we set dev up for success is by, quote unquote, annotating our designs. We might use a tool like the Stark Figma plugin, and it's actually really cool because it can scan your design and help you with the focus order, and you can add headings, and here's a landmark, let's throw a skip link in here, that kind of thing. But there are also some comments that you can leave for dev, whether you're doing so in Figma, in Confluence or Jira or Asana or whatever you're using.

[00:21:46] There's just some stuff that can't be conveyed in the visual representation. I mentioned interaction and behavior and that kind of thing. That's a good example of something where I want to annotate it for dev. So we've got annotations in Figma. We've got comments in code. We have a dedicated portal with all the requirements and how to achieve them. Sure, there's what I'm going to call storefronts, like zeroheight and Supernova and Knapsack. Those are storefronts, I think, that combine your design files and your dev coded components and all of your documentation.

[00:22:33] I will say that if we can document as much as possible at the smallest pieces in the design system, talking components, even your buttons and your links and whatever, if we figure everything out as much as possible for these smallest pieces, then when we get to the larger pieces, when we're using them, there is less guesswork, if you will. Documentation has always been a bit of an issue, would you agree, between design and dev, just in general. When I first had to write documentation in Confluence for jeep.com a number of years ago, it was horrible. I hated doing it.

[00:23:17] Now there are a lot of really good tools that we can use, and there are some good ones in the accessibility space. But I think it's important to remember that breaking down silos is really important. If there's an opportunity to talk to dev, don't just annotate. Again, talk to dev about what your expectations are, about how this thing is going to work, how it's going to be used. And also keep in mind with respect to your documentation: if you have a lot of people touching your design system, whether they're actually working on it or using it to create something else, the more people there are, the more guardrails you have to set. Your goal with this design system is that people can just grab and go. We've figured everything out with respect to that design system, so you just grab it, and there's a little bit of guidance about how you can use it. That should include some accessibility considerations.

Measuring accessibility: tying it to usability and business metrics

[00:24:14] Just looking to see if anyone's raising a hand, a toe, a finger. Okay, so we have one more poll here and one last discussion question. How confident are you with respect to this statement: my organization has accessibility metrics that map to business metrics. You could even ask yourself: does my organization have usability metrics that map to business metrics? And do you have accessibility metrics that map to your usability metrics that map to your business metrics? Oh. 93% say no. I'm shocked at that number, but I was guessing it would be really high like that.

[00:25:00] The reason I asked that is because I wanted to ask a different question that's in line with it, so here's our last discussion question. What have you, or your teams, done to actually try to measure the effectiveness of your accessibility initiatives? It's in the context of design systems, but that's okay, it doesn't have to be. What are you actively doing right now to measure the success of your accessibility initiatives? Anybody?

[00:25:33] Now, how do I even pronounce that? "Nothing." "We perform assessments on our solutions." Okay, that's excellent. Again, I mentioned my company does manual evaluations on digital properties. There's a bunch of accessibility-focused companies that do that, and that's actually really important. With the EAA, the European Accessibility Act, that's coming in, and I'm guessing most of you are beholden to that act, it's something that you're going to have to do. You have to test your digital properties. And the EAA covers any product or service that a consumer would interface with, so that includes hardware: kiosks and point of sale terminals. So you have to take a look at your portfolio and say, okay, what have we got, what does the EAA apply to? We need to test this stuff, we need to find what issues there are, and we need to make a roadmap on how we're going to execute on it.

[00:26:30] But that's just one way of measuring your effectiveness. You're probably going to have to start reporting on how well your organization is doing with respect to accessibility, and you have to have a roadmap on how you're going to start to improve. These are some of the things that the EAA is asking of you. So if you don't know how to measure right now, testing is definitely one way to go about doing it. But the key is in the framing of the question that I proposed to you.

[00:26:59] Maybe I'll rephrase just for a second, and we can get a raise of hands or toes or whatnot. Who has usability metrics that are tied to business metrics? Does anybody? I don't see any hands. No? Okay, so maybe start there, because in my experience working with customers, you want to do that first. You want to make sure that you're showing ROI on usability, and that it ties to whatever your business is, what's important to the business. Start with usability, because I find we just have more traction in the design space by getting people to understand the usability issues. It's been around a lot longer than accessibility; that's the reason why I'm pushing that.

[00:27:44] Then what you can try to do is tie some accessibility metrics to your usability metrics. They're not that different. If you can show: hey, we found this accessibility bug, for instance contrast, and we fixed it, and now as a result we're not seeing the same number of people, with a heat map or something, focusing on this particular widget. We inferred that the time they spent focusing on that widget was because the contrast was so low, and because we fixed the contrast, we've freed up their time. You can do quantitative research on time on task and that kind of thing. All of your typical usability research you can start to apply to accessibility problems, and you can prove your case that the effort you're putting in has significant value.

[00:28:32] Cool. Okay, I'm seeing Lighthouse, I'm seeing dev tools. Those are all really great. It's all about testing. Did we see... yeah, we have a hand here. Probably the last comment before I think we have to close.

Q&A

[00:28:40] Audience: I just had a question around usability metrics and tying them to business metrics. At least in our enterprise organizations, sometimes they're really far-fetched, abstract goals. It would be great to get some examples from you of usability metrics and how those tie to the more overarching enterprise business metrics that we might be receiving as a team.

[00:29:03] Karen: That's a really good question, and I'm going to be totally honest: I think it would be better suited for one of our myriad of research professionals, just because they spend more time there, and I spend more time in the accessibility space, not the usability space, these days. I apologize for not answering, but I want to be honest with you.

[00:29:22] Audience: Of course, no, I appreciate that. But maybe from an accessibility perspective, then: do you have an example of a metric that you personally use in your work when you're tracking metrics?

[00:29:31] Karen: Okay, well, that's a good question. We are software as a service. We have a platform where we track all of our customers' accessibility endeavors: all their digital properties, all of the bugs that they have, and remediation, all that stuff. So we have our own software, and the things that are important for us are very similar to the last speaker on the other stage. It's enterprise, it's platform, and what's important to them is efficiency and executing on these bugs that they have. How quickly can we get them to understand what the issues even are? Because if you do a manual evaluation, you've got a thousand, 2,000, 5,000 bugs sometimes. How do you find the themes?

[00:30:12] If we can help our customers find themes and then start to execute on that, that for them ties into efficiency on their own side. I'm not articulating this well, but we're looking at helping them identify issues, and then actually tying it to their own business metrics too, because if they have success in their outcomes, then we're having success in our outcomes. Does that make sense?

[00:30:42] Audience: Yeah, for sure.

[00:30:43] Karen: Okay, I hope so. So this is great. Thanks, everybody. Again, my name is Karen Hawkins. I'm going to pull Katherine back up here, but thanks again. If you have any accessibility questions, I'll be around. Nice to meet you.