We're sunsetting PodQuest on 2025-07-28. Thank you for your support!
Export Podcast Subscriptions
cover of episode #96 Designing for accessibility w/ Anna Cook

#96 Designing for accessibility w/ Anna Cook

2024/3/13
logo of podcast Honest UX Talks

Honest UX Talks

AI Deep Dive AI Chapters Transcript
People
A
Anna Cook
M
Matt May
Topics
Anna Cook:无障碍性设计常常被忽视,原因在于产品组织中存在的偏见,他们低估了无障碍性的价值,并且没有充分考虑残疾用户的需求。许多组织将无障碍性视为锦上添花而非必需品,这与合规性要求有关。早期无障碍性实践主要集中在开发和测试阶段,而设计阶段则被忽视。设计师普遍缺乏这方面的培训,这使得他们难以将无障碍性融入设计流程中。基于合规性的无障碍性设计只是最低标准,更重要的是满足人的需求。解决无障碍性问题需要从领导层开始,基层倡导者的努力需要领导层的支持才能产生显著的改变。微软的包容性设计方法论强调“为一人解决问题,惠及众人”的原则,通过解决障碍最严重的用户群体的问题,从而惠及所有用户。在快节奏的工作环境中,设计师需要找到方法来倡导无障碍性,并向产品经理和领导层展示其商业价值。利用现有的设计系统和组件可以降低成本,并提高可访问性。AI可以作为辅助工具,提升现有产品的可访问性,但不能作为解决所有可访问性问题的方案。 Matt May:可访问性设计需要很多人略知一二,少数人精通。

Deep Dive

Chapters
Accessibility is often overlooked in design due to biases within product organizations and a lack of emphasis on design in accessibility practices.

Shownotes Transcript

Translations:
中文

I want us as designers in our day to day, just think for a moment, where might I need to consider accessibility here? That the very question itself and investigating the answer is the most important part of bringing accessibility into your practice because it's a mindset. Matt May, who's another man in the inclusive design space, has said something along the lines of, we need a lot of people who know a little and a few people who know a lot about accessibility. So learn a little.

That's plenty. But also know that it cannot be on us as individuals to change an organization without leadership buy-in.

Hello, everybody, and welcome to the next episode. And the sponsor of today's episode is proudly presented by Mobin. I really love this tool because we use it at my work, and I also use it for my side projects. I'm very excited to have them as a sponsor. I love it because it saves me so much time. It's basically the world's largest UX UI library where you can filter apps by categories, UI elements, flows, and they have already

more than a thousand apps across 300 industries. So you can basically imagine finding there absolutely any pattern from any edge case from any industry. And the problem it solves, in my opinion, is that we as designers, when we save some inspiration screenshot from whatever app, we are usually looking at the app statically from one screen perspective.

And as we all know, UX is not static. It's not linear. There is a lot of nuance between screens, between interaction. There is a lot of progressive disclosure, right? When we try to minimize the amount of information on the screen. And so one screen reference is just not enough. There is a lot of context that you need to save. And Mobin already solved that. They have documented a lot of flows

And that's why I sincerely suggest you to check out Mobin. And instead of looking at one specific screen, you can look there with the flow perspective and you can save existing patterns from existing products, not just some dribble inspiration from the concept. You can analyze real apps and have a very holistic perspective rather than one app or whatever app that you have been able to access kind of perspective.

And also you can find there all possible edge cases, not just happy paths, but all the things that you cannot typically try out in the free apps. So if you're looking to save yourself some time as well as find edge cases from absolutely any industry, definitely check out Mobin. And a little ask for myself is please, when you register there, mention that you heard about this product from Honest UX Talks. This will really help us out by supporting our podcast so that we can create more conversations and more episodes in the future. And

yes, you will thank us later, like Joanna already mentioned earlier. Today, I'm joined by Anna Cook, who happened to be an accessibility inclusivity designer at Microsoft. She also has been, of course, on the same topic. I'm really excited to invite you today for the conversation. I was introduced to what you do by Steph Walter, also a very great and

