Todd Werth:

Welcome back to React Native Radio podcast. Brought to you by the Apple Finance Department. Would like to remind you that Stripe is bad, stinky, and they kick puppies. Episode three 30, react Native accessibility.

Robin Heinze:

Hello everybody. Welcome back to React Native Radio. I'm Robin. This is Mazen. We don't have Jamon today because he's getting some sun somewhere in the world on vacation, but we're going to have more fun than him. We'll make sure of that. We have a really fun episode for you today. We have a special guest, Karly Lamb. She's going to talk to us about accessibility and React native. And Karly, welcome to the show. Why don't you tell us a little bit about yourself? Hey, thanks.

Karly Lamm:

Yeah. So I'm Karly Lamb and I'm a senior consultant with Aron Software and I mainly focus on mobile development and I'm a big advocate for accessibility in mobile applications.

Robin Heinze:

Awesome. Well, we're really happy to have you on the show. Before we get started, let's hear from our sponsor, infinite Red. Of course. Infinite Red is a Premier React native consultancy located fully remote in the us. We're a team of 30 senior plus level React native developers and support staff, and we've been doing this for nearly a decade. If you're looking for React native expertise for your next project, hit us up at Infinite Red slash Radio. And don't forget to mention that you heard about us through the React Native Radio podcast. Awesome. So React native and accessibility. Tell us a little bit about how you got to be interested in accessibility, how you got, well, maybe first how you got into tech and then how you got into React native and then how accessibility kind of became your focus.

Karly Lamm:

Yeah, definitely. So I've got a bit of a non-traditional background in the tech industry. I actually started in pharmacy. I was a pharmacy student and at one point I realized, hey, I'm really not happy with this path. So I decided to take a semester off to try and figure out what I wanted to do next. So for fun, I worked at a coffee shop and one of my coworkers was talking to me about this bootcamp that they applied for. And at the time I had barely heard the term software engineer come up at that time and I was like, wow, that sounds really cool, coding in the movies with all the green text on the screen. So I was like, yeah. And that was what I thought of at the time. Whenever it came to coding, I'm

Robin Heinze:

Pretty sure that's what my family thinks I do.

Karly Lamm:

Yeah, my mom thinks I fix printers, maybe I don't tech support, but I was like, yeah, tech support. I was like, that sounds super cool. So I decided to apply too and I ended up doing a coding bootcamp and I was like, this is really awesome. So ended up sticking to the coding world and not looking back.

Robin Heinze:

Awesome. I mean I have a really similar, not the pharmacy part, but the coding bootcamp part was how I got into tech as well. So I can really relate to going from a completely different career and sort of catching the coding bug as they say, because it's really kind of addicting when you learn it and it's a very strong feeling of like, oh, this is what I need to be doing.

Karly Lamm:

Absolutely. And it gives you so much industry experience in such a short amount of time. It's awesome. And from that coding bootcamp, I ended up working at a really, really cool startup company based out of St. Louis. And a couple years in, we ended up getting acquired by this Fortune One retail giant and that acquisition was, it was crazy. It was awesome. We learned so much about it and through that acquisition we ended up losing a couple of our contractors and those are who managed our mobile application. At the time I had had no experience with React native and our boss was like, Hey, we need somebody to learn React native and take over the mobile application. And me with no prior experience, I'm like, Hey, I'm qualified. I'll take over the application.

Robin Heinze:

I'm pretty sure that's the story of software engineers. Oh

Karly Lamm:

Yeah. So once I started learning about React native and mobile applications in general, I just fell in love with it and that's where I decided to specialize my career as mobile development.

Robin Heinze:

Awesome. So you're doing React native then. How did you end up specializing in accessibility within React Native?

Karly Lamm:

