How to incorporate accessibility testing early in the SDLC

Picture the scene: your team has spent months building a global, user-facing application. The major features are all ready and you’re eager to get the application into production. Then you discover the accessibility score is too low and the application wouldn’t be usable for an extensive set of users.

Boom! We can’t release the app and the go-to-market timeline takes a big hit.

This is actually a really common problem when we don’t give enough importance to non-functional requirements (NFRs) such as accessibility. Let’s look at how we can shift left accessibility testing to the unit level, by leveraging some good practice and widely available tools.

ByRole query in React testing library

We often try to use an escape hatch by adding test IDs to the HTML elements and using getByTestID query to get hold of elements in the unit tests. For example, we might have an inaccessible form where inputs aren’t tied with label:

Since we are adding testIDs, it’s very easy to add the unit test for this inaccessible form:

Even the div with click listener, which behaves like a button to submit the form, works as expected but is totally inaccessible.

To overcome this problem, React Testing Library does provide byRole queries to get the elements by their accessible role. This means that the same form with proper accessible role should use the accessible role to get hold of the element.

The test will fail if we:

• Remove the html for attribute from label, or event ids from the input elements
• Use any other element other than a button with the name submit to submit the form
• Change the heading level of the welcome message

Taking these steps makes the form more accessible by checking it at the unit level only.

UserEvent catches what fireEvent misses

User-event is a companion library for the testing library that simulates user interactions by dispatching the events that would happen if the interaction took place in a browser.

The browser usually does more than just trigger one event for one interaction. For example, when a user types into a text box, the element has to be focused, and then keyboard and input events are fired and the selection and value on the element are manipulated as they type.

fireEvent dispatches DOM events, whereas user-event simulates full interactions, which may fire multiple events and do additional checks along the way. It therefore adds visibility and interactivity checks along the way – manipulating the DOM in the same way that a user interaction in a browser would.

An interesting example of an accessibility error caught by userEvent that’s missed by fireEvent is pointer-events: none CSS property. If you try to click a button that has this CSS property using userEvents, the test will fail – but this would not be the case when using fireEvent.click.

Use packages to add accessibility assertions

Plugins like jest-axe or vite-axe (a custom Jest matcher for testing accessibility with axe) help to run automated tests at unit level. Simply wrap the container inside the axe utility provided by the package to check for any accessibility issues.

If the input doesn’t have a label, the tests will produce an error.

What else could we do to check accessibility?

It’s important to remember that around 30% of access barriers are missed by accessibility tools. We need to do more than simply rely on automated tests. Some other things to consider:

• Include accessibility checks in automation pipelines and use the lighthouse score for accessibility as a check with every build
• Test your interface with assistive technologies like Voice Over in Mac etc.
• Always test for keyboard access and manual accessibility testing
• Involve people with disabilities in your accessibility testing

Accessibility is a very important part of any successful product. We need to make sure we’re testing for it early in the software development lifecycle, rather than making accessibility something we only think about at the end of the process.