I've been pushing accessibility testing across all levels (dev, QA, content, etc) for the last few years at the company I work at.
At a development level, the built in browser tools are handy for very quick checking, although Chrome's Lighthouse is very basic, it just looks a bit prettier than Fx. Then, there are various plugins available, of which aXe is the best I've found. The pro version has some useful collaboration features which is helpful in a team situation.
The QA team has been integrating aXe and Lighthouse into their automated test suites. They manually test across a variety of browsers and operating systems using different screen readers as well. If you're a bit stuck there with access to devices, I did notice that BrowserStack seems to be implementing screen reader support now too which is a welcome surprise.
Then, we try to get all levels thinking about the issues. So the design/UX process is thinking about things like content, colours, the user journey and ease of access. Developers need to be thinking more about semantic HTML, testing states, and ocassionally putting the mouse/trackpad aside and relying on a keyboard. I've given a few short talks/presentations on various aspects of a11y, and we take things into consideration with code pull requests (at least as far as we can from a pure code POV).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've been pushing accessibility testing across all levels (dev, QA, content, etc) for the last few years at the company I work at.
At a development level, the built in browser tools are handy for very quick checking, although Chrome's Lighthouse is very basic, it just looks a bit prettier than Fx. Then, there are various plugins available, of which aXe is the best I've found. The pro version has some useful collaboration features which is helpful in a team situation.
The QA team has been integrating aXe and Lighthouse into their automated test suites. They manually test across a variety of browsers and operating systems using different screen readers as well. If you're a bit stuck there with access to devices, I did notice that BrowserStack seems to be implementing screen reader support now too which is a welcome surprise.
Then, we try to get all levels thinking about the issues. So the design/UX process is thinking about things like content, colours, the user journey and ease of access. Developers need to be thinking more about semantic HTML, testing states, and ocassionally putting the mouse/trackpad aside and relying on a keyboard. I've given a few short talks/presentations on various aspects of a11y, and we take things into consideration with code pull requests (at least as far as we can from a pure code POV).