Accessibility as a First Class Citizen

So, what's the most popular language? TypeScript. And, of course, React. TypeScript is the best language for learning JavaScript. And it's really not about type. It's about the type. It's about the word. The language is about how to write it. It's about how you can learn it, it's about the way to express it, and, yes, it's about the language coming up. It's about making a connection. And, of course, React is about that. Most people don't do a lot of research when it comes to languages or languages. But it's about making a connection. So, if you're working on a course, it's about making a connection. If you're working on a course, it's about making a loop. And that's it.

Hey, everyone. And welcome to my talk. Accessibility as a first-class citizen. My name is Sophie Au. The pronouns are she, they, or he. I'm not too fast. People generally go with she, though. I'm a front-end full stack developer. Coming from the back-end originally but for the last one and a half years, roughly, I've been doing front-end, React Native specifically. And in my time in the React Native front-end, I've also been somewhat of the token diversity person in my company which also essentially led me down the accessibility rabbit hole, which is I guess part of the diversity. If you want to know more about me, you can find me on the internet on SophieAu.com. My website among other things, I have a whole block series on accessibility and you can also follow me on Twitter at Sophie Au.

Before we jump in, just a quick note that this is somewhat of a part 1 of 2 together with Jean-Luc's talk on accessibility on the web, which is going to be airing, or she is going to be airing in about an hour, I think, one and a half hours. So I'm going to focus more on accessibility in general in the first half of my talk, so who is it for? Why do we do it? How do we do it? And then I'm going to focus on accessibility in React Native, specifically. So, let's jump right in.

Who's accessibility for? When I ask my engineering buddies, usually the number one answer that I get is for blind people, people with visual impairments, which technically isn't wrong, it's definitely for those people, but that's only a small sub-group of people who we need to build an accessibility for.

When I try to dig in deeper, asking who else could accessibility be for, usually what I get is people who are disabled, which, amongst other things, includes people who are deaf or have a hearing impairment, people who have a motor impairment, people with neurological or mental disorders, or people with learning disabilities. And again, this is definitely people that we need to build an accessibility for, but it's not everyone, because what accessibility also contains is building for people who have slow internet, or no internet, or spotty internet connection, people who have old and slow devices with different screen sizes, some are tiny, some are huge.

Like, for example, me personally, I have a Samsung Galaxy S5, which is probably older than most people who are going to watch this talk, and if I turn on Bluetooth, my battery is just immediately going to drain, which means that, for example, I can't use the German COVID app, because my phone just dies immediately. But also, things you need to be aware of are people's personal sensibilities. Some things that you think are normal and fine are offensive to people, are hurtful. And also one thing, especially in mobile development, is you need to be aware that some people are left-handed and some people have small hands, and you need to make sure that your app can be, like, that the corners of the app can be reached by everyone.

So now that we have the list of people who we build an accessibility for, why should we care? And really there's kind of two big things. Number one is it's the right thing to do. You don't want to on purpose exclude people. Of course, you know, if you're not aware of the issues that your app has in terms of accessibility, that's fine. You know, everyone starts somewhere. Do your best. Get there. But if you are aware of your issues, you should fix them to help other people out. And then the one point which usually goes down really well with the C-level types, your managers is, you know, not being accessible can get really expensive. And why is that? Because if your accessibility is bad, you run the risk of getting sued. In the U.S., there's the Americans with Disabilities Act, there's different types of legislation in, I guess, most countries around the world where if your app or your website is inaccessible, you can get sued, and those legal costs can run really high. It happened to Beyonce. It happened to Domino's Pizza, and you don't want to run, you don't want to join that club. And then it's not only the legal costs that are going to cost that, that are going to make it expensive. It's also fixing that issue if you don't want to get sued like two months later. So fixing the issue takes engineering time, it takes design time, you might have to overhaul the whole feature because it's just not possible to do this accessibly. And it's going to cost you time as well, which might give your competitor the advantage to shoot ahead and like take part of your, of your market. And then not only is it costly in that situation, it's also costly in the future where, you know, nowadays, people want to work for companies that do good, and users want to use apps of companies that do good, and to attract a valuable user, to attract good employees, you want to show them that you are a company that values people, which also includes making your app accessible, making your website accessible. And speaking of users, up to or according like, depending on the statistic, with the World Health Organization, it's around 50% of people. Yeah, 50% of people are of the world population are disabled. And that doesn't include, for example, your, your parent who, even though they can barely going to wear reading glasses because they're not that old and they can read just fine, or your grandparents who even though they can't hear a thing, just tell you no, just speak up louder. It's fine, I don't need a hearing aid. Those people aren't even counted in that statistic.

