Accessibility in React has been a hot topic in the last few years, but in this talk, we'll be going beyond the basics. We'll discuss what disability means beyond what you've heard before, and then use code examples to learn why semantic HTML is helpful, and when it's just not enough. We'll then look into tooling, and talk about how you can introduce accessibility testing into your teams and existing code. You'll leave with the tools and knowledge to make a difference starting today.
Slides - https://www.jenluker.com/slides/a11y-btb-reactsummit2020.pdf
Hello, everyone. Today, we're going to be going over react accessibility beyond the basics. Now, to tell you a little bit about me. My name is Jen Luker. I am an editor and a quilter, a sci fi nerd and accessibility advocate. And then I'm a software engineer and I like to play with Iot devices. And as you can see from all of these photos, I am a lover of pretty dresses. Before we get too deeply into the advanced portions of accessibility, if you wants more of an introduction, you should go watch Sophy's talk on accessibility. As a first class citizen, she does a fantastic job of giving you that introduction. So one of the things that goes with accessibility are various web tools. Now, Chrome has quite a few built-In tools that we used to be able to use plugins for, but we really don't need to at this point. We have the tools that allow us to do things like emulate the colorblind features or we can see the comparisons between different contrast colors. And it really gives us a great idea on how to modify those ISIS rules that we need to make. Firefox also has their own, but it's a little bit more complicated to get to if you're going to need to modify your settings in order to get to these. And once you turn on that simulate dropdown, you're going to be able to do the same thing. Now, don't forget that when you do that, you are, in fact, going to need to close all of your Firefox windows and bring them back up, a refresh is not enough. So make sure you do turn it off and turn it back on again. I also really enjoy using the Axe Chrome and Firefox extension, even though Chrome and Firefox have this built in. In fact, Chrome uses AKs for their lighthouse extension, which, you know, gives you a not only in accessibility overview, but also an overview of your entire EP. This, however, is more of an educational tool for me. Because it gives you not only your violations, but it also gives you a description of where it's located, it highlights it for you and gives you more of an idea of what the impact is and also gives you a lot of different ideas regarding how you can solve this. No one problem has one solution. Therefore, understanding what the problem is in the first place is a very big deal. I love X because it gives you the opportunity to learn. It's not just telling you what's wrong, it's telling you why it's wrong and how to fix it. Fantastic tool. Now are doing manual testing, using those tools. You want to make the right things easy and the wrong things hard to do, it can be difficult when. The only way to handle accessibility, features and accessibility problems is to manually test and manually fix. So taking care of a lot of the low hanging fruit using automated testing is really helpful. Now, another reason for automated testing is because when you as a person go and tell your co-worker that something needs improvements, needs to be in a different format, they need alt tags or Ariah rolls or even that they're props are in the wrong order. They can build resentment and anger between the team. But if your automated testing suites or your linta tells someone that these things are needed, they just fix it. So if it if it is a hell you are willing to die on. Right. A lint rule, it will save everyone on the team. A lot of strife and anger and frustration. X goes beyond just being a Web tool. It also is a key ally and you can implement it into your existing test suites. Now, testing tools like testing tools has it built in so you don't have to deal with trying to set this up on your own. But these are some examples of how you can use it in selenium or just or Cyprus or Xpress or a various list of formats. You can, in fact, set up all of these dev tools within your existing test suite without having to switch to something else. OK, but once we've integrated automated testing. Where are we, are we good? Absolutely not. And the problem most deeply is something like this, we have a website here that is 100 percent inaccessible and this is a beautiful article that walks you through how they wanted to keep 100 percent accessibility score and how they started excluding people by, you know, removing various features or converting code. And when we get down to the bottom of this. And we run the very last test. On Copan, you'll see that your cursor disappears when you're on it, but when you're off, it's fine. Nothing is clickable. You can't tab to anything, you can't do anything with it. But it is, in fact, a valid website. It does give you information. You just can't see it at all. And this still gives you a 100 percent lighthouse score. So just because you've used all of your automated tools, you've gotten all of your reminders that the functionality needs to be available within the code doesn't change the fact that this code is still not accessible. There is nothing at this point that is going to replace clicking through looking at your website, which ties us back again to the tools that can help you look at those things and give you reminders but isn't going to do it all for you. There's a lot that goes into accessibility. It's not just can I click on something? Can I see it? Can a screen reader see it? It's also as deep as can someone who's coming into this with English as a second language read it clearly or can someone who is. Autistic be able to understand what's going on, it's not just about the technological functionality, it's about the readability. It's about how people can use the website, the way that they need to in order to reach the goals that they're trying to obtain. So what should you be testing when you're looking at a website? I'm going to give you a couple different sources. One of them is a list of checklists. These are beautiful because when you go to each one, you're going to notice that they have a list of what each one is, what you're looking for. So you can walk through this list and understand what it is you need to be testing, clearly identifying input errors or making sure that all elements are built for accessibility. But what does that mean? When you go to something like the WebMD checklist, it has a similar option, but does in fact give you a little bit more detail on what they mean for each section and you can, in fact, check them all. It gives you a lot more detail on how you may want to walk through that testing manually or even create automated tests. Now. Even if you're trying to figure out. Your components, when you're coating it, can be easier to have code examples, and this is a difficult to find. Why are you paged? But it gives you references like a dialogue model, what a model code should look like and examples. It means that you can go here and start building your own components that include these features, like what happens when you tab, what happens when you shift tab, what happens when you escape. But these things are expected. So you're not deviating from that expectation or that expectation of functionality. React, accessability is reacts actual website or not today that walks you through. The. Really specific formats and suggestions for how to keep their components accessible material UI can't reach UI. They're all component libraries that are starting you out with accessible components and you can take those and build upon them or compose them in order to make the websites that you're working with. It's a beautiful way of developing a website with components that have already been in existence, that have already been vetted and troublespot. That's also open source. And above all, just remember, while you're working with all of these accessible features and inaccessible features that. Everyone you meet is, in fact, fighting JavaScript, thank you.