All right, here we go. Hello,
react advanced. Very excited to be here today with you remotely. My name is Yorima 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.yorima.com. And if at any point you do want to show me some love on Twitter or you want to ask some questions, you can feel free to find me at yorim04. 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. Access by everyone, regardless of disability, is an essential aspect of it. So for us as engineers, web
accessibility is about making sure that we don't gatekeep 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 be opening 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. Because as you know, building out
accessibility testing suites, building out
automation suites, these are things that take time and effort up front. 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 at 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 codebases 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 that 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 codebase 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. And another bonus is that you can automate all of this using Git hooks 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. So moving right along, we're going to talk about Lighthouse. Now this is an open source automated tool for improving the quality of your web pages. And 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. So 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 in 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. And 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 are going to see that Lighthouse gives us a full audit of the web page that we just ran it against. And 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're 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. So our next tool that I always like to talk about when talking about
react accessibility testing is
react X. 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
devtools 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
devtools console and right away we're seeing that
react X 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 X are pretty similar. They essentially are telling us where we have made errors in our
accessibility support and how to fix them. But 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 X, 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 X 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 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 X 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. Going right into unit tests, these tests are going to be looking at individual standalone components. We're going to be validating a component's
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. So, 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. So, 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. And because of that, they're not going to support keyboard navigation. So, that raises 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 so 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's a
validation run. And when that
validation is run and there's 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 just going to pass a few props to it. To all of the components. Here we have an accessible input, as we saw earlier. And this is going to take an on blur 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 accessible alert 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 my alert 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 my input component and my alert component. I'm going to focus into my input and assert that the alert contains no text in it. Because again, the text should be 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 my error message should have the text content that matches my error message value that I have passed to it. So, 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. So, 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. And another bonus is
cypress has this
cypress AXE plugin that I really like. It's pretty similar to Lighthouse and
react AXE in that it checks for
accessibility errors, except it's built right into your
testing suite. So it kind of keeps all of your
validation in one place and it allows for really an easy integration into your
ci cd pipeline. So using
cypress, let's write a very simple test for that same Slack signup form that we just talked about. We want to know that our Slack signup 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 signup form when we are successfully submitting an email address to this form. And we're able to do this simulating using just a keyboard. And that's what we want to be checking for in our test, 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 tests, we're thinking about our users, thinking about the flow of our websites and 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. And our
testing is 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 are 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 Advance. I really appreciate you having me here today. My name is Yorai Maestaves. 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. Thank you again.
