Cancel

Sarah Gooding

aXe: An Open Source JavaScript Library for Automating Accessibility Testing

axe-logo

In June 2015 Deque, an accessibility consultancy, open sourced aXe, its accessibility rules engine for automated web UI testing. aXe is a compact JavaScript library (~100 KB) that executes automated accessibility tests inside your testing framework or browser. Deque outlined a number of advantages that the aXe library has over previous approaches to automated testing of HTML-based user interfaces:

  • It works on all modern browsers
  • It supports in-memory fixtures, static fixtures, integration tests and iframes of infinite depth
  • It has zero false positives (bugs notwithstanding)
  • It is open source
  • It is actively supported by a major accessibility vendor
  • It is designed to work with whatever tools, frameworks, libraries and environments you have today
  • It is designed to be integrated into your existing functional/acceptance automated tests
  • It automatically determines which rules to run based on the evaluation context
  • It is highly configurable

aXe integrates with Karma, QUnit, Jasmine, Mocha, PhantomJS, and many others – basically any testing framework that supports JavaScript execution.

aXe Extension Adds Accessibility Testing to Chrome Developer Tools

If you’re not using automated testing tools in your projects, the Chrome developer tools extension is the easiest gateway to performing accessibility tests directly in the browser as you’re viewing or building a website or application.

aXe is available as a free extension from the Chrome web store. (Alternatively, it’s also available as an add-on for Firefox.) Once you click “Add to Chrome,” aXe will be available under its own tab in Chrome DevTools panel. It automatically ferrets out accessibility defects and offers details for each violation.

axe-on-wordpressorg

The creators of aXe were invited to contribute the open source library to the W3C WAI Evaluation and Repair Tools Working Group, as the group works to develop a normative set of rules for evaluating WCAG 2.0 conformance.

If you’re working on improving WordPress’ accessibility, the aXe extension can even help perform some of the tests recommended by the Accessibility team. You can log issues by creating a ticket on WordPress Trac or testing patches for existing tickets.

In 2014 the Accessibility team discussed adding automated accessibility testing to WordPress, with Quail.js as one of the frontrunners. The team is just now adding accessibility code standards to the WordPress core handbook. The next step would be firming up a list of requirements for an automated testing tool. aXe might be a new possibility to consider, as it is open source and focused on helping websites meet WCAG 2.0 requirements.

Deque’s mission with aXe is to bring equality to the digital world. They are working to make automated accessibility testing more mainstream with professional web developers. If accessibility is a priority for your work, aXe is a lightweight library you may want to consider for automated testing on own projects.

Category:
Tags:
10

10 responses to “aXe: An Open Source JavaScript Library for Automating Accessibility Testing”

  1. accessibility rules engine

    Rules?

    We’ve been here before: there can be no rules because different accessibility issues require addressing in different ways.

    Using this tool makes sense only if a site owner has already decided that the WCAG 2.0 Guidelines (note: NOT rules) make sense. For me, they don’t.

    The most common accessibility issue faced by users of my sites is dyslexia. Not only do the WCAG 2.0 Guidelines not mention dyslexia, its recommendations exacerbate the problem.

    Create forum topic from comment

    • This article is a bit unclear in that it seemingly refers to the WCAG 2.0 guidelines as rules. In the aXe tool, each criterion is referred to as a rule for the sake of writing tests, and only the guidelines that would present zero false positives when tested against, (excluding, for example, the alt attribute, since if it exists, any automated tool will flag it as good, while determining whether or not that is actually true depends on how the alt attribute is written). It needs to be kept in mind that, while you can automate accessibility checking to a point, any automated tool, including this one, is only going to get you about 30% of the way there. These tools aren’t designed to be the final say on accessibility as a whole, but to act as a sanity checker. This is because most accessibility errors end up being repetitive across a site or CMS. It’s also helpful to keep in mind that the WCAG 2.0 are guidelines designed to help you implement the HTML spec.

      Create forum topic from comment

    • You are correct that WCAG 2.0 does not address dislexia requirements. Can you explain how it’s exaserbating the problem? Also, as of 2012, WCAG 2.0 is an international standard. So if using WCAG 2.0 as your standard does not make sense, which other set of guidelines do you believe makes more sense?

      Create forum topic from comment

      • Amanda,

        Take a look, for example, at this: https://www.w3.org/WAI/RD/2012/text-customization/r11

        The first “rule” that popped up when I tested this plugin was to increase the contrast between the text and the background. As the above article suggests (and it’s one of very many that say the same thing) it’s about the worst possible thing you can do for someone with dyslexia.

        Ironically, while those without dyslexia typically claim to prefer higher contrast, that’s only when viewing a site for a short period. Lower contrast is much less tiring for those without dyslexia too if they are viewing a site for a couple of hours or more. Having tried this on my own sites (which are designed to be viewed for long periods) I have received a huge number of compliments for those without dyslexia who say that they can stay on my sites without problems, which they just can’t do on other sites.

        So, apart from specific cases where extra high contrast is necessary — in which case, we should be told precisely what those use cases are — I suspect that this “rule” advocating high contrast is exacerbating problems not just for dyslexics but for many others besides.

        In fact, as the above article also suggests, but doesn’t explore much, what’s important for dyslexics is not just that the contrast is relatively low but that appropriate colors (especially of the background) are used.

        My daughter teaches a lot of dyslexic students, and the first tool she uses (and, typically, also the most effective) is to lay a colored filter over whatever is being viewed or read. The difference is often — and immediately — remarkable. (I have passed on this tip to several colleagues with dyslexic children. They have been amazed by the difference it makes.)

        Backgrounds of beige, salmon, or certain shades of blue seem to work best, with a font that is a something like a mid shade of gray.

        Obviously, you can just Google for further resources, but a quick guide to the worst things for dyslexics can be found here: http://uxmovement.com/content/6-surprising-bad-practices-that-hurt-dyslexic-users/

        None of those things are covered by WCAG 2.0 or aXe (apart from a very vague reference to sans serif fonts). So I don’t care if WCAG 2.0 is an “international standard” (whatever that means). It’s simply not addressing a major accessibility issue.

        Create forum topic from comment

        • As I understand it I as a novice fail to see the issue between the standard and the problems you write about. Essentially the issue here is conflicting needs of different groups hence all standards will go against best practice for various groups. Issue then is not with the standard but the idea that there is a one fit all solution for tackling various issues. Why not then have a dyslexia button that just alternates between different typographic palettes?

          Create forum topic from comment

  2. This is extremly helpful tool. Although it doesn’t cover everything as @KTS915 said, but some advices provided is quite useful for me.

    I did a test with this tool and looks like it analyzes included iframes, which should be excluded. Hope it will get better in the future.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.