How to Catch a11y Defects During Unit and E2E Testing

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 bugs feels like to me. Basically doing a lot of patch fixes. As a developer, accessibility bug is a 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 a project. By the time I need to fix those bugs, the page is already built. It is very hard to make any structural 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. So Studio Ghibli is a Japanese animation company. This simple app would allow you to search any films and characters under this studio. So 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. Monorepo tool is NX, which is built by my company Narwhal. 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 testing/talks">unit testing, I'm going to use jazz and jazzX. For end-to-end testing, I'm going to use cypress and cypressX.

For testing/talks">unit testing, I use jazz and jazzX. You can install jazzX and type in, use the command here. Now with jazzX installed, I need to set up. I add a setup file named jazz.setup.js here. And inside the jazz config file, I need to add a key setupFileAfterEnvironment and point to jazz.setup.js here. Inside jazz.setup.js, this is what it looks like. It's very simple. You just have an import from jazz.so.x here, and it also extends jazz's expect function to include, to have no violations from jazzX. Now the setup is done. I want to unit test 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 test to check whether it renders successfully or not. Now I want to add unit test for the component to check whether it has any accessibility violation. Note, I've imported from jazz.so.x on the top here. Then I add a unit test to check for accessibility violations. It renders the component here. And then you pass the container to the x from jazz.so.x library. You expect the output here to have no violations. The unit test will be very simple. It has two lines here, and it's pretty easy to add. Now when I run a testing/talks">unit testing again, I would 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 for the app.

If all the components are accessible, the entire app are 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 standalone and do not even need to be shown up on the browser page.

This will help to avoid accessibility bug at the component level.

How about page level?

I'm going to talk about end-to-end testing.

It's going to use cypress and cypressX.

Enter the command 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 it redirects to the results page with the right query parameter.

So this is what the cypress test looks like.

You enter the text field and redirect to the results page.

To set up cypressX testing, I need to add typing first.

In the tsconfig file, under compile option types, I need to add cypressX here.

Also in the support file, I add the import from cypressX.

Now I'm done with the cypressX testing.

I'm ready to add cypressX test.

In the before-each statement, I need a line to inject X here, then I simply add a test.

I just have one line.

Check accessibility.

Now I run the cypress test again.

Notice it failed.

I have added a console log to output accessibility violations on the search page here.

This will help test app on the page level and prevent accessibility-related regression bug.

With all these tools, it will be easier for developers to avoid accessibility bug during development rather than going through them when the entire app is built. This is the end of my presentation. Thanks for listening. In the next few slides, I will be showing a sample application which uses the accessibility features. For example, let us see how we can implement the screen readers in this application. First, we need to set the content description to the text view. On Android, the content description is the text that is read by the screen reader. To set the content description, we need to add android:contentDescription attribute to the text view. Now, when we run the application and access the text view, the text that is read by the screen reader is the one that is set in the content description. We can also make the text view accessible. In order to do this, we need to make the text view focusable, so we add android:focusable attribute and set it to true. Next, we need to add android:focusableInTouchMode attribute and set it to true. This makes the text view focusable when the app is in touch mode. Finally, we need to set the click listener to the text view. Now, when we run the application and try to focus on the text view, we can see that the text view is focused. We can also see the bounding box around the text view. When the text view is focused, we can also see that the screen reader reads the text view. The screen reader read the text that is set in the content description of the text view. Next, let us see how we can implement a Talk Back feature in this application. In order to do this, first we need to add the android:importantForAccessibility attribute to the text view. We can set the android:importantForAccessibility attribute to auto. This means that the text view is important for accessibility. Now, when we run the application, we can see that the text view is focused, and we can also see the bounding box around the text view. The screen reader also reads the text that is set in the content description of the text view. We can also see that the screen reader reads the text that is set in the content description of the text view even outside the bounding box. When we press the button, the screen reader reads the text that is set in the button. The Talk Back feature does this by default. We can also make the Talk Back feature read the text that is set in the text view, even when the text view is not focused. In order to do this, we need to set the android:accessibilityLiveRegion attribute to the text view. We can set the android:accessibilityLiveRegion attribute to assertive. Now, when we run the application, we can see that the screen reader reads the text that is set in the text view, even when the text view is not focused. We can also see that the screen reader reads the text that is set in the text view, even when the text view is outside the bounding box. We can also see that the screen reader reads the text that is set in the text view, even when the button is focused. In the next few slides, I will be briefly talking about a few tools to test the accessibility of our app. These tools are useful for developers to avoid accessibility bug during development rather than going through them when the entire app is built. The first tool that I will be talking about is the accessibility Scanner. The accessibility scanner is a free app for Android that helps developers access their apps for common accessibility issues. The accessibility scanner is available for free on the Google Play Store. The next tool that I will be talking about is the accessibility Developer Tools. The accessibility Developer Tools is a part of the Chrome devtools, which is a set of web authoring and debugging tools built into Google Chrome. The accessibility Developer Tools allows us to inspect the accessibility properties of the elements in a webpage. The accessibility Developer Tools is available in the Chrome devtools. The accessibility Developer Tools is also available as a Chrome Extension. The next tool that I will be talking about is the accessibility Insights for Android. The accessibility Insights for Android is a free and open source tool for developers to debug and fix accessibility issues in Android apps. The accessibility Insights for Android is available for free on the Google Play Store. The accessibility Insights for Android is also available on GitHub. With all these tools, it will be easier for developers to avoid accessibility bug during development rather than going through them when the entire app is built. This is the end of my presentation. Thanks for listening.