Yeah, so my first interaction with thinking about accessibility whenever you code is we had this bug come up, we got this support ticket saying we can't get into the app at all and we're trying to replicate it over and over. We're all like, what is going on? We cannot do this. We have no idea why the user can't get into the application. We were able to get a video from the user themselves and we found out that the issue was actually their tech size was increased on their phone and the modal that they were on had a button that was hidden because their tech size was so increased. So we had this hidden bug and I was like, wow. So we're just not focusing on a big amount of users and we have these hidden bugs. So if we were set to those system defaults and we weren't able to click through that modal on the application, we would've immediately thrown that on a high priority ticket. It would prevent all of our users from being able to access the application. But the CDC says one in four people in the United States have some form of disability, so if one in four of our users in our application can't get into our app, that's just as much a bug. Right.

Robin Heinze:

And then after that happened, how did your teams approach to testing and verifying how did it change and was there any kind of culture shift after that about making sure you caught these invisible bugs?

Karly Lamm:

Definitely slow progressing as far as testing for it goes, one of the most mistreated tests I would say is the user test. Being able to see how our users are actually using the application. Developers, we love code, we love our code and we rely heavily on these testing toolings that we use that sometimes we forget about the user themselves and doing those user tests outside of our automated testing and unit tests and things like that. So being able to test as the user and if you're able to interact with the user that's even better. User feedback is so invaluable to the developer and the product and the company itself. Absolutely,

Mazen Chami:

Totally. I think Robin and I, we talk about our Merc project that we had. We were lucky in that one where their entire focus was accessibility and making sure the app is fully accessible. That was personally my first dive into accessibility and React native and it really set a footing because my current project and the project that I was on prior to that also we're fully, we are not going to go to the store unless we are fully accessible to all user groups. And the previous client, they actually had a full accessibility team that would come in and use the application that they themselves had. The large font size that you were talking about, they were using voiceover, they were people with disabilities that were actually employed by the company to test the mobile app. And that's great and I think it's opened up my eyes a lot on how hard it is to use. So making it an easier experience is the best thing you can do for your clients. And one in four is large, right? It's 25%. That's a lot of people. And if you're a startup, your numbers are small, you still want to make sure you don't want to lose that 25% because that 1% matters at that stage anyways.

Karly Lamm:

Yeah, absolutely. And just like you said, if 25% are left out, that means we're coding our application for 75% of the user base and in school that's a C. And they say Cs get degrees, but I don't think that's good enough. There you

Mazen Chami:

Go. I think one thing we'll link in the show notes was the blog post that you put together early, late last year. Sorry. And you had a nice video that went with it that was informative. Thanks. The presentation touches on people with disabilities in the testing process, kind of like I mentioned before. What advice would you give for companies looking to incorporate the best practices to ensure that it's fully, you reach that a hundred percent rather than just the 75%? Where should they start?

Karly Lamm:

I always say whenever you're doing something new, try to start small, see what you can start adding that makes high impact but might take less effort at first. And something like that could be even adding accessibility labels into your application or ensuring that your team is using components in general correctly so that way the native platform oss are able to use their own semantics that they have if you may be miss an accessibility label or something like that. And as far as communicating to the business, there's so many benefits that come from it outside of just it's the right thing to do. It's an ethical thing to be able to code for a larger user base. There's also tons and tons of other impacts like potential revenue boost from more user retention and being able to broaden your audience for your application as well. Not to mention compliance, right? Compliance is huge and there's a big push for it lately all over, not just the United States, the EU as well. It's a broadening, the topic of accessibility is widening and that's great. It's making us talk about it more. We're starting to see companies potentially losing their reputations in places for not focusing on it.

Mazen Chami:

I think one thing that most people and developers don't really know is if you want your app to be successful and launched in the Canada app store, so we're not talking about too far overseas here in that process, you need to be fully accessible. You need to be, what is it, wcag? Aaa? No, sorry, AA accessible. So there are requirements that you need to meet to be a app within the Canadian app store. So talk about losing 25%, you're losing the entire Canadian app store market, right? That's a lot.

Robin Heinze:

