Introduction
Since 28 June 2025, the European Accessibility Act (EAA) has applied across the European Union. Digital accessibility is no longer a “nice to have” that gets pushed to the next quarter – for a large class of products it is a legal requirement, and the practical benchmark regulators point to is WCAG 2.2 level AA.
This guide explains what the EAA actually asks for, what WCAG 2.2 compliance looks like in a real product, and how to audit your own interface before an inaccessible screen turns into a complaint, a blocked procurement process, or a lost contract.
Who the EAA actually covers
The Act does not apply to every website on the internet. It targets consumer-facing digital products and services, including:
- E-commerce and online stores.
- Banking and financial services.
- Transport and ticketing.
- E-books and reading apps.
- Telecoms, and a growing list of consumer digital services.
Two details catch teams off guard. First, a product is in scope regardless of where the company is registered – what matters is whether you sell to consumers in the EU. A US or UK company shipping to European customers is covered. Second, micro-enterprises get some relief, but most funded startups do not qualify for it.
What “compliance” means in practice: WCAG 2.2
The EAA sets outcomes, not code rules. The technical standard everyone lands on is the Web Content Accessibility Guidelines, built on four principles usually shortened to POUR:
- Perceivable – content must be available to the senses. Text alternatives for images, captions for video, sufficient colour contrast.
- Operable – the interface must work with a keyboard, not only a mouse or touch.
- Understandable – behaviour should be predictable and controls clearly labelled.
- Robust – the product must work with assistive technology such as screen readers.
WCAG 2.2 added nine new success criteria on top of 2.1, covering focus visibility, alternatives to dragging, consistent help, and easier authentication. Level AA – the level the EAA effectively expects – works out to roughly 50 success criteria in total.
The failures we see most often
Across audits, the same handful of issues show up again and again:
- Colour contrast below 4.5:1 (criterion 1.4.3) – usually light grey body text or low-contrast buttons that looked good in the design file.
- Keyboard traps (2.1.1) – modals, date pickers, and custom dropdowns a keyboard user can enter but not leave.
- Missing form labels (1.3.1, 4.1.2) – placeholder text used instead of a real label, so a screen reader announces nothing useful.
- Images without meaningful alt text (1.1.1) – either empty, or a filename.
- Focus that disappears while tabbing (2.4.7) – the default outline removed in CSS and never replaced.
None of these are exotic. They are the cheap ones to fix – and the easy ones for a complainant to demonstrate.
How to check your product
1. Start with an automated scan
Tools such as Lighthouse and axe will surface contrast failures, missing labels, and broken landmark structure in seconds. Treat that output as triage, not sign-off. Automated testing reliably catches only a minority of WCAG criteria – it cannot tell you whether your alt text is meaningful or whether your checkout flow can actually be completed with a keyboard.
2. Then run a manual audit
The real work is manual: navigating the product with a keyboard only, and again with a screen reader, following the journeys that matter commercially – sign-up, search, checkout, support.
The useful deliverable is not a colour-coded score. It is a list that ties each problem to a specific success criterion (for example 1.4.3 Contrast (Minimum) or 2.1.1 Keyboard), with a severity rating, the associated EAA legal risk, a remediation note, and an honest effort estimate. That is the difference between a report your team can act on and a PDF that sits in a shared drive.
For teams shipping to the Polish market, we built WCAG Expert – a dedicated WCAG 2.2 accessibility audit service that maps every finding to its exact success criterion and translates it into legal-risk and remediation terms. You can also check any page for free in about 30 seconds before deciding whether a full audit is worth it.
Treat it as product work, not paperwork
The teams that handle this well do not run a one-off compliance project. They fold accessibility into the definition of done:
- Keyboard testing becomes part of QA, alongside browser testing.
- Contrast checks happen in design review, before a component is built.
- A periodic audit against WCAG 2.2 AA catches regressions as the product changes.
Done this way, accessibility costs a little on every sprint instead of a lot in one panicked quarter – and the result is a product more people can actually use. We have written about the same discipline applied to specific verticals in mobile banking accessibility requirements and multi-language and accessibility in hotel apps.
If you are unsure where your product stands against the EAA, an audit is the fastest way to replace guesswork with a list you can plan around.
