Web accessibility and the European Accessibility Act: what your QA team should test

Short answer: the European Accessibility Act (EAA) has applied since 28 June 2025 and requires many consumer-facing digital products and services in the European Union to be accessible. In practice, teams aim for WCAG 2.2 level AA. Automation catches only part of the problems, so you need to combine automated tests with manual review.

This article is a technical QA guide, not legal advice. To know whether the regulation applies to you and to what extent, consult a specialist.

What the EAA is and who it can affect

It is a European directive requiring accessibility in certain products and services, including e-commerce, banking services, passenger transport, telecommunications and e-books. It includes exceptions, for example for microenterprises providing services. It can also reach companies outside the EU that sell to European consumers, which matters to many businesses exporting digital services.

The technical reference is the European accessibility standard (EN 301 549), based on the WCAG guidelines. Today the safest approach is to aim for WCAG 2.2 AA.

What automation catches (and what it doesn't)

Tools based on axe-core find objective problems well: images without alternative text, insufficient contrast, unlabeled fields, incorrect ARIA roles. But many things no tool can judge on its own, such as whether alternative text is meaningful, whether the focus order makes sense or whether an error message is understandable. Common estimates indicate that automation covers only a fraction of real problems, so it is not enough on its own.

An automated test with Playwright and axe

import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("the home page has no detectable WCAG violations", async ({ page }) => {
  await page.goto("/");

  const results = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa", "wcag21aa", "wcag22aa"])
    .analyze();

  expect(results.violations).toEqual([]);
});

This kind of test, run in CI over the main pages and flows, keeps obvious regressions from slipping in.

Manual checks you can't skip

1. Keyboard-only navigation: can you reach everything with Tab? Is focus visible and in a logical order? Are there no "keyboard traps"?
2. Screen reader: walk through a key flow (sign-up, purchase) with NVDA, VoiceOver or TalkBack and confirm that what's announced makes sense.
3. Zoom and reflow: at 200% zoom or on small screens, is the content still usable without horizontal scrolling?
4. Forms and errors: clear labels, specific error messages associated with the field.
5. Non-text content: meaningful alternative text, captions on videos and alternatives to visual-only or audio-only content.
6. Touch targets and motion: minimum control sizes and alternatives to complex gestures.

How to organize it in a team

• Integrate axe into CI for critical flows and block Pull Requests with new violations.
• Include accessibility in the definition of "done" of every user story.
• Schedule a manual audit before major launches and periodically.
• Document what you know and what you fix: traceability helps with any requirement.

Well-done accessibility doesn't just reduce regulatory risk: it also improves the experience for every user and tends to have a positive impact on SEO.

To integrate these checks into your suite, see what to automate first and how to avoid unstable tests.

Is your product sold in Europe and you want to know how far you are? Let's talk and we'll scope an accessibility assessment.