Yeah. You talked about trying to convincing stakeholders, which is, I mean it's a huge part of our job as consultants is trying to convince clients to focus on accessibility. And as cynical as it is, the more you can focus on the impact to bottom line and revenue, that's what I found is usually has the most success and convincing maybe stakeholders who are reluctant to focus on accessibility. From my perspective, the real reasons are inclusivity and the ethical reasons, but if you really need to convince the CEO, compliance and revenue impact are usually a pretty good way to go.

Karly Lamm:

Definitely being able to be able to talk business is huge and a lot of that is being able to say, Hey, there's a lot of revenue impact here. SEO impact makes sites a lot more crawlable whenever you have accessibility labels and accessibility features added to your application and you can see a direct revenue boost from adding accessibility because coding with accessibility in mind is not necessarily building an application for a user with disabilities. It's building an application for everyone. And whenever we make the application easier to use for everyone, we can typically always see a boost in user retention.

Robin Heinze:

I mean, the analogy that I always think of is restrooms with a handicaps stall, anybody's allowed to use a stall, it's available and is accessible and it's also a benefit to more than the audience that it was maybe built for moms with kids or people with zuki. There's plenty of people that are now going to have access to that space because you built it in an accessible way. And it's kind of the same with apps. When I was just had my kids, I'm holding a baby and I'm using speech to text because I don't have use of my arm. So it's like a temporary disability in a way, and those features benefit pretty much everybody in different ways.

Karly Lamm:

Yeah, and I like that you said that, I watched this really cool video one time of this other woman who's very involved in advocacy for accessibility, and she referred to people without disabilities as pre disabled and she was like, the majority of people will experience some form of disability, whether that's temporary or permanent. I'm pretty sure I know the

Robin Heinze:

Exact talk you're talking about too. I think it was probably Jen Loker talk. Yes, it might've been. Yeah, it was a really good one. Really, really good. Really, really good talk. But it's like you don't know when you're going to need accessibility features. Yeah,

Mazen Chami:

It happens all the time. I think in her talks, talks about someone breaking their hand and only having the ability to use one hand. So now if you have a pro Apple phones, how are you going to reach the top left corner if you're using your right

Robin Heinze:

Hand?

Mazen Chami:

Is your app accessible in that sense? So yeah, I want to not shift a little bit, but talking about the testing in your blog, you mentioned the testing trinity. So manual testing, automated testing and user testing, that's the comprehensive trinity and one we should all strive to do all three of them. Which of these do you think us as developers tend to skip and what are the consequences from that?

Karly Lamm:

So in a perfect world, we all do the holy Trinity of testing. We get 'em all done and we know what's going on, but we just don't see that in reality. And I definitely think the one that gets underused the most would be the user testing. And what I mean by user testing is not necessarily QA using the application and testing it out or the developer themselves, although that's wonderful too. But I also incorporate getting that user feedback in there as well. If you're able to communicate directly with users and understand how they're using the application, that is the most valuable information you can have as an engineer. Because as engineers, we're not coders, we're problem solvers. And part of problem solving is not finding just the minimal solution, it's being able to find the correct solution, being able to build that for everyone and that's user testing is just so valuable to being able to find the right solution. You need to understand how the user is using it, which would be the problem case of building the application.

Robin Heinze:

Do you have ways of actually incorporating feedback from disabled users? I mean, that's one of the things that I've struggled with is figuring out a way to actually get their feedback, especially with the more intense features like screen readers and stuff. Getting screen reader users to actually test your app is really difficult. Do you have ways to do that or are there services? What are ways that we can actually get testing feedback from disabled users?

Karly Lamm:

So the teams that I've worked on, I haven't had a way to communicate directly with users with disabilities, but I really, really liked what you said, Mazen about how you worked with a team that had a dedicated team of users with disabilities to be able to test that. I think that that representation is so important in the tech industry and forces us to talk about it more. And that's what we need to do is we need to be able to talk about it more, advocate for it more, and communicate all of these benefits for the application. In general,

