European Accessibility Act website compliance for Dutch webshops: find out if it applies, then fix it properly

What does European Accessibility Act website compliance mean for a Dutch business?

It means your consumer-facing webshop, booking flow or ordering app must be usable by people with disabilities, measured against a published technical standard, and that you tell customers how well it meets that standard. In the Netherlands the EU directive was brought into national law through the Implementatiewet toegankelijkheidsvoorschriften producten en diensten, which applies from 28 June 2025 and amends, among others, the Burgerlijk Wetboek and the consumer-protection enforcement act that ACM works under.

For most private businesses the relevant category is what the law calls an e-handelsdienst: an online service where consumers can conclude a contract over the internet. According to ACM's guidance on e-commerce accessibility, that includes webshops selling clothing, groceries, books or electronics, platforms for booking hotels, flights or concert tickets, and apps for ordering meals, a taxi or a babysitter. ACM is the supervisor for this group; other regulators handle banking, e-books, audiovisual media and passenger transport.

European Accessibility Act website compliance therefore has three moving parts. The first is technical: pages, forms and components that a keyboard user, screen-reader user or someone zoomed to 200% can operate. The second is informational: a published statement that describes conformance honestly. The third is procedural: knowing when a known problem has to be reported to ACM and fixed on a plan.

None of this is exotic engineering. It is careful front-end work, and it is exactly the kind of work a small team can do inside your existing codebase, which is what the rest of this guide covers.

Does the European Accessibility Act apply to my webshop?

It applies if consumers can buy, book, order, subscribe or reserve through your site or app and you are larger than a microenterprise. If both are true, treat European Accessibility Act website compliance as a current obligation, not a future project.

Run through these questions in order. Most Dutch owners have an answer within ten minutes:

• Do consumers conclude a contract online? A cart and checkout, a table reservation, a ticket purchase or a subscription sign-up all count. A brochure site with only a phone number generally does not fall under the e-commerce category.
• Is it business-to-consumer? ACM's page is framed around services offered to consumers. A pure trade portal where only registered companies order on account is a different situation; ask your lawyer if you sell to both.
• How big are you? Fewer than 10 people and annual turnover of at most 2 million euros is the microenterprise band ACM describes as exempt for services.
• Which channels are involved? The website, the iOS and Android app, and any embedded booking or ordering widget each form part of the service.
• Who operates the checkout? If a platform like a marketplace runs the transaction, some responsibility sits with them, but your own storefront pages remain yours.

If you land in scope, the next section on exemptions is worth reading before you budget anything, and if you are still deciding on a platform, our note on WooCommerce development in the Netherlands explains how theme choice affects later accessibility work.

Who is exempt? The microenterprise rule and the disproportionate burden route

Microenterprises that provide services are exempt from the EAA service requirements. ACM describes them as businesses with fewer than 10 people employed and an annual turnover of at most 2 million euros. Both limits matter: a nine-person shop turning over more than that band is not a microenterprise under ACM's description.

A second, narrower route is the disproportionate burden assessment. If meeting a specific requirement would cost unreasonably much compared with the benefit to disabled users, the law allows an exception, but ACM says you must report it, justify it carefully, name the parts affected, and have your written assessment ready even though you do not have to send it at once. This is not a general opt-out; it is a documented, part-by-part judgement that your lawyer should review.

Three practical warnings from our side of the keyboard:

• Growth moves you out of the exemption. A shop that hires its tenth person or crosses the turnover band needs a plan, and fixing an old theme under time pressure costs more than building accessibly from the start.
• Exemption from the law is not exemption from customers. Keyboard traps and unreadable contrast lose orders regardless of headcount.
• Suppliers matter. If you build a platform that larger shops use, your clients will ask for accessibility even if you are small.

Small and exempt but planning a new site anyway? Building to WCAG from the first template adds little to a fresh build. A static site starts from US$150 and a webshop from US$750.

Which standard proves EAA website compliance: WCAG 2.1 AA, WCAG 2.2 or EN 301 549?

Test against WCAG 2.1 level AA now and design new work to WCAG 2.2 level AA. ACM states that your website and app must meet level AA of WCAG 2.1, that the European standard EN 301 549 is the technical reference, and that during 2026 WCAG 2.2 level AA becomes the new standard.

