The European Accessibility Act, Directive (EU) 2019/882, has applied since 28 June 2025 to consumer services such as webshops, online banking, e-books and the websites and apps of passenger transport. The Netherlands transposed it through a dedicated implementing act. To show that your software complies, there is the European standard EN 301 549, whose web section matches WCAG 2.2 Level AA.
Below you'll find scope, dates and supervision, then the standard, build requirements, publishing, testing and a step plan for existing software. This isn't legal advice: if you're unsure whether your service is in scope, have a lawyer check it.
Which software falls under the European Accessibility Act
The directive covers products, such as computers, smartphones, payment terminals and e-readers, and services. Business software usually falls under the services in Article 2(2) of the directive: services provided to consumers after 28 June 2025.
| Your software | Category in Article 2 | Watch out for |
|---|---|---|
| Webshop or ordering app for consumers | E-commerce service | Identification, security and payment too |
| Online banking, payment app, online loan application | Consumer banking service | Information no more complex than language level B2 |
| Booking or ticketing app of an air, bus, rail or waterborne carrier | Passenger transport | Urban, suburban and regional transport: only self-service terminals |
| E-book store or reading app | E-books and dedicated software | Accessibility metadata; DRM must not block accessibility features |
| Customer portal where consumers sign a contract online | Possibly an e-commerce service | Check whether a consumer contract is concluded |
| Dealer portal or ERP for business customers only | Not a consumer service | Mixed audience: have it checked |
The B2B line follows from Article 3. A consumer is a natural person acting for purposes outside their trade, business, craft or profession. An e-commerce service is provided at a distance, through a website or app, with a view to concluding a consumer contract.
Microenterprises providing services are exempt (Article 4(5)): fewer than 10 employees and an annual turnover or balance sheet total of no more than EUR 2 million. Article 2(4) excludes some content, including pre-recorded video and office files published before 28 June 2025 and third-party content you don't fund, develop or control.
Dates, transition periods and supervision in the Netherlands
Member states had to apply the rules from 28 June 2025 (Article 31). The Netherlands did so with the Implementatiewet toegankelijkheidsvoorschriften producten en diensten (Staatsblad 2024, 87), which entered into force on 28 June 2025 according to Staatsblad 2024, 341. The rules sit in existing acts: for webshops in Articles 6:230fa to 230fd of the Dutch Civil Code, for banking in Article 4:22.0a of the Financial Supervision Act.
Article 32 sets transition periods. Service providers may keep providing services until 28 June 2030 using products they already lawfully used for similar services. Service contracts agreed before 28 June 2025 continue unchanged until they expire, but no longer than five years from that date. Dutch law adds a separate transition rule for e-commerce in Article 190aa of the Transitional Act for the new Civil Code. The law doesn't explain what "already lawfully used" means for software you change every sprint. Ask a lawyer before you rely on it.
The Dutch government names six supervisors. These matter most for business software:
- ACM, the Authority for Consumers and Markets: e-commerce and electronic communications services;
- AFM, the Authority for the Financial Markets: consumer banking services;
- the Dutch Media Authority: e-books and services giving access to audiovisual media;
- the Human Environment and Transport Inspectorate: passenger transport;
- the Dutch Authority for Digital Infrastructure: products, under the Commodities Act.
ACM has started checking. Across about 100 large online stores and the sites of large telecom and energy providers, ordering with assistive technology was impossible on 61 percent, for example because an order button didn't work with the keyboard or a CAPTCHA puzzle was inaccessible. Companies that don't improve enough after ACM contacts them risk enforcement.
EN 301 549 and WCAG 2.2: the standard behind the law
As with the Wegiz, the technical detail isn't in the law itself. Annex I of the directive requires websites, online applications and mobile apps to be perceivable, operable, understandable and robust. Those are the four principles of WCAG 2.2. Under Article 15, a service that meets a harmonised standard whose reference is published in the Official Journal of the EU is presumed to comply, to the extent the standard covers the requirements.
The standard written for this is EN 301 549 V4.1.1, adopted on 24 August 2026 and prepared at the European Commission's request as one voluntary means of meeting the directive. It replaces V3.2.1 from March 2021 and aligns clauses 9, 10 and 11 with WCAG 2.2. By its own text, it gives a presumption of conformity only once cited in the Official Journal under this directive, so check that before you reference it in a contract.
- Clause 9, web: conforming to WCAG 2.2 Level AA is equivalent to conforming to clauses 9.1 to 9.4 and 9.6. Web applications fall under it too.
- Clause 10: documents offered for download, such as a PDF invoice from your portal.
- Clause 11: software that isn't a web page, such as a native app, including the web views inside it.
Build requirements for your webshop, portal or app
The table turns the standard into work for your team. Put the requirements in your functional design and in the acceptance criteria of your contract, so they get built and tested instead of patched later.
| Area | What you build | WCAG 2.2 |
|---|---|---|
| Keyboard | Every function works without a mouse, including the menu, date picker and pop-ups. Focus never gets trapped. | 2.1.1, 2.1.2 |
| Focus | A visible focus indicator, a logical order, and no sticky header or cookie banner that fully hides the focused element. | 2.4.3, 2.4.7, 2.4.11 |
| Contrast | Text at least 4.5:1, large text 3:1. Input borders, buttons and icons at least 3:1. | 1.4.3, 1.4.11 |
| Text alternatives | Alt text for product photos. Icon buttons get a name that a screen reader announces. | 1.1.1, 4.1.2 |
| Forms and error messages | A label for every field, errors described in text at the right field with a suggestion, and messages like "added to cart" announced without moving focus. | 3.3.1, 3.3.2, 3.3.3, 4.1.3 |
| Captions | Captions on videos and live streams. | 1.2.2, 1.2.4 |
| Zoom and reflow | Text resizes to 200 percent without losing content. No horizontal scrolling at 320 CSS pixels wide. | 1.4.4, 1.4.10 |
| Login | No memory test or puzzle as the only route. Allow paste and password managers, or offer device login through WebAuthn. | 3.3.8 |
| Target size | Buttons and links at least 24 by 24 CSS pixels, or enough space around them. | 2.5.8 |
| Documents | PDF invoices and contracts with text alternatives, structure and a logical reading order. | EN 301 549, clause 10 |
What you publish and how you test
Under Article 13 and Annex V, you explain in your general terms and conditions, or an equivalent document, how the service meets the requirements: a general description in accessible formats, how the service works and how it meets Annex I. You make that information available in written and oral form, accessible to people with disabilities, and keep it for as long as the service runs. If your webshop doesn't comply, Article 8a.0 of the Dutch Consumer Protection Enforcement Act requires you to inform ACM or AFM straight away, with the corrective measures you're taking.
Automated scanners belong in your pipeline, but according to W3C, evaluation tools can't determine accessibility; they can only assist. In 2017 the UK Government Digital Service ran ten tools against a page with 143 deliberate barriers. Counting prompts for manual checks, the best tool found 41 percent; 29 percent were missed by every tool. So test by hand as well: keyboard only, 200 percent zoom, and screen readers such as NVDA, VoiceOver and TalkBack. Involve people with disabilities too, as ACM does in its supervision.
Five pitfalls
- Testing only the website. PDF invoices and the app fall under clauses 10 and 11 of the standard.
- Treating the payment module as the vendor's problem. The third-party content exception only covers content you don't fund, develop or control.
- A puzzle CAPTCHA at login or checkout. ACM names it as a reason orders fail.
- Claiming a disproportionate burden without a file. Article 14 requires a documented assessment that you redo at least every five years.
- Forgetting the information in your terms. Even a well-built service has to explain how it meets the requirements.
Updating an existing system step by step
- Work out which channels are in scope. List your webshop, app, portal and generated documents, with their audience and Article 2 category. Put borderline cases to a lawyer.
- Measure where you stand. Run a scan and audit the journeys that matter by hand: creating an account, logging in, ordering, paying and downloading an invoice. EN 301 549 is your checklist.
- Fix blockers first. Anything that makes a task impossible comes before things that only slow people down.
- Repair shared components. An accessible button, modal and input field in your component library fix dozens of screens at once. If your system lacks that layer, this is a good moment to replace parts of it; read more about legacy systems.
- Build it into your process. Automated checks in the pipeline, WCAG 2.2 AA in the definition of done and a keyboard and screen reader test per release. Article 13 requires procedures that keep the service compliant as it changes.
- Publish the information and keep it current. Write the Annex V text, make sure your help desk can answer accessibility questions and update both after every major change.
Building accessible software with Isatis
Isatis builds custom business software, with teams in Nijmegen, in the Netherlands, and Sarajevo. We've been doing this for more than 30 years, with 30+ engineers and more than 100 projects, and we're certified for ISO 9001 and ISO 27001. Our page on custom software development shows how we work.
If you want to know where your webshop, customer portal or app stands against EN 301 549, book a conversation. We'll also tell you when targeted fixes to your current system are enough. Whether your service is legally in scope isn't something we assess; for that we'll point you to a lawyer.
Frequently asked questions
What is the European Accessibility Act?
The European Accessibility Act is Directive (EU) 2019/882. It requires consumer products and services such as webshops, online banking, e-books and passenger transport ticketing to be accessible. The rules have applied since 28 June 2025.
Does the European Accessibility Act apply to B2B software?
The directive is about services provided to consumers: natural persons acting outside their trade, business, craft or profession. A purely business portal or an ERP falls outside it. If consumers use the same channel, have a lawyer check where you stand.
Does a small webshop have to comply?
Microenterprises that provide services are exempt. That means fewer than 10 employees and an annual turnover or balance sheet total of no more than EUR 2 million. With 10 or more employees the exemption doesn't apply, however small your turnover.
Is WCAG 2.2 Level AA mandatory?
The directive doesn't mention WCAG, but requires websites and apps to be perceivable, operable, understandable and robust. EN 301 549 V4.1.1 works that out; for web content, meeting WCAG 2.2 Level AA is equivalent to meeting that part of the standard. The standard only gives a presumption of conformity once it's cited in the Official Journal of the EU under the directive.
What happens if my webshop isn't accessible?
ACM supervises webshops, and according to the Dutch government a supervisor can, for example, issue a warning or a fine. You also have to report non-compliance to ACM or AFM yourself. In March 2026 ACM reported that ordering with assistive technology was impossible on 61 percent of the large websites it checked.