Robin Heinze:

I can learn how to use a screen reader, click the right buttons, all that, but I'll never get to the point of an actual user of a screen reader who's doing it every day. So yeah, trying to find that direct feedback is so, so useful.

Karly Lamm:

And it's not just trying to narrow in on your users with visual impairments or

Auditory impairments. It is being able to communicate with the user in general because we're building the application for everyone. So if you have any path to be able to get feedback from users, eventually you're going to find users within that that are able to give you feedback on the application. For example, we had an application where we had to go into stores or the end user had to go into stores and scan different products for doing their work. So we actually went into the store one time, walked with one of the users just to see how it worked. And I learned more from that 20 minute experience than months and months at the keyboard.

Mazen Chami:

I think that goes beyond accessibility. Also that user testing is very important because you might develop for the best user experience, whether it's accessible or not, user experience that you're thinking of, you use your device completely different than everybody else, so it's hard. You're not going to sit there if you have a million users, hopefully one day everyone has a million users plus on their devices on their app. You're not going to do 1 million walkthrough your local grocery store and see how they use the, just a random example, but using how they use their app all the time, you're never going to be able to do that. So being able to figure that out universally, but also capturing everyone is very important

Karly Lamm:

And having some form of getting feedback from your users within your application is so important too. There's a lot of benefits from that as well. Angry users of a mobile application, if there's not a direct way for them to provide feedback, they're just going to stop using it. They're going to stop using it or they're going to write a nasty, nasty review and hurt the reputation. Whereas instead, you could directly outwardly reach out for that feedback for your application.

Robin Heinze:

You want to capture that anger in a way that goes directly to you and not out to the

Karly Lamm:

World. Yeah, exactly. And accessibility isn't just adding accessibility labels and using accessibility features, the idea making the app easier to use and whenever we get direct user feedback, whether that's a user with a disability or not, we're making our application easier to use from that feedback.

Robin Heinze:

Can you talk about the relationship between the initial UX designs and accessibility and how do you advocate for designs before you even started coding that are accessible and visually appealing and easy to use? How do you get your designers to build those in from the start?

Karly Lamm:

Yeah, that's a great question because accessibility is not just a one and done thing. There's a holistic view that should be with the entire team from design to code review, to pushing it out to production. The whole team should be aligned on making the application very easy to use for all of our users. And starting with design is one of the best places to start and designers should be focusing on the simplest, easiest way to use the application designers. They're not going to go into the technical weeds of, Hey, make sure you're using Symantec HTML or things like that. But they should be focusing on making the application as easy to use as possible from a user's perspective with or without a disability. So putting buttons where you would normally click the button, having that understanding and wire framing ability to know this is the psychology of the user, this

Robin Heinze:

Is the user not doing something surprising.

Karly Lamm:

Yeah, definitely. And I think a lot of people want to do the latest, greatest thing. They want to, let's put the button over here. When will the users really be positively impacted

Robin Heinze:

By that change? There's this culture of always needing to be on the cutting edge or being really innovative, and sometimes that comes at the expense of accessibility

Karly Lamm:

And designers. I mean, they're very creative individuals, so they always want to find that competitive creative edge. And sometimes the simplest answer is the best answer.

Robin Heinze:

We like to say standard is better than better, and it's definitely true in this case. Yeah.

Mazen Chami:

Okay. So I know I shifted our conversation in this direction, but I also want to get to the technical aspects, which I think are very important for our listeners. The accessibility to API in general. In your blog and also as you've been talking, you've mentioned accessibility label a lot. I know there's also the accessible tag prop, the accessibility hint, there's many props out there, the documentation is big. Which of these props do you think are most frequently misused or overlooked or

Robin Heinze:

Misunderstood?

Mazen Chami:

Misunderstood. Yeah, exactly. It's a blanket question. Which one of these are we not using? Right. Or not using enough or there's so many ways to pose this question because sometimes we're not aware of their capabilities in general,