EN 301 549 is the European harmonised standard for ICT accessibility, and its web chapter points to WCAG success criteria. In practice, a website auditor works from the WCAG criteria list and records results against it; the EN reference is what connects that work to European law.

What changes with 2.2? According to W3C's summary of what is new in WCAG 2.2, WCAG 2.2 adds nine success criteria and removes 4.1.1 Parsing. The ones that land at level A or AA, and therefore matter for European Accessibility Act website compliance, are:

• 2.4.11 Focus Not Obscured (Minimum): a sticky header or cookie bar must not hide the element that has keyboard focus.
• 2.5.7 Dragging Movements: a price slider needs a non-drag alternative, such as two number fields.
• 2.5.8 Target Size (Minimum): small tap targets such as quantity buttons need enough size or spacing.
• 3.2.6 Consistent Help: help links or chat should sit in the same place across pages.
• 3.3.7 Redundant Entry: do not make shoppers retype the address they already entered.
• 3.3.8 Accessible Authentication (Minimum): log-in should not rely on a memory or puzzle test without an alternative.

Our rule: we log every issue against its 2.1 criterion, flag which 2.2 additions also fail, and fix both together, so you are not paying twice when the benchmark moves.

How a European Accessibility Act website compliance audit works

A proper audit tests representative templates by hand, not just with a scanner. Automated tools catch missing alt text and contrast failures quickly, but they cannot tell whether a filter menu makes sense to a screen-reader user or whether focus disappears behind a modal.

Our audit follows the same pattern on every shop, adjusted to its size:

The output is an issue log in a spreadsheet: criterion, page, element, impact level, suggested fix and effort estimate. Impact levels use the same four words ACM uses (critical, serious, moderate, minor) so the log doubles as your evidence if you ever need to report. For a combined view with crawl and speed problems, pair it with our technical SEO services.

Why checkout and forms fail EAA website compliance most often

Checkout is where the contract is concluded, so it is the part of the service the law cares about most, and it is usually the least tested. A shop can have perfect product pages and still exclude a blind customer at the postcode field.

The recurring failures we look for in Dutch checkouts:

• Postcode and house-number lookups that fill the street silently. Screen-reader users need the result announced and editable.
• Error messages that only turn a border red. ACM's own example of a good message is specific text such as “dit is geen geldige postcode” placed next to the field.
• Placeholder text used instead of labels, which disappears as soon as someone types.
• Missing autocomplete attributes on name, email, address and phone, which ACM lists as a robustness problem and which also slows every mobile shopper.
• Payment method selection built from styled divs rather than real radio buttons, so iDEAL, card and other options cannot be chosen by keyboard.
• Redirects to the bank or payment page without warning, and a return page that does not state clearly whether the order succeeded.
• CAPTCHAs on account creation with no accessible alternative, another item on ACM's list of common problems.
• Session time-outs that wipe the cart without warning or a way to extend.

The hosted payment page from your provider is largely their responsibility, but the step before it and the return page are yours. If you are rebuilding the payment step anyway, our guide to iDEAL payment integration explains the flow we build, and we make it keyboard- and screen-reader-safe as part of the same job.

EAA compliance on Shopify, WooCommerce, Magento, custom builds and apps

The platform rarely decides whether you pass; the theme, the apps or plug-ins you added, and the content your team publishes decide it. Each stack has its own typical weak spots.

Will an accessibility overlay make my website EAA compliant?

No. An overlay is a script that adds a toolbar or tries to repair pages in the browser, and it does not change the code your customers actually rely on. ACM lists accessibility overlays among common problems in practice, noting they can make accessibility worse, and advises tackling problems on your website at the source.

We see why overlays sell: they install in minutes and promise European Accessibility Act website compliance for a monthly fee. The trouble is structural. Screen-reader users already have their own settings; a second layer of controls can conflict with them. Automated repair guesses at labels it cannot know, such as what an unlabelled icon button in your cart actually does. And a checkout built from non-semantic elements stays non-semantic underneath.

If you already run an overlay, you do not need to remove it on day one. We audit with it switched off, fix the underlying issues, and then you decide whether it still adds anything. In most cases it no longer does, and cancelling saves a subscription.

Decision rule: choose a fix in the code whenever the same component appears on more than one page, which is nearly always. Keep an overlay only if a customer has told you it helps them, and never treat it as your compliance evidence.

How to write the accessibility statement the EAA requires

