Welcome back everyone to the .NET MAUI podcast. I'm your host, James Montemagno, and with me is a special guest. My name is Rachel Kang. Rachel worked on the .NET MAUI team, was an engineer on the MAUI team, and now a PM on the MAUI team, right? Yeah, that's right. Yeah, and I'm really excited because Rachel and I have been here at VS Live in Redmond. We've been doing some sessions together, some videos together on all sorts of cool stuff. Yeah, meeting lots of cool people. Yeah, any like really cool stories from folks that you've been talking to while you're here on campus? Oh, let's see. All of them. All of them. Yeah, you put me on the spot there. And really, everyone's been sharing some really cool stuff. So it's really hard to choose. I think we talked to a lot of people and What we always like to tell people is we love to hear from people who actually use the product. We talk to people all the time, but it's sort of at mass when we're doing a session at the end, talking to people or at lunch, having conversations with people. And then they're like, check out this app I built. We had someone today who was like, check out this app I built that's supported all around the globe at every airport. Yeah, they're like in 200 different countries. Check it out. So it's really cool being able to see that in person. Yeah. And there was like a really cool space agency that like is like building stuff with .NET. And you're like, whoa, that's cool. Yeah. Now we've been here and we've been talking about some of the new native library interop stuff that you did a blog post on. And we've got some videos coming out and which is really exciting. Yeah. Stay tuned. But you and Shane and other people on the .NET MAUI team have been really focused for the last several years on accessibility. Absolutely. One thing I noticed as someone that's used Xamarin and then .NET MAUI now for a long time is how accessibility features are the default. And I want to talk about those, but I also want to talk about why people should care about accessibility. So why should people care about building accessible apps, Rachel? Why is it important? Because it's not something I think about, but I think I should more. Yeah, these are all great questions. Thanks for asking them. Yeah, so starting with accessibility, why is it important? Why should we care about it? So, so, so many reasons. But to start, there's over 1 billion people in the world who experience some form of disability. And if we want to make sure our apps are inclusive for everyone, it only makes sense that we're making sure that our apps are inclusive for people who have disabilities as well. And oftentimes when we make sure that our apps are inclusive and accessible, we're also just building better experiences for everyone. So things like closed captioning, subtitles, having light themes and dark mode, which all of our developers love, Those were actually initially all accessibility features that we all just benefit from. The whole build for one, extend to many is a huge principle of inclusive design and is hugely important for accessibility as well. It's too because when you say like there's billion people with disabilities, like there's a lot of different disabilities. Yeah. And that's only people who experience disabilities themselves. Like when you think about the from a business perspective, whose lives are being touched by disability. I think the metric from like a 2020 report was like 73% of individuals in the world are touched by disability in some way, shape or form. So you can imagine that from a business perspective, that's also a lot of revenue and business that you can gain from your app users when you're making sure that you're making your apps accessible and inclusive for them. When we say accessible applications like you know you talked about light theme, dark theme. You talked about some of the like scaling things like as a developer I'm I'm creating my application. I'm like kind of in the middle of development or maybe I'm just starting development or I've already shipped my app. Like what should I actually? do without even like doing any coding, like how do I right now I take on my application, how would I like see if it's accessible or not? How do I test accessibility on my phone? Because I, um, and I have some disability, like I have some knee issues and things like that. Sometimes it's hard for me to walk sometimes. Um, but you know, that's not an accessibility like that I have right now when I'm using an app. So what are some things that I could do right now to test out accessibility on my apps? Yeah, that's a great question. So there are like some common set of scenarios. So and a lot of times our phones have built in settings and features and we want to make sure that our apps can conform to those different settings as well. So I mentioned light mode and dark mode, for example, because all of our devices have the ability to switch from light to dark mode. And we want to make sure our apps are able to respond to those settings. Normally, that's extra legwork that's required, but that's another example of something we built into.NET MAUI, so you don't need to deal with that overhead. If you set the device theme settings to be light or dark mode, we'll make sure that our apps account for that in.NET MAUI, as long as you set the different styles for dark and light mode, of course. And similarly, we make sure that our apps automatically auto scale depending on the font size that you might set. So that's another accessibility setting that our devices come with. If you set your default text size to be much larger, then making sure that the labels and the text in our apps also respond automatically to those settings. That's something that's also just built into MAUI. So yeah, it's something we care about a lot. And I definitely recommend checking out these different settings on a physical device. That's super important because our users, our app users are using physical devices. They're not using emulators and simulators. And oftentimes you actually can't really test those things on an emulator or simulator. For example, screen readers, so that's typically VoiceOver on iOS or Mac, TalkBack on Android, Narrator on Windows, and there's tons more. But a lot of times, especially on mobile, you can't test the screen readers from an emulator or simulator, and the best experience is really on the physical device again. So making sure that you are familiar with those screen readers, try to activate them and see if you can have the same app experience in accessing everything in your app with a screen reader activated. That's yet another way. Similarly, there's so many different ways people access apps. So some people with limited mobility might use Google. Strictly keyboards, for example, to navigate your apps. So even if you are using like an iOS or Android device, try pairing it with like a Bluetooth keyboard and seeing if you can navigate through your app just with the arrow keys, tap keys, something like that. So those are just some common examples, but there are so many different use cases and input modalities that people have. So really making sure that you're working with folks who have disabilities themselves, making sure that you are seeing how they interact with the apps themselves. is really the best way. Of course, you can cover the common set of scenarios yourself. But we are all just one individual with our own unique experiences. So making sure that we get out there. And similar to how we've been learning from all the people we've been meeting at VS Live, by hearing directly from them, it's super important that you're doing that with your app and meeting your app users as well. We'll put links into the show notes here for some different accessibility features and, of course, ways of testing it. You've done a lot of blog posts as well. Do you want to talk about maybe some of the features of .NET MAUI that folks can actually leverage today? Because I think the theming that's built in, you talked about the font size, but what else can we add? Let's say I have a screen that has a .NET Bot image and has some text and a button. should I actually be doing there? If I'm writing my normal control, I say button, click me, or download data. What's important for me to know about what I should be adding to that screen and how would I do it in .NET MAUI? Yeah, absolutely. That's a great question. It depends a lot on exactly what you have on your app, of course. For example, if you have a label, the accessibility of that's already accounted for. Screen readers will automatically read aloud the label as is. But if you have something like an image, and if you don't set any sort of accessibility description or text, then screen reader users will have no awareness that that image is even there. They might know the image is there, but they're not going to know what it is of at all. And so we have something called semantic properties in .NET MAUI. Okay. And there's a cool set of APIs that helps you dictate what you want the screen reader to read aloud, how you want it to behave. And so you can set what we call a semantic description. I believe it's semantic properties that description. It's a property you can set in XAML or C sharp and just set the description that you want it to. and we actually have it right in our templates as well. In a file new.NET MAUI app, you can see that image of the.NET bot in the race car. We've set a semantic property that description property to it that says, cute.NET 8 bot waving hi to you or cute.NET 8 bot in a race car since we changed it to the race car image. Yeah. I noticed that on that. When I think about the description, that would be valuable. you kind of like, you know, said like, here's what it is. It's kind of like if someone was asking, oh, what is that? And then you would say it. I noticed in the template, it's a little bit more verbose. Like if you were to say .net, right, it's actually like period, N-E-T. But I noticed that that's not exactly the spelling. Can you talk about like the importance of the actual words that you're telling the semantic property to read, I guess? Yes. Yeah, exactly. In the case of labels, I was saying that they're automatically accessible, like text-based controls to just get read aloud exactly as is. But there are some cases with .NET, for example, where it's literally the period symbol and then NET. And different screen readers will handle that differently if you just type that in. So it might read the period as just a period or not say anything because it thinks it's the end of a sentence. And it might just say net. Some of them will be smart and say .net. It really depends on the screen reader. But we kind of want to be careful and make sure that we take into consideration all of that. And so in the template, we explicitly write out the word .net. net and explicitly write out everything the way we want it to be read aloud as well. I think even with UI, I have it say U space I because I wanted to make sure that it's reading it out loud exactly as we want it to be so that it is understandable when the screen reader announces that text. That's very cool. I mean, I think that makes a lot of sense. And I think that sort of talks to the point that you made earlier, which was like, you got to try it, right? Turn on the screen reader, get comfortable with using it. I remember the first time I used a screen where it seemed like a lot, like it was just talking at me. Yeah. And, you know, I did try it on my apps. And I was like, oh, it's telling me a bunch of stuff that is not important. Like it's telling me all these additional things because I wasn't setting these properties. And that was a good learning lesson, which was like, oh, this is what my users are experiencing and it's not adding a lot of value at all for them because it's not adding value for me. Whereas it would be sure great if it's reading it out loud and what I see is what it's sort of telling me in response. So actually using it seems very important. Yeah, absolutely. You want to make sure that the experience is just as seamless with the screen reader activated. Now, in addition to that, you said mouse, keyboard, keys. Are there other different settings that I can set? I'm imagining I have a bunch of items on a screen. Is the order set automatically? If my user is tabbing or swiping through them, how does that work? Yeah, that's a great question. It really depends on the platform. Another cool thing about this is because we're.NET MAUI and because everything in.NET MAUI is really just exactly what the native platforms make available to you, the same is the case for accessibility. We make sure that it is accessible just in the way your iOS apps, your Android apps, your Mac and Windows apps would be accessible as well. But because of that, that also means there are some differences depending on the platform. One way with screen reader is actually when you have the screen readers activated, oftentimes there's an outline around the control that has current focus. And when you use your keyboard with screen reader activated, outline will move depending on the order in which your controls are placed in and that's something you have to check as well when you're tabbing through the controls on your screen is that a logical order is that the order that you intended hopefully it is but if it isn't that's something to double check So yeah, that's one thing. Even when you don't have your screen reader activated, sometimes on the platform you can still see. So on Android, for example, if you have an emulator open and you tab through, it'll actually, you'll see like the slightest highlight over the interactive controls and see the order in which it goes through that. Think about like your entries and editor fields even when you're tapping through that and like the typical form type of experience. That's also part of keyboard accessibility. Yeah, it makes sense. Like there's nothing worse than when you're filling out a form and you're tabbing through them and then it jumps down and you're like, what just happened? You're all tabbing up and you're like, who made this form? Yeah, or nothing happens and you need to click into each one. That's true, yes. I've also had that happen as well. So, So it sounds like these accessibility features that you were talking about are beneficial to everybody. Yeah. You know what I mean? Exactly. By helping build accessible apps and being inclusive of all, there are things that we could do to make our apps better, but also have that benefit that it actually just improves in general for everyone. Yep, 100%. Nice. Yeah. At Microsoft, we have an inclusive design toolkit. And one of the things in there is this model called the persona spectrum. Okay. So it kind of depicts how disability is super wide-ranging and also can vary because it can be permanent, temporary, or situational. Okay. And one of the examples I really like in there is, for example, someone who is blind, someone who has a cataract, and someone who is a distracted driver. They're all in very different situations, but they all experience the fact that their vision is being occluded somehow. And they would all benefit from if they had a GPS that would read out where they are navigating to. So yeah, things like this really helps us to understand better how the best solutions can benefit everyone. Yeah, that's awesome. Is there any tooling? Is there any toolkit or something? I know you talked about the design principles, but is there something that I can use on my local environment to test this besides actually deploying it and doing stuff? Is there something to give me hints? You know what? I'm inside of PowerPoint, for example. I just went through this. We were working on the Let's Learn .NET Aspire, and we were translating to a bunch of different languages, and someone uh, reached out to me and said, Hey James, like I ran the accessibility checker inside of PowerPoint and there were a bunch of. Uh, issues with it. Yeah. Can you go through and fix up? And a lot of them were images, right. And add all tags onto them. Just kinda like you're adding all tags. Yeah. Um, we, we, you know, and, and, you know, we, for example, write blogs on the.NET blog, we actually have enforcement rules. Emo and then John and other people have contributed for this long set of rules basically, which is you set certain lengths, make sure all tags are on and use movie files instead of GIFs because the GIFs aren't accessible in different settings like this. Some of them are just for readability, but some are accessibility. But it's like we're not allowed to actually even write a blog. It won't pass validation if we don't add alt tags to everything, which is awesome. But I can ship an app without this stuff. So like how do I be proactive about it, right? Is there an accessibility check button somewhere? Like that would be rad if so. Yeah, I'm glad you asked. And we actually have literally, it's also called Accessibility Checker in Visual Studio. So you can check that out. It won't cover everything. But again, these tools are always just a great place to start before you are manually going through everything yourself. And the accessibility checker in Visual Studio will scan through your Windows app, essentially, and let you know if you're missing any semantic properties. They'll let you know, hey, like, you should have like a semantic description on this control. So it'll let you know of that. There's also a tool we have at Microsoft called Accessibility Insights. So that's another tool to leverage. It does a very similar thing and sometimes it can also help guide you through not only what might be missing semantic information, but also on semantic ordering as well. So what we were talking about, like the keyboard tab order, things like that. Sometimes it's able to identify some of those things and help guide you through that process as well. We're actually right now on the .NET MAUI team going through the process for testing for accessibility ourselves. Beyond using those tools and self-checking, we also have a third party help us because they're the accessibility experts to go through a.NET MAUI app and just super make sure that everyone who is using.NET MAUI is able to build accessible apps. We're currently going through that process for.NET 9 to make sure that everything is good to go there. Very cool. Now you also talked a little bit about other teams at Microsoft and how accessibility and creating inclusive applications for all is important to Microsoft. How has that impacted .NET MAUI's development in general because there's teams at Microsoft that use .NET MAUI as well. How has that impacted the evolution of the accessibility features in .NET MAUI? Yeah, that's a great question. I think having the support at Microsoft has just made it way easier to implement all of these great accessibility features and also for us to learn on the go. I always say that accessibility is a journey because there's so much to learn. Internally, as I mentioned, we're going through the accessibility process ourselves. We also have support like we have accessibility office hours where we can go and ask questions about anything that we might not be sure about in terms of its accessibility. So there's a lot of resources that we have at a company like Microsoft that cares so much about accessibility. But there's just so much resources out there in general now as more and more people are learning about accessibility and seeing how important it is. Very cool. Like you said, it can affect business too. I can imagine. Even as a user, sometimes I open an application and I'm looking at the user design or the login process. If I run into problems, I'm less likely to use it. There are accessibility issues, individuals that have that disability are going to be less likely to use your applications. At some point, they might not be able to use your application, Yeah, historically speaking, people with disabilities have largely been excluded from apps. There was actually a survey, I forget the source, but there's annual surveys that are run asking folks about their experience using apps, especially if they have a disability or if they're using screen readers and the like. And I remember there was a question asking why they think apps aren't accessible and why websites aren't accessible. And in large part, people responded that they think it's just because people like developers just don't know how to make them accessible and they're just not aware of how to do it. So they don't. Yeah. It's not because people don't care a lot of the time that I think that apps fail to be accessible, but it's just because folks are yet to learn that this is a really cool thing that you should be considering as you're building your apps. Yeah, that makes a lot of sense. You don't know what you don't know, right? Yeah. So spend a little time, check out the documentation. We'll put links to all of Rachel's amazing blog posts, to samples, to anywhere you can communicate with the team, office hours, things like that. Rachel, thank you so much for coming on and talking about accessibility. Yeah, thanks so much for bringing me on. It's been a pleasure. Awesome. Well, don't forget also that you can see this on the .NET YouTube. If you're over there, you can see us chat through this. You can also leave comments on the .NET YouTube video to let us know about future topics you want to hear on the .NET MAUI podcast. And if you're listening on Apple, Spotify, wherever you get your podcasts, don't forget to subscribe, share with a friend, and leave a review if there's an opportunity there. It helps other folks find the podcast as well. That's going to do it for this .NET MAUI podcast. Until next time, thanks for watching and listening.