So you know, if you actually cater to people who have accessibility needs to suddenly have a huge untapped user base that quite often you will be one of the few companies that actually cater to them and therefore get somewhat of a monopoly in your industry.

So going from there, you've successfully convinced your C-level, your managers that you need to put in accessibility, but how do we become more accessible? And the big thing is, you need to build it in from the start.

If you chuck in accessibility later on, it can get you to a certain point, but you're going to at some point hit a brick wall and it's going to take a lot more time, a lot to be accessible, if you only try to tack it on later on.

So you need to start with feature discovery or product discovery depending on what specifically you're working on. And that means for every feature, every product that you build, you need to consider all the accessibility implications.

Do you, for example, want to put in a chart that's interactive? How can you make this interactive for people who use a screen reader? Or you want to put in a cool video, a cool animation. How can you make this accessible for people who, yeah, again, use a screen reader? Or even for people who might be really sensitive to certain flashing animations. Can you put in alternatives for people to use the app still?

And then when you have all those implications listed, estimate your stories, estimate the whole feature with accessibility in mind. The last thing you want is that people, that you build your app, but you end up being late The deadline was last week. And you have to tell them, well, you know, we still haven't done the accessibility part.

Because that just signals that that signals that to them that, you know, accessibility takes time, accessibility is costly. And then the next time you do feature discovery, they're gonna go, you know, maybe we should go lighter on accessibility. And that's not something you want to happen.

So you've done the discovery, you've listed everything you need to do. Usually in my experience, next step is the feature getting into design. And then big caveat, I'm not a designer.

So if you're a designer, if you talk to your designer, really the best point for them to go is to Google, there's tons of great blog posts out there, there's books on accessibility and design that they can read.

But here's just a quick selection of things that designers need to look out for to make sure that your app, your website is accessible. And there are things like having high contrast colors, especially text and background, being able to accommodate zoom levels. So when you zoom in on the font, the design shouldn't break. The tap areas, the interactive areas should be big enough that you can easily click on them. You need to be building for loading and error states. When the data is loading or internet is down, for example, and your app flows should be simple and short so people don't get lost halfway through. Like I said, this is just a short selection. Honestly, Google it. I'm not an expert. So I'm probably not the person to ask there for a complete list.

In somewhat of the same vein as design, when it comes to content, you should keep your level to around middle school. That is generally speaking something, a level that is easy for people to understand at both native English speakers and non-native speakers that are on a reasonable fluency level.

Of course, this depends on your target user, right? If you target your app at English PhD students, your language level can probably be higher, but if it's somewhat aimed at the general public, it should be at around middle school level.

Also something you should be aware of, which I already mentioned earlier, is make sure your language isn't offensive, so, or hurtful to people, which means avoid gendered language, avoid religious language, and especially avoid jokes, like very, very especially if they are sarcastic or if they are somewhat edgy. Because people will take offense, people will misunderstand them and suddenly you find yourself in a Twitter shitstorm and that is something your PR team does not want.

And somewhat similarly, you want to avoid condescending language even if it's accidental. So don't tell your user, do this quick thing in five user steps and they are stuck for five hours, because that just makes them feel stupid. And someone who feels stupid is not going to recommend your app to anyone. In the worst case, they're going to tell their friends and their family, hey, don't use this app, it's crap when really you might have a nice app, but just making a user feel bad, it's not going to help your marketing.

