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

Write a (failing) test. Write some code to make it pass. Ensure the test passes, then repeat for the next requirement.

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

hitting the Tab key is my first accessibility test

With a little help from Testing Library’s 

 packages, we can write a test that renders a 

 component, and makes sure that it has focus after the Tab key is pressed.

 statement, we’d write something like this:

, 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 

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:

Write tests describing the behavior that fails accessibility requirements. 

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.

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