Accessibility at Zoopla
Current Zoopla portal accessibility improvement initiatives
At Zoopla we have a small working group looking into a few initiatives to improve the portal accessibility. These initiatives include a safe & welcoming communication channel where everyone can ask accessibility-related questions. The team has also run a survey where the main topic was “What does Accessibility mean to you?” and the results are currently being evaluated into actionable items. And finally, there is a project underway that has introduced automated end-to-end (e2e) a11y tests into our pipelines for the Zoopla portal. That’s what the rest of this article is going to focus on.
Automated accessibility testing for Zoopla portal
Tools explored and used
For a few months there have been several separate discussions within the Zoopla portal teams regarding the accessibility issues and the relevant testing to identify and prevent them from being deployed to production. Different tools were used for manual and semi-automated a11y (shorthand for accessibility) testing by different teams, e.g. axe-DevTools (free version) & WAVE Evaluation Tool browser extensions and our internal Pa11y dashboard.
Having used and compared all the tools listed above, we have come to the conclusion that the Axe tool from Deque University is probably the most comprehensive one and detects the widest range of a11y violations. While the axe-DevTools browser extension is for manual / semi-automated a11y testing, there are also various plugins that provide a11y testing features for automated tests out of the box.
Given that we use Jest for unit tests & Cypress for our e2e tests, we went with jest-axe and cypress-axe plugins for our automated a11y tests. In the process of writing and executing our tests, we’ve discovered that jest-axe does not detect colour contrast issues as these tests run within a virtual DOM. But that issue is detected by cypress-axe without failure so far.
Adding a job for our automated e2e a11y tests into our CI/CD pipeline
Since Zoopla portal is a mature web application with legacy codebase, we had to devise a plan on how to gradually introduce the cypress-axe e2e testing into our pipelines without having too many failing jobs and delays for code shipping.
Initially, when writing our accessibility tests we used a workaround to detect the a11y violations on a page while allowing the test to pass and logging the issues into the console. This enabled us to write the a11y tests without fear of breaking the pipelines and gave us confidence to raise the relevant bug tickets and fix the defects at the pace we were comfortable with.
Gradual addition of accessibility violation impact levels into the pipelines
Once we had all of the cypress-axe critical a11y violations fixed, we added the following snippet of code to our function to trigger pipeline failure when critical violations get detected going forward.
// fail on critical
cy.checkA11y(context, {
includedImpacts: ["critical"],
});Going forward, we are planning to extend that by adding the serious impact level violations once they are fixed and the moderate and minor to follow shortly afterwards. This should complete one of the initiatives currently underway in Zoopla for addressing accessibility tech debt.
Useful resources
Image source
- Post image by Nick Karvounis on Unsplash