As a software-as-a-service company that develops and sells a web accessibility product, it is essential that we don’t just talk the talk, but actually walk the walk when it comes to accessibility. Therefore, we want to share our story and hopefully inspire other tech companies to think about how they can build a development culture that prioritizes making their products accessible to users of all abilities.

But first things first: What is web accessibility and why does it matter? The concept of accessible web design and development ensures easy digital access—be it unassisted or through assistive technologies—for people of all abilities. Whether someone has a cognitive disability that requires simple content and navigation, or a blind user that relies on a screen reader to read a web page, there are many reasons to make your software accessible. The latest figures from the World Health Organization state that 15% of the world’s population lives with some form of a disability.

So if we know accessibility matters and there’s a significant portion of internet users that rely on accessible services, what’s the problem? Just develop accessible stuff and everyone’s happy, right? Well no, not exactly.

While most of the world rightly expects that buildings have ramps, transport has accessibility features built in, and braille is available, the same cannot be said of the internet. Despite growing prominence and a strong global network of organizations and individuals championing accessibility, there’s still a long way to go.

There are a lot of false preconceptions about accessibility—mainly lack of awareness, assumptions it’ll take more work and cost a lot, and that accessible websites are ugly, boring, and static.

Changing these preconceptions isn’t easy and doesn’t happen overnight. Likewise, our own internal relationship with accessibility has been and continues to be a journey. Building a pipeline and development culture that understands and prioritizes accessibility over quick release times in a high-paced environment can often detract even the best intending teams from prioritizing accessibility.

To better understand how our development department is prioritizing accessibility, we sat down with Martin Nørskov Jensen, Siteimprove engineering manager, and Boyd Ludlow, Siteimprove software engineer, to discuss a recent initiative of theirs called the A11Y Drive Project.

Martin Nørskov Jensen and Boyd Ludlow discussing Siteimprove's A11y Drive Project

Martin Nørskov Jensen (left) and Boyd Ludlow (right) are overseeing Siteimprove's A11y Drive Project to improve the accessibility of all Siteimprove products.

Why did you come up with the A11Y Drive Project?

Martin: We knew that we had some accessibility issues on the backlog and that we would never be able to work through them all without a systemic approach that involved all our development teams. Our platform is too big for it to be a one-person job, plus we knew that as a company we wanted to prioritize accessibility and that starts from within. As such, we came up with the A11Y Drive Project to find a way of automating the task of checking to ensure code was accessible, as well as reduce the chance of regressions.

What exactly happens during an A11Y drive?

Boyd: The period of a drive is normally about six weeks, and during this time the teams have a small amount of extra work to do, but we’re agile, so luckily we can fit that into the development pipeline with little impact on overall delivery times. The accessibility drives are a way to incorporate fixing known accessibility issues in our platform without slowing down the delivery of new functionality. We’ve done this by spreading the work out across the various product teams and giving them issues to fix during each drive period. Using our automated tests that we’ve built, we can list where in our platform those issues manifest, and then assign them to the various product units.

"Most companies don’t include accessibility checks, even though they could easily do so without it costing them a thing." - Martin Nørskov Jensen, Siteimprove engineering manager

Martin: It may seem simple, but accessibility often isn’t a gate within the Continuous Integration Pipeline. What we’ve done is added it as a check within the pipeline, combining a basic code checker that most developers already use with our free open source Siteimprove Accessibility Checker. This means when an issue is flagged, it doesn’t make it through the gate and is sent back to the team. This is common practice for quality checking code, but most companies don’t include accessibility checks, even though they could easily do so without it costing them a thing.

We often hear from Siteimprove clients and prospects that the developers they work with don’t understand how to make accessible code. What are your thoughts on this?

Boyd: I think it’s difficult because a lot of developers, myself included, just don’t spend a lot of time thinking about accessibility. There is a lack of accessibility education. Even when I did interface courses, the focus was on things like user intuitiveness, not how a screen reader would interact with it.

Martin: Plus, a lot of developers are not conscious of not making inaccessible code—not because they don’t care, but because for most it’s just not the first thing they think about when creating new stuff. Instead they tend to focus on functionality. So for example if they need to make a form, they focus on making sure it works rather than also thinking about labelling the different parts of the form so that assistive technology, like a screen-reader, can interpret it. There needs to be a culture change to get to that point.

What’s being done internally at Siteimprove to address the misunderstanding of accessibility among developers?

Martin: If you really want to do something about it, you need some kind of culture change in how you deliver your software. That’s why we have started holding workshops for all the different development teams so they learn to start thinking about accessibility from the beginning. This way we can work accessibility into the product from the beginning instead of finding out after the fact that what we have built is inaccessible.

Boyd: Just last week at our weekly internal ‘Tech Talk’ event, the topic was possible upcoming accessibility challenges our development teams may face and how to tackle them. In this way we’re trying to give our developers a sense of ownership over the process so that when we do get positive feedback from our customers about the accessibility and usability, they can understand the human value of our products.

So we’ve solved the eternal problem then of prioritizing accessibility as part of the development pipeline?

Boyd: Ha-ha, no not at all. And we’re not saying we are perfect, but rather we have identified that we do have accessibility issues, and more importantly we have decided that it is something we should work to improve. We are also demonstrating that it is not a quick, simple fix to make your website or web application accessible, but something that you need to devote some resources to.

Martin: I agree. You can’t just say, “Look! We ran all these tests, found these problems, fixed them, and now we’re accessible.” We need to constantly be on the lookout for potential issues and keep developing a process of baking accessibility in from the start. Most importantly, I think the decision to prioritize accessibility needs to come from the top so that the entire company knows that accessibility is something that we take seriously and that we want to be a company that cares about inclusion.

"We're trying to give our developers a sense of ownership over the process so that when we do get positive feedback from our customers about the accessibility and usability, they can understand the human value of our products." - Boyd Ludlow, Siteimprove software engineer


The University of California recently signed a three-year systemwide contract with Siteimprove to help them in their web accessibility work. To gain insight into the human side of having an accessible software platform, check out the University of California’s recent blog post about Siteimprove.

Jessica O’Sullivan-Munck has been with Siteimprove since 2013. She works as Siteimprove’s Public Affairs & Relations Manager, where she loves spreading the word about web accessibility and driving various good causes and initiatives. Jessica has a degree in Political Science and Journalism from Australia’s University of Notre Dame, and a postgraduate degree in Strategic Public Relations from the University of Sydney.