fantastic content creator, mostly on LinkedIn. Check it out. I think it will be very useful for many designers. And that's the reason why we're talking about it today. We have been doing this podcast for about three years and I just realized we never really did a proper episode about it.

So because we with Ioana are not experts in the area, we decided to invite somebody who might speak to the casual designers who might need to know better or understand the field better and be able to prioritize it in our work. Did I miss anything, Ana?

No, I don't think so. Steph is amazing. I recommend you follow Steph Walter if you're not already. Also really good at focusing on design and accessibility in that intersection. And yeah, no, I think you covered it pretty well. Alrighty. I think especially in the last, let's say, up to five years, we started seeing this term of designing for accessibility, inclusivity. And today it almost feels like a buzzword. And I'm personally working as a product designer. So

We do sometimes have those like sort of features that we designed for accessibility. This is like a little extra thing we did, but I don't want to generalize. I'm pretty sure everybody works in different environments, but from what I've been working with and different contexts, accessibility was always more of a nice thing to have.

It almost sounds like a buzzword to many people, at least product designers in the product companies. I kind of just want to speak about it a little bit and see why do we use it as a buzzword? Why is it more of a nice thing to have? I think that mostly designers, when we think about accessibility, we're talking about, oh, we added those extra color modes. Or the best thing I've ever seen mostly product designers do is designing for, what's the right word to say this? Like audio tech? Screenwriter? Screenwriter. Yeah, exactly. Yeah.

So that's the extent to which we usually go for. Let's talk about it. Tell me what you have on your mind right now as I throw in everything at you. This is going to take a minute because I have a lot of thoughts on these things. One of the reasons that I think accessibility has been perceived as a nice to have is because of a lot of bias that exists within product organizations in terms of

who they believe their users are and the value that accessibility creates. And I think a lot of product leaders have a tendency due to a lot of systemic inequity and bias and prejudices to think that people don't have disabilities or their users don't have disabilities or that they don't have to account for these needs because they're not being raised by our users in these contexts.

I do not think that that is correct. And that's not anyone's fault. I'm not going to be like pointing fingers and wagging them at anyone. When we look at the whole disability rights movements that have occurred across the world and in many different contexts are still happening, a lot of what happened in many different societies is erasure. And so...

When we look at it from that perspective, it's a lot easier to understand, okay, there's a bias that exists and it's quite ubiquitous still. Even though there's been accessibility standards for over 30 years, screen readers have been built for, I think, what was it? The first one was built in the 80s. You can fact check me on that. But...

I think the other part of this that comes into play is that early accessibility practice has focused so much on development, engineer, and QA positions. And part of the reason for that is because there's a gap between what designers understand in terms of what they're building and what actually gets put out. And this exists regardless of whether you're focusing on accessibility, right? We have different words for different components, but

When the developer builds it, they're using a certain type of control, and that control behaves a certain way for an assistive tech user. That is all to say that design, it hasn't been emphasized in accessibility as much, partially because of the way that organizations have been structured to support accessibility in the past. And a lot of that's compliance-focused.

Part of the reason I think this is a really timely subject, I'm noticing a lot out of Europe right now, is because of the European Accessibility Act. And that's going to change probably a lot of the way that those structures within organizations working with the EU and inside the EU. So that's a long rant about some of the things I think about.

The other thing I'll mention is that designers across pretty much everywhere have not been taught to think about accessibility. That's not their fault. Again, these are changed management issues. And so, of course, it's kind of hard to grasp right now for a lot of us because it changes the way we design fundamentally. I have a lot of thoughts. You mentioned two things here.

One thing being that we see a change right now mainly happening because of the regulations, but not coming from, I guess, leadership or not coming from education. And I have a bad feeling about it. How come that we only comply because it's pushed to us and not because we...

we bottom up care about it. I know that in most of the organization, there is always advocate for accessibility and for inclusivity. It's not usually enough to have one or two people advocating for it. It's always great. And I think like sometimes it does drive the change. But in most of the cases, in my perception, and I'm really, I'm really sad for saying this, but it just feels like a nice to have in many, many projects. When I think about my past experience working in one big corporate organization,

