QUnit

Unit Testing Accessibility

In Web Accessibility Hacker Way I mentioned that “only 20% of accessibility requirements can be verified by tools”. Nevertheless, it is worth to cover this 20%. Especially, when it is not very hard. You know that having automated test that guard against regressions always pays off in a long run.

As of today the best automatic verification tool for accessibility is aXe.

aXe

There is aXe Chrome plugin and aXe Firefox plugin that enables you to run accessibility audit manually:

aXe - results

Running automated tool manually is useful, but it is better to run it automatically as unit test, and incorporate it into your Continuous Integration to run it automatically after every commit.

Running accessibility audit with aXe

You can install aXe with npm:

npm i axe-core

The aXe has a function a11yCheck that performs accessibility audit on specified HTML Element. You may run it against widgets or partial views on your web app. That function takes 2 parameters:

  1. HTMLElement to be audited
  2. callback function that is invoked with results parameter
axe.a11yCheck($("#myElement")[0], function (results) {
    expect(results.violations.length).toBe(0);
    results.violations.length && console.error(results.violations);
});

It is useful to print errors to console, as the results.violations is an array of nested objects with different properties. Many of them are helpful to diagnose the issue.

aXe - console errors

*a11y is abbreviation for accessibility (similar like i18n for internationalization), 11 is number of letters between ‘a’ and ‘y’

Running aXe with Jasmine 2.x

In order to run aXe with Jasmine, you need to take into account that a11yCheck is asynchronous. Thus, you need to pass and invoke done function:

describe("a11y check", function() {
  it("has no accessbility violations (check console for errors)", function(done) {
    axe.a11yCheck($("#myElement")[0], function (results) {
        expect(results.violations.length).toBe(0);
        if (results.violations.length>0) {
            console.error(results.violations);
        }
        done();
    });
  });
});

Running aXe with QUnit 2.x

It is similar in QUnit. You also need to invoke done function, but first you need to get it by calling assert.async():

QUnit.test("a11y check", function(assert) {
    var done = assert.async();

    axe.a11yCheck($("#myElement")[0], function (results) {
        assert.strictEqual(results.violations.length, 0, "There should be no A11y violations (check console for errors)");
        if (results.violations.length>0) {
            console.error(results.violations);
        }
        done();
    });
});

Sample

I created a sample with button and input tag:

<div id="fixture">
  <button>My button</button> 
  <input type="text" />
</div>

This sample is not accessible because input tag does not have a label, and a11yCheck should report violations. The sample code, with Jasmine and QUnit tests, is available on github: axe-unittests.

Summary

While automated accessibility unit tests are great, you probably still want to use aXe plugin for Chrome to investigate reported violations. It’s more convenient, and it has neat user interface, while in unit tests you need to dig in into console errors.

When you start adding accessibility checks for different parts of your system, you may encounter many violations at first. It is better to still add tests, that ignore known violations, and then incrementally fix the issues. This approach prevents regressions, while delaying adding test until all violations are fixed may cause introducing new ones while fixing others.


Hi, I’m Jakub and I work for Microsoft

Blue badge

After I got my degree in August I moved to Redmond, WA to start my new job at Microsoft. I work for Azure App Platform Team. My official position is Software Development Engineer (SDE).

It has been a month since I started. So far, my team, work environment, the product and development process are great.

My team

MS team

My team (which is part of Azure App Platform) is working on the new Azure Portal. People in my team are smart. All of them. Moreover, they are really passionate about things they are doing, and they really care. I am working with Steve Sanderson, the creator of Knockout.js and one of the best technical speakers. The team is very diverse: people from many different countries all around the World, with a quite few girls among them.

My team is working in Agile.  The working culture is generally: “Get the job done”. People are in the office usually between 10am and 5pm. Some are coming later, and stay longer, others come early and leave early (there are also people who come early and leave late). If somebody feel the need to focus and don’t being interrupted then he/she is working from home, and it is not a problem.

What is the best, I am not implementing some spec written by somebody 5 levels above me. I need to implement an idea, add my contribution, suggest changes etc. When I asked a question what are the expectations from me, my lead and my manager told me that they expect me to suggest some ideas how to make the product better, how we can improve it, and what we are doing wrong. This is exactly what I was looking forward to!

Work environment

MS workspace

The building I am working in (Microsoft Building 44) is designed for Agile interactions. There are white boards everywhere. We work in Open Spaces (around 15 people per room). Microsoft is changing approach, and moving from private offices/cubicles to open spaces. What is cool, there are 3 conference rooms ‘attached’ to our Open Space (2 small, 1 big), and if somebody needs to work in peace, he/she can use one of them. If all are occupied (which does not happen very often), there are special ‘focus rooms’ (with desk and chair) in the building.

I have great machines to work on: HP Workstation Z420 (Xeon E5-1650 v2 3.5 GHz, 32 GB RAM, 128 GB SSD + 256 GB SSD + 1 TB SATA) with two 24″ monitors DELL Ultrasharp U2415, and Microsoft Sculpt keyboard and mouse. I have also ultrabook Lenovo ThinkPad X1 Carbon (i7-3667U @ 2 GHz, 8 GB RAM, 240 GB SSD). I have adjustable height desk, and very comfortable Haworth Zody Task chair.

The product

MS Azure Portal

The new Azure portal is a Single Page Metro Web Application. One of the main goals of the new portal is to make it easy for adding extensions. My team is working on the Framework, which is being used by other teams to create front-end for underlying Azure infrastructure. What is cool,  every extension is working as a standalone application in a separate iframe. Extension authors do not need to work with HTML and CSS a lot. They just use controls (e.g. list, combo box or checkbox) created by us, and communicate with them through TypeScript/JavaScript. Update of the view is performed by Knockout.js. Check Justin Beckwith’s post about the new Azure portal architecture. If you have not seen it yet, check the Overview of the new Azure Portal with Vishal Joshi and Scott Hanselman and Vishal and Scott create a new startup with the new Azure Portal. To get started with Azure, check my previous post, and get a free trial. Moreover, we need (and we appreciate) your feedback!

Technologies


MS technologies

We use HTML5 and LESS for our View layer. LESS is very handy in maintaining big style sheets.

We use TypeScript (which compiles to JavaScript). Strong typing, and abstraction over JavaScript inheritance (TypeScript classes) is very, very helpful in building large-scale application. To be honest, I do not know how we would be able to maintain the new Azure Portal using raw JavaScript.

Our main JavaScript Framework is Knockout.js. This allows us to prepare generic, reusable controls that can be used by other teams without the need of interaction with the DOM.

Our unit test framework is QUnit. For integration tests we use Selenium.

We use git for source control management. As Continuous Integration Server, we use Jenkins.

We have code review process supported by CodeFlow. It is required to have at least 2 reviews before code can be checked-in/pushed to the repository.

Building process is supported by MSBuild.

Behind the scenes, we use bunch of other JS libs, e.g. q.js, inject.js, d3.js, hammer.js or ZeroClipboard.js.

Summary

After 1 month I love it! There are many challenges, and interesting problems to solve. I am still new to the project, and I didn’t discover it entirely yet. What I can say now, I really like the people from my team, the software development process and work environment in my team.

Probably I will be writing about my work on this blog. Stay tuned!

MS sign