How to do Good Without Doing Anything

All right, here we go, hello React Advanced, very excited to be here today with you remotely. My name is Uraima Estevez. I am a front end dev manager over at Shopify on the Polaris Design System Team. If at any point you want to follow along with these slides, feel free to pop over to a11y-testing.uraima.com. And if at any point you do want to show me some love on Twitter or you want to ask some you can feel free to find me at URAM04.

So let's dive right in. I'm going to start by figuring out what is accessibility. So in my mind, accessibility is all about our users. And I mean all of our users, every single one of them. It's about making sure that everyone has an opportunity to participate on the web, in our mobile apps and more generally in society. And accessibility ensures this regardless of a person's circumstance, ability or disability. Web accessibility is really about keeping the web inclusive. Tim Berners-Lee, father of the internet, says here that the power of the web is in its universality. Regardless of disability is an essential aspect of it. So for us as engineers, web accessibility is about making sure that we don't gate keep certain populations of people from being able to access the web. And this is exactly what could happen if we aren't intentional about how we build our apps so that they do work for everyone.

And just like every other aspect of our work, accessibility goes beyond the build phase of an application or a website. Your work simply is not done right after you ship to production. There's maintenance, bug fixes and feature development that all come right after you ship to prod. And really every time we make a change in the code bases that we work in, we could potentially ourselves up to bugs and regressions. And in some ways, this is a fairly solved problem. We've found some pretty good ways to protect ourselves from unintentionally creating bugs or degrading our user experiences. And we do this through testing and automation. We've managed to cut down the time in running these tests and other processes and have found the ways to help protect the experiences that we're building on the web. So if we build out our components and apps as accessibly as possible, we write tests against them to validate that their behavior is being guarded against bugs and then we find those opportunities to automate some of those processes in our accessibility development cycle, we save time and build confidence in our systems that they will work for everyone and consequently make the web better for everyone. And we can sleep soundly knowing that we've built and kept our applications inclusive with very little effort in the long run. And that very last sentence is the caveat here, in the long run. As you know, building out accessibility testing suites, building out automation suites, these are things that take time and effort upfront, but once you have those in place, they really do have a really great return on the investment that you're making. So in a way, you'll be able to say that you're doing a lot of good without doing anything all once you make that investment. Sort of.

So we're going to break this up into two parts. We have our tools, which are going to be the automated tools that we're going to use at different stages in our development process. We are going to get some help automating the harder tasks that a lot of times we end up doing, and this is going to help keep our code bases free of accessibility bugs. And then we're going to talk about testing. We'll discuss what kinds of tests we write and what we want to be validating when it comes to accessibility support in our components and our apps.

Now quick disclaimer before jumping in. I am assuming you have a pretty good grasp of accessibility concepts and testing concepts so I'm going to make an assumption that you are pretty good at the best practices, the common lingo, and any syntax that I throw around. If you need a primer on accessibility, I have a couple of recorded talks that I've linked in this slide and if you would like a couple of primers on testing fundamentals, I can also tweet out a few helpful resources that I've found really helpful along the way. So with all that said, let's dive right in to tooling.

So I really like to start off with this ESLint plugin, JSX Accessibility. This is a set of accessibility linter rules that are going to check your JSX elements and React during your development. So this is super low-lift because most people, especially most people here, probably already have some sort of linter in their code base, and likely are using something like ESLint. So this is going to help you catch the most common accessibility mistakes in your code while you're writing your code. Another bonus is that you can automate all of this using GitHooks to prevent inaccessible code from getting committed. You can also throw it into your CICD pipeline and fail any builds if errors are thrown, so that you can prevent accessibility errors from making it into production.

Moving right along, we're going to talk about Lighthouse. This is an open source automated tool for improving the quality of your webpages. More specifically, Lighthouse allows you to run accessibility audits on your website. This is going to give you a really good understanding of just how accessible your website is. It's going to help you unearth any issues that you might need to resolve. Lighthouse comes in a few different flavors, Chrome DevTools, Command Line, CI Systems, and a really helpful web UI. All of these are going to be great for any different stages in your development process and can really be tailored to the way that you like to work. For now, we're going to take a look at Lighthouse and the Chrome DevTools because that's how I like to use it, but there's really a lot of documentation out there for any other use case that you want to explore. So in the Chrome DevTools, we're just going to pop into the audits tab. Now you're going to see Lighthouse offers us a list of audits that we can run with a few different options that we can set. So here I have the accessibility category, and we're going to run it against a desktop device. By click generate report, it'll take a couple of minutes, and then we're going to see that Lighthouse gives us a full audit of the web page that we just ran it against. That's going to give us a score out of 100. So this score is going to let us know how accessible our website is by checking if we're adhering to accessibility standards and best practices. So we want to get to as close to 100 as possible.

