UI Acceptance Testing Accessibility

2016-09-26 • Comments [2]

Accessibility keywords

In the previous post Unit Testing Accessibility I showed how to run accessibility check on HTML node with aXe. This approach can be used to test components of your website.

You can take your accessibility testing to the next level by adding accessibility check for entire pages.

Do you remember Martin Fowler’s testing pyramid?

testign pyramid

While high-level UI tests can detect the same issues that unit tests can, usually UI tests are slower to run. Sometimes it takes 30 seconds to 1 minute to run 1 UI test, while unit test can be run in less than 100 milliseconds. Ideally you should have the most common scenario covered by UI test, and all possible customizations (on the component level) covered by unit tests. You can also add UI tests for some complex combinations of your components, and when you are fixing a bug in situation that unit test cannot cover encountered scenario. Because as you know, while fixing a bug, you should add unit test covering buggy scenario.

In general, unit tests and UI tests should be complementary. UI test should indicate an issue, while unit test should help you to find a source of the problem.

In accessibility testing, high-level checks are very useful in detecting accessibility issues caused by some “small change”. Once you detect accessibility violation, you should:

  1. narrow it down to particular unit of your website
  2. add unit test to cover broken scenario
  3. make sure it fails
  4. fix the issue (by writing code)
  5. make sure that unit test pass
  6. make sure that end to end UI tests pass

Check out Marcy Sutton’s article: Accessibility Testing with aXe and WebdriverJS. She created sample github repo that is demonstrating how to set everything up.

Comments [2] • Category: programming • Tags: ,

Unit Testing Accessibility

2016-09-20 • Comments [0]

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.

Comments [0] • Category: programming • Tags: , , ,

Azure Portal Tips & Tricks – 21. Azure Portal Settings

2016-09-14 • Comments [0]

Azure Portal Tips & Tricks is a series of short videos where I am showing various features of the Azure Portal and how you can take advantage of them to be more productive.

In this video I am showing the Azure Portal settings.

You can follow the series by subscribing to my channel or going directly to Azure Portal Tips & Tricks playlist:

If you have any suggestions or questions about the Azure Portal, or there is something in particular that you would like to see in this series, tweet me at @JakubJedryszek or leave a comment.

Comments [0] • Category: other • Tags: ,

Working Effectively with Legacy Code

2016-09-12 • Comments [0]

I haven’t publish any book review for a while. It does not mean I am not reading books anymore. I just didn’t feel that some of the books I read recently requires my recommendation, or I didn’t have any thoughts that I needed necessary to share right now.

I have added a few books to my favorite books list though. Check them out!

Working Effectively with Legacy Code deserves blog post because of a few reasons:

  1. Every Software Developer should read it
  2. It’s not really about legacy code
  3. Published in 2004 (12 years ago!) is still very up to date

Working Effectively with Legacy Code 1st Edition by Michael Feathers (Michael Feathers)

The book has three parts:

  1. Importance of unit tests when changing software
  2. Recipes for real World problems that we face when changing software (e.g., “I need to change a monster method” or “What methods should I test when introducing a change”)
  3. Dependency-breaking techniques catalog

The first part should be familiar to most of programmers these days. If it is not for you then you should read Agile Principles, Patterns and Practices (by Robert Martin), TDD by Example (by Kent Beck), and The Art of Unit Testing (by Roy Osherove). You can thank me later.

The second part is the essence of the book. It shows, by example, how to add new feature, make a change to existing code, or fix a bug. Most books about software development, present examples on very simple, clean code that we never see in real World. This book, takes some messy piece of code and shows how to make it testable, how to get rid of too many side effects, and clean it up by separating dependencies and responsibilities. Many times we want to test one functionality, and then we realize that we need to instantiate tens of objects that other method depends on. Sounds familiar? This chapter shows how to handle that.

The last part (Dependency-Breaking Techniques) is very similar to Martin Fowler’s Refactoring: Improving the Design of Existing Code. It’s a set of techniques, and step by step description how to apply them to existing code.

As I mentioned earlier. This book is not really about legacy code. I think it is more about evolving existing code. It is natural, when adding features, we add lines of code to the method. The hard part is to know when you should extract new method, or introduce a class, and refactor dependencies. It’s OK to have global variables. The problem is to keep track of them or localize them. How do you know, that adding a new functionality will not break something? You have 100% test coverage for every possible use case? That’s not possible because of complexity of software we are creating today. “What methods should I test” shows neat technique to backtrack effects, and side effects of a change that we are introducing.

There is much more, and you should check out this book. You don’t have to read it from cover to cover. I strongly recommend you, at least, to scan through part 2 (changing software), and I am sure you will learn something new that you can apply for your project today!