Publish a statement on your website and in your app explaining how your service meets the accessibility requirements. ACM says it must be easy for consumers to find, must itself be accessible, and must also be offered orally, for example as an audio clip of the text being read out.

A statement that holds up is built from evidence rather than adjectives. We draft ours from the audit log, and the structure looks like this:

• Which service it covers: the webshop domain, the app names and versions, any booking subdomain.
• The standard used, WCAG 2.1 level AA via EN 301 549, and the date and method of the last evaluation.
• What conforms, in plain words: for example, “all checkout steps can be completed by keyboard and screen reader”.
• What does not conform yet, per part, with the planned fix date.
• Any disproportionate burden claim, described in outline, where your lawyer has agreed one applies.
• How customers can report a barrier or order another way, with a contact route that is itself accessible.
• The supervisor, ACM, for complaints.

Dutch government bodies use a model statement published on digitoegankelijk.nl under their own separate rules; its layout is a useful reference, but the EAA statement for a business is a different document. We supply the English draft; you or your translator supply the Dutch version, and your lawyer approves both before publication.

When do you have to report accessibility problems to ACM?

ACM asks you to report accessibility problems you know about and have not fixed: critical and serious problems within one week, moderate and minor ones within one month. If you solve the problem inside that window, ACM says you do not need to report it.

A report names the parts that are not accessible and the impact level of each problem, and you send a plan with it for making the service fully accessible. That is why we score issues with ACM's four impact words from the first audit. When the log is ready, you can see at a glance which items sit on the one-week clock.

This timing shapes how we schedule remediation. In a typical project:

• Days 1–3 after the audit: critical items, such as a checkout that cannot be completed by keyboard, are fixed first, often within the week.
• Week 2: serious items such as missing form labels and focus hidden behind sticky headers.
• Weeks 3–4: moderate and minor items, such as contrast tweaks, heading order and link text.
• Anything that genuinely cannot be finished in time goes into the plan with a date, which you can attach to a report.

We do not file reports on your behalf; that is your communication with your regulator. We give you the evidence and the fix plan in a form that is easy to attach.

Fix or rebuild: budgeting European Accessibility Act website compliance

Fix the existing site when problems cluster in a handful of shared components; rebuild when they sit in the page structure itself. The audit log tells you which case you are in, which is why we price remediation only after seeing it.

What pushes the cost of fixes up:

• Number of distinct templates and interactive components, not number of pages.
• Third-party widgets you cannot edit, which must be replaced or wrapped.
• Custom JavaScript for filters, variant pickers and mini-carts.
• Content volume that needs editorial work: thousands of product images with no alt text, PDFs, videos without captions.
• A theme that has been patched by several developers over the years.

Rules of thumb we use when advising: if more than half of the log items live in core layout templates, or the theme is several major versions behind, get a rebuild quote alongside the fix quote and compare. An accessible webshop rebuild starts from US$750; an SEO-heavy site of 299+ pages from US$300; a custom ordering or booking web app from US$900. Every quote is itemised in USD, and nothing is billed until you approve it in writing. For broader budget context, see website development cost in the Netherlands.

How long does EAA website remediation take?

A focused fix of a mid-sized webshop usually takes two to five weeks from audit to retest; an accessible rebuild takes 4 to 8 weeks, like any webshop build. The spread depends mostly on how quickly your side reviews changes and supplies content such as alt text.

The phases, and who does what:

Content fixes run in parallel. Your team writes alt text and captions using a short guide we provide, because only you know what a product photo needs to say.

Does EAA website compliance help SEO and AI search visibility?

Yes, indirectly and in useful ways. Much of what makes a page accessible, such as a clear heading outline, real text instead of text in images, descriptive link text, labelled forms and a declared page language, is also what search engines and AI answer engines use to understand a page.

Accessibility work does not guarantee rankings, and nobody can honestly promise those. What it does is remove friction that hurts both audiences. A few overlaps we see on almost every Dutch webshop:

• Page language: an html lang attribute set to nl on Dutch pages and en on English pages helps screen readers pronounce text correctly, a problem ACM calls out, and supports correct language targeting in search.
• Headings: one h1 and a logical h2/h3 outline lets screen-reader users jump through the page and helps search engines see structure.
• Alt text: meaningful product image descriptions help blind shoppers and give image search real text.
• Performance: removing heavy overlay and pop-up scripts often improves Core Web Vitals.

