Stay up-to-date on the latest episodes of Allied

Accessible Design Systems with Joe Baker

April 21, 2023

Transcript


Welcome to 3Play Media’s Allied Podcast, a show on all things accessibility. This month, we’re excited to share an episode with Joe Baker on accessible design systems.

Joe Baker is the Senior Product Manager for Accessibility for the Design System at Atlassian and has previously worked on several digital accessibility teams, including at Amazon and Microsoft. He is passionate about building sustainable accessibility programs and design systems to ensure all customers are considered when building products and services. Utilizing his background in front-end development and UX design, he shares his guidance on his site Diga11y.com to help advocate for pushing past compliance and to focus on the user experience of people with disabilities.

Check out this episode on any of these platforms:

Want to get in touch? Email us at [email protected]. We’d love to hear from you.

Episode transcript

ELISA LEWIS: Welcome to Allied, the podcast for everything you need to know about web and video accessibility. I’m your host, Elisa Lewis. And I sit down with an accessibility expert each month to learn about their work.

Every episode has a transcript published with it, which can be viewed by accessing the episode on the 3Play Media website. If you like what you hear on Allied, please subscribe or leave a review. Allied is brought to you by 3Play Media, your video accessibility partner. Visit us at www.3playmedia.com to learn why thousands of customers trust us to make their video and media accessible.

[THEME MUSIC]

Today, we’re joined by Joe Baker to discuss all things accessible design systems. Joe is the senior product manager for accessibility for the design system at Atlassian and has previously worked on several digital accessibility teams, including at Amazon and Microsoft. He is passionate about building sustainable accessibility programs and design systems to ensure that all customers are considered when building products and services.

Utilizing his background in front-end development and UX design, he shares his guidance on his site Diga11y.com to help advocate for pushing past compliance and to focus on the user experience of people with disabilities. Thank you so much, Joe, for being here and joining us on Allied. We’re so excited to have you today.

JOE BAKER: Yeah, it’s a pleasure. I’m really excited to be here.

ELISA LEWIS: As we get started, I love to just ask our guests, what’s something important about who you are that you want to share with your audience that’s maybe not on your formal bio?

JOE BAKER: Yeah, something just more of a personal note, I’m lucky to be husband to my incredible wife. And I’ve got two daughters, Lily and Mackenzie. And my wife’s name is Kristen. And that’s something I don’t usually put out there. But that’s something that I’m really proud of.

Additionally, something that’s not in my bio is that I’m a founding partner of a creative and marketing agency based in Richmond, Virginia, called Pixelstrike Creative. So I still help them out with a lot of strategic initiatives and sort of the overall direction of the company. But, overall, I’m more focused on my day-to-day on accessibility.

ELISA LEWIS: I love it. Thank you for sharing that. I love the sort of personal piece and a little bit of another kind of side project. So that’s great.

I want to kind of start a little bit just talking about your career trajectory in general before we dive in to our topic today, which is really going to focus around design systems. So before getting into your role at Atlassian, how did you get into accessibility and design? When did that passion and commitment begin? And where did it come from?

JOE BAKER: Yeah, so, originally, I was– I wanted to be a network engineer. That was my path going to college. That was my end goal overall. I sort of quickly pivoted to doing sort of freelance design for different student organizations and different events that were happening within the university campus itself, started playing around with some HTML and doing some WordPress sites.

And after college, I was able to sort of spin that up into working in a lot of consulting agencies and became a full-time UX designer, front-end developer, developed my technical skills, and started Pixelstrike Creative. Shortly after sort of getting– after a couple of years of Pixelstrike Creative full-time, we had had a client that was diagnosed with ALS and quickly, unfortunately, lost the use of his limbs, except for some mobility in his arms. And I had some previous experience working at Capital One Bank with accessibility in that it was something that sort of came out at the end of a feature delivery. But that really sort of drove it home that this is something that affects everybody at some point in their life.

And so I decided to go full-time into accessibility. And I actually also started that. That same accessibility team that was dinging me for issues when I was the developer there, that’s the team I joined. And that was my first full-time role in accessibility.

