Moonpig Tech Blog
Published in

Moonpig Tech Blog

How We Automate Accessibility Testing at Moonpig

By Robert Smith


Lighthouse is an open source tool that can be used to run audits against any webpage. It is built into the Chrome dev tools and can be found under the “Audits” tab. Lighthouse provides the ability to audit against a number of measures such as performance, accessibility, and SEO. Here we’re going to focus on the accessibility tool.

Moonpig homepage Lighthouse audit

ESLint JSX A11Y Plugin

ESLint is a static analysis tool that reads our source code and can alert us to errors that we see. We can also configure our IDE environments (most of us here use VSCode) with an ESLint plugin to give us instant feedback as we code. ESLint can be extended with a number of plugins and one of them is called ESLintJSX a11y plugin to parse our React code and alert us to any accessibility issues it finds. This instant feedback helps us to move faster and fix accessibility issues early.

Accessibility plugin highlighting the fact our labels are not correctly associated with their input fields.

Jest Axe

Jest is the unit testing framework that we use for JavaScript projects at Moonpig, it has been built in a way that allows third parties to extend its matchers that are used to make assertions on test cases. Axe is a website accessibility testing engine that can parse HTML markup and alert us to any violations.

Jest Axe reporting a failure due to an image not having an alt attribute set.

React Testing Library

React Testing Library is a tool that allows us to render and interact with our React components and test against the rendered DOM. It has a number of “getter” functions that implicitly assert that we are following correct accessibility standards.

Testing Keyboard Navigation

While the above techniques take us closer to automating our accessibility testing with very little effort, they only go so far due to limitations of static analysis.

  • Longer feedback loop. Not only are these tests slower to run, you also lose the power of watch mode as Jest watch mode will look at your dependency graph and run all the appropriate tests based on what’s changed since your last commit. Cypress for example (A browser-based testing runner) will only watch against your spec files and runs against compiled output.
  • Because the browser based test runners run against compiled output you lose the ability to run test coverage against the source.


To conclude I think we get a huge benefit from automating large parts of our accessibility testing at Moonpig, it saves us time and reduces the likelihood of in-accessible features being released or refactors causing accessibility regressions. However this doesn’t mean that we take our foot off the ball when it comes to manually testing accessibility. We still use screen reader technologies such as voice over but we can do much more.
I’d like us to bring in a disabled user who could help provide us insight into how we could further improve the user experience for our disabled users.


Robert Smith is a Senior Software Engineer focusing on Frontend Engineering at Moonpig.



Learn about how we use technology, lean and agile practices to succeed in the online personalisation market whilst moving at supersonic speed.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store