I remember that, let's say, push for starting to design for inclusivity and accessibility was also coming with the main directive that, oh, we have those new compliance we had to now follow. Again, it was not coming from, we need to start thinking in a new way, right? But it was mostly coming from, okay, there are those regulations coming, we just need to comply. So let's just check the box, you know? I don't even know if I have the big question here, but I just wonder, how can we do it better?

How do we flip it and not

you know, being asked to design for accessibility and think about it. Should we maybe have a conversation about why accessibility is so important? Is that the way to start caring for it and change the status quo for us designers and how we design things? Should we as product designers start advocating more or should we rely on leadership or should we just say, that's fine, let's just go with the compliance and regulations and it will eventually become a norm? What are you thinking?

So you touch on a really interesting intersection and a lot of the issues we as designers tend to encounter when trying to think about accessibility and inclusive design. And the thing that comes to mind first is compliance-based accessibility, it's not everything. It is an essential and absolutely required aspect of this. But what happens when you think about it?

with compliance is often the bare minimum when it comes to accessibility. And when we're looking at it from that perspective, what usually happens is a developer will go in and add a bunch of code to fix issues. They'll hack into it and they'll do as much as they can in that regard.

While the compliance side of it is essential, I think what tends to happen is that it can be a little bit more, metaphorically speaking, stick than carrot. And designers, they don't necessarily get motivated by, I think,

thinking about it as like legal compliance need. And the reality, of course, is that it is a human need. Accessibility is part of design and it is very much about the people we are creating experiences for. So I think this touches on compliance is essential because we need organizations to at least do the minimum to make sure that access is ensured and available. But

when we as designers, again, are looking at something as a need, we don't often see compliance as a motivating or interesting aspect of the work we're doing. And

And so what tends to happen, right, is organizations will go, okay, we have to fix these things to be compliant. And we're going to have a developer, a bunch of engineers stack in some code to do that because that'll do enough to be compliant. But then, of course, what happens because of that is organizations tend not to, at least in early accessibility maturity models of an organization, they tend not to bring the people into that conversation. And there are a lot of people who are affected by those things.

I think the bias exists today that accessibility serves very few people, but that is very much not true. Of course, in the United States, we have the CDC data that says 26% of the American population on average has a disability. That data is going to vary where you are, who you're asking, because how we gather that data varies.

But it affects people who have permanent disabilities, who have temporary disabilities, or are in certain situations. Let's say like right now, if you have a baby crying in the background, it would be perhaps beneficial to have captions so that you can make sure you're not being distracted or like

You can still understand what I'm saying, but the people, those real needs get stripped out of our conversations in the design phase when we are only thinking about it. And again, compliance is essential, but when we are emphasizing compliance only, if that makes sense.

And the last thing, and I know I'm really, really good at rambling, I say this all the time, but the last thing I'll mention is the thing you touched on with who should in the design roles at a grassroots level be doing this, or should it come from leadership? And ultimately, what I tend to find happens the most with accessibility priorities is that everyone says they care about them, but when push comes to shove and something else has

to get done and we have a timeline, we get a lot of what I like to call a soft no, like we'll deal with it later. Suddenly your backlog is filled with a bunch of accessibility issues that aren't getting addressed. And so ultimately accessibility advocates in the grassroots or like lower levels of an organization should try.

But if leadership's not supporting it, there will not be enough significant change to benefit users at large. So leadership ultimately has to lead in this regard to help support the designers and our developers doing this work. Okay, so you have two topics here, and I'm kind of thinking which path to take right now. Okay, let's start from the ability bias, because you started talking about it, and I think this is a very interesting topic.

You did mention briefly that when we're talking about ability bias, right, it's not that we design for people who are permanently, I don't know, disabled. But obviously, there are different ways or different situations that we encounter throughout the life. And sometimes the disability might be temporary or situational, right? Do you remember that I was once designing for a hospitality context?

