Accessibility-focused Test Driven Development

The Test-Driven Development process has a certain beauty in its simplicity:

Think about how the small pieces of your applications should behave for accessibility, then write tests to make sure they do. This helps keep us on track and saves us from breaking things later.

As the developer tooling ecosystem has evolved over the years, we are now able to write tests that go beyond business logic and into accessible user outcomes.

Testing Library is a fantastic tool for a web developer to become familiar with.

Using the Jest framework and utilities provided by Testing Library, we can write tests that ensure that elements are not only rendered to the DOM, but also that they properly support keyboards and Assistive Technologies.

Remember how hitting the Tab key is my first accessibility test when I’m using a web app?

With a little help from Testing Library’s jest-dom and user-event packages, we can write a test that renders a SearchButton component, and makes sure that it has focus after the Tab key is pressed.

Inside of a describe statement, we’d write something like this:

it('can be reached with the keyboard and a screen reader') {
	render(<SearchButton />)
	const button = screen.getByRole('button')
    tab() 
	expect(button).toHaveFocus()
}

it('can be reached with the keyboard and a screen reader') {
	render(<SearchButton />)
	const button = screen.getByRole('button')
    tab() 
	expect(button).toHaveFocus()
}

If the test passes ☝️, we can be confident that the user will be able to tab over to the search button.

Another useful tool for testing at the component level is Cypress Component Testing.

With this tool, we are able to write similar tests to our example above, but with the same API and add-on ecosystem that Cypress uses for integration & end-to-end testing. In addition, components are rendered to a real browser and include a UI for debugging test behavior.

No matter which of these tools you use, the TDD process for your accessible components is the same:

1. Identify the component to test.
2. Write tests describing the behavior that fails accessibility requirements.
3. Make the tests pass by fixing the accessibility problems in the component. To validate your approach, make sure to cross-check in a browser (and screen reader, where applicable). This will make your tests more solid and worthwhile.

Here are some ideas for Accessibility-focused tests you can write:

• Check that hidden items aren’t reachable by keyboard when they shouldn’t be, such as inside of a closed menu
• Component props passed in for accessible names or other text content output the correct markup
• Menus can be toggled open and closed with the keyboard
• ARIA states and labels update when a combobox component is opened and items filtered