Braaf
New AI CMS: farewell dashboards Say hello

[email protected] · Braaf. · KvK 99996251

All articles

What the accessibility act requires of your web shop

Webshops

Accessible isn't extra, it's finished

The law doesn't look at how your site looks, but at whether everyone can use it.

Of all the laws that have landed on your plate in recent years, this one sits closest to my work — because building accessibly is exactly where design and code meet. And unlike most rules, the deadline here isn't approaching: it has already passed. Since 28 June 2025 the European Accessibility Act applies, introduced in the Netherlands as the Implementatiewet toegankelijkheidsvoorschriften. No transition period, and the ACM has already started checking. Below: what the law actually asks of you, where it goes wrong in practice, and where you start.

Who does it apply to?

Short version: if you sell anything to consumers online, almost certainly to you. The law targets e-commerce services — web shops, booking platforms, anything with a checkout or account area. A purely informational site without transactions usually falls outside it, and so does a B2B platform in many cases.

There's one exception: micro-enterprises with fewer than ten employees and annual turnover under two million euro. Above that, the law simply applies. And it doesn't matter that you only sell within the Netherlands — the regulator looks at the Dutch market, so a Dutch web shop is just as much in scope.

What the law actually asks

The standard is called EN 301 549, but in practice it comes down to WCAG 2.1 level AA: the standard the web world has worked with for years. If your site passes a clean WCAG 2.1 AA check, you're in good shape. What it boils down to:

Works without a mouse

Everything has to be operable with the keyboard — tabbing through a form, opening a menu, checking out. And you must always be able to see where you are: a visible focus outline around the element that's up. Together with the screen reader, this is what the ACM looks at first, because getting it wrong shuts out the largest group.

Readable to a screen reader

A blind visitor "hears" your site through software that reads the code aloud. That software needs tidy structure: a logical heading order, alt text on images that actually means something, labels on your form fields, buttons that say what they do. It isn't an extra layer — it's just decently built HTML.

Enough contrast, don't lean on colour

Text has to stand out enough against the background — light grey on white doesn't cut it. And information may never come across through colour alone: a red border on a required field helps no one who can't tell colours apart. Add a word to it too.

Forms that think along

A label on every field, and an error message that explains what went wrong and where. "Something went wrong" isn't an error message. At checkout this counts double — that's where someone who can't get further drops off, and that's exactly the customer you already had.

Media with an alternative

Video with spoken words should be captioned, a standalone audio clip gets a transcript. For a couple of product videos that's a manageable job; with a whole media library it's structural work.

The statement and the reporting duty

Alongside the site itself there are two things on paper. The first is an accessibility statement on your website: a short, findable page in plain language that says how accessible your service is and where someone can report a problem. Meant for your visitor, not for the lawyer — so no PDF, just a web page. The ACM checks that it's there.

The second is the reporting duty. If your site doesn't fully comply yet, you have to report that yourself to the ACM — what's off and when you'll have it fixed. Critical problems within a week, the rest within a month. Flagging that you're working on it is a better position than waiting for a complaint to come in.

Where it breaks down in practice

The overlay button

There are widgets that promise to make your site "accessible in one click" — a floating icon with sliders for contrast and font size. They don't work. The underlying problems stay put, screen reader users trip over them more often, and they don't make you compliant. It's the expensive way to fix nothing.

A statement without changing the site

Publishing an accessibility statement while nothing about the site itself changes is a note on the door saying it's a mess inside. The statement describes reality, it doesn't replace it.

Right once, then never again

Accessibility isn't a project with an end date. Every new product page, every plugin update, every banner dropped in between can break it again. Without a fixed moment when someone rechecks it, last year's audit isn't right this year.

And the fines?

They can run up to 900,000 euro or 1% of annual turnover. But Dutch enforcement is "dialogue first": first a conversation, then a period to fix it, and only then sanctions. None have been handed out yet. Still, that's not the reason to do it — the real gain is elsewhere. One in three people in the Netherlands has a disability, and that's custom that currently drops off at an unreachable checkout button. The same tidy code that helps a screen reader also happens to help Google — and the AI assistants your customers increasingly put in front of searching. Build it right once, win three times.

Where do you start?

With a baseline measurement. You don't have to be perfect in one go — you need to know where you stand. Start with the two things that have the most impact, which are also the two the ACM looks at first: can you get through the whole site with the keyboard, and does a screen reader read your checkout out neatly? That exposes the bulk of the snags.

Then the rest: contrast, forms, media, and the statement on your site. For most web shops it isn't a rebuild but a series of targeted fixes. And whatever does turn out to be a real rebuild, you know that now — instead of at the moment a report comes in.