WCAG compliance — who it actually binds and what has to be done

For years digital accessibility in Europe was a matter for public bodies. Directive (EU) 2016/2102 covered the public sector; private firms treated WCAG as good practice — worth doing, not required.

On 28 June 2025 that changed. Obligations came into force for part of the private sector, with penalties set in national law and authorities to impose them.

The scale of the problem is not niche. WebAIM's annual analysis of a million home pages found in 2026 that 95.9% of them have detected WCAG violations — up from a year earlier. The average number of errors per page rose from 51 to 56.1. After years of slow improvement, the trend reversed.

This text answers three questions in order: does the obligation reach you, what exactly has to be done, and how much free tools catch. We start with the first, because the commonest claim on this subject — "everyone except microenterprises is covered" — is untrue.

Where the new obligation came from

The basis is Directive (EU) 2019/882, the European Accessibility Act. It exists to harmonise the internal market: a manufacturer who adapted a product in one country should not have to adapt it again in another.

Every Member State transposed it, and the obligations apply from 28 June 2025 across the EU. Article 2 sets the scope as a closed list of products and services — and that closed list is the most important thing here.

Four dates, two instruments

These are two different regimes, and mixing them up is the commonest source of confusion. An authority, a school or a library has been bound since 2020, under the older instrument. An online shop since 2025, under the newer one.

Who enforces, and what non-compliance costs

The EAA sets no penalty amounts. Article 30 requires Member States to lay down penalties that are "effective, proportionate and dissuasive". The consequence is easy to miss: the number that applies to you comes from the law of the country judging you, not from the directive — and national figures differ by orders of magnitude. A penalty quoted in an article written for one market tells you nothing about your exposure.

One example we could verify at source: Germany's transposing act, the Barrierefreiheitsstärkungsgesetz, sets fines of up to 100,000 EUR for serious breaches — a non-accessible product placed on the market, a non-accessible service, a missing CE marking — and up to 10,000 EUR for information and labelling duties. The federal states' market surveillance authorities enforce it.

Supervision is not one body either. Products fall under market surveillance; for services each Member State designates the authority that checks compliance, and in regulated sectors that is usually the sector's own regulator. A bank answers to its supervisor, not to a disability agency.

Does the obligation reach you specifically

The directive covers a closed list of products and services aimed at consumers. It does not cover "firms" in general.

The services include:

• e-commerce — online shops, marketplace platforms, booking systems
• consumer banking and financial services
• passenger transport services — tickets, timetables, mobile apps
• electronic communications services
• services providing access to audiovisual media services
• e-books and dedicated reading software

Plus a list of products: general-purpose computer hardware and its operating systems, smartphones and other consumer terminal equipment, self-service terminals such as payment terminals, cash machines and ticketing machines, and e-readers.

The product–service distinction is not a formality. A product's manufacturer, importer and distributor carry different obligations from a service provider. A firm selling its own device online can be caught from both sides: as a shop and as an operator placing a product on the market.

The microenterprise exemption and its trap

Microenterprises are exempt — fewer than 10 people AND an annual turnover or balance sheet total not exceeding 2 million EUR. Both conditions together.

But the exemption has an edge that is easy to miss: it covers providing services, not placing products on the market. A microenterprise running an online shop is exempt as a service provider. One putting a terminal or an e-reader on the market is not.

A table you can send to the board

The last two rows and the one about B2B firms are the most important here, because they say what the industry dislikes saying: many readers have no obligation at all. A machine manufacturer selling only to other firms is not covered. It may want accessibility for other reasons — we come to those — but it does not have to.

WCAG, or how accessibility is measured

The directive does not describe what an accessible page looks like. It points to the harmonised European standard EN 301 549, which names WCAG at level AA as the technical standard.

WCAG rests on four principles, POUR:

• Perceivable — information can be received whatever sense is available. A product photo has a description, a video captions, a sale price enough contrast to read with weaker eyesight. Test: turn images off and see whether the page still says what it meant to.
• Operable — the interface works without a mouse, without a time limit and without traps. Test: go through the purchase process on the Tab key alone.
• Understandable — content and behaviour are predictable. A field has a label that does not disappear, an error message says what to correct, the menu looks the same on every page.
• Robust — the code is correct enough for assistive technologies to cope. The one an automated tool checks well, and therefore the one most teams have under control.

