Unit Testing Web Frontend For Accessibility Aspect

When we’re talking about unit testing, it is something that developers want to avoid, but what about accessibility?? the same thing, even most developers will say, ‘Nah, I’m good` *kidding

So, what is unit testing?? Isn’t it enough when we test the feature we developed works fine? The short answer may not be! I’ll tell you why…

OVERVIEW

Unit testing is a way of testing a unit — the smallest piece of code that can be logically isolated in a system. In most programming languages, that is a function, a subroutine, a method, or a property. The isolated part of the definition is important. In his book “Working Effectively with Legacy Code”, author Michael Feathers states that such tests are not unit tests when they rely on external systems: “If it talks to the database, it talks across the network, it touches the file system, it requires system configuration, or it can’t be run at the same time as any other test.”Modern versions of unit testing can be found in frameworks like JUnit, or testing tools like TestComplete. Look a little further and you will find SUnit, the mother of all unit testing frameworks created by Kent Beck, and a reference in chapter 5 of The Art of Software Testing. Before that, it was mostly a mystery. I asked Jerry Weinberg about his experiences with unit testing — “We did unit testing in 1956. As far as I knew, it was always done, as long as there were computers”.Regardless of when and where unit testing began, one thing is for sure. Unit testing is here to stay. Let’s look at some more practical aspects of unit testing. In fact, the traditional test of our application by black box testing, the thing that we talked about earlier manual testing only finds whether the feature that we developed already works or not. Then, when we talk about something important thing that most developers skip or miss is about accessibility (a11y). Accessibility is when we design, and develop products and any application that we put on it our thoughts about how this thing will work for everyone literally everyone, diversity disabilities included. So when we combine both a11y and unit testing it will lead to perfection.

Here is how I achieved that when developing applications using react.js

Setup

We need a setup to make our workspace easier, and that’s why we need to install some helpful plugins. Here are my top-tier plugins for a11y support in vscode.

• axe Accessibility Linter
• eslint-plugin-jsx-a11y (for react development)

When the tools that you set are already complete you can run tests, when you write the test don’t use id or class have role instead like this.

import { fireEvent, render, screen } from '@testing-library/react';
import React from 'react';
import Nav from '../Nav';

describe('Nav tests', () => {
    it('should contains button', () => {
        const handleDarkMock = jest.fn();
        render(<Nav handleDark={handleDarkMock} />);
        const button = screen.getByRole('button', { name: 'Dark Mode'});
        fireEvent.click(button);
        expect(button).toHaveAttribute('aria-pressed', 'true');
    });
});

Now it will trigger by role so part of the a11y won’t be missed/skipped right now rather than using id/class if you change it you also need to change the test as well, with role is not necessary.

When you forget to add an accessibility attribute to your HTML it will now trigger the eslint plugin and axe-linter we installed before

Or if you’d like to apply stricter, you can just extend the rule of the eslint a11y to your own eslint.config like this

{
  "extends": ["react-app", "plugin:jsx-a11y/strict"]
}

So it will trigger stricter even if you forget to add a label or wrap something in your label

That’s it for today’s sharing, thank you stay tuned for the next article 🙂