If you want an accessible product, your best friend is not a last-minute audit. It is your testing strategy — and whether your tests reflect how real users experience your product.
Real accessibility is not only about fixing issues. It is about preventing them.
Testing Library Has an Accessibility Principle Hiding in It
Kent C. Dodds and the Testing Library team have a guiding principle:
The closer your tests are to the way your software is used, the more confidence they can give you.
Most teams read that as testing advice. It is also an accessibility principle — and that connection is what most teams miss.
A Different Question
Testing Library is not just a different API. It is a different question.
Old tests asked:
Did this render correctly?
Testing Library tests ask:
Can the user actually use this?
That shift changes what tests catch.
Why Integration Tests Carry More of the Weight
Kent C. Dodds also makes a case for the Testing Trophy — a counter-take to the old Testing Pyramid. The pyramid put unit tests at the foundation; the trophy puts integration tests at the center.
That re-weighting matters for accessibility.
A unit test for a form-validation function tells you the function works. An integration test for the form tells you the form works — that the inputs have labels, the submit button has a name, error messages are announced, focus moves where it should.
The accessibility surface lives in the integration, not in the units.
The more your test suite leans toward integration, the more accessibility regressions it catches before they ship.
Why That Catches Accessibility Issues
Testing Library queries elements the way assistive tech does — by role, by accessible name, by label. A button without a name has no getByRole('button', { name: /continue/i }) to bind to. The test cannot find it. The test fails.
That is the prevention mechanism. Not a checklist. Not an audit. The accessibility regression gets caught at the same step every other regression gets caught — when the test breaks.
If Your UI Is Hard to Test, It Is Probably Hard to Use
If you can't write screen.getByRole('button', { name: /continue/i }) cleanly, something is off. Maybe the button isn't semantic, the name is unclear, the intent isn't obvious, or the UI depends too much on visuals.
That is not just a testing issue. It is a product issue.
If Your Test Can Buy the Product, Your Users Probably Can Too
If your test can buy the product, your users probably can too.
If your test can find a product, understand it, add it to cart, and complete the flow, you are closer to a usable experience than any audit could verify. If it cannot, pay attention — that friction is real, and your users are feeling it.
What Prevention Actually Looks Like
Testing Library will not make your product accessible on its own. It will not replace screen reader testing, keyboard testing, or human judgment.
But it shifts where the work happens. Issues that used to surface in audits start surfacing in pull requests. Issues that used to surface in pull requests stop being shipped.
The audit catches issues. The PR catches more. The test never lets them in.