Write E2E Tests for Accessibility Using aXe-core and Cypress

Instructor: [0:00] To get started using Cypress to automate testing your application for accessibility issues at runtime, you'll need to yarn add or npm install cypress and the cypress-axe plugin to your development dependencies.

[0:19] You'll also want to add a script command to your package.json file for opening the Cypress app. When you run the command to open Cypress for the first time, it will automatically open in a new browser window, and upon running, will install some directory scaffolding with some example files into your project.

[0:39] To set up the cypress-axe plugin, you'll need to open up the index.js file that was just created by the Cypress app, which you'll find located in the Cypress support directory in your project. All we'll need to do is import the cypress-axe plugin. Now Cypress will have access to additional commands related to checking for accessibility violations.

[0:58] Let's write a sample test. Note that Cypress tests are written using Mocha and Chai with additional commands provided by Cypress and any of its plugins. We'll start by adding a beforeEach, which will run before our test. In here, we will tell Cypress to navigate to the page we want to test. We'll be testing our login page for this example.

[1:17] Then we'll add the command to inject axe. This injects the axe-core runtime into the page, so it will be available to use in our test. Now, we need to add our test to make sure our page doesn't have any accessibility violations. We do that by calling the checka11y command provided by the Cypress axe plugin.

[1:37] Now that our test is written, we're ready to run it. We'll go back to the Cypress test runner, which is still open from when we ran the open command earlier. Here, we see that Cypress has already detected the test file that we just created. A quick note that I can select which browser I want to run my tests in here, and I'm going to go with Chrome.

[1:56] All we have left to do to run it is to just click on this link for our test file. Here, we can see where Cypress navigated to the URL we gave it, and it loaded our login page. Here are the results of our accessibility test. We can see that it detected four accessibility violations on the page. By clicking on an issue, it will highlight the elements on the page that have that violation.

[2:24] Additionally, if we open up the dev console, more details about the violation will be printed here. We've got the description of the issue. We've got the severity of the impact. We've got a URL where we can go find more information about the issue and how we can fix it. Expanding this Nodes array will list out each of the elements on the page that have this violation.

[2:48] This test only checked the initial render of our page for accessibility issues. We can also automate an interaction on our page in order to test for violations as the state of the UI changes. Here's a test that will click on the login button on the login page and should trigger the form validation to display errors on the required fields that are missing values.

[3:10] Let's see what the results of this test look like. We can see after this new test is run that the login button has been pressed, and the error messages for each field are showing. Here's that test.

[3:28] We still have four accessibility violations. We now have seven nodes that have the color contrast violation, whereas before, before the login button was pressed, we only had five nodes, which we can see when we hover over the violation. We can see that now our new error messages are also violating the color contrast rule.

[3:50] Once again, if we open up our console and look at the details printed there, we can expand this Nodes array and confirm that our error messages are now included in the list of elements that have this violation.