Continuous Integration (CI) And Accessibility Testing – A Modern Solution for A Modern Problem

Manual Tests Can’t Be Done with CI

When the default in accessibility testing is manual testing, there’s no way for it to be part of the development cycle as it’s typically done today. Continuous Integration (CI) cannot incorporate accessibility testing unless accessibility testing can be reliably automated. Fortunately, automating accessibility is exactly what we’re doing.

 

What is CI?

Continuous Integration (CI) is the development practice wherein after the developer finishes a bit of code, they integrate it immediately into the automated testing cycle, which allows them to get near-instantaneous feedback and the opportunity to remediate mistakes immediately. This progression is commonly referred to as a CI pipeline. It allows the developers to be the testers, thereby ensuring a higher level of consistency in the product’s vision. CI is opposed to what used to be, wherein only after meeting certain preset milestones in a waterfall (step-by-step) development flow would a separate quality assurance team test it for any and all errors it may have. It would then be sent back to the engineers to start the process all over again.

The widespread adoption of CI has been a revolution in the world of software testing and development. It falls in line with DevOps and agile development practices, both of which have become very popular for their ability to lead to faster release cycles. CI increases efficiency, cut down on costs, and allow for faster production overall. These are all great features; the problem is how accessibility comes into play with it.

 

How Does Accessibility Testing Work?

 

In the world of accessibility, it almost goes without saying that accessibility testing is done manually. Because while there are automated solutions, most of them aren’t robust enough to be worth the paper they’re printed on.

A manual accessibility test is done by a person in front of a computer performing the functions set out for them in a test script. When testing for accessibility, in addition to being able to perform the test as it’s designed, the tester needs to have knowledge about accessibility standards and how people with disabilities interact with the software under test. They essentially design a usability test themselves, and it has very little to do with how the software is designed to function.

 

Problems with Accessibility Tests

Because the testers need to be experts in the field of accessibility, the average developer can’t design or perform these tests, and they’ll need to be outsourced. This means that the cost of manual accessibility testing is going to be even higher than other kinds of manual testing. And, because the tester doesn’t know why the designers and developers made the choices they did, it can be clunky to remediate potential issues, and developers may be reluctant to compromise their ideas of their product to make it accessible.

 

 

But the bigger problem, as we see it, is a more systemic one: a manual test can only be performed on a completed product. That means that whereas all the essential functions for a “mainstream” user are being tested for early and often thanks to the CI pipeline, functionality for users with disabilities is left by the wayside and only addressed as an afterthought. And it’s not even the developers’ fault! The very nature of accessibility testing as we know it has made it so – a manual test cannot be incorporated into a CI pipeline.

 

Our Solution

At SenseIT, we recognize that as a barrier to accessibility in its own right, and our solution is to automate the parts of an accessibility test that beg to be automated. We focus on keyboard navigation functionality because that covers a whole swath of accessibility barriers, and it’s not covered by any other automated testing platforms. We believe in the potential that automation in general has for the world of accessibility, and that it just takes the right people at the right time to make it work.

We can make the web more accessible if we apply our knowledge of accessibility testing to automation, and that’s exactly what we’re doing. To learn more about why we believe that, read our white paper about automation and accessibility. You can also request a demo or get in touch with us to talk.