All too often A11Y is only an afterthought and will be added to a project "when we have time" i.e. never. But there are a many reasons why you should develop with a11y in mind from the start including some that will convince The Higher-Ups. We'll explore tools we can use to help us develop more accessibly and talk about some of the quirks and limitations that React Native has.
Hey, everyone, and welcome to my talk accessibility of a first class citizen. My name's Sophie. How you pronounce ArchCity, they or he? Honestly, I'm not too fast. Generally, people go with Chido, but whatever your feel appropriate. I'm a front end developer coming from the Bakken originally, but for the last one and a half years, roughly up front, in fact, native specifically and in my time in the native front. And I've also been somewhat of the tolerant diversity person in my company, which also essentially let 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 SOFA Outcome, which is my website, where, amongst other things, I have a whole, like, look serious on accessibility. And you can also follow me on Twitter on at SÖLVI. Before we jump in, just a quick note that this is somewhat of a part one of two, together with Chattanooga's talk on accessibility on the Web, which is going to be airing or what she's going to be on 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 native specifically. So let's jump right in, who's accessibility for when I asked my engineering buddies, usually the number one answer I get is it's for blind people, it's for people with visual impairments, which technically isn't wrong. It's definitely for those people. But that's only a small group of people who we need to build an accessibility for. When I try to dig in deeper, asking who else could accessibility before you see, 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 and accessibility for. But it's not everyone because what accessibility also contains this 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 a German covid out because my phone just dies immediately. But also things do need to be aware of people's personal sensibilities. Something 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 of 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've the list of people who we build and 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. Everyone starts somewhere to 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 types, the sea level types, the managers is not being accessible, can get really expensive. And why is that? Because if you accessibility is bad, you run the risk of getting sued. In the US, there's the Americans with Disabilities Act. There's different types of legislation. And 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, can run really high. It happened to be on say it happened to Domino's Pizza and you don't want to run like 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, 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 excessively accessibly. And it's going to cost a time as well, which might give your competitor the advantage to shoot ahead and take part of your off your market. And then not only is it costly in the end, that's also costly in the future, where, you know, nowadays people want to work for companies that do good and the 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 accessible, making a website accessible. And speaking of users up to or according like depending on the statistic with the World Health Organization, it's around 50 percent of people have 50 percent of people are of the web population are disabled. And that doesn't include, for example, your your parents, who, even though they can barely see, decides they're never 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 know, just speak up louder. It's 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 sea level, your managers, that you need to put in accessability, but how do we become more accessible? And the big thing is you need to build it from the start. If you check in accessability later on, it can get you a certain way 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 more effort to be accessible if you only try to tack it on later on. So you need to start with your discovery or product discovery, depending on what specifically you're working on, and that means for every feature of 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 cool video a cool animation? How can you make this accessible for people who. Yeah, again, use a screen, Twitter 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 applications listed, estimate your storage estimates, the whole feature with accessibility in mind. The last thing you want is the people that you built your your app, but you end up being late and your name comes up to you and say, hey, so why isn't this done? 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 accessibility takes time, accessibility is costly. And then the next time you do feature discovery, they're going to go, you know, maybe we should go later 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 future getting into design and then the caveat, I'm not a designer. So if you're if you're designing 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 you. It's just a quick selection of things that designers need to look out for to make sure that you have your website is accessible. And they are things like having high contrast colors, especially text and background, being able to accommodate some level. So when you zoom in on the font, the design shouldn't break the top areas. The interactive area should be a big enough that you can easily click on them. You need to be building for loading and states when the when the data is loading or when the Internet is down, for example, and your app flows should be simple and short so that people don't get lost halfway through. Like I said, this is just a natural selection. Honestly, Google it. I'm not an expert, so I'm probably not the person to ask for a complete list. In someone of the same vein as Divine, when it comes to content, you should keep your language level to around middle school, that is, generally speaking, something, a level that is easy for people to understand about native English speakers and non-native speakers that are on a reasonable fluency level. Of course, this depends on your target. You are right. If you talk to your rapid English students, your language shovel 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 is offensive so or hurtful to people, which means avoid gendered language, avoid religious language, and especially avoid jokes like very especially if they're sarcastic or if they're 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 and five years of steps and they are stuck for five hours because that just makes them feel stupid. And someone who feel stupid is not going to recommend your app to anyone. The worst case, I going to tell their friends and their family, hey, don't use this app. It's crap. When when really you might have a nice app, but just making users feel that it's not going to help your marketing. And now 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 designers don't have much influence on screen Vitters 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, spotty Internet, and also that it doesn't just completely drain useless 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 is going to go into later on. That allows us to double check that design is accessible, that the content is accessible, and to allow us to kind of put in like a lost gate to make sure that the app that's going to release 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 the other talk on the soundtrack. Just maybe take a break. But, of course, also very welcome to stay on for the native part. And let's just jump straight in. First off, like I said, there's a lot of tooling out for Web development. Unfortunately for native, there isn't a lot. The one tool I'm going to go into because I'm actually giving us talk on the Mac and the app, the demo that I'm going to go into later. Also, when I also saw the one big tool that 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 on the from my view of side and can run audit telling you, for example, the hit area. So the chapel area is too small. And on the left side, you can also see that you can influence, for example, the same level on the font size. So, yeah, before we go into the demo, one quick note, though, on the Native Accessibility API, the main thing that you need to focus on are the accessibility. Perhaps there's a few other things out there, but if you want to cover around like ninety ninety five percent of your accessibility use cases, the accessibility projects are what you want to go for. And that means and those prompts, they are available for every core component, which means you text the various lists that you have, all the touchable and the new principal as well. And there's 14 of those, six of those are for either I also andred only. So generally a bit too easy to use. And then on the other age, really the only ones you need are accessible accessibility, label accessibility and accessibility. Those cover, in my experience, around 90 to 95 percent of the accessibility needs. And with that, let's jump into the demo.