For developers, it is better to catch any a11y defects during unit and e2e testings. This talk is going to show how to automate a11y testing using jest and cypress.
This talk has been presented at TestJS Summit 2021, check out the latest edition of this JavaScript Conference.
The speaker is Emily, a developer based in Toronto. She currently works for a company named Narwhal.
Fixing accessibility bugs is challenging because they are often identified at the end of the project, making it difficult to make structural changes and move components around. This process feels like doing a lot of patch fixes.
The main focus of the speaker's talk is to show ways for developers to automate accessibility testing during both unit and end-to-end testing phases while they are developing.
The sample website created by the speaker is a search engine for Studio Ghibli. It allows users to search for films and characters related to Studio Ghibli.
The frontend of the sample website is built using React. The Monorepo tool used is NX, and for unit testing, Jazz and JazzX are used. For end-to-end testing, Cypress and CypressX are used.
The speaker integrates accessibility testing in unit tests by using Jazz and JazzX. They set up Jazz with a configuration file and extend Jazz's expect function to include accessibility checks. The unit test checks for accessibility violations in the component.
To set up CypressX for end-to-end testing, the speaker adds typings in the tx.config file, imports CypressX in the support file, and injects accessibility checks in the before each statement of the Cypress test.
Adding accessibility tests during development helps developers avoid accessibility bugs at both the component and page levels, making the entire app more accessible and preventing accessibility-related regression bugs.
The Cypress test for the search page involves entering text in the search field, submitting the search form, and ensuring that the user is redirected to the results page with the correct query parameter.
The test failures are significant because they indicate that the accessibility tests are working correctly and are successfully identifying accessibility errors, allowing developers to address them early in the development process.
I'm going to show you some ways to catch accessibility defects during testing. Accessibility bugs are challenging to fix, especially when testing is done at the end of a project. I'll demonstrate how to add accessibility testing to a website for Studio Ghibli. The tech stack includes React, NX, Jazz, JazzX, Cypress, and CypressX.
Hello everyone, I'm going to show you some ways to catch accessibility defects during unit and end-to-end testing.
First, a bit about myself, I'm Emily, I'm a developer in Toronto, and I currently work for a company named Narwhal.
So this is how fixing accessibility bug feels like to me, basically doing a lot of patch fixes. As a developer, accessibility is the type of bug I do not wish to be assigned to. In my past projects, accessibility testing is usually done at the very end of the project, by the time I need to fix those bugs, the page is already built. It is very hard to make any structure change and move components around.
This talk will show you some ways for developers to automate some accessibility testing while we are doing the development. I'm going to show you how I add accessibility testing to this simple website I've created. It is a search engine for Studio Ghibli. Studio Ghibli is a Japanese animation company. This simple app would allow you to search any films and characters under this studio. This is what this website looks like. You can search anything, for example princess. If I enter princess here and search, it will show me any princess-related films. If I search for example Kiki here, it will show me films and characters related to Kiki. I can click the film here and it shows me the film detail.
Quickly go through the tech stack. Frontend is React. MonorepoTool is NX which is built by my company Noworld. NX is a powerful tool that will set up unit and end-to-end testing for your outdoor box. So I highly recommend you to check it out. For unit testing, I'm going to use jazz and JazzX. For end-to-end testing, I'm going to use Cypress and CypressX. For unit testing, I use Jazz and JazzX. You can install JazzX and it's typing. Use the command here. Now with JazzX installed, I need to set up. I add a setup file named Jazz.setup.js here. Inside the JazzConfig file, I need to add the key SetupFileAfterEnvironment and point to the Jazz.setup.js here. Inside Jazz.setup.js, this is what it looks like.
The setup is done. Now I want to unitize the search form component to check for accessibility violations. Developers can add similar tests to each component of the app to ensure accessibility. Let's move on to end-to-end testing with Cypress and CypressX. Here's a Cypress test for the search page.
It's very simple. You just have an import from Jazz.so.x here. And it also extends Jazz's expect function to have no violation from Jazz.x. Now the setup is done.
I want to unitize the search form component on the top here. It's a really simple search form. It has a text field and a search submit button. Currently, you have a default text to check whether it renders successfully or not.
Now I want to unitize for the component to check whether it has any accessibility violation. Note I've imported from jazz.x on the top here. Then I added unitize to check for accessibility violations. It renders the component here and then it passes the container to this x from jazz.x library. You would expect the output here to have no violations. The unit test would be very simple. It has two lines here. It's pretty easy to add. Now when I run the unit testing again, I will notice that the test failed which is actually great. It means the tests are actually working. It will show the accessibility errors in the console here.
Developer could add similar tests to each component of the app. If all the components are accessible, the entire app is more likely to be accessible. It is good that we allow developers to add accessible unit tests while just building the components. The components could be stand-alone and do not even need to show up on the browser page. This would help to avoid accessibility bug at the component level.
How about page level? I am going to talk about end-to-end testing. It is going to use Cypress and CypressX. Here are the commands to install CypressX.
I have a Cypress test for the search page, which is basically entering text in the search field. Submit the search form and make sure you redirect to the results page with the right query parameter. This is what the Cypress test looks like.
Comments