for the restaurants and it was like a point of sale sort of software for the restaurant and I think the first time I was introduced to the situational disability was learning from the restaurant waiters that they have to switch context very often from indoor to outdoor and the light is changing so when you are with a light mode on the outdoor and the sun is shining you cannot really see what's happening on the screen and you know you have to take orders you're stressing and

That's obviously situational impairment, but there are so many more of those cases when we don't think about it. And I really would love to hear maybe your point of view. How do we work with the disability bias? Because there are so many ways we don't think about when we're designing for disabilities. We always have this very strong perception that we're just designing for disabled people. And since they're not majority, let's just not prioritize them, especially if you're working in, I don't know, agile, fast pace, whatever scale up environment, you always have to deliver the next big thing. So

How do we actually start caring and start spotting those ability biases? How do we start prioritizing those? Like any ideas there, especially when it comes to working in the fast-paced environments, which I feel like many of us do work at.

Sure. I'll pull from Microsoft's inclusive design methodology here because it informs the work I do pretty significantly. There's three different inclusive design principles. There's recognize exclusion, learn from perspectives, and solve for one extends to many.

And that third principle is really what's important in this regard. When we look at accessibility in our designs, we want to solve for the person and the people where the barriers are most significant. And the reason we do that is because that, well, one, that benefits them and their needs are

valid. Accessibility, of course, is a human right, but also because that benefit extends out to everyone, right? So if we were designing an experience for, say, the restaurant that you were talking about, and we were making sure that our experience worked for people who need high contrast modes or people who are lower vision and need...

you know, again, more higher contrast modes or need more support in that regard, we're more likely to be able to support somebody who's moving in an environment where the sun is shining on a device. Now, of course, it's not always A to Z simple like that. What I would like to say is in an ideal situation, organizations would be bringing in people with disabilities to learn from them and how they interact with the experience.

What tends to happen is that organizations don't have the budget and they don't consider doing that because if they're not thinking about accessibility already, then they don't have the budget or they don't create the budget to do that. So then suddenly, okay, well, how do we create that empathy? How do we tell that story? And this is where I tend to find almost every organization runs against one significant barrier in making accessibility happen.

Because where we tend to divide that gap is we focus on WCAG, WCAG guidelines, WCAG criteria, which are made with and by people who have permanent disabilities. And those are significant in reaching, at least having some perspective on what needs to be done and how it should be done. But then what happens, again, this is where designers tend to struggle most, is there are no people telling those stories anymore.

Not directly. Right. You're not hearing from somebody directly talking about how meeting this affects them. And so I'm not saying all of this comes back to compliance is important. What CAG is important. Those are the ways that we go get at least the starting areas. But what I wish would happen.

And I don't know the solution to this is that leadership would bring in folks with disabilities, pay them and equitably for their time and get those perspectives early and often the same way they do with all users.

Because disabled people are using our experiences today. I wish I had an easier answer. But what I'm trying to say is I empathize with these situations because I've been in them as a designer. And this is, of course, part of the reason I made the LinkedIn learning I did is because I wanted to show how to advocate for more and for better as a starting point.

I really love this design for one principle. I think the reason why it rings the bell was me because I recently read this book called Miss Much by Kat Holmes, which maybe has a lot to do with this principle set in Microsoft. I was like very in line with it because, you know, as designers, we have all those

catchy phrases like, oh, when you design for everyone, you're designing for no one and blah, blah, blah. And this is literally the opposite, but also is a very tangible principle. And I really love this example because it opens the door to so many situations when you think about designing for one specific, very niche group of people.

And then, like you brought up already with the captions, you design for one specific group of people, and then suddenly we all use them, especially for those temporary situations when, I don't know, I'm sitting at the metro and I'm watching YouTube video and I can read the captions because it's noisy and I cannot really hear everything very well. So design for a big need, but for a small group of people, and then very often it could be scaled to so many other users. But I think that the challenge here, and you brought it up already with leadership, the