If search visibility is a parallel goal, monthly SEO from US$150/mo can run alongside the accessibility fixes, handled by the same three people, so nothing one person fixes is undone by another.

Keeping European Accessibility Act website compliance after the fixes go live

Compliance decays as soon as new content goes up. A marketing banner with text baked into an image, a new review plug-in or a product added without alt text can reopen issues you paid to close.

The habits that keep a shop compliant are small and repeatable:

• A one-page editor guide for your team: alt text, link text, heading levels, video captions.
• A short checklist before installing any new app or plug-in: can it be used by keyboard, does it trap focus, is it labelled.
• A monthly regression pass on the checkout and the templates changed that month.
• A quarterly look at the statement, updated whenever a known issue is fixed or a new one appears.
• A named person on your side who receives accessibility feedback from customers.

After an accessible rebuild you get 2 months of free maintenance, which covers these regression passes. After that, maintenance starts from US$120/mo. You own the code, the hosting account and the domain throughout, so any developer can take over later using the issue log and the notes we leave in the repository.

Working with a team in India on EAA compliance from the Netherlands

It works well because accessibility remediation is asynchronous by nature: an issue log, a staging site and a retest list travel across time zones easily. India is 3.5 hours ahead of the Netherlands in summer and 4.5 hours in winter, so the European business day overlaps with ours from late morning onward.

How the practical side runs:

• Calls: a kick-off video call in your late morning or early afternoon, then short calls as needed. WhatsApp replies 7 days a week, in English.
• Access: staging environment, theme or repository access, and an admin account without payment rights.
• Payments: quotes in USD, paid by Wise, bank wire or PayPal. Invoices come from India; your accountant advises on your side of the paperwork.
• Contracts: the written quote sets scope and milestones; if you need an NDA or a data processing agreement, raise it before access is shared. See our terms.
• Ownership: every fix is committed to your repository or theme; nothing runs on our accounts.
• Languages: we write English. Dutch labels, error messages and statement text are supplied or approved by you.

The first two weeks usually look like this: scope call and access on days 1–2, audit through day 7, quote on days 8–9, and critical checkout fixes on staging by the end of week two. More on this model on our outsourcing to India page.

Worked example: a hypothetical Utrecht kitchenware webshop checks its EAA position

Say a kitchenware webshop in Utrecht has 14 staff, sells to consumers across the Netherlands and Belgium on WooCommerce, and runs an overlay widget it installed in 2024. It is not a microenterprise, and consumers conclude contracts online, so European Accessibility Act website compliance applies to it. This is an illustration, not a client story.

The audit samples 11 templates and 9 components. The log shows the pattern we would expect for a shop like this: the checkout's payment options are styled divs, the postcode lookup gives no feedback, the mega-menu traps keyboard focus, product images lack alt text, and a sticky header hides the focused element on scroll. Two issues are critical, six serious, the rest moderate or minor.

The decision: the problems sit in components, not the whole layout, so fixing beats rebuilding. Critical items are fixed on staging in the first week, removing the need to report them. The overlay is switched off during testing and later cancelled. The shop's team writes alt text for its top 300 products using the editor guide, and we draft the statement listing the remaining minor items with dates.

Had the log shown failures across every template of an old theme, the comparison would have pointed towards an accessible rebuild from US$750. The audit is what makes that call, not a guess.

European Accessibility Act website compliance checklist before you sign off

Use this list to judge whether your site is ready for a statement. Every item should be true on your live site, not just on staging.

• Scope confirmed: consumers conclude contracts online, and you are above the microenterprise band.
• Every checkout step completed with keyboard only, focus always visible.
• Every checkout step completed with NVDA and VoiceOver, with the order confirmation read out.
• All form fields have visible labels, specific error messages and autocomplete attributes.
• Links distinguishable by more than colour; text contrast meets AA ratios.
• Pages readable at 200% zoom and at mobile width without horizontal scrolling.
• Page language set correctly on Dutch and English pages.
• Carousels and videos can be paused; videos carry captions.
• Cookie banner operable by keyboard and not hiding focused elements.
• Accessibility statement published, linked from every page footer, accessible, with a spoken version.
• Known remaining issues logged with impact levels and dates, and reported to ACM where the windows require it.
• An owner on your team for customer accessibility feedback.

If you tick most items but not all, that is normal; the statement exists to describe exactly that honestly. Want the list checked for you? Send us your URL and we will scope the audit.