On June 28, 2025, the European Accessibility Act (EAA) took effect across the EU. If your business runs a customer-facing website, app or software service that falls under its scope, you have a legal obligation — not a suggestion — to make it accessible. For products and services launched after that date, the requirement applies immediately. For existing products, the deadline to comply is June 28, 2030.
Most business owners I speak to have heard of it vaguely and assumed it only applies to government agencies. It doesn't. The EAA is a private-sector regulation, and for Dutch businesses in e-commerce, financial services or passenger transport, it has direct consequences for the software you commission and run.
What is the European Accessibility Act?
The EAA (EU Directive 2019/882) requires certain digital products and services to be usable by people with disabilities — including those who rely on screen readers, keyboard navigation or high-contrast displays. It covers both companies that build products and companies that offer services through digital channels.
The technical standard it references is WCAG 2.1 Level AA — the Web Content Accessibility Guidelines. This is the same standard that has applied to Dutch government websites since 2018. What's new is that the EAA extends it to significant parts of the private sector, with enforcement and fines attached.
Which businesses and services are covered?
The EAA doesn't apply to all software. It covers specific sectors:
- E-commerce — Websites and apps used to sell products or services online
- Banking and financial services — Online banking, payment services, investment platforms
- Passenger transport — Digital services from air, rail, bus and ferry companies
- Electronic communications — Telecom services and their customer-facing interfaces
- E-books and dedicated software — Platforms distributing e-books and the software used to read them
If your business operates in one of these sectors and you run a customer-facing website, portal, app or checkout flow, the EAA applies to that digital surface.
Internal tools — software used exclusively by your own employees — are generally outside the scope of the EAA. That said, good accessibility in internal systems is still sound practice: it reduces friction for employees with visual impairments, motor difficulties or cognitive differences, and avoids potential discrimination claims under Dutch employment law.
What does WCAG 2.1 AA compliance actually require?
WCAG 2.1 Level AA sounds abstract until you look at what it means for a real application. The requirements cluster around four principles — content must be perceivable, operable, understandable and robust. In practice, that means:
- Images have text alternatives that screen readers can announce
- All functionality can be accessed using only a keyboard, with no mouse required
- Forms have properly labelled fields so users know what to enter
- Colour contrast ratios meet minimum thresholds — normal text requires 4.5:1, large text 3:1
- Error messages are specific and tell users how to fix the problem
- Pages work at 200% zoom without horizontal scrolling
- Dynamic content like pop-ups and notifications can be dismissed and doesn't trigger seizures
Some of these are cheap to implement from the start and expensive to retrofit. A form built without labels takes five minutes to fix at design time; a complex interactive interface that was built around colour-only signals can require significant rework after launch.
This is exactly the same logic as GDPR requirements: decisions made during design and development determine whether compliance is cheap or expensive. Raising accessibility requirements during a discovery phase costs almost nothing. Retrofitting them into a live system costs serious money — typically 30–50% of the original front-end build.
The microenterprise exemption
There is one important carve-out. Businesses with fewer than 10 employees and an annual turnover or balance sheet total below €2 million — what the EU classifies as a microenterprise — are exempt from the EAA's service requirements.
This matters for smaller Dutch businesses. If you fall below both thresholds, the EAA's service obligations don't apply to you. Note that "both" is the key word — you need to be below the employee count and the turnover threshold. A nine-person business with €3 million in revenue is not exempt.
The product side is different: businesses of any size that manufacture or import products covered by the EAA — self-service terminals, e-readers, consumer electronics with digital interfaces — still face product requirements, regardless of company size.
The two deadlines
Two distinct deadlines apply:
- June 28, 2025 — Any new service or product launched on or after this date must already comply
- June 28, 2030 — Services that were already live before June 2025 have until this date to reach compliance
We're in late 2026. If you launched something after June 2025, compliance is a current obligation. If you're counting on the 2030 window for older services, you have roughly 3.5 years — which sounds comfortable until you account for the realistic lead time to audit, scope, build and verify an accessibility pass across a full system.
What non-compliance can cost
Enforcement in the Netherlands runs through the Autoriteit Consument & Markt (ACM) for general market surveillance and through sector-specific regulators for financial services and telecom. The EAA requires member states to impose "effective, proportionate and dissuasive" penalties. The trajectory mirrors GDPR: administrative fines, public notices and mandatory remediation orders.
Beyond regulatory risk, accessibility failures create grounds for complaints from users, potential discrimination claims under Dutch equal treatment law, and reputational damage — particularly for consumer-facing e-commerce businesses where accessibility is increasingly visible to the public and press.
What to demand when commissioning software
If you're commissioning new software in a covered sector, treat accessibility as a delivery requirement in the brief, not an afterthought. Concretely:
- Specify WCAG 2.1 AA as a contractual requirement, not an optional extra
- Ask the developer to run an automated audit — tools like Axe or Lighthouse catch roughly 40% of issues — and provide results before delivery
- Test with at least one real screen reader before you accept the work (NVDA on Windows is free)
- Request an accessibility statement — required by the EAA — listing what's compliant and what's not yet fixed
- Include keyboard navigation and screen reader testing in your acceptance criteria alongside functional testing
A developer who looks blank when you raise accessibility is a warning sign. A competent developer can discuss contrast ratios, ARIA roles and keyboard focus traps without blinking — and will already be building against them.
The cost premium for an accessible build over an inaccessible one is modest — typically 5–15% of the front-end work — when it's planned from the start. That compares favourably to the 30–50% retrofit cost and the compliance timeline pressure of addressing it after the fact.
If you have software in a covered sector and aren't sure where you stand, describe your system and I'll give you an honest assessment of the gap and what closing it would involve — alongside realistic figures for what accessible custom software costs to build. How I run a build covers what's included in a typical delivery.