Now, along with our score, we are also going to get a list of where we lost points for when we didn't exactly meet those best practices or standards. If you see here, I ran it against the Polaris DevTool web page documentation. And on the previous page, we got 100 out of 100, really great stuff, navigated into another page in the Polaris documentation. And we got docked a couple of points here. So another thing that's really great about Lighthouse is that when we do lose points out of that 100 point score, it's going to give us some pretty helpful tips for how we can fix those errors. Here, you see that we actually have some heading elements that are not in sequentially descending order. If I click into this error, it'll give me a little bit more details around how I can exactly fix this error and bring that score back up to 100. So I really like to use this Lighthouse tool as I'm making changes in my code, basically to make sure that I'm not unintentionally degrading my accessibility to support and to keep me as close to that 100 out of 100 as possible.

Now, something that I really, really love about Lighthouse is that it's not just for accessibility support. We can also use it to run a bunch of different audits. We have performance, best practices, SEO, progressive web apps, really anything that we can think of in order to have a top-quality website. So all of this is rolled into one tool so that we can make sure that we're building the best website possible. And fun little fact here is if you get 100 out of 100 across multiple different categories, you get a really nice little surprise at the end.

Our next tool that I always like to talk about when talking about React accessibility testing is React Axe. Now this is another open-source tool that is going to test the accessibility of our React applications and it's going to display those results in the Chrome dev tools console. So here I'm actually using the New York Times 30-Day Wellness Challenge as a demonstration. I'm going to open up the dev tools console and right away we're seeing that React Axe is highlighting all of the accessibility errors on the page. So these errors are going to include something called a severity rating. It's going to range from minor to moderate to severe and these ratings are basically going to give us a very quick understanding of how badly does this affect my user experience and how should I prioritize fixing those errors. Along with those errors it's going to give us a link to a really helpful resource for details on what the error is exactly and some ways that we can fix it. So in a lot of ways Lighthouse and React Axe are pretty similar. They essentially are telling us where we have made errors in our accessibility support and how to fix them. One really key difference here to note is that you saw Lighthouse really is only checking after a page has loaded and you're essentially statically checking that page. For React Axe you're seeing here that I'm clicking around interacting with the page and as I'm interacting with it, it's giving me new errors. It is rendering as I go and as I am dynamically interacting with this website. So React Axe is a really great way to test out that not just at the initial page load that our website is as accessible as possible, but as my user runs through the website or the application to make sure that all of my bases are covered.

So last tool I want to talk about today that I won't get too into, but it is a really important one to hit, is axe-core. This is an accessibility engine for automated web UI testing. So axe-core is essentially a really powerful lower-level API that helps with running automated accessibility tests and processes. And a fun fact about axe-core is that because it is such a low-level and powerful API, both Lighthouse and React-Axe are built using the axe-core API.

So essentially that should signal to you that this is going to allow you to take full control over the workflows, the processes, and the tests that you want to build to custom fit your specific use cases. And that really wraps it up for tooling that I want to go over. We talked about a couple, and that is really by no means an exhaustive list of the tools that are available for your JavaScript applications when it comes to accessibility testing but I think this is a pretty good start to get you at least thinking about your accessibility development processes and where you can start to automate some tasks.

So now let's move into our testing, we're going to talk about some automated tests that we can check to make sure we're keeping our apps accessible. So quick disclaimer, I'm going to share the tools that I use but the frameworks and the libraries that I call out here really don't matter all that much. What I want you to pay attention to is what I'm testing and why it's important to test them. So we're really going to cover the main three kinds of tests that are relevant to us and these are unit tests, integration tests and end to end tests.

Diving right into unit tests, these tests are going to be looking at individual standalone components. We're going to be validating a components API and its behavior. This might look like testing our aria attributes and making sure that they are present and that their values are correct. This can also look like testing keyboard navigation within that component itself. So again, tools don't really matter here, or the specific tools don't really matter here. But just in case you want somewhere to start, I like to use React testing library and Jest together. They work really well together and they've got great accessibility support. So let's start off with a really simple component. We're just going to build out an accessible button. In my button, I'm going to make sure that I'm passing an accessible label prop and I'm going to conditionally render that accessible label. That label is actually going to show up as the HTML attribute aria-label. And this is going to provide a descriptive label for the element that it's applied to, so that something like a screen reader or some other sort of assistive technologies can announce it to our users or make it more accessible, essentially.