Now we're finally on the engineering step where also the main reason for why everyone seems to think that we're building for blind people comes in. Because engineering is the one part in the chain that is building specifically for screen reader. Designers don't have much influence on screen reader's content. The content team doesn't really have much influence except for them obviously supplying the content, but as engineers, it's our job to make sure that the app, the website, is usable on a screen reader. But that's not all we do. We also need to make sure that your app runs on low computing power, that it runs on slow and spotty internet, and also that it doesn't just completely drain the user's battery.

And then finally, one thing where we as engineers are very lucky is that there's a lot of tooling out there, especially for the web, which Jen is going to go into later on, that allows us to double-check that design is accessible, that the content is accessible, to allow us to put in a last gate to make sure that the app that's going to get released into production is actually accessible for the user. And with that, we're already done with the general part, so if you were only here for that, now's the time to grab a coffee, maybe watch the other talk on the SummerTrack, just maybe take a break, you know, but of course you're also very welcome to stay on for the

First off, like I said, there's a lot of tooling out for web development. Unfortunately, for React Native there isn't a lot. The one tool I'm going to go into because I'm actually giving this talk on a Mac and the app, the demo that I'm going to go into later is also an iOS app.

So the one big tool that us Mac developers have is the Accessibility Inspector. It works as somewhat of a fake-ish screen reader, but it also allows us to run an audit, as you can see from my view of right side. It can run audit telling you, hey, for example, the hit area. So the tappable area is too small. And on the left side, you can also see that you can influence, for example, the zoom level on the font size.

So yeah, before we go into the demo, one quick note though on the React Native Accessibility API. The main thing that you need to focus on are the accessibility props. There's a few other things out there. But if you want to cover around like 90, 95% of your accessibility use cases, the accessibility props are what you want to go for. And that means those props are available for every core component, which means view, text, the various lists that you have, all the touchables and the new pressable as well. And there's 14 of those props. Six of those are for either iOS or Android only. So they're generally a bit positive to use. And then on the other eight, really the only ones you need are accessible, accessibility label, accessibility role and accessibility state. Those cover in my experience around 90 to 95% of your accessibility needs.

And with that, let's jump into the demo. So as you can hopefully see, I've prepared a short app. It's a one screen app. It's a quest app and your current quest is restoring magic. And to restore magic, you need to find seven keys. These are held by various people. And you have a button that allows you to set the next key as found. So if we just click through this real quick. When I click the button, as a sighted user you will be able to see that the first key has now been selected as found, which is indicated by a higher contrast on the fonts. And the key icon that is on the right of the list item is now golden. And then you can do this for every list item. And when you have found all seven keys, the button to set the next key as found is disabled.

And when you have found all seven keys, the button to set the next key as found is disabled. All right. So first a quick caveat. The accessibility inspector, unfortunately, is sometimes a bit buggy. So if it crashes, please bear with me. Restarting it is really quick. So yeah, let's just quickly go through it with the screen reader to understand what a non-sighted user will actually see or hear in this case, actually. There you go. I warned you, it is a bit buggy. I'm very sorry about that. But usually that resolves itself eventually. Or not.

All right. So as you might have just heard and or seen, and as you can see on the left in the basic label field here, doesn't focus unfortunately, every single text element is read as a single element. So for a list row that includes the realm key and fairy queen for example, fairy queen being the owner of the realm key, it will read realm key and then fairy queen as if they have no relation. But of course they're in the same list row. So you want to make sure that a screen reader user knows that they belong together. And to do that, you need to set the accessible prop. The accessible prop, as I just said, groups all children into a selectable component, and the label, so what the screen reader is going to read, is set by concatenating all the text children. Now one note on that is that all touchable and pressable core components are accessible by default, which means it's the touchable opacity, the touchable highlight, and there's a third touchable that I just can't remember off the top of my head now, but they're all set to accessible by default. Everything else is set to accessible faults by default. So let us set that prop. For that, have a look in line 8 here after the style. So on this end, when I now select that commit, you will now see here that the accessible prop is set to true in the list item. And yeah, assuming that the simulator doesn't crash, or the accessibility inspector, let's see what happens. It crashes. I'm sorry. All right. Nothing happens, which is also great. Oh, there you go.

