Accessibility Testing with React Testing Library

As React applications mature, accessibility often becomes reactive rather than architectural. Teams add ARIA attributes late in development, write visual tests that pass, and assume that if the UI looks correct, it is accessible. But accessibility is not a visual concern; it is a semantic rendering contract. Assistive technologies do not “see” components. They consume roles, names, relationships, and live-region updates that React commits into the accessibility tree.

React 19’s concurrent rendering model makes this coordination even more important. Suspense boundaries may pause regions. Transitions may defer updates. Optimistic UI may briefly show a provisional state. Throughout all of this, the accessibility tree must remain coherent. Focus must move intentionally. Live regions must announce meaningful state changes. ARIA relationships must remain valid across re-renders.

The actual problem we must solve is this:

How do we test accessibility in a way that validates semantic output and keyboard behavior, not implementation details or visual structure?

React Testing Library aligns naturally with this goal because it encourages querying the DOM the way assistive technology does: by role, label, and accessible name. When we test accessibility correctly, we are not “testing ARIA.” We are verifying that every meaningful render commit produces a synchronized semantic update. We also extend this contract with automated accessibility audits using tools like aXe, ensuring regressions are caught continuously in CI.

Imagine a component tree with two parallel layers. The first is the visual DOM that users see. The second is the accessibility tree composed of roles, labels, relationships, and live-region updates. Every time React commits a render, both layers update together. Suspense fallbacks, validation errors, and pending states must update not only the visible layer but also the semantic layer. Accessibility testing validates that these two layers remain synchronized during interaction and async updates.

Accessibility testing through semantics, keyboard flow, and ARIA state

Accessibility testing starts with semantic queries. Functions like getByRole, getByLabelText, and getByText operate on the accessibility tree rather than the internal component structure. When we use these queries, we’re asserting that roles and accessible names are correctly defined. If a query fails, it often indicates the component is missing a label, has an incorrect role, or isn’t accessible at all.

Keyboard navigation is part of the contract. A component that looks interactive but can’t be reached via Tab or activated with Enter is broken from an accessibility standpoint. Testing keyboard interaction verifies that focus order is predictable and that focus moves intentionally at workflow seams, such as after a modal opens or a validation error appears.

ARIA verification ensures state changes are communicated semantically. Attributes such as aria-invalid, aria-describedby, and aria-busy connect visible changes to assistive technology output. Live regions (role="status" or role="alert") announce dynamic updates. Testing this means asserting that the appropriate roles and relationships exist when state changes occur. ...