DEV Community

Discussion on: Why can't we solve accessibility with a one line script tag?

mfurmaniuk profile image

Interesting stuff, I'd be curious on your experience with accessibility tools as well. We have a Team that does check internally, I implemented something simple use aXe from Deque with Selenium but I know that tool the way we use it barely scratches the surface.

ashleyjsheridan profile image
Ashley Sheridan

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).