ELISA LEWIS: Cool. It’s so fun when things come full circle like that. That’s a great story. I also know that you are the founder of Diga11y.com, which helps to advocate for pushing beyond compliance and really focusing on user experience when it comes to accessibility. At what point did you start that? And how does that fit into your sort of career journey and your journey with accessibility?

JOE BAKER: Yeah, so Diga11y is a consulting company, a side project that I have to my day-to-day, as well as a mentorship facilitator. So I currently mentor three or four folks in the accessibility space at big tech and sort of smaller companies as well. They’re either early in their journey, or they’re doing a career shift. And I’d like to really help those folks out.

Originally, I’d started Diga11y as a vehicle to share the knowledge, essentially. When I started in accessibility, it was really hard to find anything outside of specific role checklists. For instance, for design, you’ve got to check for color contrast. And that’s all well and good, but I wanted more.

I wanted, OK, well, how do you actually build a program? How do you scale it? What are the things to really be thinking about as you build that program?

And then how do you actually effectively communicate how accessibility is important? That’s come a long way since I started in accessibility, now in terms of articles on Medium and other things that you find across the web. But my Diga11y focus is a lot on the tactical stuff, the pragmatic approach of, you have this problem with accessibility, what are some things that you can do to tackle it that not only are scalable, but practical depending on the size of your company and your organization?

ELISA LEWIS: So I’m really glad that you brought up the idea of a checklist and kind of that you started Diga11y to move away from that or beyond that. It’s something that’s interesting to me because we’ve been talking about it a lot recently at 3Play. I’m on the marketing and brand side. So content is also in my wheelhouse.

And people love checklists. But when it comes to accessibility, I think checklists often give the sense that accessibility is something that can be done or completed, when really it’s something that’s sort of constantly evolving and there’s always room for improvement. So that’s kind of interesting. And just on a sort of personal note, I love that you brought that up. So thank you for sharing that.

I’m curious what about pursuing a career in accessibility has surprised you the most and what’s changed since you started. Like I said, accessibility is something that’s always kind of changing. And we kind of need to keep up with new trends and new technology. So, yeah, what surprised you the most? And what’s changed?

JOE BAKER: So the thing that surprised me the most when I started my career and still does to this day is how little I know and how much I have to learn about accessibility. As I mentioned previously, my first sort of foray into accessibility was mostly from a development standpoint. It’s, A, we have this problem. It must be fixed before it goes live to a customer. And as I dug deeper into it, you truly understand how widespread accessibility actually is in a company.

One of the best things– and it’s something I tell sort of mentees and other people who are possibly interested in getting into accessibility full-time– is that if you want to learn anything or if you want to be eclectic, wear multiple hats, go into accessibility. Because on any given day, I’m doing design, development, program management, KR writing, front-end services, back-end services. You’re doing a bit of everything.

You’re touching a little bit of every part of a company or product. And that really excites me. Because I have probably a million hobbies at this point. I never want to stop learning. And that’s something that I truly value about accessibility. And I’m pretty sure for the rest of my career, it’ll never change.

ELISA LEWIS: I love that. I think that’s such a great way to look at it. I know that you started your answer there saying that you don’t know a lot. But I think it’s really– what you touched on at the end is that there’s just always more to learn.

I think the other thing that I personally love about working in accessibility is, to your point, I think people are eager to learn. But people are also really eager to share their knowledge. And that’s a really cool place to be.

I do want to talk a little bit– I feel like we could have a whole episode on some of your side gigs in accessibility. But I do want to talk a little bit about your role at Atlassian. Can you share kind of what a day or maybe a week in the life looks like and what your job at Atlassian entails?

JOE BAKER: Sure, yeah, so Atlassian, in general, has this concept of, every team is managed by a triad or a squad. So I’m a product manager for accessibility for the Atlassian design system. I work very closely with an engineering manager and a design manager, both of which are also assigned to the accessibility team. And then those folks help manage sort of the timelines, the roadmap, and then the engineers and designers that sit with on that team.

So a typical part of my day is checking in with those folks, checking in with the work, checking in with our products– Jira and Confluence are probably the most well-known on their accessibility issues– adoption of the design system, and, broadly speaking, how do we integrate our customer feedback? Customers, for us, are not just our products. But they’re also our end users, a concept that we call “makers,” which are our designers and developers. How do we take all of that feedback, collate it, and then making sure that we’re prioritizing the right amount of work for the right people for the right reasons?

