React Accessibility: Beyond the Basics

REACT JS ReactiveJS ReactJS TypeScript ReactJS ReactJS ReactJS 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 a knitter and a quilter, a sci-fi nerd, an 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.

So, before we get too deeply into the advanced portions of accessibility, if you want more of an introduction, you should go watch Sophie'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 dev tools that allow us to do things like emulate the, you know, 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 CSS rules that we need to.

Now Firefox also has their own, but it's a little bit more complicated to get to. 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 an up. 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 AXE for their Lighthouse extension which gives you not only an accessibility overview, but also an overview of your entire app. 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. It 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 AXE 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, beyond 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 helpful. Now, another reason for automated testing is because when you as a person go and tell your coworker something needs improvement, needs to be in a different format, they need alt tags or ARIA roles or even that their props are in the wrong order, it can build resentment and anger between the team. If your automated testing suite or your linter tells someone that these things are needed, they just fix it. So, if it is a hill you are willing to die on, write 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 is also a CLI and you can implement it into your existing test suites. Now, testing tools, like React 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 Jest or Cypress or Express or a various list of formats. You can, in fact, set up all of these DevTools within your existing test suite without having to switch to something else.

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% inaccessible. And this is a beautiful article that walks you through how they wanted to keep 100% accessibility score and how they started excluding people by removing various features or converting code. And when we get down to the bottom of this, and we run the very last test on CodePen, 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% 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, it doesn't change the fact that this code is still not accessible. There's nothing at this point that is going to replace clicking through, looking at your website. Which ties us back again to the axe 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 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 resources. 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 WebAIM 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 off. 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 coding, it can be easier to have code examples and this is a difficult to find YARIA page, but it gives you references, like a dialog modal, what a modal 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. These things are expected. So, you're not deviating from that expectation of functionality.

React accessibility is React's actual website, or not today, that walks you through the React specific formats and suggestions for how to keep their components accessible. Material UI, React Kit, 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 troubleshot 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. Hey there, how's it going? Pretty good, pretty good. It's dark and gloomy in Zurich, how is it in your place? Sunny. Looks so nice, oh my, oh my. Ah, that's a pretty room to be in, that's nice. Jen, I am so happy that we had not just one, but actually two accessibility talks at this conference, and that you went and ventured further than the introduction topic which I think a few people might already know, most people might not know that yet, but we'll figure that one out hopefully eventually and we don't have to get many people up to speed. But I really like that you went through a bunch of different things, and one thing that caught my attention, because I have fallen for this one very specifically myself, was if our automated testing does not catch everything and it never does, and you showed that very very beautifully, how can I manually testing spot things where I'm not affected, like certain colour issues where I'm not in the affected group or issues with accessing information or interacting with touch screens when the phones are large but my hands are small because I have pretty large hands, what would you do about these things that I can't spot manual testing? For things like colour contrast or colour blind issues, within both Chrome and Firefox they have built-in tools that allow you to simulate what those look like. That gives you a better idea of what kind of contrast issues you're running into or whether you're running into colour similarities that are too close for comfort. For small hands and big screens, some people ask their kids to try to do a particular task. Another really important option is to hire an auditor. Once you've handled the basic technological ability, at that point you bring people in that are trained and experienced in using the technologies. A lot of companies are into empathy training. They have you wear goggles that make you vision impaired, or they have gloves that make it more difficult for you to move. The problem with this is it makes things so much more harder for you than it would for someone who's familiar with the tools that they're working with. It's not your daily experience, so everything is awkward to you. Not just what is the expected flow, and whether the process that you have implemented falls within that expected flow. Hiring an auditor, having people that have those various disabilities tested out, is going to be a really important part of adding to that more manual testing side of accessibility.

That sounds fantastic. You mentioned a linter as well that can catch a bunch of things. Choco is asking, what was that linter that you mentioned to check alt tags and A11y issues? It is built into quite a few of the tools that we already use. It is, I believe it's JSX A11y plugin extension. I'll go ahead and look for it. Is that part of Axe or is that separate from Axe?

That is separate from Axe, but you'll find it in a lot of linters that you're utilizing from like Airbnb or things like that. It's the eslint plugin JSX A11y that will catch a lot of the technological aspects of essentially accessibility while you're coding. And besides that linter and Lighthouse and Axe, as a developer, is there anything else that I can do to make sure and test my website and my components individually for accessibility? That's a question coming in from Paul.

When it comes to testing your individual components, I did add a link to my slideshow, and I will absolutely post that in the Discord. There's the web accessibility like practices that allows you to see not only the expected behaviors for each type of component, but they also provide code so you can see how that's implemented within the HTML element. It gives you a much better idea of what types of features you need to add to the JavaScript to make those interactive functionalities work. Right, awesome. And you're going to post the slide deck into Discord? That's pretty awesome as well because there was a question on if the slides are available somewhere too. Yes. Also, have you seen any complications when it comes to accessibility with the rise of dark mode interfaces so that you can switch between light and dark?

