Introduction
In this article, I want to share my thoughts on accessibility testing included in the Continuous Deployment (CD), with Jenkins as the environment.
In general, when creating and improving our CI/CD Pipelines it’s good to pay a lot of attention to functional and integration tests. From the product quality perspective, they are crucial, of course. But I will try to convince you that you get significant benefits from introducing accessibility tests into your pipeline. In this article, we’re going to focus on web applications (with the exclusion of streaming or playing videos).
The importance of accessibility testing
The first question that comes to my mind is: Why do I need this kind of tests and what's in it for me? Well, first of all, according to studies up to 15% of people has some kind of disability. Creating applications that may not be used by them is like ignoring a substantial part of the market.
Also, some legislation all over the world may require IT products to be accessible to people with disabilities. Your company might even get sued if your products are not designed to be accessible. The bottom line is - with a little effort, you can make your application user-friendly to everyone - including people with disabilities.
Passing accessibility tests
Let's list all some of the most widespread kinds of disabilities that we need to take into account if we want to build an inclusive web application:
- Vision disabilities - the most important issues here are colour blindness and poor vision, also problems with strobing or flashing effects.
- Physical disabilities - that may impact the use of the mouse or keyboard.
- Literacy and learning disabilities - includes potential problems with reading and writing.
So we need to think of some amenities in our application that will allow it to be used by all users. The most important of them are as follows:
- The application should have keyboard equivalents for all mouse operations.
- Tabs must be ordered logically to ensure smooth navigation.
- Shortcut keys need to be provided for menus.
- All labels in the application should be accurate and understandable.
- Colours in your applications need to be distinguishable for all users.
- Images and icons should be easily understood by all end users.
- The user should be able to adjust or disable flashing, rotating, or moving elements.
Accessibility rules for vision disabilities
Let’s take a closer look at the real-life examples of what we need to consider when designing our product for people with vision disabilities like colour blindness and poor vision.
Colour blindness means that people cannot see particular colours, in most cases it’s red and blue. The first rule is to use a high contrast between special elements like buttons or headers and the background colour. The second rule is using universal colours like black or white.
The other vision disability I’d like to discuss here is poor vision. To address this user need, we need to remember about several things and most importantly - it’s best to avoid small text and enable users to zoom and enlarge text without ruining the page layout. Besides text, all other elements on the page need to be visible and easily accessible.
Accessibility testing with Jenkins
Manual testing of accessibility can be tricky for testers, especially if they are not disabled themselves. It could be hard for them to step into the shoes of someone with a disability. For them, a web page can look perfectly fine while for someone with vision problems, it could be quite difficult to make sense of. Of course, each tester can use some guidelines or specifications, but still, that kind of testing is very challenging for most people.
So if manual testing is difficult and complicated, we can try automated accessibility tests which can be more reliable. We can use various tools available on the web for that. Most of them are open-source so you don’t need to spend any extra money on adding them to your development project.
You can run tools like that from the command line or by a build tool like Maven or Gradle. You just need to have your application deployed under an accessible URL address. Most of the tools provide various accessibility metrics and generate reports we can easily publish in our CD environment. If our rate is low, we should fail our pipeline.
Accessibility testing in practise
At Solidstudio, we use Lighthouse for that. We integrate it with a built tool to our CI/CD provider. Most recently, we introduced such a step in our Jenkins pipeline which lets us to enable automatic deployment to production. If you cover security, performance and accessibility testing (apart from the standard units and integrations) you can be sure that your application meets the highest standards all the time.
Introducing accessibility tests in your pipeline is quite easy and cheap, while gives you a lot of advantages. You can ensure that your product can be used by people with disabilities and avoid risking any legal problems. It also helps to build a higher quality product in general - after all, accessibility rules work great for all end users.
P.S. If you’d like to stay in touch, please sign up for our newsletter: no spamming, just information about the latest content.