Automated Accessibility Testing in React: Beyond the Basics

Hello there. Let's deep dive into accessibility testing concerning React applications. So, first of all, let me introduce myself. My name is Vinicius Neves. You can call me Vinny if you want. I've been a tech lead at S2 and also teaching in a Brazilian college called FIAP. So, let's talk about the reasoning. Why should we automate accessibility in the early stages of the project? So, first of all, bugs found late cost more. We need more time to fix this. So, as soon as we get bugs, it's cheaper to fix them.

Manual testing doesn't scale. So, if our application grows, the regression test must be there to help us to make sure that everything is all right. And also, this kind of automation will catch 55% of these issues. So, it will help us to catch these kind of issues. Like, I'm talking specifically about accessibility issues. So, it will help us on that. And also, like, on the regression, like, making sure that we didn't break anything.

What can be automated? Accessibility is far beyond like giving images like alternative text. But what do we do? What we can automate? Like, so, all these attributes, so, outs and labels. First of all, area, like, way area, help us a lot while making our applications accessible. But invalid use of it will break things instead of fixing them. So, we can also, like, get this, like, invalid area usage. And also, contrast in semantics. So, this is, like, what we can use automation to help us with. And so, let's talk about these levels, like, these layers. What I'm going to show you next is, like, linting.

So, we get, like, while developing stuff, we get, like, instant feedback from the IDE or code editor that you are using. Unity test, like, we can use, like, to make sure that we didn't break anything. So, it helps us, like, to make sure that all our code base is still, like, accessible. Entry and testing will catch, like, full levels issues, so we can focus on the most important parts of the application. And also CI to enforce consistency, right? But I talk cheap, so let's show some code.

So, let's start, like, with the aesthetic analysis of the code. So, let's talk about the linter. So, one linter to rule them all. What I bring here is just, like, a plugin specific for accessibility. It's easy, like, to install. We can install it, like, a dev dependency and just, like, we need to config. So, I have here an example of s-lint config.js. And then I'm showing, like, what we need to do. So, we are just, like, importing them. We are declaring them as a plugin and also adding rules. So, this helps us to catch this kind of thing.

Like, we have an input with, like, a div clickable and this rule, this lint can help us to identify that a div should not be clickable. And if we need to do this for some reason, there are some ways that it can help us to fix that. But this is just, like, to talk to you that a lint can help us to prevent this kind of situation. So, we have, like, we could, like, change this div to a more accessible element, native element, like a button, or apply Whey Area if needed. But what I'm showing here that we can fetch this while developing stuff. So, in the very early stage of the project. But I won't stop here.

Let's talk about more tests, like, one test to find them. So, what, how can we use end-to-end testing to help us with the accessibility. So, there is a lib called Jest-Axi. So, we can, like, extend. For this example, I'm using Vitest, but we can use, like, Jest or whatever you want. But I'm just, like, extending the expected to have this specific method, just, like, to have no violations. So, if you think about the input components that I've shown you, we can make, like, a simple test that only renders the components. And we are expecting the results to have no violations. And when we are talking about violations, we are talking about accessibility rules, like well-known accessibility rules. So, this is not adding more effort. Just, like, a simple test we can use and we can write to avoid us to having this kind of accessibility issue.

But there is more. So, one test to bring them all. So, what we are talking about now is accessibility, right? And end-to-end testing. So, we can use something like Cypress to help us to identify this kind of issue as well. So, if you pay attention on the code that I'm sharing, I'm just, like, configuring a test. So, before each, I'm just doing, like, a simple line that is CI dot inject x. So, we have this library available to be used during, like, our tests. And what we can do, we can just, like, run whatever we need. So, in this case, it should not have violations. So, we are still talking about accessibility violations. But in this case, we're focusing on form elements. So, we are just, like, getting an input, getting the focus on the input. And then check the accessibility. And then, like, changing the focus to another input and checking again. So, this will help us, like, to ensure that we didn't, like, break or add a specific accessibility issue. Right? And, of course, CI-driven tests.

So, the pipeline to bind them. So, what I did bring here just, like, a lighthouse GitHub action. So, it's easy, like, to set up.

And then, by running this, like, on PRs, on the main branch, like, once the PR is merged, we are also, like, getting feedback around accessibility. So, this kind of thing, like, all these tools that I've showed you, it's just, like, to help us to make sure that we are not breaking the accessibility rules. And then, it's this kind of thing, like, can help us to make our application, like, future proof.

So, we can evolve it without, like, thinking about the regression. But one thing that I would like to highlight, it is, like, this it is not a substitute for manual testing. When we are talking about accessibility, we need to have people testing, testing, like, testing parties, and this kind of thing. So, these extra tools will just, like, help you to keep your project accessible and give you, like, more confidence, like, while developing web apps.

So, if you have questions or if you want to talk about something, just reach out to me on LinkedIn. I will happy to share. It was a pleasure to share this time with you, and I'll see you in the next time. Bye bye.