Robin Heinze:

We don't

Karly Lamm:

Know what we dunno. Definitely, definitely. And being able to understand them better. The first step is using them and being able to test them. And I would say the one that I see misused the most would probably be the accessibility label property. Kind of just throwing those all over the place and now we've got duplicate texts being announced by the screen reader. So I would say definitely accessibility label is the one that is misused the most underused. I'd probably say maybe the accessibility hint. A lot of the times people use the accessibility label as both the label and the hint when we should really just be using that label to say this is what it is, and using that hint to give that additional context for the end user,

Robin Heinze:

Like an accessibility label. Would a good use case for that be like an icon that doesn't have a text label and so you have to add an accessibility label so that something is read out? Oh yeah,

Karly Lamm:

Absolutely. Especially with icons, because the screen reader has no way of saying, at least not now, Hey, this is a check mark icon, so if you have a confirm button with just a check mark button, the screen reader isn't going to read anything when they highlight over that. So they'll have no context on what it is that they're highlighted on or if they even are at that point.

Mazen Chami:

So yeah. Keeping on the whole conversation about the React native accessibility API, you've worked extensively with it in general, what improvements have you seen over the years or what still remains for the React native accessibility API to bridge the gap and be a complete API?

Karly Lamm:

Yeah, so we've seen a ton of improvements. The talk about accessibility has just expanded throughout the years, but we definitely do still have a long ways to go. One of the things that has improved a lot, but still we need some more improvement on is the compatibility across the platform. Oss, we've seen a ton of it improved, but we still have some ways to go for accessibility. Hint, we were just talking about that. That's not always read correctly on Android. And iOS, for example, has really, really great, for the most part, semantics with their components that they have, whereas Android doesn't as much. So there's pros and cons between the platform OSS and having the accessibility features within React native, being able to bridge that gap better is absolutely tremendous. Well, would be tremendous and has been great what we've seen so far.

Robin Heinze:

Yeah, I mean it's almost like React native is filling a gap, which is creating a unified accessibility standard, API kind of, whereas each platform is kind of doing their own thing and then React native comes in and has to create this API that talks to both platforms. And in doing that is basically building a universal accessibility standard. I think that could be really big going forward.

Karly Lamm:

Yeah, I'd also like to see better testing tools. For example, Xcode, their accessibility auditing features are really great for color contrast, all kinds of stuff. The Android one, it does the job, but it's not quite as solid, I'd say, as the Xcode platform that we have right now

Robin Heinze:

As reacting to developers. We're very used to the polish and sort of completeness of iOS compared to a little bit more rougher around the edges of Android development. Android tends to have maybe more overall things that you can do, but they're less documented and

Karly Lamm:

Yeah,

Robin Heinze:

Definitely and well polished.

Karly Lamm:

Yeah,

Robin Heinze:

But that's maybe my iOS bias speaking. I dunno. I'm an Apple girly.

Karly Lamm:

Yeah, and documentation, that's another big thing too. We've seen a lot of more documentation React native has react native accessibility documentation. That's pretty thorough, very solid documentation, but I would like to see an expansion in documentation for usage for developers.

Robin Heinze:

Yeah. Yeah, absolutely. I mean, I think both documentation and training tutorial content, there's really just not all that much out there teaching people how to test for accessibility and how to use the tools. I had to learn how to use a screen reader just reading the docs and other, we have some coworkers and infant read who were willing to pair and teach people, but it's all kind of been self-directed and there's not a ton of resources out there for, Hey, here's how to do this well. A lot of it's just learning as we go.

Robin Heinze:

So

Robin Heinze:

I'd love to see more documentation, more content, more teaching.

Karly Lamm:

Absolutely. And I think a lot of that really does come down to understanding our user, because as engineers, whether that's a software engineer or a mechanical engineer, whatever that may be, we build for the problem that we know. And if we're not given this representation of how our user base actually looks, we don't have that in our mind for our engineering capabilities because adding accessibility in our code is really not all that complex. But I think having that advocacy and that knowledge about what our user base actually looks like allows the engineer to code with that in mind.

