Configuring Axe Accessibility Tests

Rate this content
Bookmark

Axe-core is a popular accessibility testing engine that is used Google, Microsoft, and hundreds of other companies to ensure that their websites are accessible. Axe-core can even integrate into many popular testing frameworks, tools, and IDEs. In this advanced session, we'll be learning how to configure axe and its integrations to fine tune how it runs and checks your pages and code for accessibility violations.

This talk has been presented at TestJS Summit 2021, check out the latest edition of this JavaScript Conference.

FAQ

AXe core is an accessibility engine for automated web UI testing. It runs a set of rules on a webpage or code to identify accessibility problems.

To use AXe for testing accessibility, load the AXe core library script from a source like unpkg.com. Once loaded, use a script of type module to await the AXe.run results and log out the violations property to see each rule that reported a violation.

AXe integrates with various languages and frameworks. It has CLI integrations, and supports testing frameworks such as Playwright, Puppeteer, React, WebDriver.IO, and WebDriver.js. AXe also offers a VS Code integration called Axelinter for accessibility linting.

You can configure AXe to run specific rules by disabling certain rules, specifying a set of rules to only run, or running rules that match a particular tag. Configuration can be done through options objects in AXe core or through configuration files in integrations like AXe linter.

For AXe core, the list of supported rules can be found on the AXe core GitHub page inside the docs directory under rule-descriptions.md. For AXe Linter, the list is available on the VS Code AXe Linter page.

You can contact Steven Lambert via Twitter at StevenKLambert, by email at [email protected], or through his website at stevenklambert.com.

AXe offers integrations with Chrome and Firefox through browser extensions, allowing users to perform accessibility testing directly within these browsers.

Yes, by default, AXe can test accessibility within iframes as part of its integration features, unless specified otherwise in the run options.

Steven Lambert
Steven Lambert
30 min
19 Nov, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

AXe is an accessibility engine for automated web UI testing that runs a set of rules to test for accessibility problems. It can be configured to disable or enable specific rules and run based on tags. Axe provides various options, but axe linter does not support all options. The importance of investing time and resources in accessibility is emphasized, as it benefits not only those with disabilities but improves the web for everyone. Manual testing is also highlighted as a necessary complement to automated tests for addressing accessibility issues.

1. Introduction to AXe and Its Usage

Short description:

Hello, my name is Steven Lambert. I am a tech lead and people manager at Deque Systems. I'm also the primary developer on AXe core, the accessibility testing library. AXe is an accessibility engine for automated web UI testing. It runs a set of rules on a page or your code to test for accessibility problems. You can use AXe on a webpage by loading the AXe core library and awaiting the AXe.run results. The violations property will show you each rule that reports a violation. Axe has many integrations into various languages and frameworks, such as the CLI integration, Playwright, Puppeteer, React, WebDriver.IO, and WebDriver.js. We also have integrations into VS Code, Chrome and Firefox extensions, and other languages like Java and Ruby. To configure which rules Axe runs, you can specify the set of rules to be used.

Hello, my name is Steven Lambert. I go by he, him pronouns. I am a tech lead and people manager at Deque Systems. I'm also the primary developer on AXe core, the accessibility testing library.

In case everybody wants to get a hold of me later or in connect, you can find me on Twitter using the handle at StevenKLambert. You can email me using Steven at sklambert.com or you can visit my website, stevenklambert.com and contact me there.

So before we dive into how to configure AXe, I first wanted to give a quick overview of what AXe is and how to use it in case anyone was unfamiliar. So AXe is an accessibility engine for automated web UI testing. What that means is that AXe runs a set of rules on a page or your code to test for accessibility problems.

Here is an example of how you would use AXe on a webpage. You would first load a script whose source points to the AXe core library. In this case, it's from unpkg.com slash AXe dash core at latest slash AXe dot JS. That will load the main AXe core library onto your page. Once that's loaded, you can use a script of type module to await the AXe dot run results. Using those results, you can then log out the violations property, which will show you each rule that reporting a violation. Here is an example output of what that would look like.