ELISA LEWIS: And I’m curious, particularly, you know, working with so many different people on so many different teams, how has accessibility changed or developed in recent years? And is there anything that’s kind of stood out to you about from the development side, really– or design side– getting accessibility in kind of from the beginning? Has that been a challenge? Has there been pushback? Has it been easy to gain buy-in? And, again, has that– how has that changed over the years?

JOE BAKER: Yeah, so I’m very fortunate at Atlassian that the typical struggle for accessibility in any company is getting folks to care about it, right, having it added to the roadmaps, having people even just generally aware of what it would take in order for something to be accessible. Atlassian is very passionate about the customer and the end user experience. And so from day one, I had people already fighting for accessibility who were not on any accessibility role or team or anything like that.

The hard part gets into, everybody cares about it, but then it’s, you have the empathy aspect locked down, but then it’s the impact. OK, great, we care about it. How do we actually do it? And that’s usually, at a company, where problems occur.

So how it’s changed at Atlassian in the past couple of years is that we now have dedicated roles specific to accessibility that are focused on training, QA testing, working with our large clients. And this accessibility team within the design system is brand new as well as of last year. So we have a full– the concentration on accessibility is sort of the big sweeping change as we sort of adapt to the different products and the different legal landscapes that we’re going to be encountering here in the next couple of years.

ELISA LEWIS: It’s really great to have this background. I do want to pivot the conversation over to design systems. I think it’s good to start broadly. Our audience comes from various areas of accessibility. So can you kind of share for us, what is a design system? And why is it important? And then also, what does a design system entail?

JOE BAKER: Sure, yeah. So a common misconception about a design system is that it’s a component library, essentially reusable design and code that developers and designers can just pick up, use, and then that’s it. A fully matured design system has far more components to it, such as content, patterns, resources, brand activities and resources, and something that we call tokens, which is a popular thing in mature design systems, which is essentially assigning a name to a color. And so if you scale out colors correctly, you only have to change it in one place and it changes everywhere.

A design system is really important because it allows you to scale design brands effectively. And it allows the makers– the designers and developers that use that design system– to focus on the real problems, the real customer experience, and reduces their time spent on solving the same issues repeatedly. Specific to accessibility, the great thing about design systems is you solve compliance or a user experience issue once and it’s solved for the entire company.

You don’t have to iterate it on again. You don’t have to spend time, money, or other resources to solve it. And it allows you to really focus not just on the user experience, but also the research and the patterns, the interactions, and other things that heavily go into what would typically be problems at a company for accessibility just to be remediated once.

ELISA LEWIS: And I’m curious, who’s typically responsible or involved in creating the design system? And is there anyone that’s specifically focused on accessibility?

JOE BAKER: Yeah, so if you’re fortunate like me to have a team purely focused on accessibility and design system, it would be that team. The broad answer is everybody. Everybody is responsible for it.

One of the things that a great design system will really tap into is that if you don’t have a dedicated accessibility team– because that is fairly rare– you’re able to place accessibility throughout the design system in different ways. You can do that through definition of done files, where essentially it’s a checklist of, these are things that must be completed at each step of a process– either a component or pattern delivery– but also in resources. And the big thing is content. As design systems are handing off all of the work that they have done, it’s really important that they document how to use it accessibly. If there are problems that occur because of the implementation down the road of the use of a design system, it’s really important that folks have that fallback to understand why that’s a problem and what the customer impact is.

ELISA LEWIS: Yeah, so that leads me to a question. I had seen a statistic from Deque that about 67% of accessibility issues start in design. But many people assume that accessibility is the job of developers. Do you have any idea where this assumption comes from? And how can design systems help address this?

JOE BAKER: So, traditionally, that’s, in a product lifecycle– the engineering part of the lifecycle is where the issues are identified because of automated testing. And that’s the actual experience. That’s the actual usable area. So that’s sort of where that myth comes from. It’s where the problems are found typically versus where they originate.

So the reality is that in a lot of product teams, the flow is to go from design immediately to development. And a developer will just blindly follow the design patterns or design that has been given to them without understanding what the customer impact, particularly to people with disabilities, would be. And that’s due to a number of factors.

