Accessibility Granted: Building Inclusive Components One Test at a Time

At Evinced, we run a mission to make the web more accessible for everyone. Approximately one in six people worldwide live with significant disabilities, and in the US, this figure rises to more than one in four. These disabilities include vision, hearing, mobility, cognition, and more.

In our digital age, where we shop online, work online, and doomscore ourselves to sleep, it is our duty as developers to ensure we do not exclude such a substantial segment of the global population. Moreover, this group represents a significant portion of our business target audience.

This might sound obvious. Everyone would have liked to make their applications accessible, so why are accessibility issues so common? I ran the Evinced site scanner on 1,000 pages from the Fortune 500 company website. This is just a sample of the issues that were found, and there were thousands of accessibility violations. For example, 800 elements could only be accessed by users who can operate a mouse, locking out keyboard-only users and many assistive technology users. 1,800 elements lacked accessible names, which are critical for screen readers. In fact, back in 2016, Domino's Pizza was sued by a blind man named Guillermo Robles because he couldn't order a pizza on their site, as they didn't label key elements. 1,100 elements were missing the required semantics, making it impossible for assistive technology to interact with them, and so on. All of these issues have reached production, a stage of development where it costs much more to find and fix bugs. You all know the pain of debugging a piece of code you haven't touched in months, or maybe ever.

What's interesting about this is that these companies were clearly attempting to build accessible sites. Otherwise, they wouldn't have even used ARIA attributes, whose purpose is to enhance accessibility. And yet, it's a perfect example of how intentions don't always lead to results in accessibility.

Today, I am going to talk about an approach to coding in an accessible way, that I think can prevent these kind of defects from ever reaching production. But before I do that, let me quickly introduce myself. I'm Daniel Gorin, a passionate researcher dedicated to refining chaotic processes. And that's me in the picture, trying to decipher the contents of a jar in my Airbnb. I've been working for the past six years as a researcher, and I currently lead the analysis technologies team at Evinst, where we focus on developing innovative capabilities for accessibility analysis.

Evinst is a software company that builds tools for developers, designers, and other professionals that take part in the product development life cycle. We help them make their sites and mobile applications accessible to all, where our focus is on helping our users detect and prevent accessibility violations as early as possible. In this talk, we'll explore the concept of accessibility through test-driven development. We'll start by understanding what it is, and how it's applied in front-end development. We'll dive into the complexities of choosing the right pattern. There's more to it than meets the eye. And finally, we'll tackle the challenges head-on, providing you with tools and examples to help you get started.

TDD was rediscovered in 2002 by Kent Beck. In his own words, the original description of TDD was in an ancient book about programming. It said, you take the input tape, manually type in the output tape you expect, then program until the actual output matches the expected output. So we can think of it as a timeless approach to software engineering. By writing tests before the code, TDD fosters better design, encourages simpler code, and helps developers catch defects early in the development cycle. This proactive method not only enhances code quality, but also improves maintainability, and makes refactoring easier. Now, we can start our journey with a unit test.

And unit testing is not just for applicative code. It's already used extensively in front-end code, especially when building components. In this slide, I'll demonstrate unit testing in React, using VTest with JS DOM as the browser environment. JS DOM is an incredibly useful tool for testing web applications. It's a partial implementation of a web browser in pure JavaScript. Its main advantage is speed, as it skips heavy lifting of visual rendering, things like computing styles and layouts, and instead focuses on simulating DOM APIs like Document or Window, making it ideal for testing logic and interactions. In this unit test, I render a Button component, which expects to get a click listener. In this case, the click listener is supposed to just change the value of a variable called click from false to true.

After rendering the Button, I find it on the page, and simulate a click on it. Then I verify that the click variable has indeed changed to true. Similarly, we can write unit tests to ensure our applications meet accessibility requirements. We can validate that our components conform to the most widely accepted standards for accessibility, the WCAG and the ARIA Authoring Practices Guide by the W3C organization. We can ensure they are fully operable by keyboard and screen readers. We can get lightning fast feedback even at large scales. This is achieved through the power of JSDOM, which I mentioned before. However, it's important to recognize that great speed comes with certain limitations. The tool has restricted capabilities for visual accessibility tests, such as assessing sufficient color contrast or focus indication. Additionally, the effectiveness of these tests heavily relies on the knowledge and expertise of the person conducting them.