The challenge is always, at least in my experience, comes back to the budget and like thinking what's the business case. We as product designers typically work with PMs, with, you know, there is like classic, I don't know, either product trios.

When there is a technical lead and then PM, and then PM usually makes a case to get a budget for the new feature, new initiative. And obviously, the PM typically thinks about business benefits rather than user benefits. We as designers typically would think about the users. But again, because we are so wrapped up in so many things that are happening all at the same time, all the communication, all the crosswork, collaboration.

We very often don't even have the bandwidth of thinking for it. And like you said, we need to have those empathy stories. We need to be able to be exposed to those. So I think it still comes back to us as designers to still add more to the plate and start kind of advocating for those stories that we need to hear those stories. We need to hear those voices. But have you ever...

seen happy cases when the designer could advocate for bringing smaller groups of people to the table, interview them, get their stories to be heard. And that would make a business case for designer to pitch, then to bring it to PM, then to bring it higher and so forth and so on. Have you ever seen those cases? Is it even possible? Is it a unicorn story?

It's not a unicorn story per se. Sometimes when you look into accessibility in organizations, you'll hear the phrase accessibility maturity. And some organizations, particularly ones who haven't thought about accessibility before, are probably on the lowest end of maturity. And then there are organizations that move higher up on that maturity scale. And so part of the reason I say that is because I work at Microsoft. We are higher up on that maturity scale.

We do inclusive design sprints and we'll bring in folks who are blind and use screen readers and we'll bring in folks who are neurodivergent and we will do sprints where we are co-designing with those individuals and we can show. It makes it so much easier to go to like our like.

like higher level folks and go, look at this, this is happening today. And our users are dealing with these barriers as they interact with the product today. But Microsoft isn't, there's different maturity levels. And part of the reason for that is, you know, Microsoft's a huge company. We've had the people do the work to get to that maturity level far

before I got the chance to join. So most designers and most organizations don't have that opportunity or at least not yet, which I really hope that changes. I'm trying to say it's not a pipe dream. A few different things I wanted to pull here in terms of resources. Christina Mallon, our inclusive design director, has a LinkedIn learning on making the business case in your organization that I think is pretty exceptional. And again, it's on LinkedIn learning. If you have access to that, you can use that anytime.

Christina is fantastic and does so much hard work in this space. The other thing, Cat Holmes worked on the original Microsoft Inclusive Design Toolkit. I know I'm pulling a lot of Microsoft in here. There's a reason I joined the organization is because of all of the amazing accessibility and inclusive design work they do.

Kat Holmes worked on that kit. I also love that book. Mismatch is a really good book. The other thing I'll mention here is if you're doing user research now, you can use some of those platforms to actually bring in users with disabilities in your process. I've seen our researchers do that with the

products that we're using to bring in those perspectives. And so again, it does come down to you have to find allies in the organization to help build some budget in for this. But if all else fails, if you have no budget, there's so many videos of people just sharing their perspectives. You can look on TikTok. You can look on the Microsoft Inclusive Design website. You can look on YouTube.

And there's a zillion videos of people with disabilities just showing how they're interacting with the web, with mobile, because ultimately you can show somebody that video and immediately what will happen is somebody will say, I didn't realize that this is what happens.

I'm rambling again. I get really excited about this topic, so I'll stop now. I love to hear rambling. I have a lot of thoughts. So first that comes to my mind, you did mention the accessibility maturity. We talk a lot about UX maturity of organizations. A lot of the organizations are still very low in UX maturity, but I honestly never heard about this term, accessibility maturity, and I would love to learn more about it. Is there any resources, anything to learn more about it? And also, most importantly,

How does one company or one designer start promoting the idea to start bringing the awareness to then start building that maturity? Because most of us probably work in the not accessibility mature companies. Let's be honest.

Totally valid. This is part of what happened in my career is I've been the designer in companies that are not mature or haven't thought about it. And I've been the designer in the room going, hey, we have to do this. And it's really tough sometimes because what happened partially to me, and I'm really glad it did because I love the work I do, is I was the designer who said, we should be doing this.