Comments [0] • Category: books, programming • Tags: ,

My second year at Microsoft

2016-09-08 • Comments [0]

Jakub Jedryszek - Microsoft badge

It feels like it was yesterday when I published My first year at Microsoft. Time is going fast! This is what usually happen when you have a lot of things to do, and you enjoy it. My second year spent at Microsoft has been great! Full of new experiences, challenges, and lessons learned.

Azure Portal

Azure Portal in 2016

For the past 2 years I’ve been working on the Azure Portal. Last 12 months has been very important for entire Portal team. Since December 2, 2015 the new Azure Portal is no longer in preview, and is now an official management interface for Azure. The Old Portal is still available, but we slowly retire its features, and move them one by one to the new Portal. More, and more people start liking the new, revolutionary UI. We are getting requests to Open Source our UI, so that people can use it to build their own management interfaces. If you are interested in that, vote here.

Over last year I helped to improve Portal reliability, which was our last milestone before becoming the official management portal for Azure. It was one of the hardest things I’ve ever worked on, because of the Portal Architecture. We started from 80% reliability in some areas, and our goal was to achieve 99.9%. It was extensive few months of investigation, bug fixing, and optimization. Once we achieved three nines, now we have to stay there. We are getting regressions from time to time, but for most of the time we keep the reliability at the desired level.

Another big area was improving accessibility (keyboard + screen reader support). It was very challenging task because, again, the Azure Portal is nothing like most of web apps. Especially from the design perspective. It’s totally different, non-standard, and has a bunch of features nobody have done before (blades, tiles and journeys). As of today I am amazed how much progress have been done, and what the current state of Portal accessibility is. One thing that amaze me at Microsoft is how the smallest, tiniest, everyday improvements makes a difference in a long run.

Besides reliability and accessibility, I work mostly, on the web controls that are being exposed by our Framework. Partner teams (e.g., Web Apps, Virtual Machines, SQL, etc.) are building Azure features using our Framework and controls. Over last 12 months I created a few controls, added a lot of features to existing ones, fixed a tons of bugs, and made a lot of improvements for date/time controls with help from Matt Johnson (yes, he does not work for our team, but he is one of the best date/time and timezone experts in the World, and it happened that he works for Microsoft so it would be stupid to not ask for his expert advice).

There is also one thing I need to rant about: Safari 9.x (and all earlier versions) does not support Internationalization API (Intl). We are using Intl API for numbers and currency formatting. At the beginning, when we were still in preview, we hoped that Safari will add Intl support soon (in a year or so), but it didn’t happen. We had to use polyfill. Oh…actually I should rant about other issues we had with Safari (like Local Storage does not work in private mode), but you can check caniuse.com or just read an article: Safari is the new IE.

In addition to work on features, I also did a few improvements on our development workflow. From automation scripts, through some helper methods for unit testing, to speeding up local build time by changing MSBuild verbosity (printing to console takes time, in some cases we saved up to 1 minute of build time thanks to this simple trick!).

Speaking, traveling, conferences

NDC London 2016

 

Over the last year I have spoken at a few conferences, Seattle Code Camp, and gave a talk at SeattleJS meetup.

I’ve been speaking mostly about TypeScript, Azure Portal and Aurelia Framework (yes – the last one is totally not related to my day job).

My most recent talk about the Azure Portal architecture received a lot of great feedback. One gentleman told me that it was the best talk of the VSLive Redmond conference, somebody wrote a comment that it was the “Most interesting non-scotthanselman presentation ever”, and one person mentioned it (as “excellent talk”) in Azure Portal user voice (which I found while writing this post and searching for a link to Open Source Portal UI user request for previous section).

Over last year I learned that going to talks at the conferences is the least important thing. The most important is to connect with people from outside of your everyday work environment, share experiences, and networking. The most interesting conversations don’t happen during the presentations, but at the post conference dinner or after party. I really recommend to read chapter 14 of Never Eat Alone before attending a conference!

When I am telling people that I travel around the World to speak at conferences, they think it looks like this:

conferences wolf of wall street

They forgot that most of the time it looks like that:

conferences - travel

Of course there are pros and cons.

Pros:

  • Learning new things (while preparing your talk, and during the conference from others).
  • Meeting new people
  • Visiting places you haven’t been before. On my way to NDC London I paid from my own pocket for flight through Iceland with 34 hours connection flight in Reykjavik. I managed to see the Golden Circle, attend New Year’s Concert at Harpa, and I’ve seen the Northern Lights. I have also seen a little bit of London during the same trip

