WCAG requirements in the EU: who is covered since June 2025, and what it means

Web accessibility moved from being a public-sector obligation to something a large part of European business is covered by. The change took effect on 28 June 2025, and plenty of companies have not noticed yet.

This guide covers who is in scope, what the requirements actually are, how they are enforced, and how to start without beginning with the most expensive step.

If you just want to see where your site stands, you can run a scan and get the automatically detectable issues listed against the WCAG criteria they fall under.

The short version

• The requirement is WCAG 2.1 level AA. Not A, not AAA.
• Public sector bodies have been covered since 2019 and must publish an accessibility statement.
• Private businesses in a range of sectors have been covered since 28 June 2025 under the European Accessibility Act.
• Automated tools find 30-40% of issues. The rest requires manual testing.

Who is covered

Public sector

The Web Accessibility Directive (2016/2102) has required public sector websites to meet WCAG 2.1 AA since 2019, and mobile apps since 2021, across member states. Bodies in scope must also publish an accessibility statement describing how well the site conforms, which parts do not, and how users can complain.

Private sector

This is what changed. The European Accessibility Act (Directive 2019/882) has applied since 28 June 2025 and covers a range of consumer-facing products and services:

• E-commerce — online shops selling to consumers
• Consumer banking and payment services
• Passenger transport: ticketing, travel information, apps
• E-books and dedicated reading devices
• Telecommunications and access to audiovisual media services
• Computer hardware and operating systems, self-service terminals, payment terminals

If you run a consumer-facing online shop in the EU, you are very likely in scope. That is the group most often caught by surprise.

The micro-enterprise exemption covers businesses with fewer than 10 employees and under EUR 2 million in annual turnover or balance sheet — and it applies to services, not products. It is narrower than many assume, and "we're a small company" is not by itself an answer.

There is also a disproportionate burden exemption, but it has to be documented and assessed case by case. It is not a general opt-out, and an undocumented appeal to it will not hold.

This is a technical guide, not legal advice. Implementation differs by member state, so if you are unsure whether you are in scope, get it confirmed by your national authority or a qualified adviser — the boundary depends on what you sell and to whom.

What is actually required

Both regimes point at the harmonised European standard EN 301 549, which for web content incorporates WCAG 2.1 level AA.

WCAG 2.2 was published in October 2023 and is backwards compatible: meeting 2.2 means meeting 2.1. There is no reason to build something new against 2.1 when 2.2 is current.

The criteria sites most often fail are not exotic:

• Contrast (1.4.3) — 4.5:1 for body text, 3:1 for large text. The most common failure on the web, usually a design decision nobody measured.
• Non-text content (1.1.1) — meaningful images need alt text; decorative images need an empty alt="".
• Keyboard (2.1.1) — everything reachable and operable by keyboard, with no traps.
• Focus visible (2.4.7) — removing focus outlines with outline: none without replacing them is a direct failure.
• Name, role, value (4.1.2) — icon-only buttons with no accessible name fail this constantly.
• Labels (1.3.1, 3.3.2) — a placeholder attribute is not a label.

A fuller walkthrough of the principles and criteria is in our WCAG reference.

How it is enforced

Public sector monitoring is carried out by a designated national body, which samples sites each year — typically a simplified, largely automated review across many sites plus an in-depth manual assessment of fewer. Results are published, and users can complain, which in practice is a faster route to attention than the scheduled sample.

For private businesses under the EAA, market surveillance sits with the relevant national authorities depending on the product or service, and consumers can file complaints.

Enforcement runs through supervision and orders to remediate, not automatic fines. In practice you get a deadline, with further sanctions only on continued non-compliance.

That sounds mild, and in a sense it is — but it is worth understanding where the real cost sits. The risk is not a surprise fine. The risk is holding an order with a short deadline on a site where accessibility was never part of the process. Fixing contrast, labels, and focus handling across an entire design system under time pressure is far more expensive than doing it gradually, and it lands at the same time as everything else.

Then there is the part that is not about rules: roughly one in six people worldwide has some form of disability. A shop that cannot be operated by keyboard loses sales regardless of what the law says.

Automated testing gets you 30-40% of the way

This is the most important expectation to set, and it applies to the tool I build too.

Automated testing reliably catches roughly 30-40% of WCAG issues. That figure is consistent across the field. Any tool — including Sitecheck — that implies a green scan means compliance is misrepresenting it.

What automation is good at: colour contrast, missing alt, missing form labels, empty buttons and links, invalid ARIA, heading order, missing page language, duplicate IDs. Objective, machine-checkable, and very common — so continuous scanning is genuinely worth doing.

What it cannot do: judge whether alt text is meaningful rather than merely present, whether focus order is logical, whether an error message actually helps, whether a custom widget behaves sensibly with a screen reader, or whether captions are accurate.

Sitecheck runs axe-core and QualWeb, both open-source implementations of the WCAG success criteria, so results map to named criteria rather than a score someone invented — and it does not claim to cover the manual half.

A realistic order to do this in

1. Run an automated scan for the overview. It is free and takes a minute. Start here.
2. Fix the objective failures. Contrast, alt text, labels, empty buttons. This is where the volume is, and it is the cheapest part.
3. Tab through the site with the keyboard. No mouse. Can you reach everything? Can you see where you are? Can you get back out of menus and modals? Twenty minutes here reveals more than any tool.
4. Zoom to 200% and check the layout holds and nothing disappears.
5. Try a screen reader. NVDA is free on Windows, VoiceOver is built into macOS and iOS. The first time is uncomfortable, and that is the point.
6. Set up continuous scanning so new issues are caught at deploy rather than at audit.
7. Get a manual review from someone who does this daily, if you are in scope and the site is of any size. Steps 1-6 get you a long way, but the last part needs a human.

The order is deliberate: the cheap objective fixes first, so you are not paying consultant hours to be told your contrast is too low.

Common misconceptions

"We have an accessibility overlay, so we're covered." No. Overlay widgets that layer over a site do not fix the underlying problems, and several have been sharply criticised by disabled users and the accessibility community. They have been the subject of litigation in the US precisely because they were marketed as compliance.

"Our site is new, so it's probably fine." New is not the same as accessible. Modern component libraries and design systems introduce accessibility problems about as often as they solve them — especially custom dropdowns, modals, and date pickers.

"We'll fix it if someone complains." You can choose that. But a complaint arrives with a deadline, and the work does not get smaller for waiting.

"AAA is better, so let's aim for that." The W3C states plainly that AAA cannot be required across entire sites. Target AA, and pick individual AAA criteria where they genuinely help your users.

Accessibility and SEO pull the same direction

A fair amount of this work pays off twice, because search engines and assistive technology read the same semantics:

• Proper heading structure serves both screen reader navigation and content understanding.
• Alt text describes images to assistive technology and to image search.
• Descriptive link text helps both.
• Captions make video both accessible and indexable.

That is not an argument for doing accessibility for SEO reasons. But it is a useful argument when the work has to compete for budget.

Getting started

The usual outcome is postponement, because the topic feels large. It does not have to be at the start: run a scan, fix the objective failures, and tab through the site with the keyboard. Those three things move more than most people expect.

Scan your site and see what comes up.