Primarily, it’s time. They don’t have time to look into this thing. There’s no time to question. A timeline has been set. A roadmap has been delivered. And you have to meet that. So shifting accessibility left into a design and iterated process helps folks really understand a lot of those core issues.

And there’s a statistic as well by Anna Cook, who did an article on Deque. It’s 36 times more expensive to fix an issue in production than it is in design. So let’s take, for example, you develop a button. It has a color contrast issue. It’s identified on your website.

You have to go back all the way through that whole process again. And you have to understand too that if you’re changing something in one place and you’re not changing it in other places, that leads to terrible user experience as well as your brand perception goes down. So it affects multiple things where the designer is sort of the key holder to unlock that door to make sure that they really understand that everything starts from them, but it ends up as a problem in a different area. And it’s on them to solve that.

ELISA LEWIS: Yeah, that’s a fantastic statistic. I think we always talk about baking accessibility and from the beginning. But that really hits home on not just why it’s important, but from a financial perspective what the benefit is and what you can avoid by doing so. I’m curious if you can give an example of what a design system might look like when it includes accessibility versus what one looks like when it doesn’t.

JOE BAKER: Yeah, for me, there’s a major flag to look at to– and that’s the documentation on that site. I talked about this a little bit earlier, but if your site has a component library and there isn’t an accessibility section provided to your developers specifically, but also your designers, on the accessibility considerations, accessibility problems, relevance, WCAG– or Web Content Accessibility Guideline success criteria– sort of the teaching person how to fish kind of thing, you’re not scaling out that knowledge. You’ve made the decisions, but communicating that out, how to effectively use those components and the customer impact– which I can’t say enough. The customer impact has to always be identified.

Another common flag that I see is in a design system, as you mentioned, a lot of design systems who are sort of newer are just the component library, right? So a mature design system like Google Material or Atlassian design has a section called foundations. And foundations is a core component to any design system that focuses on the patterns– the main patterns that a design system would use– for instance, colors, spacing, grid, just to name a couple. The emphasis on creating those, documenting those, and solving those problems that then scale out through not only design system, but other products, is key to making sure that accessibility is at the very forefront, at the very start anything to do with a design system.

ELISA LEWIS: Yeah, that makes a ton of sense. How are different kinds of disabilities considered when designing a system to be accessible?

JOE BAKER: Yeah, generally, all forms of disabilities are considered for us, certainly, and certainly for the much more mature design systems. So the main cohorts being vision, hearing, mobility, and cognitive. And then there’s a broad range in between each one of those buckets. Each of those four groups have to be evaluated in different ways, particularly to make sure that you’re covering the needs of those cohorts. But a key emphasis should be– I think– not to necessarily focus on the cohorts and sort of that checklist of things, but how do users actually interact with your components, with your end user experience?

For example, if folks have a mobility impairment and they’re using assistive technology, a lot of that times for them to navigate requires the use of a keyboard or something that relies on keyboard navigation. So it’s important to not say, hey, we’re going to check off all mobility impairments for good. But it’s, how is the keyboard interaction?

Same thing for vision impaired users, it’s not, hey, a screen reader works or it announces– it does announce something or status to a user, but what does it announce? What’s the actual user experience?

And really making sure, too, that manual testing people with lived experience– I cannot stress this enough either– should absolutely be integrated into your process. We have automated testing throughout the design system, as most folks do.

But we also have folks with lived experience who will review every component before it goes out. And we get tons of feedback. Hey, this is great, but this is actually the user experience I’m expecting. And we’ll run that through several times. That is core to sort of the things that we do to make sure that it is accessible.

ELISA LEWIS: Absolutely, yeah, that’s a huge part of it is making sure that you’re involving those people who have that lived experience and who rely on certain technologies to actually be part of the testing and do the testing and, of course, get paid for that testing that they’re doing. I’m curious, you talked a little bit about user interaction and user experience. And I think there’s something interesting sort of about the obvious accessible design or design in general versus kind of subtle design. I think when individuals think about design, they assume that design means making things look good or pretty. And that’s kind of the obvious part of the design or obvious part of design.

But design is also navigation. It’s the user interaction, the user experience, the way a problem is solved. And I’m curious if you could talk a little bit about this and kind of what the more subtle space looks like, just broadly, and then also from an accessibility standpoint.

