For years, accessibility lived on the someday list. You knew the alt text was thin and half your buttons were <div onclick>, and you filed it under "when we have time." The deadline was abstract, the enforcement was theoretical, and nobody was going to fine you for a missing label.
That era ended on June 28, 2025. The European Accessibility Act has been in force since that date, and 2026 is its first full year of active enforcement. The first lawsuits were filed in France in November 2025, national market-surveillance authorities are ramping audits through this year, and the statutes put real money behind them: fines of up to €60,000 in Ireland and up to €900,000 in the Netherlands. No fine has been confirmed under the EAA yet — which is exactly what the year before enforcement finds its footing looks like. If you sell digital products or services into the EU, "someday" is now a date that's already passed.
What the standard actually asks for
The EAA points at an existing standard instead of writing a new one: EN 301 549, the European standard for ICT accessibility, which folds in WCAG 2.1 level AA as its web baseline. The technical bar is the one accessibility engineers have worked against for a decade (perceivable, operable, understandable, robust), now with legal teeth behind it.
Strip WCAG down to what it means for the DOM your app ships, and a large share of it comes down to one thing: every meaningful control has to announce what it is and what it's called. A button has to be a button, with a name. A form field has to have an associated label. An image that carries meaning needs a text alternative. A heading has to be a heading, not styled text pretending to be one. These are the accessible semantics, the roles and names and labels that assistive technology reads out loud so a screen reader user can operate your app without seeing it.
Most teams miss the part that makes this an engineering problem and not just a compliance one: those same semantics are what a good end-to-end test suite depends on.
Be honest about what testing does and doesn't do
Let me draw the line clearly, because it matters and because it's easy to oversell.
TestVibe is not an accessibility auditor. It does not produce a WCAG conformance report. It won't scan your color contrast ratios, tell you your compliance percentage, or certify you against the EAA. Conformance is a dedicated discipline. You need real audits, automated scanners like axe, and, crucially, testing with actual assistive technology and disabled users. Nothing on this page replaces that. If someone sells you "one-click EAA compliance," close the tab.
What functional end-to-end tests do is create standing pressure on the accessible semantics you already have. That's a narrower claim, but it's a true one, and it turns out to be worth a lot.
Accessible semantics are the locators
The most durable way to find an element in a browser test is by its accessible role and name, the same handle a screen reader uses. In Playwright terms, getByRole('button', { name: 'Place order' }) and getByLabel('Email address') don't reach into your CSS classes or your DOM nesting. They reach for the thing a human, sighted or not, would use to identify the control.
// Anchored to accessible semantics, not markup structure
await page.getByRole('button', { name: 'Place order' }).click();
await page.getByLabel('Email address').fill(email);
await expect(page.getByRole('alert')).toHaveText('Order confirmed');This is already the resilient locator strategy, the one that survives a CSS refactor, a component-library swap, or the DOM nesting one level deeper. We've argued before that role-and-name locators are the most robust way to write a test that doesn't break on cosmetic churn.
But look at what the locator requires to work. getByRole('button', { name: 'Place order' }) can only find that button if the button is a real button (or has role="button") and exposes the accessible name "Place order." The day a developer replaces it with a clickable <div>, drops the label, or nukes the aria-label in a refactor, the locator returns nothing and the test fails.
That failure is the whole point. A control that loses its accessible name breaks the locator that was pointing at it, so the accessibility regression surfaces as an ordinary red test on the pull request that caused it. You don't need a quarterly audit to find out that a control lost its name. Your suite tells you the same day the change lands, in CI.
Accessibility debt and testability debt are the same debt
What makes an app testable and what makes it accessible are mostly the same properties. An app that's hard to write stable tests against (where you're forced into nth-child selectors and brittle class chains because nothing has a stable, meaningful handle) is almost always an app that's hard to use with a screen reader, for exactly the same reason: there's no semantic surface to grab onto. An app where every control has a clear role and a stable accessible name is one you can both test cleanly and navigate without a mouse.
So the two debts move together. Give a control a proper role and name to make it testable, and you've made it more accessible at the same time; fix a missing label for accessibility, and you've made a more stable locator possible. That's rare in engineering, because compliance work and quality work usually compete for the same budget. Here they're the same work.
This is also why accessibility fits naturally into a shift-left quality posture. You catch semantic regressions continuously, on every change, as a byproduct of tests you were going to write anyway, instead of scrambling to fix them all in the week before a launch audit. Repairing a broken label on the pull request that introduced it costs a fraction of what it costs to find it three months later.
Keyboard flows are just test scenarios
There's a second WCAG pillar that translates cleanly into tests: operability without a mouse. Every interactive path in your app has to be reachable and completable with a keyboard alone: tab to the field, type, tab to the button, press Enter. For a lot of teams this is the most quietly broken part of their UI, because nobody on the team drives the app by keyboard, so nobody notices when a modal traps focus or a custom dropdown eats the arrow keys.
You can turn that into a regression test by describing it in plain language, the same way you'd describe any other flow. "Open the login form, tab to the email field, type the address, tab to password, type it, press Enter, and confirm the dashboard loads." When you write that as a test description, you get a generated Playwright scenario that exercises the keyboard path and asserts on the outcome with a web-first assertion that retries until the dashboard is actually there. Break focus management later, and the scenario goes red.
Again, this is not a WCAG audit. It's a targeted regression check on the specific keyboard journeys you decided matter. And the specific journeys that matter are exactly where the real complaints and the real lawsuits come from: the checkout that can't be completed without a mouse, the sign-up a screen reader user can't finish. Lock those down as tests and they stay locked.
The honest bottom line
If you have EU customers, you need a proper accessibility program — audits, scanners, assistive-technology testing, ideally disabled users in the loop. Nothing here changes that. Treat any tool that claims to be your compliance program as a red flag.
What functional tests give you is a floor that doesn't erode. Once your suite is anchored to roles, names, and labels, your accessible semantics can't quietly regress without a test noticing, because those semantics are what the tests hold onto. The cheapest layer of defense here is one you were probably building for stability reasons anyway; point it at your semantics and it pulls double duty for compliance too.
Want tests that anchor to the accessible roles and names your users actually depend on, so a semantic regression fails the build the same day it lands? Get early access, or read how resilient locators keep a suite stable while it does it.