Google Selects Deque’s axe™ for Chrome DevTools

Google’s Lighthouse Now Includes axe-core!

aXe: the accessibility engine logoNotice anything different about Chrome DevTools lately?

The Audits panel is now powered by Lighthouse, and the Accessibility Audit is powered by *drumroll* Deque’s very own axe-core rules engine!

We learned that Google was planning to replace their own automated accessibility testing engine with axe at the 2017 CSUN Assistive Technology Conference in San Diego. Specifically, it would become the engine behind accessibility testing in their open-source Lighthouse testing tool which would then be rolled out in the new Audits panel in Chrome DevTools.

It’s very exciting to see axe recognized this way and integrated into a testing tool that is literally at the fingertips of every Chrome user. In addition to accessibility, the Audits panel provides data and tips to optimize site Performance, Best Practices, and Progressive Web Apps. These metrics are part of Google’s overall goal to encourage better web development practices. These are also data points that Google can use to determine how pages are ranked in search results. And, in some cases – like Performance, they definitely do impact your search ranking.

What Does This Mean for Accessibility?

Does this mean your site’s accessibility is going to impact its ranking in Google search? Given that there’s quite a bit of overlap between accessibility and SEO, it technically already does.

In any case, Google’s got a clear message: accessibility is as essential as site Performance and Best Practices.

Accessibility testing is so basic, it’s already part of your browser.

Google has also made accessibility testing about as approachable as possible, which is important when it’s still a new concept to most developers. The DevTools audit is only performing automated accessibility testing.

Because they’re using axe as their rules engine, their audits only return issues that can absolutely be determined with automation – no false positives. The result is clear reporting of the most common and most easily fixed accessibility issues.

The downside of the DevTools accessibility audit is that’s only half of the story. Your page may have scored a 94 in accessibility according to Lighthouse, but it’s only telling you the results of automated testing. You also have to perform manual accessibility testing to really know where you stand.

It’s great to see Google taking such a strong position on the importance of accessibility in their DevTools, and if you’re totally new to accessibility, it’s a great place to start. If your site has accessibility compliance requirements (or if you just want to take accessibility and inclusive design to the next level), we hope you’ll go straight to the source.

Ready To Try Testing for Accessibility with axe?

Download the axe extension for Chrome or axe for Firefox. The axe-core API is available on Github. If your organization has accessibility compliance requirements and needs tools that can test on a large scale, check out our WorldSpace suite. Finally, visit Deque University to learn more about accessibility and develop your expertise.

photo of Caitlin Cashin

About Caitlin Cashin

Caitlin is an "Accessibility Decoder" at Deque Systems. She joined the team back in 2011 and has taken on a variety of roles over the years. These days she spends her time exploring the best ways to communicate accessibility ideas and solutions to the general public.
View all posts by Caitlin Cashin
update selasa

Comments 4 responses

  1. Does the Chrome Dev Tools use same testing level as the Axe extension? I am trying to find out if what level it test to? WCAG 2.1 AA or A or AAA or Section 508?

  2. Hi, Bryan. The Chrome Dev Tools accessibility audit is the same ruleset as the extension, so the testing level is the same – the axe ruleset currently tests against WCAG 2 rules (including 2.0, 2.1, A, AA, and AAA) and Section 508. The axe extension (and the library itself) does indicate which rules/regulations are being violated with each issue, but this information was not included as part of the UI for the Chrome Dev Tools auditor. If this is a concern for you, you may want to try using the axe Chrome extension instead of the Dev Tools auditor.

    In the axe extension, there’s a bar at the bottom that lists what requirements/regulations the issue violates. You can see a complete list of axe supported rules and which requirements/regulations are tagged for each rule on GitHub: https://github.com/dequelabs/axe-core/blob/develop/doc/rule-descriptions.md

    That said, automated testing tools cannot test for all WCAG or 508 requirements. Axe was designed to test for everything that can be accurately detected with automation, but you’ll need to perform some manual testing to cover all your bases.

    I hope that helps!

  3. How do we know which version of axe-core is used in the axe Chrome extension?

    When running the Chrome extension I will see different issues than when I copy and paste axe-core.3.2.0.js into the Google Chrome console and then run:

    axe.run(function (err, results) {
    if (err) throw err;
    console.log(results);
    });

  4. Hi, Scott – When you open up the axe extension, the axe-core version is listed above the Analyze button on the left-hand section. After you’ve run axe, there’s an information logo at the top of the left side that you can click for the axe-core and extension versions. The extension (v 3.8.0) is currently on axe-core 3.2.2. If that info doesn’t solve anything, I’d submit an issue to the axe-core GitHub: https://github.com/dequelabs/axe-core/issues

Comments are closed.

Related Posts