How to test for EAA accessibility compliance

Accessibility testing used to be the item that stayed at the bottom of the backlog without anyone feeling bad about it. That changed when the European Accessibility Act became enforceable in June 2025, and it changed again in June 2026 when a French court ordered Carrefour to make both its e-commerce site and its mobile app accessible, with six months to comply and fines behind the deadline.

Enforcement is real and it's moving. Sweden's Post and Telecom Authority started inspecting devices in late 2025 and has since opened e-commerce cases. If you sell to EU consumers, accessibility is now a test surface with a legal consequence attached, which means it needs to live in your pipeline rather than in an annual audit PDF.

Here's how to build that, and what the automated part can and can't do for you.

What the standard actually requires

For digital products, the EAA points at WCAG 2.1 Level AA by way of the harmonized standard EN 301 549. That's the bar. It covers the four principles you'll see referenced everywhere: content must be perceivable, operable, understandable, and robust.

Scope catches people out more than the standard does. The EAA covers e-commerce, banking, e-books, transport services, and telecoms, among others, and it covers the mobile app as well as the website. Carrefour got ordered on both. If your product has a mobile app, it's in scope, and mobile accessibility testing tends to be the half nobody set up.

Step 1: run automated scans, and know their ceiling

Start with axe-core. It's the de facto engine, it plugs into Playwright, Cypress, and most CI setups in a few lines, and it will find the machine-checkable violations: missing alt text, insufficient color contrast, form inputs without labels, missing document language, bad heading structure.

A Playwright integration is about as involved as this:

import AxeBuilder from '@axe-core/playwright'

test('checkout page has no WCAG AA violations', async ({ page }) => {
  await page.goto('/checkout')
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa'])
    .analyze()
  expect(results.violations).toEqual([])
})

Now the part that gets skipped in most vendor blog posts: automated scanning catches somewhere around a quarter to a third of real WCAG issues. That's not a knock on axe, it's a property of the problem. "Does this image have alt text" is machine-checkable. "Does the alt text describe the image usefully" is not.

Treat a clean automated scan as the floor. Anyone selling it as compliance is selling you something.

Step 2: cover keyboard navigation in your functional tests

The barriers that actually stop people using a site tend to be interaction failures rather than markup failures. Focus that disappears into a closed modal. A dropdown you can open but not escape. A custom component that works beautifully with a mouse and is inert to a keyboard.

Those are testable in the tools you already run, and they don't need a separate accessibility suite. Add keyboard paths to the journeys that matter most:

• Complete the primary conversion flow using only Tab, Shift+Tab, Enter, and Escape
• Assert focus moves into a modal when it opens and returns to the trigger when it closes
• Assert focus order follows visual order on any page with a multi-column layout
• Check that a visible focus indicator exists on every interactive element
• Verify error messages on form validation are associated with their inputs, not just rendered nearby

Adding these to existing specs is cheaper than building a parallel suite, and it has the side effect of making the tests better at catching normal bugs too.

Step 3: manual testing with real assistive technology

There is no way around this one. Somebody has to use the product with a screen reader. NVDA on Windows and VoiceOver on macOS and iOS cover most of what you need, and both are free.

You don't need to do it on every release. Quarterly on the core journeys, plus whenever you ship a new component pattern, is a defensible cadence for most teams. Write up what you did and when, because the documentation is a compliance artifact in its own right.

Budget for real users if you can. People who use assistive technology daily find things in ten minutes that a sighted developer with VoiceOver open will not find in a day.

Step 4: keep the evidence

Enterprise buyers and public-sector procurement now routinely ask for accessibility documentation at vendor selection and renewal. What they want: a conformance claim, an audit summary, and a remediation roadmap with dates on it.

That's a test management problem more than a testing problem. You need to be able to say which criteria were checked, by what method, when, and what the result was. A CI job that goes green and leaves nothing behind doesn't answer that. Run the accessibility checks as managed test cases with recorded outcomes, the same way you'd handle anything else with a regulator on the other end.

Where teams are actually losing ground

Re-testing of EU sites a year into enforcement found some basics moving backwards. Missing page language declarations, one of the easiest things to get right and one of the first things a screen reader depends on, went from 9% of sites in 2025 to 33% in 2026.

A regression like that on a one-line fix points at process, not knowledge. Somebody fixed it for the audit, then a redesign or a new framework default undid it, and no test was watching. Which is the whole argument for putting accessibility checks in CI rather than in a consultant's report: the report is a snapshot, and the code moves.

qtrl runs tests in real browsers, so keyboard paths, focus behavior, and the interaction failures that automated markup scanning misses can be covered as ordinary test cases rather than a separate accessibility project. Agent-driven exploration can walk those journeys and turn what it finds into repeatable coverage.

Every run is recorded with what it checked, which is the evidence trail procurement asks for and the thing that stops a fixed issue from quietly regressing two redesigns later. See how it works.