So you just saw and also heard that now this row for the key is read as illusion key father Po, which like I just said, is the concatenation of the title and the owner, but this doesn't actually tell the user anything about the state of the rose. So as a sighted user, you now know this means that the key hasn't been found, but the label doesn't actually tell you that. And now when I like set the key as found and I run the inspector again, hoping that it doesn't crash, which it does. Come on.

You just heard that even when it is selected, it doesn't actually do anything. So what you want to do is you want to set a label to let the user know that, Hey, this key has been found, all this fee has not been found. And for that, you need to set the appropriately named accessibility label. Like I just said, it describes what the component contains or what the component is used for. And it should not be used as a replacement of good design of good, like visible components. It should only be used to rearrange the component content and let a screen reader user know any information that cannot be conveyed via text. So yeah, let us set this prop. You will now see it after the accessible true prop in line 9 to I think 11. Actually, it is 11 to 13, I'm sorry.

So over here, you can now see we're setting title held by the owner. And then if the key has been found, it's set to retrieved. If not, it is set to not retrieved. So let's see if that works. And then the next element is red. All right, there you go. Now the screen reader user is made aware of, you know, has this key been retrieved or not. And that is actually pretty much it for those list items that are not interactive. But as you might have noticed while the screen reader went through the list, when it comes to the set next key as found button, there's no indication to a screen reader user that this button is actually pressable, that this is actually a button. So assuming that thing doesn't crash, I'm really sorry. For some reason since the newest upgrade, the accessibility inspector has been specifically buggy. But as you can see here, we are now in the reader on the button. But the label is set next key is found, which is essentially the same as any text item. So how do we let the user know, hey, this is actually a button, this is interactive? For that, you need to set the accessibility role. What the role does, it describes, like the name says, the role of the button, the role of the component, which is in many cases the button. Like, honestly for me, 90% of the time, it's really just me setting the role to button. But there's also others such as link and header.

I think in total, there's around 20. You can look them up in the docs. The thing with the role is you need to always set it manually. There's no default. Which means that if you have a touchable or a pressable, which in most cases are a button, you need to make sure that you still set the role. Otherwise, the user will not be aware that this is actually interactive.

So let us set the button. For that, we need to go into the refresh button component. And now when you look at line 11, we have now set the accessibility role to button. And already on the left in the accessibility inspector, you can see that the trait button has been set. And then, assuming that it doesn't crash, there you go. It now announces that the button is an actual button. Which is great. You now have covered around 90%. But there's still another 5% that we can get out of this. It just announced button. Meaning that we can interact. But like I showed in the beginning, once you've found all keys, the button is disabled. Because there's no more keys to be found. Unfortunately, the screen reader will still just read buttons. So a screen reader user will think this button continues to be interactive.

Sorry. There you go. To fix that, we need to set the accessibility state. The accessibility state, like it says, is the state the component is in. And it can be, for example, loading or disabled. It can also, I think, be selected or checked. And it's an object, so you can give it multiple states. So let us set the state on this element. You can now see in line 12 here, we just set the state to disabled, based on the prop, which is a boolean.

And let us see what happens now. There you go. Now it's announced it's not enabled. What happens if the button is enabled? So let me just sneakily reset the whole thing. There you go. Now the user is aware that this is a button, there's no mention of it not being enabled, so it has to be enabled.

And yes, that is actually pretty much it already. already allow you to cover around 90 or 95% of your accessibility needs for everything else. The documentation in React Native is actually pretty good on all the other things. There's cool things like you can do conditional stuff based on if a screen reader is turned on or not, but I'm not going to go into those, because at some point, the Pareto principle hits where you know, those last few percents you want to get out, they are a lot of work.

So yes, that is already it from myself. Thank you very much, and I think we're now ready to go into the Q&A.