Accessibility Errors Are Breaking Your Build

July 19, 2013 Cameron Cundiff

Imagine if someone flipped a switch on your project that broke your entire integration test suite with failures that surfaced critical, long standing bugs in production that render your site useless to many thousands of users.

Hundreds of failures in CI, up on a monitor for everyone to see. The dev team is gawking, product folks are looking around, and leadership is raising an eyebrow. Imagine it for a moment. Did you feel your heart sink? Did the hair on the back of your neck tingle?

I’ve already introduced capybara-accessible: it’s a webdriver that automates accessibility testing in Rspec by running javascript assertions from Google’s Accessibility Developer Tools.

Install it. Run it. It will fail hard, on every test. You should see it happen and feel the pain.

“Why bother?” you say. “The product team doesn’t care”, or “that’s not are target audience” or “it’s too much to fix everything”. For most people on most projects, all of these statements are probably true. That’s not good enough.

You call yourself agile. You practice TDD. You have stellar test coverage and an automated accessibility testing extension available to you. Use it! You can at least stop the bleeding of adding new inaccessible features.

Go do it.

Now that you’ve got a clear picture of what’s failing, you can decide what to do. Keep in mind that the failures you are seeing are just the low hanging fruit. They are the aspects of accessibility that an be automated – most accessible development has to do with human judgement. These are a place to start.

Take a stab at the first two or three failures – focus on global layout issues. Give it a go for an hour or two, maybe an afternoon. Use the links in the error messages for guidance. At the end of the day, tag the rest of the tests as inaccessible and your suite will go back to green. Now you can push, deploy, and breath a sigh of relief. At least now you and your team won’t be making the same mistakes in the future, lest you break the build.

Now that your suite is green again, and your team is avoiding known accessibility errors, think for one more moment about all those other silent failures. There are accessibility failures that CI can never catch. They’re failures that could render the site useless once more, after all that hard work.

Don’t let that happen.

About the Author


More Content by Cameron Cundiff
Tracker and SemaphoreApp integration for continuous delivery
Tracker and SemaphoreApp integration for continuous delivery

We’ve been using SemaphoreApp for continuous integration of an internal app I’m working on. It a beta featu...

Reading the Ruby Source to Understand Rails Idiosyncrasies
Reading the Ruby Source to Understand Rails Idiosyncrasies

Suppose somewhere within our Rails application, we have something like the following line of code. (10.days...

Enter curious. Exit smarter.

Register Now