Test-driven Frontend — Accessibility first

In Part 3 of the Test-driven Frontend series, you will learn about accessibility testing.

Around 15% of the world’s population has some form of disability. The internet and smartphones have given voice, eyes, and ears to people who did not have these possibilities before. But this is only achievable when we as Software Engineers make accessibility a standard. Instead, it is often an afterthought. And like every change that comes in late into our project, it becomes expensive to implement. This article will help you to integrate accessibility into your workflow, so it becomes a natural part of developing.

How can we improve?

As Product Owner or Frontend Engineer, we often don’t even know where to start when it comes to the topic of accessibility. Because it’s not the one thing we can do and our product is magically accessible. The range of disabilities is broad and includes all sort of physical as also mental disabilities.

If we talk about accessibility, we have to remind ourselves this is not exclusively targeting disabled People. Accessibility is also about gender, colour, religion and wealth.

Another fact is that the majority of inaccessibility for most people can be avoided by designing inclusive. An escalator, for example, is already able to help a certain amount of people who have difficulties with stairs. Adding an elevator to the scenario now makes it accessible for almost everyone. When you plan, design and develop a product, it’s the same. If your product is built for inclusiveness, it will be able to reach the broadest audience.

Be inclusive!

To achieve this, we have to start by who we are hiring. A single mother will have a different point of view than a male without family and children. So will a person of colour have to a white person or a person with a disability to one that is fully abled. A diverse team will always come up with a more advanced product as a team with a single mind and world-view.

What can we as developers do?

Let’s go back to our test-driven design system we set up in Part 2. I have chosen storybook not only because you can easily demo your components, but also because of the broad field of helpful addons. The one we will use now is called a11y.

A11y is based on Axe Javascript Accessibility API. Axe is an accessibility testing toolkit, developed by https://www.deque.com/. It will automatically apply a set of rules developed by W3C and best practices from the companies experience.

Using this tool will not cover all possible issues, but will help us to integrate accessibility in our testing routines as I mentioned at the beginning of this article its a vast field to cover. Some more resources, for example, can be found here and here.

The developers’ dream — more tooling

For using the storybook addon, we need the following steps:

• adding it to our package.json and install
• load it into storybooks addons
• add it as a global decorator for all stories.

yarn add @storybook/addon-a11y --dev

When we now start storybook again, our counter story should look like this.

We already have five passes, mostly because of the browsers default design, and one violation regarding labels. When we expand the violation we can read more explanation about why this is a violation and how to solve it. To fix it, we could apply now a label tag to the counter if we want. If there is no visual label needed then we can use an aria-label tag instead. The aria-label tag is understandable by most screenreaders and so a person who can not see the arrangement can identify it as a counter by hearing the aria-label tag. Let’s change that quick.

Congratulations — we are now up to 9 passes and the end of this article. The a11y addon will stay our companion for the rest of this series when we add functionality and design to our component.

Until then, keep educating yourself, play around and be the change that helps to give voice to others.