One of the reasons why I like aXe is because they kind of have this whole mantra, mission statement thing of making sure that their accessibility tests have zero false positives, meaning they only test stuff that they’re really, really confident that they can say is either passing or failing. And the reason why I like that is because if you’ve got a really, really big team and you don’t have everyone, maybe, bought into accessibility testing, and you’ve got a tool that’s maybe throwing like flaky errors or something like that, it might be easy for the team to just disable that thing or just start ignoring it. So I love aXe because I like the idea of zero false positives and making sure that if something is failing, everyone on your team can kind of agree, like, hey yeah, that’s an actual issue.

So to get started with aXe, follow me over here to my laptop. Over here, I’m just sort of showing the GitHub page for aXe.

It’s made by Deque. So this is Deque Labs organization. This is axe-core, which is kind of like the library that powers everything. And you can scroll down to the Read Me and see, they kind of talk about their philosophy, their manifesto, and things like that. There’s a few different ways to use aXe.

So for instance, as it shows here, you can just drop it as a script tag onto a page and it will start logging errors that way. That’s one way to go about it. But what we’re going to do today is I’m going to show you how to use it as a Chrome extension, how to use it with Selenium, and how to use it using the newly released axe-cli. So let’s get started with the Chrome extension. I’m going to go over to the Chrome Web Store and just look for aXe, like a chopping axe.

And you’ll know it if you see this blue triangle thing here.

So I’m going to go ahead and add that to Chrome. Yep. So the extension is really useful if you just want to maybe quickly look at a page or a few pages of your site. You don’t have a whole automated testing workflow setup or anything like that.

You just want to look at a page and be like, what’s broken here? So I’m going go over to my blog. So this is robdodson.me. Now, I know that there are some issues on this site.

I found them during the making of this episode. And I’m going to leave them in so you can see the process in action. So what I’m going to do here is I’m going to open up my dev tools. And now that I have that Chrome extension installed, I’ve got this little aXe tab here.

So I can click on that, and there’s big Analyze button.

I run that and it will now show me over here on the left some of the issues that I have. For instance, I have elements that need to have better color contrast. An HTML element needs to have a lang attribute to indicate the language the page uses. And I have some links that need to have better discernible text. So right now, I have links that probably just say “more.

” Whereas it could be a more fleshed out phrase. It could be “click here to read about custom elements” or something like that. So let’s check out this color contrast thing.

So I’ve got 16 violations that it’s showing me here. It tells me which of the standards that we’re failing here.

So WCAG 2.0 AA. And also show me the selector path to get at the elements that are failing. So here I can see it’s basically these anchor tags that are inside of my post metadata headers. And what’s really cool is I can click this More Info button and it’ll take me to a page called Deque University, which is sort of a resource that the folks at Deque run, along with aXe.

And that’ll just explain in more detail what exactly is failing here, how to fix it, and also the severity of the error.

So for instance, you can see here, this is kind of like a critical failing when we have bad color contrast. But it’s useful so that when we’ve got a ton of errors and you’re trying to prioritize which to work on first, you can say, OK, let’s deal with the critical ones first and then we can deal with the minor ones a little bit later. So I love that they provide this resource. All right.

So that’s one way to go about things. You can use the extensions to quickly look at a page. Another way to go about things is to use a tool like Selenium to do automated testing of your application. Selenium, if you haven’t heard of it before, it’s basically a tool that can drive your browser in an automated fashion. It can click on things on the page, open URLs, send keyboard events.

So to do that using aXe, there’s another variation that we can use called axe-webdriver.

This is also available on the GitHubs. If you scroll down to the Read Me, it’ll have getting started steps. So a few resources that we need to install. And then there’s this really helpful snippet right here that we can actually just copy and paste.

And we’ll walk through what’s happening in the snippet in just a sec. But let’s start by installing these dependencies. We need axe-core, that library I was showing before. And we’re going to need axe-webdriverjs.

So I’ll go over to my terminal, and I’ve actually already got my little command ready to go here.

So I’m going to mpm install, save. And I’m saving to my dev dependencies because this is probably not something I want to ship in production. This is probably something I just want during development time. So I’m installing axe-core. I’m also installing Selenium WebDriver.

At the time of this recording, this is also a dependency of the axe-webdriver project, so we want to make sure and install Selenium WebDriver. And then finally, axe-webdriverjs. So we’ll install all of those, save them into our package JSON file– so we’re good to go there. And then I’m going to just create an index.js file, open that up in Visual Studio Code, and I’m going to paste in that little snippet that we copied off of their page.

So let’s talk about what’s happening in this snippet. So the first thing we’re doing is we’re grabbing axe-builder, or axe-webdriverjs. This is basically going to be a tool that will tell Selenium how to do automated testing of the page.

We’re grabbing WebDriver. So that’s Selenium WebDriver.

This is basically the tool that’s going to automate opening up a browser and sending commands to it. Well, we start things off by creating a new instance of WebDriver and we tell it which browser we want it to use. So it could use Firefox, Chrome, Safari, what have you. In this case, I want to change it from Firefox over to Chrome, just because I did this demo earlier with Chrome and I’ve got that all set up. And then once that’s ready, we’re going to take our Selenium instance.

We will tell it which URL to open. So here I’m going to tell it to open my blog. So I’ll change that to robdodson.me. And again, if you were doing automated testing or something like that, you could spin up a local server and point to at local host, like, 8080 or something like that.

That works. This returns a promise for when it’s finally ready to go. And then we say, all right, take axe-builder, make sure it has been passed the instance of Selenium WebDriver, and then tell it to analyze the current page.

And when it does that, it’s going to return a JavaScript object full of results. So things that fail, things that passed.

And what I want to do here is just log those results. I’m actually going to filter this down to just log violations. So I don’t want to see things that passed just yet. I just care about the violations, right? And we’re going to see if this matches what the Chrome extension was outputting earlier.

Now, there’s one more thing that we need to do before this is ready to run.

As found on YouTube