Cons:

  • You need to work after hours to learn and prepare talk for the conference. You also need to write a good abstract so you talk will be selected. This takes a lot of time!
  • Travelling to conference takes time that you could spend with friends, family, or riding bike. Even if it is domestic flight it takes ~30 mins to get to airport, then ~2 hours on airport, ~2-4h during the flight, ~30 mins to get to the hotel etc. When it is on the other continent then you waste even more time + get jet lag. Oh…and you need to pack day before (~30 mins to 1 hour), and you don’t have your nice 3 monitor setup and comfortable Herman Miller chair for a few days.
  • Sometimes you don’t see anything except airport, aircraft, hotel and conference venue (that was the case when I went to ConnectJS conference in Atlanta and Open Source North in Minneapolis).

Thanks to speaking at conferences, I met a lot of interesting people, and definitely expanded my knowledge. What’s important: I learned the most during one on one conversations in the hallway or at the conferences’ dinners.

In addition to conferences I was a guest at .NET Rocks podcast, where I talked about the Azure Portal. I was also interviewed by David Giard – who I met at Open Source North conference – for his Technology and Friends series. Sara Clayton – who works on Open Source at Microsoft, and who I met at the All Things Open conference – did an interview with me about my Open Source library: voiceCmdr. Jeremy Foster (who I met at SeattleJS meetup) did an interview with me for his CodeChat show (episode coming soon).

Learning

workspace

Over the last year I’ve learned a lot about web development, performance, and accessibility. A lot of things I learned are captured in my last talk about the Azure Portal. I improved my coding skills, debugging skills, and also – mainly thanks to attending conferences – communication skills, which is very important in Software Engineer portfolio.

In my first year review I forgot to mention Microsoft Library, which is one of my favorites benefits at Microsoft. Most books I have read over last 2 years are from MS Library. I reviewed a few of them, and some landed in my favorite books list. The Pragmatic Programmer book said that you should read a technical book every quarter.

Last time, I also didn’t mention that when you are working on something related to Cloud, you have to be on-call once for a while. I am very lucky, because our team is large, and rotation requires everybody to be on-call only 1 week per 6-7 months. I have some friends who are on-call one of every three weeks, or even every other week (sic!). FYI – being on call means:

  • no flexible work schedule
  • no freedom (you need to be able to act on incident right away = you need to be close to your computer and Internet = you don’t go hiking, you don’t go out with friends, you don’t go for a bike ride)
  • I don’t know what can be worse than your phone ringing at 4 am, and some people asking you for help with investigating some problem they cannot solve (hint: these people are not stupid, the problem is hard, your brain usually do not work the best in the middle of the night)

However, there are also a good things in being on-call:

  • you can learn more about the project (when you need to investigate/diagnose something in the area you are not familiar with)
  • you can improve your debugging/investigating/diagnosing skills
  • you can meet new people across the company

The new thing for me, over last 12 months, was conducting interviews. It was very interesting experience. The most important thing I’ve learned was to never skip the coding question. My interview usually contains 3 parts:

  1. chat about candidate previous projects/experience
  2. easy coding question
  3. design question

There will be more details in upcoming blog post, but if you are interviewing people, I really recommend you to check out The Guerrilla Guide to Interviewing (version 3.0) by Joel Spolsky.

Staying fit and healthy

Jakub Jedryszek - run

When you are developer, you need to take care of your health. Sitting 10+ hours is not good for you. Sitting is the new smoking. Additionally it turns out that staying fit and healthy makes you better developer.

I bike, I swim, I run, I hike, I take part in bike rides (like 206 miles Seattle to Portland, or 180 miles Seattle to Vancouver), and I compete in triathlons once for a while.

Staying fit and healthy is not only about exercising. It is actually more about your diet:

exercise and diet chart

However, diet-miracle is not a way to go. Last year I tried to count calories I burn and consume throughout the day, and develop a diet I would be able to sustain for a long term. The trick is to realize that it is not worth to eat some things. E.g., this 500 calories cookie is not worth it. I would rather eat two Symphony bars from Hershey’s. Oh…and you need to wait for results couple of months or so.

It’s great that Microsoft cafeterias now provide calorie counts in the food menu. I am not eating these burgers that are 1400 calories, but other ones that have only 700. Together with Microsoft running trails it provides a great fitness bundle.

There are also other aspects you should take into account to stay healthy.

Oh…and I forgot to mention another awesome Microsoft benefit: Pro Club gym – one of the best gyms on the West Coast, and for sure the best in Seattle area. When I did a tour (right after I joined Microsoft 2 years ago), and the guy who was showing me around told me that they can service my car when I work out I was sure he was joking…he wasn’t.

PRO Club

What next?

Stay tuned!

Comments [0] • Category: career, programming • Tags:

«< 8 9 10 11 12 >»