EAA Accessibility Requirements for Dutch Webshops: What the ACM Found

In November 2025, the ACM (Autoriteit Consument & Markt) published the results of its first large-scale accessibility investigation of Dutch e-commerce. The target: the 60 largest Dutch webshops. The finding: 61% had serious accessibility problems that prevented or significantly hindered users with disabilities from completing purchases.

The ACM announced that it would contact those webshops in 2026 with a formal request to remedy the issues — the beginning of active EAA enforcement.

Who Must Comply

The EAA (Directive 2019/882) applies to digital services offered to consumers. This explicitly covers:

• Online shops and webshops
• Mobile apps for shopping
• Online reservation and booking systems
• Digital subscription services

Exempt: Micro-enterprises with fewer than 10 employees AND annual turnover below €2 million. If you exceed either threshold, you must comply.

The ACM's November 2025 investigation targeted the largest webshops. But the law applies to all non-micro businesses — enforcement against smaller businesses is likely to follow as the ACM builds its enforcement capacity.

What the ACM Found: The Most Common Violations

1. Images without alt text (WCAG 1.1.1)

Product images, promotional banners, and category images without descriptive alt text make screen readers announce "image" or "untitled" — providing no useful information to blind users.

The scale: Of 10,338 images checked in our scan of 499 Dutch restaurant websites, 61% lacked alt text. The pattern is similar in e-commerce.

The fix: Add descriptive alt text to every meaningful image:

<!-- Bad -->
<img src="product-red-shoes.jpg">

<!-- Good -->
<img src="product-red-shoes.jpg" alt="Red leather Oxford shoes, size range 36-46">

<!-- For decorative images that add no information -->
<img src="decorative-divider.jpg" alt="">

2. Form fields without labels (WCAG 1.3.1)

Checkout forms that use placeholder text instead of proper labels cause screen readers to announce the field as unlabelled after the user starts typing — because placeholder text disappears when you type.

The fix:

<!-- Bad: placeholder only -->
<input type="email" placeholder="Email address">

<!-- Good: visible label with for/id relationship -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" placeholder="you@example.com">

<!-- Good: if design requires hidden label, use aria-label -->
<input type="email" name="email" aria-label="Email address" placeholder="Email address">

3. Insufficient colour contrast (WCAG 1.4.3)

Text that does not meet the minimum contrast ratio of 4.5:1 against its background is difficult or impossible to read for users with low vision or colour blindness.

Common failures:

• Light grey text on white background
• White text on light brand colours
• Disabled button text that is nearly invisible

How to check: Use the browser's developer tools (F12 → Computed → colour → contrast) or the free axe DevTools extension.

WCAG requirements:

• Normal text (below 18pt / 14pt bold): minimum 4.5:1 contrast ratio
• Large text (18pt+ / 14pt+ bold): minimum 3:1 contrast ratio
• Focus indicators: minimum 3:1 against adjacent colours

4. Checkout process inaccessible to keyboard users (WCAG 2.1.1)

If any step in the checkout process cannot be completed using a keyboard alone — without a mouse — the entire purchase path is blocked for users who cannot use a mouse (mobility impairments, some visual impairments).

What to check:

• Tab through every step of your checkout using only the keyboard
• Every button, link, and form field must be reachable and activatable via Tab/Enter/Space
• Custom date pickers, quantity selectors, and address autocomplete must be keyboard-accessible
• No keyboard traps (where focus gets stuck and cannot be moved out)

5. Focus not visible (WCAG 2.4.7)

When keyboard users Tab through a page, they need to see which element currently has focus. Many websites remove the default browser focus ring (the blue outline) with outline: none for aesthetic reasons — this makes keyboard navigation impossible for sighted keyboard users.

The fix: Restore visible focus indicators:

/* Remove this: */
:focus { outline: none; }

/* Add this instead (custom visible focus ring): */
:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

6. Dynamic content not announced (WCAG 4.1.3)

When content changes dynamically — a shopping cart count updating, a form error appearing, a product added to wishlist — screen readers need to be notified. Without ARIA live regions, these updates are invisible to screen reader users.

The fix: Use aria-live regions for dynamic content:

<!-- Shopping cart count -->
<div aria-live="polite" aria-atomic="true">
  <span id="cart-count">3</span> items in cart
</div>

<!-- Error messages -->
<div role="alert" id="error-message"></div>

7. Lack of error identification (WCAG 3.3.1)

When a form is submitted with an error, the error must be:

• Identified in text (not just by colour)
• Associated with the specific field that has the error
• Described in a way that tells users what to fix

<!-- Bad: error only shown in red, no programmatic association -->
<div style="color:red">Invalid email</div>
<input type="email" name="email">

<!-- Good: error associated with field, not just colour -->
<div id="email-error" role="alert">
  Please enter a valid email address (e.g., you@example.com)
</div>
<input type="email" name="email" 
       aria-describedby="email-error" 
       aria-invalid="true">

The axe-core Detection Rate

TrustYourWebsite uses axe-core (the same engine used by Google Lighthouse and Microsoft Accessibility Insights) for automated accessibility testing. Per Deque's research, axe-core detects approximately 30–57% of WCAG violations automatically.

The violations it catches reliably:

• Missing alt text on images
• Missing form labels
• Insufficient colour contrast
• Missing document language
• Empty links and buttons
• ARIA attribute errors

Violations requiring manual testing:

• Keyboard navigation completeness
• Screen reader announcement quality
• Logical focus order
• Cognitive accessibility issues
• Context-dependent contrast (e.g., text over images)

An automated scan is a necessary starting point but not sufficient for full compliance. After fixing automated findings, test with a keyboard and ideally with a screen reader (NVDA on Windows is free).

Practical Prioritisation for Webshops

Focus on the checkout and purchase flow first — this is where accessibility failures have the most impact on users with disabilities and where the ACM focused its investigation.

Priority 1 (Checkout flow):

• All form fields in checkout have labels
• Every step is keyboard-navigable
• Error messages are descriptive and programmatically associated
• Order confirmation is announced to screen readers

Priority 2 (Product browsing):

• Product images have descriptive alt text
• Product filters and sorting controls are keyboard-accessible
• Quantity selectors are keyboard-accessible

Priority 3 (General site):

• Colour contrast meets 4.5:1
• Focus is visible throughout
• Page title changes on navigation
• Headings are structured (H1, H2, H3 in logical order)

Automated Testing Tools

For the most efficient starting point: install the axe DevTools Chrome extension and run it on your homepage and checkout page. Fix everything it finds, then move to keyboard testing.

---

This article is technical analysis, not legal advice. Consult a lawyer for advice specific to your situation.