illustration of two developers with cypress and axe logos

How to test for accessibility with Cypress

Cypress is a complete end-to-end testing tool. It reduces complexity by offering an all-inclusive testing platform, rather than requiring you to select and piece together individual libraries.

Creating, writing, running, and debugging becomes a simple, trivial process with Cypress. A few key features to call out are time travel (timestamped snapshots at each step), real-time reloading, automatic waiting, and screen & video captures. The best part is all of these features and more are available in the open source package.

In this article, we’re going to discuss how to:

  1. Create test cases in Cypress
  2. Integrate and use axe to check for accessibility violations
  3. Enhance accessibility tests

Creating Test Cases

In this post, I will be focussing on testing the login form for my app. I want to ensure that my login form is functional before creating a release build. Cypress tests can be used to verify the correct classes, IDs, elements, etc. We can also simulate user actions such as clicks, drags, drops, hovers, etc. We won’t need to get too sophisticated with this form, but just know that these tests are available if you need them.

Starting off, we need to create a file which will contain all of our test case logic. In the project directory, I created a file at this location –  ./cypress/integration/login.js .

Next, I constructed some simple conditions for a successful test suite. Nothing too fancy, but this will help cover the basics and ensure that my application remains functional every time I make a build.

After a short roast in the easy-bake-oven and diligent documentation browsing, we end up with a solid set of test cases.

Integrating and using axe

Great! Everything is working. Now, with a few simple additions, we can increase the amount of coverage that our test suite performs. We can also automate the accessibility testing process and capture a huge chunk of common and easy to address accessibility issues of the Web Content Accessibility Guidelines (WCAG) without even breaking a sweat. Let’s dive in!

I’ll assume you’ve heard of axe-core– it’s kind of a big deal as it’s the most widely used open source accessibility rules library. If not, head over here and check out what it’s all about: axe – Accessibility for Development Teams.

An awesome web citizen named Andy Van Slaars did all of the heavy lifting for an axe + Cypress integration. Now, all we have to do is install the plugin and fire off the commands to test for accessibility.

Cypress-axe – npm

First, we install the package using NPM or Yarn.
npm i cypress-axe or yarn add cypress-axe

Then, follow the documentation to integrate into your Cypress test cases.

In my example, I am using the before() hook load the URL for the login page. This is a good spot for me to inject the axe-core library. I can do that using the cy.injectAxe() command.

Now I can place the cy.checkA11y() command in various locations of my test script to validate or expose accessibility violations.

To really make use of the violation results, you’re going to need to toggle the developer tools in the Cypress test runner window. Once you have the dev tools console open, you can get a bit more detail about what the issues are, why they are issues, and how to resolve them.

Here is the completed test logic, with axe-core integration.

As a developer or QA engineer, this has greatly increased my ability to find and resolve accessibility issues within the end-to-end testing process. We now have a singular test suite which will inform us when our application is not doing what we expect it to do or has accessibility violations. Because we’re using the axe-core rules engine, the accessibility violations will contain an explanation of why they failed and offer notes on how we should remediate the issue.

Enhanced Accessibility Testing

Worldspace Attest is the next step to take for a more scalable, automated accessibility testing initiative. The Attest tool offers customized rulesets, advanced reporting, enterprise support, and more.

We may find the need to have easily-digestible reporting on hand after an automated run. The Attest Reporter will allow us to produce HTML reports that are easy-to-read and offer violation remediation notes.

At the time of this article, there isn’t an official Cypress integration. Not to worry, however, because I’ll demonstrate how this is super easy to accomplish!

Assuming you already have Attest installed in your project, you simply need to swap out cy.injectAxe() with the following snippet.

Because Cypress runs from the web browser, we will need to create a task which can work with the Attest tool in Node. Add this to the ./cypress/plugins/index.js file.

Great! Last step. We’re almost there.

Now we can test for accessibility and produce the reporting we need using the following code.

Here is what our login test suite looks like at the end of the day:

With a small amount of effort, we’re able to increase coverage within test suites and deliver advanced reporting of accessibility test results which can tell us what the violations are, why they are violations, and how to fix them. This could potentially save us from spending numerous hours and non-trivial effort to find and fix front-end and accessibility issues.

If accessibility test coverage is a priority, consider starting with axe-core. This will help cover the immediate needs and pave your way to a more sophisticated approach: Attest. The Attest tool does this by arming you with customized rules, advanced reporting, and technical support for those advanced integration cases that have you stumped.

update selasa

Leave a Reply

Your email address will not be published. Required fields are marked *