So the violations property is an array where each index of the array is an object. Those objects will list the rule name that failed as well as things like the impact on the user and all nodes that failed the particular rule. So in this example, I'm showing that there is a landmark one main violation, a page has heading one and region rules are all failing.

So where can you use Axe? Well, Axe has many integrations into various languages and frameworks. The main library is axe-core and that can be used in the browser or node directly. We also provide a handful of integrations into the command line and popular testing frameworks. So on npm, you can look at the at axe-core namespace and there you can find the CLI integration, a Playwright, a Puppeteer, a React, a WebDriver.IO and the WebDriver.js integration. This year, we also released a new integration for VS Code, which is called Axelinter and it provides accessibility linting for your code that is consistent with Axe-Core's rule engine.

So what that means is that as you type, you will get linting suggestions for anything that we can detect. Lastly, we have other integrations such as the Chrome and Firefox extensions. We also have integrations into Java and various Ruby libraries, but we won't be covering any of those for this presentation. We'll just be talking about JavaScript and Node compliant integrations.

So now that we know what Axe is and how to use it, I wanna talk about how to configure which rules Axe runs. So as I mentioned, Axe runs a set of rules that determine the accessibility problems on a page.

2. Configuring Rule Execution in AXe

Short description:

By default, Axe will run all supported rules. You can configure which rules to disable, specify a certain set of rules to run, or run rules that match a particular tag. I will show examples of how to do this in Axe core, Puppeteer, and Axe linter. To disable rules in Axe core, pass an options object to ax.run with the rules property set to an object where each key is the name of the rule to disable. In Puppeteer, use the disabledRules function of the ax builder object to pass an array of rule names to disable. For Ax linter, configuration is done through a config file.

By default, Axe will run all supported rules. Now, which rules are supported depends on which integration you are using. So for Axe core and its various node integrations, you can find the supported rules by going to the Axe core GitHub page. In there, we have a docs directory and the rule-descriptions.md file, which will list all supported rules. For Axe Linter, you can find the list of supported rules by going to the VS Code Axe Linter page. For Axe core, there's about 91 supported rules that you can look at. And for Axe Linter, as I mentioned, as only a subset of rules has about 33 supported rules.

So there are various ways that you can configure which rules Axe will run. For starters, you can disable a certain set of rules so that they won't run during a normal run. You could also specify a certain set of rules to only run, and you can also run rules that match a particular tag. Now, for this presentation, what I'm gonna do is I'm going to show an example of how to do this in only three integrations. I'll show you how to do it in Axe core, I'll show you how to do it in an example of a node integration like Puppeteer, and I will also show you how to do it in Axe linter.

So first, I wanna talk about disabling rules. So let's say as an example that you wanted to disable two particular rules, the button name and label rules. Now, the button name rule ensures that every HTML button element has an accessible name, and that can be used either through having text content in the button or that the button has an ARIA label, ARIA labeled by, or title attribute. The label rule does something similar where that it ensures every input element has an accessible name, either through an associated label element or using the ARIA label, ARIA labeled by, or title attribute. So for using this in ax-core, what you would do is you would pass an options object to ax.run. The object takes a rules property, which is whose value is also an object. Each key of that object is the name of the rule that you want to disable. And then the value of that is an object who takes an enabled property and can pass either true or false. Now true is the default behavior and that means that the rule will run, passing false will disable the rule so the rule won't run. So in this example, we pass the button name and label rules and we enabled false both of them. For a CLI and a test framework. So what you would do is you would initialize a new ax builder object that allows you to chain a couple functions off of it. One of those functions you can chain is called disabled rules. And the disabled rules function allows you to pass a rule name or an array of rule names that you wish to disable. So in this case, we can pass an array of button name and label to disable both of those rules. And then lastly, you would chain the analyze function and that would then run ax on that page. For ax linter, we don't have a an API you can use. So instead what you do is you configure it through a config file.