Many automated testing tools monitor the whole site. While these also catch errors in the code, I recommend having separate monitoring in place for only the code changes. This approach usually speeds things up because not everyone in the team always has access to the automated testing tool. There are many tools available for accessibility testing, like axe-core, Lighthouse and Pa11y. These can be used with GitHub Actions, Jenkins or GitLab CI/CD, if you want to automate things in the pipeline.
Linting helps you check for accessibility issues before you push your code to version control. It doesn’t matter if you are an accessibility expert or not, sometimes we make mistakes and the automated tools are here to help when those situations happen. In a team setting linting will save time for everyone involved. If no linters are in use, everyone has to spend more time commenting on issues easily caught by the tools. So definitely use some linting tools that check for accessibility. And if you don’t already have linters in place for code quality, now is a good time to add those as well!
Deque has released axe Accessibility Linter for VSCode that will check your code for common accessibility issues. It works with React (JSX), React Native, Angular, Vue, HTML and Markdown. The tool is free, so there isn’t a reason why you shouldn’t start using it right now.
If you use ESLint with your JavaScript code, there is eslint-plugin-jsx-a11y that will check for JSX accessibility. Axe-core also has a package for React. Make sure to check Deque’s documentation to see where you can use axe-core. They aim to make the world a more accessible place. Of course, since they are a company after all, some of their toolings do have a price tag on them. If you don’t have the money to spend on tooling, don’t worry. There are a lot of great options that are free to use.
Integrate automated accessibility testing into continuous integration and continuous deployment (CI/CD) pipeline. By having this type of testing process in place, you can prevent new accessibility issues from being introduced by code changes. This way it doesn’t matter as much if a team member won’t use the local tools available. I added a couple of sources that can help you set up testing processes. If you have any good instructions or suggestions, please let me know e.g. by sending me a message on LinkedIn!