There's so many conflicting bits of information when it comes to accessibility. For instance, someone with ADHD needs bright, direct colors with very little distraction. Whereas someone with autism may need muted colors because the intense bright colors is too much. You have dark mode which means that your light colors need to be brighter and bolder and larger in order to stand out from that black background it tends to fade right in. Whereas on a light background blacks are really strong and bold by nature. So yeah you definitely see things disappear as soon as you transition to light and dark mode. It can be an interesting fight. The other thing is when things are over like background images and you switched from light to dark mode sometimes the colors switch to a color that you can't actually see. Like it'll go from a black text on a white background to a white text on a white background. So being aware of how those are being affected is definitely something you need to look out for. And again a lot of that comes down to manual testing. Switch to dark mode. See what happens. But would you say that if dark mode is implemented properly it can also actually solve some accessibility issues because it offers those who might need the tone down muted colors a little little more um comfort? Or... It may not be that the tone down muted colors is what you're going for. You can have black with really with white text and it'll still be a very high contrast.

Right? However someone with like photosensitivity issues like me, the dark backgrounds hurt less. It's not quite as bright in my eyes. The amount of brightness is left to small things like text as opposed to the entire bold white background. That makes that makes sense.

And also that brings me into something. Because I found it very interesting. I have not heard or thought as much about the different needs of the different groups as in colors and less contrast versus those who need higher contrast and more vibrant colors. What would you say are the worst offenders in terms of accessibility issues on websites that you see and what can we do to work against those? What are the most prevalent in practice? This might skew the poll.

However, what I asked was what you do use, not what you should use. And I see people use a div for everything. A div for containers, a div for buttons, a div for links, a div for literally everything. We have these landmarks like main and content and article and these various options that give context to screen readers or to the web platform as a whole that allows people to interact more fluidly. However, when we use a div for everything and we just add on clicks to stuff, it breaks that process. So the most common thing I see is people using a div instead of a button. There are times when you want to use a div instead of a button and that's when you try to include a div inside of a button and that's not allowed. Or you can, but it's not semantically correct. At that point then you want to start adding the button accessibility features. But it's extremely rare when you should be adding that. As they say, the first rule of ARIA is don't use ARIA. When there's a better alternative available. Yeah that's I think it's very rarely necessary to tread outside of what the browser offers you. And if you do you have to be very, very careful and most people unfortunately aren't. That's definitely a problem.

And another issue that I have been seeing is that it sometimes is it's great that we convince developers to do things right, and then they want to do that, but then they don't find backup in the manager or in the team that they work within or the entire organization they work within. I know that some countries are penalizing accessibility issues on websites, especially if they are like government websites and things like that. But outside of these countries, say in Germany, say in Switzerland, what would you say to a manager who's like but we don't need accessibility. It's fine, just skip it. If you had a bug in your purchasing flow that prevented a user from actually buying your product, you would be hot fixing that, like immediately. Heads would spin so fast based on the hot fix. So why is it different when someone with an accessibility requirement can't purchase something? Why is that not a bug? That's a fair question.

And the answer I heard from managers in the past to this was like, well, that's not our customers. Our customers are young and healthy and sporty, and we don't need that. How do you convince them, how do you fix that thinking? There's quite a few different options there. So many places my brain is going right now. One of them is to argue that you are selling things for young, sporty people. However, there are aunts and uncles and grandparents and cousins and friends and siblings who buy things for young, sporty people. Not all of them are young and sporty and physically abled. Some have disabilities and are young and sporty. Either way, they need to be able to purchase these things or you're losing sales. Not only that, but as Sophie mentioned in her previous in the talk before mine, is you are, you have the potential of accessing 15% of the world who is considered disabled. Now, if you have a code base or a product that accesses like 10 million people, right, you've got 10 million users, but we have like 9 billion people and 15% of those are disabled. Are disabled, but only 1 in 10 website is even partially accessible, which means that you have the ability to corner the market on that many people. So many more than you currently have as users, if your websites accessible. So you're dealing with the fact that you could double, triple, quadruple, quintuple, octuple, the number of people that you can have accessing your website just by catering to the disabled markets. Not only that, but when you implement accessibility features, it makes it easier for everyone to use the website. It's not just a, I fixed an alt tag, it's I made the website easier to use. So if you've got the sleeping baby in your mouse hand, then you can use your keyboard on your left hand to navigate the website. Or you are in a noisy room and you're trying to show your friend a video and you want the subtitles to display so they can see what's going on. It's not a standard situation where they are deaf or they are missing an arm. It's that they're everyday people doing everyday things and utilizing these features as well. And the more often they are hindered from doing that, the less likely it is they'll come back to your site and the less likely it is they'll make the purchase in the first place. And this is something that I'm surprised that not more of us think about. And thank you very much for giving us ammunition to have this conversation with our managers. Because especially the example of being partially incapacitated throughout our daily lives. I know so many moments where I was in a public setting, did not have my headphones with me, and then I wanted to read up on something. I was presented with a video that had it all in sound and I'm like, yeah, no, this is worthless to me. Bye. And then going somewhere else and probably making the purchase there as well, if they had textual information or just subtitles. The small things sometimes can make a huge difference. Yeah.