JOE BAKER: Yeah, I mean, actually, I can do both from a broad and accessibility standpoint. It’s about the usability of it. So it’s getting back to those foundations of ensuring that who your customers are, you’re building for the right people for the right reasons, are checked out sort of at the beginning.

So as I mentioned, Atlassian design system has a series of foundations already baked in. The colors, again, sort of gets into the visual aspects, the obviousness. But you’ve got to get into interaction patterns and motion design. And then even then, you have to understand how spacing works, how far apart things should be spread apart, how close buttons should be in relation to their forms. There’s a lot of little details that you can get into, particularly on a design front, that craft the overall experience.

And it’s really key to ensure that you’re not only looking at it from a basic point of, we’ve solved accessibility or user experience for one component, but the overall page level, making sure that makes sense. And then testing it against another page. Does it make sense in relation to that? Do you have a common flow? There’s a lot of psychology into the subtle part, I think, is where the differentiation is on how a user experiences it and something that every design system should take a close look at.

ELISA LEWIS: Yeah, I think that’s a really great point and a nice segue into understanding how the design system really works across different types of design. Can you talk a little bit about how decisions are made at scale, how making things accessible at scale works across an organization? Particularly, if there’s a larger organization, how do you sort of gain that buy-in to the design system?

JOE BAKER: Yeah, I mean, this alone could be a podcast into its own and sort of the whole– one of the main drivers of why I started Diga11y. The common misconception, I think, that a lot of folks have around a design system is that it’s a platform, it’s something that people are used– I would heavily suggest if folks are either starting a design system or they have one in place, to mentally shift and turn it into a product mindset. So find your partners that are interested in using the system– whether those be product managers, design leaders, engineering leaders.

Find out what their problems are. Do your customer research. Identify what those problems are. And attack those problems. Give them a solution to make their lives easier.

It’s sort of easier to start more with product folks, as they’re the ones driving timelines and milestones. Same thing with sort of heads of departments. But it’s really integral that you get that buy-in from all the roles.

If you’re starting out a design system or your design system is there but it’s not well adopted, start small. Get one partner, go from there. Figure out what their problems are. Test it out. Test everything you’ve got going.

Does it work for them at scale? Then go on to the next partner. The more and more you get, it turns– a small pebble turns into an avalanche.

Really key too is having your data. I mean, you need to know the amount of design and engineering time a design system solves for. You need to know what issues are currently in product backlogs that these would solve for. They don’t have to spend the time, the manpower, or the resources to fix those if they just adopt something you’ve already solved for.

And just creating that standardized approach as well helps a lot of engineers and designers on product teams evaluate, hey, this is something that has already been solved. Why don’t we go after this particular problem that only we can solve? Let’s be creative about that.

And the last point, I think, that broadly speaking, you have to really understand too, the customers’ needs, as I mentioned before. But you have to make resources for those makers. You have to make sure that your documentation is 100% ready to go, it’s very clear, concise. Folks without a background or just onboarded to that company can immediately get to a Getting Started page or go through your site’s documentation and pick it up and start going.

You need to provide not just the content, Figma libraries, component libraries, basic stuff where people can grab and go. And don’t make it hard on them. Make it hard on the design system to create. Then make it easier down the road.

ELISA LEWIS: I particularly love the point that you made about really kind of showing the stats and the numbers about the time and kind of problems that having the design system can solve. I think for a lot of people, particularly some of the teams that you mentioned– the product team, engineers– I think everyone across an organization loves to see what the results are. So I think that’s a really great, tangible suggestion there. So thank you for that.

I know we touched on it a little bit earlier in the conversation. But I want to jump back for a moment and just talk a little bit more about testing. We certainly talked about how important it is to have individuals who are users of certain technology and who have lived experience. But I’m curious if you could also touch on automation in the testing process and kind of where that may fall short. Are there any examples of commonly missed accessibility issues that are hard for automated testing to catch, but can maybe more easily be tested manually?

JOE BAKER: Yeah, there’s a bunch. I’ll give a quick example. So there’s four main types of automated testing as it relates to accessibility. You have linting, which is essentially, as a developer, is coding something, it throws an issue or it throws an error. And they can fix it in real time. Scanning, there’s a user experience that gets scanned by a set of accessibility rules. And a set of issues are popped out.

