Beyond compliance: Building accessibility into quality with test automation

Accessibility matters, now more than ever before.

Across most organizations, accessibility is often introduced through compliance, and regulations like the European Accessibility Act (EAA) are making this a legal requirement for organizations serving the European market. Meeting these rules not only reduces legal risk, but also sets a baseline for inclusivity.

However, accessibility goes beyond meeting regulatory obligations.

Digital products increasingly shape how people work, communicate, learn, and participate in society. When those products are inaccessible, they exclude people, not because of a lack of ability, but because of avoidable design and implementation decisions. Building accessible software is a way of acknowledging that people experience technology differently, and that those differences deserve respect.

It also makes perfect business sense: removing barriers expands your audience. And the same improvements often lead to clearer interfaces, more robust interactions, and better experiences for everyone. That’s no coincidence of course, because accessibility overlaps heavily with usability. Captions help in noisy environments, good focus management supports keyboard and power users, and clear structure improves comprehension.

In practice, accessibility raises the overall quality bar of a product.

As a part of Cycos, an Atos business, we have been part of project-based services in software development, testing, DevSecOps, software architecture, and consulting where we deliver tailored solutions across industries. And in this article, we discuss how you can add accessibility checks in test automation to tools that your team may already have in use.

This includes a practical comparison of axe-core and IBM Equal Access (IBM EA) — two leading automated accessibility testing engines, and how accessibility testing choices can influence product quality, compliance posture, and development velocity directly. This can go a long way in helping your organization take an accessibility-first approach in building and adapting future-fit systems.

Here’s how.

Getting accessibility right the first time

Accessibility cannot be a last-minute checkbox. It needs to be considered throughout the product lifecycle. Leaders should start by capturing accessibility requirements early, carry them into design (layout, interactions, and structure), implement them in code (correct semantics and predictable behavior), and validate them continuously in testing.

If accessibility is only addressed after problems show up, fixes tend to be slower, more expensive, and more frustrating. Retrofitting often means undoing design or architectural choices that would have been easier to get right in the first place. For developers, this means building accessibility into everyday work, simply by following best practices, understanding how assistive technology reads your UI, and checking both the code and the rendered result as you go.

Automated accessibility testing: Early signals, not a silver bullet

A practical way to support this end-to-end approach is with automated accessibility testing. You can run these checks inside your existing workflows and get fast feedback as code changes.

However, it’s important to be clear about the limitations of this.

Automated checks usually catch only a part of the problems — often estimated at 20%–30%. They do not replace manual testing, expert reviews, or testing with assistive technologies and real users. Also, automated tests are early warnings. They catch common, well-defined issues quickly and consistently, before they reach production. This helps teams avoid regressions and reduces the cost of fixing issues later.

Think of automation as a guardrail, not a final answer.

Integrating accessibility tests into existing toolchains

We have created practical examples that combine accessibility checks with the tests developers are already running. They show unit test integration, end-to-end (E2E) integration, or both, depending on what you need.

The goal isn’t to add a brand-new process. It’s to improve what you already do, so you get better coverage without slowing teams down.

Scope

The tool comparison in the follow-up post isn’t meant to be exhaustive. We focus on a selection of widely used tools that we’ve applied across multiple customer projects, and we highlight the trade-offs we’ve encountered in practice. Most of the tools we cover are designed to run offline as part of your test suite (local builds, test environments, and CI pipelines), and don’t require the system under test to be publicly reachable from the internet. This intentionally excludes many website/cloud-based accessibility scanners that crawl public URLs.

Integration into unit tests

Unit-level accessibility tests are a good fit for component-based frontends. They catch many structural issues early, while the code is still easy to change. Many problems start inside UI components, such as missing labels, wrong roles, missing ARIA, unlabeled form fields. Unit tests help stop them from spreading across the app. These also work best for rules you can check from a rendered markup: semantic HTML, ARIA roles and attributes, label associations, heading order, and basic contrast checks (within jsdom’s limits).

Both vitest-axe and jest-axe are thin wrappers around axe-core, where vitest-axe started off as a fork of jest-axe. The flow is simple: render the component, run axe-core on the DOM, and fail the test if it reports violations. The reports are structured, which makes them easy to review in CI and works well with snapshot-style workflows.

Integration in Vitest

Vitest is popular in modern toolchains due to its speed, native ESM support, and integration with Vite. With vitest‑axe, accessibility checks can run directly on component output. Vitest supports multiple environments: jsdom, happy‑dom, and most importantly browser mode via Playwright, which allows accessibility tests to run in a real browser instead of jsdom.

Running axe-core in a real browser provides more accurate rendering, better support for browser APIs, and a more realistic evaluation of CSS‑dependent or shadow‑DOM‑based components. Typically, teams choose browser mode when jsdom cannot represent component behavior accurately or when higher‑fidelity checks are needed without the overhead of full E2E tests.

Common Vitest patterns include using jsdom for fast checks, Playwright for high-fidelity checks, global axe configuration, component-level tests, and CI enforcement.

Integration in Jest

Jest differs architecturally from Vitest. It uses jsdom as the default environment, which requires no additional setup and works predictably with axe-core. However, Jest does not support running tests in a real browser.

Jest-axe provides an axe function adapted to Jest’s async model, custom matchers like toHaveNoViolations (same as vitest-axe), and integration with Jest’s assertion and reporting system.