Robin Heinze:

Yeah, absolutely. We're getting to the end of our time, but I want to look ahead a little bit. You talked some about what features or improvements you want to see, but I'm curious whether you see a future and accessibility for things like ai. What are the big advancements that you see in the accessibility world, specifically in React native that can turn the industry on its head a little bit?

Karly Lamm:

So some things that have been talked about recently and some big things for React Native as far as accessibility. One is that compatibility that we talked about, being able to bridge that gap easier between Android and iOS, but also incorporating this into cis, having our linting process, being able to check, Hey, do you have the accessibility labels on? And we're taking it as serious as we do for a broken test for let's say a different feature. Having those accessibility tests baked into our process from start to finish, including in that CI process there is massive for a development team.

Robin Heinze:

I'm super curious to see whether there'll be a role for AI in terms of testing, but also is a screen reader, a traditional screen reader going to be even necessary or use the same way? Or can AI have a role to play in taking in the screen and telling you what's on there without having to have to be coded behind the scenes? I'm really curious whether there's going to be any innovation in that area

Karly Lamm:

That would be really neat. And the hot topic right now is agents having these agentic systems.

Robin Heinze:

So

Karly Lamm:

If you're able to build, let's say a user agent and have that representation like an AI agent for the representation for being able to test quickly and accurately, that would be really cool.

Robin Heinze:

There's so many possibilities. Yeah, it'll be really interesting to see where everything goes. Definitely.

Mazen Chami:

I think as we're wrapping up, last question. For anyone that's listening that's new to accessibility, wants to get started with accessibility, doesn't know where to start, what do you recommend? Where do you recommend they start

Karly Lamm:

Small, right? Start adding properties into your application and test out how they work, see how it feels as a user using a screen reader. Walk through your application. I made a video where I walked through a very simple to do Apple application and using a screen reader, it would be almost impossible for even an application that simple to be able to go through it with a screen reader. So imagine a very complex form with lots of user input. I mean, that would be nearly impossible. So start small and really think about the components that you're using. React native developers specifically love the view component, but a screen reader doesn't necessarily know. Let's say you build a button using view, the screen reader can't convey that to the user and say, Hey, this is a button that you built with the view. So be conscious about the components that you're using in your application. And that's a very easy place to start right there.

Robin Heinze:

Turn on your screen reader and see what happens is about the easiest thing you could do. We have some accessibility resources that we use that I'll make sure to link in the show notes as well as Karly's blog.

Mazen Chami:

And listeners should watch Karly's video within the blog because I think you do a good job of showing it in how a developer would start the app in its quote, broken state, and then how you fix it. And in some scenarios, you highlight how, I don't want to oversimplify it, but it is simple by just one line of code that will get you to be fully accessible within that one feature. So it's really important to notice that you're not doing a whole rearchitecting of your app to make it accessible.

Karly Lamm:

Yeah, absolutely. And I do post a lot about advocacy on my LinkedIn. I'm very active on there for posting fun tidbits about how you can make your applications more accessible. So be sure to follow me on there as well.

Mazen Chami:

Yeah, definitely.

Karly Lamm:

Perfect.

Mazen Chami:

As we're wrapping up, Robin, thanks.

Robin Heinze:

Yeah.

Mazen Chami:

Do you have a mom joke for us?

Robin Heinze:

Okay, I have a good one. This one's from Gantt. Why does a golfer wear two pairs of pants? Why in case he gets a hole in one? You have it. All right. Thanks everyone for listening, and we'll see you next time.

Robin Heinze:

Bye

Robin Heinze:

Bye. Bye.

Jed Bartausky:

As always, thanks to our editor Todd Werth, our assistant editor, Jed Bartausky, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Heinze and Mazen Chami. Thanks to our sponsor, Infinite Red. Check us out at https://infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.