The other two are integration and unit testing. Those I’ll get to here in a second. Those are the two sort of pain points right there, unit and integration, in that unit testing primarily focuses on, we’re going to test the batch of code and make sure that that’s accessible. The primary problem with unit testing is that a lot of unit testing requires it to have a holistic understanding of everything that’s going into the code.

So typically with JavaScript frameworks, you’ll be working on a tiny piece in the code. And you reference the parent elements that get rendered to a user experience. If that code doesn’t know that those parent elements exist and that unit test doesn’t know that either, it’s going to throw issues where there actually are no issues, it’s actually fine.

Integration testing, as well, is really key. There’s not a lot of maturity overall for accessibility outside of design systems, or at other companies in this space, mostly because it’s tricky to add. It adds a lot of complexity.

You have to make a lot of program decisions about, do you block something from being deployed? Are folks comfortable with that? To what severity? There’s a lot of minutiae around that.

So automated testing overall catches, 40%– if I’m being generous, 50% of all accessibility issues. And when I say that, it’s not WCAG criteria that I’m mentioning. It’s literally user experience issues is what I’m referring to. A good example where manual testing is absolutely critical, something I referenced before– so automated testing, if you are doing a status message to a screen reader user, automated testing could really only tell that that status message exists. But that status message could sort of not make sense the end user. It could actually confuse them wildly. Or that status message is something that is repeated from an earlier instance, causing even more confusion. So it’s really critical that you have manual testing for the issues that rely on context of the page, context of the content.

And, in addition to that, there’s no real automated testing for cognitive disabilities right now. And that’s, you know, I’m hoping with this recent surge in AI that everybody’s had 20 blogs a day about, that that sort of can be solved, that both the context, as well as some of the cognitive disability issues. But the reality is that there’s no tests that sort of automatically fix those or let alone detect those.

ELISA LEWIS: Yeah, that’s really helpful to hear those examples. And you’re right, we’re at a very interesting time where I think there’s a lot of opportunity to further and enhance accessibility. But I guess only time will tell how that pans out.

So as we wrap up, I would love to just get some of your advice to share with our audience. What advice would you give to companies or, maybe more so, to individuals at companies who really want to bake accessibility into their design systems? Maybe they don’t know where to start, or maybe there’s a pre-established design system in place. What can you share with them?

JOE BAKER: I think it’s really important that folks working in accessibility and design systems understand what their actual current status is. One of the first things that we’ve done here at Atlassian is gone through the components. And we’re doing a full audit, both manual and automated, to find any and all issues with our components.

It’s a full audit of those components, a full audit of your resources. Really understanding, again, talking to your customers, the people using the design system. How do they feel about accessibility? Do they know anything about it? Is it a problem? And truly understanding exactly where accessibility should sit within a company is also key.

I’ve been at a number of different companies. I’ve been at Amazon, Microsoft, Capital One. I’m currently here at Atlassian. Every single one of those accessibility teams has sat in a different work, different place, wildly different from the other. You have sort of the legal and compliance sections.

When I was at Capital One, that’s where that accessibility team sat. Amazon, it sat on the product team. Microsoft, specifically Xbox, focused more on just general program management. And then, of course, my current role is in a very specific centralized focus on a design system.

So it’s sort of understanding in your company, where are things tested? Where should accessibility sort of sit in that company from a logistical standpoint in order to make sure that it’s effective, scalable? And I think if you’re just starting out in accessibility and really want to get folks into accessibility, there’s sort of two primary tools that I would highly suggest. It’s sort of what I call the carrot and stick model.

So the stick is learn the legal ramifications of folks who do not do accessibility. I’m wearing a Judy Heumann shirt, who famously really helped get the Rehabilitation Act passed that had Section 508 in it. That was one of the first of many laws in the United States that a lot of folks have to follow in order to be accessible and to make sure that you don’t lose any revenue, let alone for some of these compliance issues.

But we also have the Americans with Disabilities Act. That is a very key thing. That’s where a lot of those regulations and sort of where the Web Content Accessibility Guideline standard originally sort of stems from, or at least the creation of it.

