Accessibility testing with axe-cli

[00:00] if you're wanting to start testing for accessibility, I have a super helpful tool for you. On the command line, you can run MPM install Axe-CLI-G. Once it's installed, I can say Axe and then pass it in a URL.

[00:14] I'll type www.dq.com. I could also put a comma and then add any number of other URLs, but we'll just run dq.com. It's using the Axe core JavaScript library and phantom JS to head this browser to go hit dq.com, run Axe's accessibility rules, and then return a result.

[00:32] DQ.com has zero accessibility violations, but Axe CLI is very helpfully reminding us that that doesn't cover all of it. You still need to test for accessibility manually. You need to test with the keyboard, make sure you can operate everything. You need to check the quality of your alt text and transcript content and things that require a human to review.

[00:55] But if we go look at another website that has more accessibility problems such as the smartest commuter website that was built intentionally to test for accessibility, we can go and run Axe CLI against this site by putting AXE, and then I'll paste the URL. It will again use Axe core and phantom to go and hit this website, run its accessibility rules, and then return a result.

[01:17] Depending on the size of the web page, it might take a second to complete, but this is a great tool that you could put in your continuous integration environment or just in your development workflow.

[01:28] Axe CLI returned 51 accessibility issues. If we scroll up, the rules that failed on that web page were button text, so buttons being empty. It will give you the selector of where you can go and find it. It will also give you a URL to go and learn more about how to fix it or remediate it as we say in the accessibility world. There's issues with color contrast, and every one of these selectors has a different element that has an issue.

[01:57] If you've ever used the AXE Chrome browser extension or Firefox extension, as well, you can go and actually inspect these nodes in the browser. But this is the same API as the browser extensions but from the command line, which is super useful.

[02:13] Something else we could do is tell it to use a different browser. Say, we wanted to run it with Selenium WebDriver and a real browser instance which would be more like a real user's experience. We could tell Axe CLI to use Chrome, Firefox, Edge, or whatever browser drivers you have installed on your machine.

[02:30] Let's look at the mars commuter website again. I'll pass it -b and c for the Chrome browser. We can see it open up Chrome programmatically, run the accessibility audit against the web page, and then return the results on the command line.

[02:44] Now, there were a few differences with phantom versus Selenium WebDriver, that's why you definitely want to try and test it in a real browser. I would actually recommend using Selenium WebDriver first so that those few issues that might be caused by phantom you're not chasing down.

[03:02] If you want to learn more about the API for Axe CLI, you can go over to GitHub where you can see all the options, such as passing multiple URLs, running specific rules or specific tags since the rules have different tags. You could save the JSON results that Axe CLI is returning with the use of the Axe core API, scoping the test to look at specific element or exclude elements. Then, you can see the API for passing different browsers.

[03:31] If you want to learn more about Axe core, you can find that on MPM and GitHub, as well, or you can go and look at the entire extensible JavaScript API.

[03:37] That's how you can test for accessibility on the command line using Axe CLI, Selenium WebDriver, and phantom JS. But don't forget to do your manual testing, as well...