And then suddenly we have our product manager director looks at me and is like, OK, you're the accessibility person now. And I go, what? Anyway, long story short, the accessibility maturity models, I will have to find some articles to send them to you later because I don't have any that come to the top of my mind. I know they exist. And if you Google them or being searched or whatever them, you'll find them.

But here's my tips for designers as they navigate this. One, I think every single thing that we do has an impact on our users. And so I want to emphasize to designers to find little ways to bring this to your process. Investigate what exists out there today. There's far more knowledge.

now than there was when I started doing this. There's annotation kits, there's focus order plugins. I keep plugging in Microsoft work, but yesterday we released a mental health plugin for Figma. The team that did it that I kind of got to sneak peek on, they released it. So there's a lot of stuff that's being made today that wasn't made even five years ago. And so for designers, what I want to say is like every little thing counts. Make it a

little bit of your process and you'll find that those skills and knowledge builds. Find the people that are in your org that are also interested in these things and share that. Build a little bit of a community around that and work your way up. What made the difference for me? When I was in the conversations where I was talking about

hey, we need to do this. I showed them where the issues were, where issues were reoccurring. And I did talk about the legislation aspects of this. I talked about we are servicing people here. These are some of the laws that affect that. Use the EU accessibility legislation that's coming to your advantage. That is where you can pull a little bit. Don't expect to be a lawyer, though. That's reasonable. You don't have to know all that.

This brings me back to, I think, one of those rumble questions I had earlier. Imagine we are designers, we had a little allies and we are, I don't know, advocating for it, but

Every time working in a fast-paced environment, in products and especially agile environment, you could see those sort of pushbacks by PMs saying that that doesn't bring money on the table. We as PMs, our performance review is based on how much money we could make for the company. So this is great. Let's push it to the next whatever sprint. How do we advocate that there is, I guess, monetary benefit to also designing for inclusivity and accessibility? Is there a

ways for us to actually make it sound legit, find the money in it. At least in my environment and many environments I've been working at, this is what usually happens. We usually prioritize those bets that bring ROI. Maybe it comes down to, of course, the company growths and product stage. If you work in scale-ups or startups, it's very common that we typically push accessibility very far in the future. But any advices here? How do we advocate for also the business case here?

There's a few different ways to approach this. The first thing I'll mention is anytime you're advocating for the business case, be prepared to have many different conversations. I don't think you can change somebody's perspective on something overnight. I think accessibility maturity and design and UX maturity kind of go hand in hand. So if your organization's in a position where they don't have a lot of design maturity, it's going to be a little bit harder, right? What I'll emphasize is a few different things.

Part of the reason I mentioned compliance aspects of accessibility and the legal aspects of it is because that is almost always the starting point. The reason it is so essential that we have these things is it's usually like for organizations, the starting point of them paying attention. You know, in an ideal world, it would not be that way, obviously. But in the world we live in, it is.

And so what I emphasize a lot is the cost of having to fix accessibility bugs later in your production lifecycle. If you do not address accessibility bugs and needs early in your cycle, at least from a compliance perspective, that cost increases significantly like any bug over time, and it's

It has to be fixed eventually. And so that is one thing I like to emphasize to leaders to kind of get them to understand, at least let us do the compliance because if we don't, it's going to cost a hundred times more to fix later. And I don't think...

Candidly, I don't think product leaders want to be the ones who have to say, oh, the thing we put out is not going to cost this much more because we didn't do it right the first time. It's a little, again, more stick than carrot, right? But I think that's what I've found success in in the past. Sometimes that's just how it goes. There's like a whole business case for accessibility website. They have a bunch of data and they talk about how people with disabilities have, I think, trillions of dollars in buying power. But

What tends to happen is that we don't see that in the data and the metrics we present because we don't know which users have disabilities in that data. We just know they're users. We just know they're people. And that makes sense. I wouldn't segment that data. But ultimately, when it comes to advocating, I don't have an easy answer for this, but the reality is that the data that shows your experience is usable is also more likely to show it's accessible.