And just be aware of the cases, the legal cases that have happened in the past. The previous litigation that happened, if you don’t do accessibility, if you’re working in a large company, you are absolutely at risk for being sued if you are not resolving those issues. If it’s not baked in, you don’t have a public roadmap for accessibility. Smaller companies, you know, less noticeable, but for the end user experience, you should always worry about that.

The carrot part of it that I really enjoy doing– and I’ve used this at multiple companies– is if you’re meeting some objections to adding accessibility to a product, from a product manager or a product leader or design and engineering, something that I really love doing is getting that team into a room, bringing in someone with lived experience, particularly one that is– those issues are mostly focused on. I think a screen reader one is probably a great one.

Bring in somebody who uses a screen reader every day. Have them go through the experience so that everybody can hear and see it. And 10 out of 10 times, the product folks in that room, the makers, genuinely are shocked about the experience, how bad it can be, and how unusable it is. And I think if you focus on the empathy part, building that empathy, why it matters, you’ve got to also drive that impact part and making sure that folks know how to fix it, where to fix it, and when to fix it.

ELISA LEWIS: I’d actually love to sort of leave off with that empathy piece. I know you had a recent article on your site, on Diga11y, about measuring empathy and accessibility. I’m sure, again, that could be a whole other episode. But could you give us the high-level takeaways? And I would encourage everyone to then go check out and read the article.

JOE BAKER: Yeah, so one of the– this is one of the main things that I was particularly trying to find information on when I started my career in accessibility was, it’s very easy to measure, OK, how many issues that we’ve fixed, how to get quantitative data and qualitative data from those. But it’s not easy to sort of– and generally most companies don’t measure how do we feel about this particular thing? And so in that article, I mentioned sort of a few techniques that you can go to.

Employing an internal survey to folks– how do you feel about accessibility? What’s your knowledge on accessibility? And sort of what trainings do you, have you ever attended, conferences, that kind of thing? Sort of understanding where they’re at for a mental model. Taking those and sort of helping create internal training processes and programs as well is key.

And as you create that training, you can use those metrics from that training. How many people attended? Are you getting requests– not just individually– different crafts, different organizations, different products? Who’s concerned about accessibility? How many people are coming? The different topics.

And the last major area, I think, is customer sentiment, which is, I think, probably the most important and the ultimate one is you need to understand your end users, how they feel about your product as it relates to them. And there’s a number of different ways that you can do that. User? interviews and surveys. You can use social media to understand. Use specific keywords in your customer reviews. If you have previously identified customers with disabilities that you could interview. And then a lot of folks end up having a review or customer support database that you can research.

You mentioned this earlier, if you are interviewing people for their opinions, no matter what, pay them. Gift bags and little tchotchkes are not enough. This is their time. Pay them please for their time. You’re asking for their opinion. Pay them for that opinion.

And there’s a number of organizations too. I list out a few that you can go to. Every country has its own specialized accessibility research company. When I was at Amazon, I was fortunate to work with one specifically just for Germany. That was fantastic.

But you can reach out to different lighthouse institutions around that we have. There’s the American Foundation for the Blind, the National Federation of the Blind. There’s lots of resources you can reach out to as well. If you don’t have those folks previously identified or you just really don’t know how to do that user interview– I mean, you genuinely, you want to do the right thing, but you don’t know what’s the right terminology, what are some accessibility problems, conducting these surveys, the best way to approach those, those organizations are great to reach out to.

ELISA LEWIS: Absolutely Thank you for sharing that. And like I said, I encourage listeners to take a look at the whole article. But I think it’s a really interesting topic to close us out today, talking about the empathy piece of accessibility. So thanks again for sharing. And thank you, Joe, so much for being on the podcast today.

JOE BAKER: Yeah, great, it’s been a pleasure.

[MUSIC PLAYING]

ELISA LEWIS: Thanks for listening to Allied. If you enjoyed this episode and you’d like to help support the podcast, please share it with others, post about it on social media, or leave us a rating and review. To catch all the latest on accessibility, visit www.3playmedia.com/alliedpodcast. Thanks again, and I’ll see you next time.


Contact Us

 

Thank you for listening to Allied! For show information and updates, visit our website. To get in touch, email us at [email protected].

Follow us on social media! We can be found on Facebook and Twitter.