There are three conformance levels: A, AA and AAA. The legal reference point is AA — A is a minimum nobody treats as sufficient alone, and AAA is sometimes impossible across a whole site.

WCAG 2.1 or 2.2

The legal requirement today is WCAG 2.1 AA, through EN 301 549 V3.2.1 of March 2021 — the version cited in the Official Journal, and that citation is what creates the presumption of conformity.

It is about to move. ETSI published EN 301 549 V4.1.1 on 2 September 2026, aligning the standard with WCAG 2.2 AA. Publication by ETSI and citation in the Official Journal are two different events, and at the time of writing the citation had not happened. So 2.1 AA binds now, 2.2 AA will bind.

WCAG 2.2 has been the W3C Recommendation since 2023 and adds nine success criteria, of which six sit at level A or AA and therefore matter in practice:

One change almost nobody writes about: criterion 4.1.1 Parsing was removed in 2.2. Duplicate id attributes stopped being a violation. If a report still counts them as errors, the report is older than the standard.

Building a new site, we would aim at 2.2 straight away — the extra effort is small and the reference point is moving there.

Six errors account for almost everything

The interesting thing in the WebAIM data is not that 95.9% of sites have errors. It is that six types of violation account for 96% of all errors detected.

That is good news dressed as a bad statistic. The repair is not bottomless — six things clear almost everything tools can detect at all. A second result from the same study confirms it: 20.5% of pages have five errors or fewer, and 30.4% no more than ten.

Three families of barrier

Visual. Missing alternative text turns a product photo into "image", and that is all a screen reader user hears. Contrast that is too low excludes not only people with low vision but anyone looking at a screen in sunlight. A separate category is information conveyed by colour alone — a red border round a field carries no content for someone who cannot distinguish that colour.

Navigational. A site that cannot be navigated with a keyboard is closed to some users entirely. A focus trap — a modal Tab cannot escape — can end the session for good. Then heading structure: if H1, H2 and H3 are chosen for looks rather than hierarchy, a screen reader loses the map of the page, because headings are its table of contents.

Multimedia. Video without captions excludes deaf users, and anyone watching without sound — which is how most mobile traffic watches. Audio description is harder and less often required, but material whose key information appears only in the picture does not work without it.

What this looks like in an online shop

Four places where e-commerce falls over:

• A field described only by a hint. <input placeholder="E-mail"> with no label looks clean and vanishes the moment the user types. Correctly: <label for="email">E-mail</label> beside the field.
• A button with no content. A bin icon in a <button> with no text and no aria-label is "button" to a screen reader. Nobody knows whether it removes the product or opens the basket.
• Focus with no outline. outline: none with no replacement of your own leaves a keyboard user with no idea where they are.
• An error message in colour only. A red border is not a message. A sentence saying exactly what is wrong has to appear beside it.

The fifth is contrast, which leads the table above at 83.9% — most often grey helper text, sale prices and labels under fields.

How much a free tool will catch

This is the part that audit sales pitches stay quiet about.

We ran Lighthouse 13.4.1 — built into Chrome, based on the axe-core engine — over our own site. One page scored 100 out of 100, the blog 96.

The score is pleasant but does not mean what it appears to. Lighthouse's accessibility category counts 76 audits. On our site 24 passed, 42 were marked "not applicable", and 10 as `manual` — meaning Lighthouse does not test them and leaves them to a person.

Among them, on our own site:

• whether interactive elements can be reached with a keyboard
• whether the tab order is logical
• whether the visual order matches the code order
• whether focus falls into a trap
• whether focus moves to content that has just appeared
• whether custom controls have labels and roles
• whether off-screen content is hidden from assistive technologies

One hundred out of one hundred in Lighthouse does not mean "WCAG compliant". It means the automatable part passed. A machine is excellent at counting contrast and missing alt attributes. It will not tell you whether the product can be bought without a mouse.

Four traps that will have you fixing working things

In that same audit of ourselves, three of our four manual findings turned out to be false alarms once checked against the documentation. We list them because anyone auditing under their own steam hits the same ones:

• `<label for>` works on `<button>`. A button is a labelable element, so a component with role="checkbox" can be described correctly without an aria-label.
• An element with `aria-hidden="true"` and `tabindex="-1"` is hidden on purpose. A hidden input under a UI-library component is not an unlabelled field.
• `placeholder` counts as an accessible name. A tool accepts it and reports no error — and it is still bad practice, because the name disappears after the first character.
• Criterion 2.4.1 is satisfied by landmarks or by headings. A "skip to content" link is recommended for keyboard users but not required if the page has a correct structure.

Implementation step by step

Step 1 — audit. Machine plus human, in that order. Free: Lighthouse in Chrome, the axe DevTools extension, WAVE. Then the keyboard test — the Tab key alone through the whole purchase process — and a screen reader: NVDA on Windows, VoiceOver on macOS, TalkBack on Android.

On the price of a commercial audit we have no European figure worth printing, so we will not print one. We can say where the spread comes from: a short expert review and a full UX audit with users are an order of magnitude apart, and both get called "an accessibility audit". Ask which one a quote covers.

The keyboard test sounds trivial and is the most revealing part of the audit. Put the mouse aside and Tab from the home page to order confirmation. Note three things: where you cannot see what the focus is on; where Tab jumps somewhere unexpected; where you got stuck. Fifteen minutes of that usually yields more than an entire machine report.

Step 2 — repair. The order follows from the WebAIM table: contrast, alternative text, field labels, link and button names, language declaration. Changes in HTML, ARIA attributes and styles — in most cases days of work, not months.

Step 3 — documentation. Public bodies have to publish an accessibility statement with the assessment result and a feedback mechanism. Private firms covered by the EAA have to make public an explanation of how the service meets the accessibility requirements. Neither is a box to tick — it is the document an inspector starts from.

Step 4 — maintenance. Accessibility decays with every content change, and this is the part most often skipped. An editor inserting a photo with no description undoes the developer's work. Somebody adding a banner with the text burnt into the graphic makes that text cease to exist for a screen reader. A new component goes into the shop without labels, because nobody asked for them in the ticket.

Three things stop this: a short training session for the editorial team on alternative text and heading structure, an "accessibility" line on the pre-deployment checklist, and one automated check in the build so obvious errors do not reach production. None is expensive. All are cheaper than a second audit in a year.

What can be done in the first week

If you do not yet have a budget for the whole process, the order is this:

• check the contrast of helper text, prices and labels — statistically the commonest error and the cheapest to fix
• add alternative text to photos that carry information; leave decorative ones with an empty alt
• Tab through the contact form and the basket, and restore a visible focus outline if the styles switched it off
• make sure <html> has a lang attribute

That is four of the six items in the WebAIM table. They do not produce compliance, but they remove most of what tools and users see first.

Two sources are worth knowing: the W3C Web Accessibility Initiative, which publishes techniques and a quick reference for every WCAG criterion, and the market surveillance or accessibility authority designated in your own country, which publishes guidance on the act that actually applies to you.

Why bother if the obligation does not reach you

If the table above put you on the "essentially no" side, three reasons remain to do it anyway.

The market. In 2024, 23.9% of people aged 16 and over in the EU reported a disability — a limitation in usual activities — 17.2% some limitation, 6.7% a severe one. This is Eurostat's self-reported activity-limitation measure, broader than a formal disability certificate, and worth using because every Member State collects it the same way. The age gradient is what matters commercially: 7.1% among people aged 16 to 24, 72.3% among those aged 85 and over. Not a niche — it scales with the age of your customers.

Convenience for everyone. Limitations can be temporary and situational. A screen in bright sun is a contrast problem. Noise on a train is a need for captions. One free hand is keyboard operation. Solutions designed for people with disabilities win in those situations too.

SEO. Correct heading structure, sensible alternative text, descriptive links and a language declaration are simultaneously WCAG requirements and signals indexing relies on. No magic — accessibility forces semantics, and semantics help a search engine.

What next

If you want to know where you stand and you are planning changes in the coming months — we will run an audit: 1,625 EUR net, the result in five working days, a report with a list of fixes, priorities and an amount against each item, plus an hour of discussion in the price. If you then decide on a new site or a rebuild with us, we deduct that amount from the quote.

If you would rather check for yourself first — two things with no registration: a self-audit checklist and a website speed test that shows Core Web Vitals for your address.

If you are still planning, accessibility is cheapest to build in during design — described in building a website step by step. How it looks in an online shop we cover in UX and UI in e-commerce, and the testing tools in the guide to website testing.