because accessible experiences are intrinsically more usable. I think it could sound probably like the same question I've just asked, but I wonder, is there a way to do this for the startups or scale-ups even? Because very often when we think about early stage startups, zero to one type of startups, they don't have time, right? They're always like, oh, we're running out of money. We need to quickly get an investor as build and break ideas. Coming from working with a lot of startups, I would say very often I would hear they don't care

the cost will not be a big thing because we're a company that might even run out of business tomorrow. So why should we care about legal consequences in whatever five years from now? In scale-up, it's definitely changing for the good because if the company is growing, the customer base is growing, they need to start to be compliant. But I don't think that's a very common mental model for startups. And is it all right? What would you say? Should startups don't prioritize it? Or is it

also dangerous if you start deprioritizing it early on, then it's just become habit and you never really come back to it. When you're working in a startup, a lot of things get pushed by the wayside. My tip for people working in startups to make sure that accessibility is considered is to use a design system and make sure that you're using one that is

And I don't mean make up a whole new one. Grab what you need from existing systems, pull it in, modify it as needed and use their resources to help make your components, your controls and your systems. Because a lot of the heavy lifting happens on that level.

And design systems save money because you're creating a set of reusable components and you're using them at scale across your product. If you're using a design system or even like bootstrap to start, it makes it a lot easier to build at scale, a lot cheaper. And if you're using them correctly, you're more likely to be accessible by default. And so I think there is a lot of power in that. And I would say startups, as much as you can use existing systems, components and pieces.

Yeah, and I really love how Microsoft people in the company constantly launch new kits, new guides, new resources, new plugins, which really, really helps. And I feel like it becomes much more democratized, even free that everybody can use. And this is fantastic. I feel like this is, like you said, it's already much better situation that you were in years ago. And so it's a good idea to take advantage of existing resources. And honestly, I

Most of the times it still comes back to, you know, development and design system means already developed components. So if the components are developed with accessibility guides in mind and US designers provide them, from my experience, what we usually did was just designing handoff guides when we show how to navigate through the interface. And so I feel like it's a combination of using the design system, designing, not missing out on providing the guides for the developers and obviously developing for different needs.

One thing that I also want to touch base on is the impact of AI on accessibility and how does that play a role moving forward? We all start using AI, right? It's the biggest thing right now. But is there a benefit we can draw and kind of take advantage of to also make designing for accessibility more common?

I think this is so relevant to the whole industry right now. We're all experiencing that AI boom. What I'll mention is there's many stories that already exist of people with disabilities using AI as an assistant. If you're using AI and that AI is able to help people as an assistant, like Co-Pilot is doing, it does make a difference.

you can use AI to help you write the email so you don't have to type it all out yourself. And somebody who may not be able to type is going to benefit a lot from that, right? Or it's going to make it a little easier. So the one thing I'll mention is like with AI, I would advise people to kind of move a

away from the desire to create separated experiences in AI for different types of disabilities. I would not use AI to go, do you have this disability? Yes or no. If you do, here's what we're going to do for you yet. Because AI is not ready to do that yet.

But what AI is ready to do is really serve as an assistant in your existing experience and to take what exists in that experience, pull it out and make it easier to use within that context. And I realize I'm probably speaking abstractly. I'm trying not to allude specifically to the work I'm doing today because it's still happening. But what I mean to say is like, considering

AI as an assistant. And again, this kind of comes back to like, if you have an existing experience that is accessible by default, it makes it a lot easier to build AI as a very good assistant because AI is what it eats. It is the information it is consuming. And so if you make it an experience more accessible, AI is going to be able to give you a more accessible output. So what I'm trying to say is, yeah, AI is going to make a big difference.

But we also have to be the ones to make it do that too. I like this framing with this pilot in mind. The best example that comes to my mind would be those AI pins that we saw, like a couple of them were launched recently, where they all look sleek. They're like, I don't know, somewhere near your pocket and you can talk to it and it will reply or do a task on your behalf, which is already what AI

