Customizing Axe DevTools for Web Accessibility Rules

This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard

Modifying your rule configuration within Axe DevTools for Web

Not for use with personal data

Within the Axe DevTools APIs, the option exists to change your standard ruleset as well as your axe-core version. As Axe DevTools is updated, the ruleset and the axe-core version will change. For users of only one tool the specific ruleset configuration and axe-core version may not matter. For users of multiple Axe DevTools components, making sure they all use the same rule configuration and axe-core version keeps scan results 100% consistent across tools.

Ruleset Configuration

Axe DevTools has the ability to use a wide variety of rule configurations. For more information on the various rulesets, read the page on axe-core rulesets. You can change to one of several other WCAG rulesets, ADA section 508, Trusted Tester v5, EN 301 549, or RGAA. Additionally, modifications to these rulesets like best practices not covered under WCAG or section 508, or brand-new experimental rules can be added to any ruleset configuration. For a description of each ruleset, see Rulesets.

The Default Ruleset

Unless you configure something else, the Axe DevTools for Web APIs and the CLI test against WCAG 2.1 Level AA, identified by the ruleset ID wcag2.1. Because the WCAG rulesets are cumulative, this covers the level A and level AA rules from both WCAG 2.0 and WCAG 2.1.

important

Under the default ruleset, rules tagged best-practice and rules tagged experimental are turned off. A default scan reports only failures that map to the WCAG 2.1 Level A and AA success criteria, so it does not surface Deque's best-practice findings unless you ask for them.

Best-practice rules are not part of any accessibility standard, but they help make a site as equitable in use as possible. How you turn them on depends on the language, and not every integration exposes a dedicated switch:

Language Enabling best practices
Java Pass true as the second argument to forRuleset(rulesetId, enableBestPractices). See the Java Selenium API reference.
C# Pass true as the second argument to WithRuleset(rulesetId, enableBestPractices). See the C# API reference.
Python Pass enable_best_practices=True to with_ruleset(). See the Python API reference.
Node.js and JavaScript Playwright, Puppeteer, and WebdriverIO accept an enableBestPractices option. Other integrations select rules by tag instead. See the Node.js and JavaScript overview.
Ruby There is no best-practices flag. Add the best-practice tag through the tag clause described for RSpec and Cucumber.
CLI Generate a ruleset file that includes the best-practice rules and apply it with --custom. See Custom Rulesets.

To test against a different standard instead, pass its ruleset ID in the same place. Using the RGAA Ruleset walks through that for one standard and lists the selection method for every language.

axe-core Version

The accessibility testing engine behind Axe DevTools, axe-core, is continuously being updated and improved. Because of this, different versions of axe-core may not always produce the same scan results. Ensuring your axe-core version is consistent between components, developers, and development teams eliminates the risks associated with different scans producing different results. In Axe DevTools, your axe-core version will be synced with your Axe DevTools version. The option is available to import specific axe-core versions.