So, here's our test. Let's dive right in. We're going to start by checking that our aria-label attribute is rendered when we pass accessible label prop to it. We're going to create a button component and render that to the page. Finally, I'm going to assert that our button does have that aria-label attribute present and that it is set to the correct aria-label value that we pass to our prop. Now, this test is going to ensure that we always have the right aria-label for our component. And this is key because it could really protect us from any regressions if one day someone comes along and refactors the button component. They may accidentally delete that accessible-label prop unknowingly or just simply forget to render it, and if that happens, this test is going to yell out, hey, you forgot something really important here, maybe go back and take a look to validate what you wrote. Now, we also want to validate when that aria-label should not be rendered. And we only want to render this aria-label. If the accessible-label prop is not passed to it.

So, much the same as our last test, we're going to render out our accessible-button component, and then we're going to query for that button component. And now, here's the key. We want to make sure that because we did not pass an accessible-label prop to our accessible-button, we are not rendering an aria-label, not even the empty string in that aria attribute. And the reason we want to do this is because if we have an aria-label that is set to empty or maybe set to null, or something that is not the specific label that we want, this could have some unexpected side effects when it comes to assistive technologies, like something like a screen reader comes into play. So, again, this is not too difficult of a test. It's fairly straightforward, but in the long run, it really does help protect us against introducing any sort of accessibility bugs that may degrade our user experience.

So let's talk about another test, this time, figuring out our keyboard focus. So, making sure that we're testing that our components can gain focus is a really good way to test for keyboard navigation. Now, all of our interactive elements need to support keyboard-only users. And only elements that can be focused are interactive with a keyboard.

Here, we're going to take that same accessible button and then call the focus method on it. And then, we're going to assert that after we've focused on this button, that that button should actually have focus. Now, this test really protects us in the future from introducing bugs that break keyboard navigation.

For our accessible button that we've written here, we have used the HTML button element as the main element. And HTML buttons by default are keyboard navigable because they are able to gain focus. But let's say somewhere down the line, probably you honestly, six months later after you wrote this, come in and you change from our button HTML element to a div. Now, here's the issue is that divs are not focusable elements by default. They are not interactive out of the box and therefore they don't need to gain focus. Because of that, they're not going to support keyboard navigation. So that is a problem. But because we have our test, now this is going to fail our test. And it's going to let us know that we have likely introduced an unintentional bug in our code that breaks keyboard navigation for our users. And these are the kinds of things that we want to make sure we're testing for. We want to find those test cases that are going to distill down exactly what the outcomes look like through an accessible lens for our components. If you have a component that is interactive, this lets me know that I have to check for keyboard focus in order to make sure that keyboard navigation is supported. When my components rely on ARIA attributes, for example, I want to make sure that I'm validating those ARIA attributes. Making sure that they are present in the code and that they have the correct value when they are present.

So, enough with unit tests. Let's talk about integration tests. And, integration tests are going to help us validate how individual components interact with each other. And a lot of what we just covered talking about unit tests can be applied to integration tests. We are less concerned about component APIs. We are more concerned about the outcomes of how these components come together and work with each other.

So, while we can still test for aria attributes and keyboard navigation, this time we want to test them across multiple components coming together. Here, I have an example using the use React meetup website. We have a Slack signup form on the site where you can submit your email and join our Slack group. So, here, when I focus into the email input, and then blur out of the email input, there is a validation run. And when that validation is run, and there is no valid email address, you see that there is a red outline added to this input to signal to me that I need to add some sort of valid email. I also need to make sure that my screen reader users are notified of this error somehow, and that's where we're going to test right now. We're going to test that we are properly signaling to any assistive technologies of this specific flow.

So, let's take a look at this component. Our Slack signup container is composed of multiple components, and the container is going to pass a few props to all of the components. Here, we have an accessible input as we saw earlier, and this is going to take an onBlur function, and we also have an accessible alert component. And this component is going to accept some sort of message, likely an error message, that is going to run with validation. So, looking into our accessibleAlert component, we can see that it is visually hidden so that it doesn't show up on the page, because this is a component that is only here for assistive technologies. I have here the role attribute set to alert, and this is an aria-attribute that's going to announce any changes to this component, so when we do add an error message, something like a screen reader is going to be able to announce that message to our user, and I've set it to empty to start, because this is only going to alert our user of any changes to this paragraph node.