Cool. Now that we've covered the benefits and limitations of ATDD, let's put it into practice and build an accessible Toggle component. But the first thing we need to understand is what a Toggle component really is. For example, a switch or a Toggle button are ideal for a control element that take effect immediately, providing clear, real-time feedback on binary choices or actions. In contrast, a checkbox is typically used in forms to mark a selection or the changes take effect once the form is submitted. Choosing the right write pattern is crucial for creating an accessible and user-friendly experience. Think of it as a contract with your users. The appearance of the component should indicate how it should be used and what its effect would be. Just as you expect neurotypical users to understand how to interact with your component, each pattern has specific accessibility semantics, so that assistive technologies users can do the same. As developers, we have an obligation to challenge product requirements to be as accurate as they can be, right from the start, to protect our precious time. To help you get familiar with the commonly used patterns and their accessibility requirements, I've added links to the most popular guidelines, specs, and blogs for designing and developing accessible UI patterns, for mobile and web. I want to jump into one of the most useful tutorials. The APG serves as an excellent benchmark for organizations to select, define, test, and refine the accessibility of their components. It provides practical examples and guidelines for implementing accessible UI components with ARIA, the Accessibility Supporting Attributes for Web Elements. It helps developers understand the required interactions, states, and properties for various patterns. While it has its drawbacks, such as overlooking semantic HTML in favor of ARIA, it remains our best benchmark yet. Plus, as an open-source project, you can contribute to its improvement. For example, when you open the button component entry, you will find a short summary of the pattern, along with accessibility requirements for both keyboard and screen reader, as well as example implementations. From these sources, I've extracted the accessibility requirements for toggle buttons. With a fairly short and focused read, you can do the same.

To test these requirements, we can leverage great open-source utilities created by Testing Library. A big shout-out to them. They are working hard to make accessibility testing simple. So let's get started.

It doesn't matter whether I'm using components I've built myself, leveraging open-source implementations, or even if I haven't written any code yet. To ensure accessibility, I can begin by writing my first test. I'm building a toggle button, so I want to make sure it has a role of button. I'm using the getByRole function from Testing Library to locate the button. The test will already fail if the button isn't found, but as an additional step, I use the Expectation Matcher to be in the document, to make sure that the button has been rendered in the JS DOM document. Now screen readers will be able to determine that this is in fact a button.

Moving on to our second test. A button should have an accessible name, so that screen reader users can understand its function. That's easy to forget with an icon button. This will allow screen readers to narrate something meaningful as they reach the button. In this test, I'm rendering the button as before, and using getByRole to find it. Then, I'm using the Expectation Matcher to have accessible name, in order to assert that the button has a name, including the word PAUSE, which corresponds to the icon that I'm using. To show you how powerful this Expectation Matcher is, I created an example of a test that tries to check for the attributes that compose the accessible name, like the text content or the aria-label attribute. It is long, hard to read, and only partially captures the final name. The matcher to have accessible name is an elegant and much simpler solution.

For our next test, we'll ensure that the button is accessible through tab presses. This is crucial for users who have difficulty using a mouse, allowing them to reach and interact with the button. Imagine a case where a keyboard user is unable to reach a cookie consent dialog, making it impossible for them to use the entire site. This is a perfect opportunity to showcase simulated user interactions. I'll use the UserEvent library to simulate a tab event. My button should receive focus, since it's the only element on the page, so I can expect it to have focus. While it's possible to test this statically, by checking for a tab index attribute or a tag that places the button in the focus sequence, firing an event is a much safer approach, as JavaScript event listeners might interfere with the normal focus order. This ATDD approach allows me to continuously create tests that ensure compliance with each accessibility requirement. These tests serve as my safety net, providing guidelines and confidence as I modify components, add new features, or refactor the code base. Now I can start creating my toggle button. By developing until all tests pass, giving me confidence that the component is in fact complete.

I would add a role attribute of Button, enforce that the label property is provided, and set the tab index attribute to 0. I can trust that accessibility violations won't come back to bite me months from now, as I edit my component or add new features.

Of course, there's still a glaring issue here. Even skilled front-end developers may not always know which accessibility requirement to test for each component they build. While a button is relatively simple, the true value of unit testing emerges with more complex components. These include managing focus in composite components like radio groups, hiding inert background from assistive technologies in overlays, and let's not even get started on carousels.

Moreover, creating a comprehensive suite of tests is a time-consuming task that is often dropped in favor of actual component development. To address this and actually make accessibility tests easy, we at Advanced have developed an SDK called the Unit Tester. It automates the creation of accessibility tests for developers. You simply call one function, like AnalyzeToggleButton, and the SDK handles everything, finding the right requirement for that pattern, making sure your code supports screen reader and keyboard operation.

The Unit Tester integrates with your Test Runner, VTest in my case, and leverages tools like VS Code extensions or CI pipelines to embed accessibility into your existing development workflow, assuring your components remain accessible over time. Designed by developers for developers, it aims to make accessibility approachable, eliminating the time and headaches typically required to get it right.