Shift Left for Accessibility

It’s hard to assess the accessibility of a digital product when you don’t know what it means to do that, but we at SenseIT believe that it needs to be done anyway, and we think we know how that should look. We believe that using the shift left approach to development in the context of accessibility would make for more accessible digital products. The idea should apply to accessibility as much as to anything else, and that’s the basis of our work.

 

Accessibility Solutions on The Market

Current digital accessibility solutions are severely limited. They break down into two main types: manual testing and code-based solutions. Manual testing involves someone (often someone with one or more disabilities) manually performing an accessibility test. The results can vary depending on who is doing the test, and though they give a more accurate picture of the problems a product might have, they often lack the shared language with developers to effectively explain how to fix them. Other problems include the cost, both of paying a person an hourly rate to perform these tests, and of fixing the product after the tests have been done, since they can only be done after the product is almost ready for release. It’s an imperfect solution (and it’s why we started SenseIT), and it can mean a product has to go through multiple rounds of testing before it’s ready for market.

Code solutions are at the other end of the spectrum. They’re designed to be easy to use – just copy this line into your code and voila! Accessible. Except that’s an oversimplification of the issue. For one, there’s no actual testing going on – your code might be more accessible than it was before, but there’s no way to know that there won’t still be issues with accessibility. But more importantly, as you update your product, that line of code isn’t necessarily taking those changes into account. Anything worth doing is worth doing badly, of course, but why do it badly when there’s a better solution out there?

 

Shifting Left

Shifting left essentially means doing something earlier in the development cycle than it has typically been done[i]. If you visualize the development process as a timeline wherein the requirement analysis for a product is at the leftmost extreme and product release is at the rightmost side, then to shift something left on that timeline would mean that it appears sooner than it might have otherwise done.

 

 

The term “shift left testing” was first used in an article published on Dr. Dobb’s in 2001[ii]. The author argued that the way testing was then done – as a ping pong between development teams and quality assurance (QA) teams – was wasteful and ineffective (This was very similar to what manual accessibility testing is like today). He argues that QA should be brought in early and often in the development cycle to prevent bugs from the outset rather than to remediate them later. And he advocates that as much of the testing that can be automated should be automated. These two suggestions would save time and money, and the approach leads to more naturally elegant solutions to potential problems and good design overall.

As with most things, however, shifting left isn’t as simple as it might seem; you can’t do things earlier if it doesn’t make sense to do them then. In functional testing, for instance, you can’t test something before it exists[iii]. This is true for accessibility testing as well, and you have the additional challenge of not always knowing how assistive technologies on the user’s end might interact with the product, and so even with the right intentions, it can be tricky to incorporate accessibility testing into your development cycle without having some crossover in the expertise of developers and accessibility testing. That’s what we provide at SenseIT, and when we say shift left for accessibility, we mean that that’s what we aspire to do on our end. However, we also mean it as a call for awareness to the fact that accessibility needs to be accounted for not as an afterthought, but as part of the design – if the product is going to be truly accessible, that is. “Shift left” isn’t just about development – it’s also about mindset.

 

Why Shifting Left Hasn’t Been Done Before – And How to Change That

Whether a product is accessible to users with disabilities is usually an afterthought for developers. The requirement to make it so comes from public policy and is usually left to the domain of product managers. Moreover, the policy isn’t enforced except by lawsuits, like a game of Russian Roulette wherein everyone believes the worst won’t happen to them. This approach means that oftentimes developers view accessibility as an unwelcome burden, especially once they’ve put in significant effort into creating what they think of as a finished product. In many cases, products are simply left as is and are therefore inaccessible for any of the approximately 15% of the world’s population with disabilities[iv], the elderly, and anyone else who relies on assistive technology to access the digital world.

We don’t expect everyone to take on accessibility as their cause. There are far too many worthwhile causes out there for us all to have in-depth knowledge of each of them, so we outsource, and there’s no shame in that. If you’re reading this in the first place, then odds are that you care about a lot of things, and we want you to be able to focus on whatever your niche is. Our automated testing platform makes it easy for you to implement accessibility testing throughout the development cycle without you having to invest time and energy into it that you don’t have. We shift left in accessibility so that you don’t have to – and you still get the benefits of having done it well.

Accessibility can be difficult to assess in general, but it can be simplified by spreading out the assessment over the entire development cycle, either if you know how to do it or if you use SenseIT. The “shift left” approach is being adopted in lots of areas of development, and now we can adopt it for accessibility too.

 

[i] Source: Devopedia. 2022. "Shift Left." Version 6, February 15. Accessed 2022-02-15. https://devopedia.org/shift-left

[ii] Source: Smith, Larry. 2001. "Shift-Left Testing." Dr. Dobb's, September 01. Accessed 2022-02-15.

[iii] EvilTester. 2018. "What is Shift Left Testing?" EvilTester - Software Testing, YouTube, June 11. Accessed 2022-02-15.

[iv] Source: WHO