Accessibility testing is a form of automated and manual testing that helps us identify some of the potential accessibility concerns on Forem. See also, the Forem Frontend Accessibility docs.
Many accessibility (a11y) issues are not obvious to everyone who contributes to the Forem project, therefore leaning on tools to help us identify these issues is a good practice.
It's a good idea to use browser plugins while you're developing to keep an eye out for these issues, as well as including automated tests to catch regressions in future changes.
The axe devtools extension is a great place to get started. It works in both Firefox and Chrome. Use an extension like this one to find potential a11y issues in your workflow.
An overarching a11y testing strategy isn't currently in place for the Forem application, but there are some automated tools you can take advantage of in this project.
It is important to note that automated accessibility testing is only effective at finding ~30% of accessibility issues. It's important to do manual a11y testing as well.
When you're writing Preact components, you can include some basic a11y testing in your unit tests with jest-axe.
If you're still curious there are some great talks on accessibility for developers.
Pull Requests should include accessibility testing to prevent barriers from making it into the codebase. Sometimes issues found may be out of scope for a particular PR – those can be opened as separate issues to be followed up on.
Test the functionality in Forem-supported browsers for accessibility impact: Chrome and Firefox were popular for Windows screen reader users in 2019 according to WebAIM. Safari is the most common choice for Voiceover users on the Mac, even if Chrome is widely used for development. Mobile browsers are worth checking, too.