That's a good point. As a parent, I use subtitles all the time. I'm watching a movie later at night. And you know how it is, the explosions are really, really, really loud, but the quiet moments are so quiet you can't hear them and you're constantly adjusting that volume, this way I can just leave the volume down at something that's reasonable, and then just watch the subtitles for the really quiet parts that I can't hear what they're saying without waking up the kid.

Yeah. Yeah. And also if English is not your first language, and then you have someone with a strong dialect in an English movie, you might also just need the subtitles. It has nothing to do with having a choice at this point really, because you just don't understand what is carried in that part of the conversation, which makes it also very frustrating when subtitles are like intense dialogue. I'm like, yeah, but what are they saying? Exactly.

Nantunes is asking us, with all that diversity in the options that we touched on and that you mentioned, could it make sense to have different or separate versions of your website or app to cater to these different requirements? I'm not sure you need complete separate versions, but some options would be great, being able to go into your own user settings and select those options. Keep in mind that the browsers themselves do have some of those features to increase the contrast of your site, to reduce the contrast of your site, light mode, dark mode. Understanding what the browser gives you, and then being able to make sure that whatever settings they choose are going to still work with your website, gives you a good chunk of that to begin with. And then after that, you can start adding individual setting options. However, don't jump right into those setting options when you're still fighting with the fact that all of your buttons and links are dips. Start with the low hanging fruit. Get the stuff that's going to work for everybody and then start narrowing down as you go.

I know that we should always start working on accessibility before we start building a product, but we very few have that luxury. And we are trying to add accessibility to an existing website already. And I say start with your own definition of done. Make sure that you've decided yourself as a developer that no code is going to get past you without being accessible. Your own code is going to be accessible. And then you can start extending that to like peer reviews. Hey, this isn't going to be an accessible thing. Can you just add that alt tag? Can you turn that into a button? And then beyond that, start looking at your component libraries. The component that's reused the most, work on that. Once that component is accessible, then its use everywhere is accessible, then you can go dig into individual one-off pages and see how the combination of those components are used together and how that can create some inaccessibilities in your site. And then start working on how you can expand it to make it more accessible for people that need different setting options. But definitely start with the low-hanging fruit. That makes sense.

And speaking of components, there is a question from, hold on, let me see, GJ asking, is there a tool to not just integration tests like X does, but also unit test components accessibility, and specifically VoiceOver is apparently very hard to test for? VoiceOver is very hard to test for.

Part of VoiceOver is that technological aspect of making sure you're not using ARIA roles over various pieces. Axe-Core actually can be used in unit tests as well as functional and end-to-end tests. Axe-Core is the basis or the foundation behind Lighthouse in Chrome and the Axe Firefox in Chrome plugin, so it's a great option to start with.

All right, okay. Axe-Core is also, that's really good to know. One last question. B. Benedict is asking what's your opinion on the 508 standard, never heard that before, and how important is certification to the standard? The standard goes a long way to making sure that the websites in the US are accessible if you are either working on government land or within a government website because they need to be accessible. As a government entity, they need to have access, or everyone needs to be able to have access to their information. Important. I feel that it's important because it takes into account so many different accessibility problems that we run into on the web as a standard. And it's not just I'm going to get sued if I don't do this. It's also just the right thing to do. Talking with a lot of people with disabilities, their biggest frustration isn't always that the website doesn't work for them. But most importantly, it's that they didn't matter. Their experience didn't count. They're considered not important. And sometimes they're not even considered at all. Their existence doesn't even occur to you. And that's literally the definition of being erased. Right.

Awesome. Thank you very, very much for being with us and giving this amazing talk and answering all these fantastic questions. I think you are also in the zoom room afterwards if anyone wants to join and have a formal informal Q and A with Jen as well. That is totally possible. Let's quickly look at our poll before we jump into the break. So thank you. Thank you very much, Jen, for joining us. And again, thanks for everyone who submitted questions. Jen is definitely available and will post her slides into the Discord channel as well if you're interested. It was a great talk. It was a great Q and A. It was fantastic to be with you here.