So, let's take a look at what a really simple test might be for a Slack signup container component. We're going to test that myAlert is updated when the input is blurred and no valid email address is added to it. I'm going to render out my signup container component and get references to myInput component and myAlert component. I'm going to focus into my input and assert that theAlert contains no text in it, because again the alert should be empty when it's rendered to the page. Then I'm going to blur out of that input component and now I'm going to assert that myerrorMessage should have the text content that matches myerrorMessage value that I've passed to it. That was maybe a lot of moving parts, but the guiding principles are the same in this case. We are checking that the behaviors of these components as they come together are accessible throughout the different stages. We can check that our components will contain the correct aria attributes, the appropriate keyboard navigation, even though there are a bunch of components coming together for one functionality.

Now we'll talk about end-to-end tests. These are tests that are probably going to be the closest to how our user is going to experience our websites or our apps. We're essentially going to evaluate the same things as with our user and integration tests, but now we're going to do it within the context of a fully fleshed out user flow.

Any sort of full pages or even our entire applications. I like to use Cypress.io. This is an open source end-to-end testing framework. It's really great for browser driven testing and it has excellent accessibility support.

Another bonus is Cypress has this Cypress Acts plugin that I really like. It's pretty similar to Lighthouse and React Acts in that it checks for accessibility errors except it's built right into your testing suite. It kind of keeps all of your validation in one place and it allows for really an easy integration into your CI, CD pipeline.

Using Cypress, let's write a very simple test for that same Slack sign-up form that we just talked about. We want to know that our Slack sign-up component works using only a keyboard. We're going to query for our accessible input. We're going to type in a valid email address, hit Tab to get to the Submit button, and then hit the Enter key in order to submit our email address. Finally, we're going to check that our accessible alert is updated with that success message.

Now, that was really quick, simple, super small, but this tests the entire user flow of our Slack sign-up form when we are successfully submitting an email address to this form. We're able to do this simulating using just a keyboard. That's what we want to be checking for in our end-to-end test, specifically. We want to check how is the user interacting with my app or my website? How can I translate that into a test and validate that that works, and how am I doing that through an accessibility lens?

We can also test that we are alerting of errors in the same way that we did in our integration test, making sure that errors are properly announced to our users. Or we can take it a step further and say, what if I wanted to test my entire navigation flow? What happens when a user is using a single page application? And what is the implications for navigation and accessibility support? For end-to-end test, we're thinking about our users, thinking about the flow of our websites and then our apps, and figuring out how do we want to validate all of these concepts as they're coming together.

And that's it for testing. That was a lot to cover using just the three types of tests that we usually focus on. Our unit tests are going to be for our component APIs and our behaviors. Integration tests are going to be for components that interact with each other or depend on other components, and end-to-end tests are for validating entire user flows. So putting all that together, our tooling helps us prevent accessibility bugs from being introduced while we're writing code, committing to code bases, and shipping to production. They're going to help generate audits and uncover where we can improve our accessibility support. And then in our testing, we covered unit integration and end-to-end tests, when it's appropriate to use each kind, and what to test for when we're working in each sort of category.

Now, that was admittedly a lot to cover in a really short amount of time. And there's still plenty that we haven't uncovered, that are really going to be critical for creating an accessibility development flow that will benefit your projects and your teams. So, if I can leave you with really just one piece of advice that I want you to take away, it's going to be that, admittedly, it can be really overwhelming if this is the first time that you've thought about the accessibility of your projects. And you're taking stock of the work that needs to happen in order to bring it up to standards and create really reliable processes around them. So, it's not expected that you have a fully accessible site or 100% test coverage on day one. I'm urging you to make incremental changes where you can and consistently chisel away at the accessibility errors.

Eventually, implementing those small changes are going to add up to possessing a really deep understanding of what it's going to take to make your website accessible. And how to make it resilient against the bugs that are crawling around. And once you have that understanding, and you have your automation and testing processes in place, it'll be easier to make your websites work for everyone. And that means it'll be easier to build a better web for everyone.

So with a little bit of work on the front and slowly chiseling away at all of these different bugs, eventually you'll be able to say that you're doing a lot of good without doing anything at all. Sort of.

Thank you so much, React Advanced. I really appreciate you having me here today. My name is Yorayma Estevez. Please feel free to hit up these slides or catch me on Twitter. I'll probably be sticking around for a few after this talk. So if you have any questions, please feel free to find me and ask away.