is required from the software and interfaces that we usually design, right? I think maybe if I try to even imagine the future, I would imagine that there will be much more reliance on the voice technology, like screen reader. Maybe the AI will be the new screen reader or whatever crazy thing can come up in the future. You brought something to mind. You should look into, I know about this specifically because I was in Ability Summit yesterday. Look into the

like the Be My Eyes new stuff that's coming out. Be My Eyes is an app where somebody who is blind or lower vision can call somebody and have them describe something that they're showing. But what is happening is that Microsoft's been partnering with Be My Eyes and I think integrating AI into parts of that, there's like a lot of really cool stuff happening.

in making technology more accessible in these ways, in the context like that. So anyway, I got excited. We touched on a lot of different bases. The reasons we're not designing for accessibility very often, the accessibility maturity of the companies, building the business case, the future of AI and potential impact on accessibility factors.

So there's a lot of things to think about. And also, there are a lot of resources. I still come back to the, I guess, takeaway for myself is that it's on us designers to advocate, to build a community around ourselves, to really start investing into that accessibility maturity within the organization, which obviously will then impact the UX maturity of the company as well. So it's still our responsibility to do that. And for that reason,

We just need to start educating ourselves better. I definitely would recommend the same book by Kat Holmes, which you already brought up today, Mismatch. I would definitely link a lot of resources in the show notes. But is there one key takeaway that you want our listeners to remember from this conversation?

I want us as designers in our day-to-day, just think for a moment, where might I need to consider accessibility here? And know that you don't have to be perfect to do that. That the very question itself is the most important part of bringing accessibility into your practice.

is asking that question and investigating the answer because it's a mindset, right? It's a methodology. It takes time to learn these things. Matt May, who's another man in the inclusive design space, has said something along the lines of, we need a lot of people who know a little and a few people who know a lot about accessibility. So learn a little. That's plenty.

But also know, last and not least, that it cannot be on us as individuals to change an organization without leadership buy-in. So if you're feeling a little like, how can I do this? Is it my fault? It's not your fault. All of this is going to take a long time to change and become normalized.

And so what you do to be a part of that is teach yourself little things here and there. And probably take advantage of the resources, especially by Microsoft. Microsoft. And of course, there's a lot of other great organizations out there. I only know a lot about what's happening at Microsoft because I'm there. But there's people doing amazing work in other places, too. And the cool thing about accessibility is we're all in different organizations trying to share with the world how to do it.

Yeah. And I honestly feel like it's almost like a community of designers designing for accessibility that advocates, write articles. There's a lot of resources. Honestly, I've seen so many articles and I followed most of the recommendations by staff and experts.

There's a lot to be educated about and you have a course. We definitely will link it in the show notes. I feel like that's where the education can even start from. But yeah, for sure. It does feel like a community that you can be a part of if only you would choose to do so. I really hope that at some point it's not going to be just a small community, but it will be an

massive movement and everybody will think about it. But I also hope that the more education and the more AI help will be, the more change we'll see. Because yeah, obviously we can do small things. We can educate ourselves a little bit, help, but I don't think we can change it. And like you said, it's not our fault, but it's definitely our responsibility to do it. I like the way you put that.

Not our fault, but it is our responsibility. And I'm excited too. Like I said, what's really cool about AI is it is what it eats. And right now there's a lot of opportunity to make things better so that what AI does is better. The community...

I love this community. Like it's, it changed everything for me about my career because we have our little group chats and we'll talk and chit chat and like the community of accessibility in design and inclusive design. It's just so rad. I love those folks. They're amazing. Yeah, I can definitely sense that.

All right. So let's wrap it up. Thank you so much again for joining us today and sharing your brilliant thoughts, all the resources. This episode will be full of links in the show notes and make sure to check them out. Again, like, thank you so much for taking your time to talk to us. Thank you. I'm really pleased you let me join and thank you for letting me ramble about these things. I can't help it. I love it. So thank you. Alrighty. So again, thank you everyone for listening. Definitely check out the show notes and we'll see you on the next episode. Bye-bye everyone.

so