Website Accessibility: EAA and WCAG Explained

Since June 28, 2025, the European Accessibility Act (EAA) requires every business website and app in the EU to meet WCAG 2.1 AA standards. Non-compliance carries real consequences: fines, legal claims from consumers, and exclusion from public procurement contracts. Yet most small and mid-sized business owners still don't know exactly what needs to change — or what it costs to get there.

This article breaks down what the EAA requires, how WCAG works, which problems to fix first, and what the costs look like for a typical business website. No legal jargon, just checklists and numbers.

What the EAA requires vs what WCAG specifies

Business owners often mix these up, but the distinction matters:

• EAA (European Accessibility Act) is the EU regulation that says what you must do. It's the law: you're required to make your digital products and services accessible. Each EU member state has transposed it into national legislation.
• WCAG (Web Content Accessibility Guidelines) is the technical standard that describes how to do it. Developed by the W3C, WCAG contains specific criteria your website must meet.

The EAA mandates WCAG 2.1 AA as the minimum baseline. WCAG 2.2, published in October 2023, adds improvements around mobile interaction and focus indicators. If you're building a new site, aim for WCAG 2.2 AA from the start.

Who does the EAA apply to?

The law covers any business offering products or services to consumers via websites or apps. That includes e-commerce stores, service provider websites, booking platforms, and customer portals. There's a limited exemption for micro-enterprises: businesses with fewer than 10 employees and less than €2 million annual turnover. Every other business — including most SMBs — falls under the requirement.

If your current website was built without accessibility in mind, that doesn't exempt you. Responsibility lies with the website owner, not the agency that built it. For more on what a properly built website should include, see our complete breakdown of website costs in 2026.

The 4 WCAG principles — POUR

WCAG is built on four principles. Each principle contains concrete guidelines and success criteria. This framework helps you evaluate any accessibility question.

Perceivable

Content must be presentable to all senses. If someone can't see an image, there must be alternative text. If someone can't hear a video, there must be captions.

Examples: alt text on images, closed captions on videos, sufficient color contrast (minimum 4.5:1 for normal text), content that doesn't rely solely on color to convey information.

Operable

The interface must work with keyboard, mouse, and assistive technology. Someone who can't use a mouse must be able to reach every part of your site using the Tab key.

Examples: full keyboard navigation, skip links to bypass repeated navigation, no content that could trigger seizures (flashing elements), sufficient time to read content.

Understandable

Content and interface must be predictable and clear. A form that displays a vague error message ("Something went wrong") after submission helps no one.

Examples: clear language, consistent navigation across the site, descriptive error messages explaining what to correct, labels on all form fields.

Robust

Content must work with current and future assistive technologies. That means valid HTML, correct ARIA roles, and semantic structure.

Examples: proper heading hierarchy (H1, H2, H3 — not random levels), ARIA labels on custom components, HTML that validates without errors. This principle overlaps strongly with technical website security, where valid code also plays a role.

The 10 most common accessibility failures

An analysis of over 1 million homepages by WebAIM (2025) shows the same mistakes appearing repeatedly. Here's the breakdown:

The good news: six of these ten are straightforward to fix. Most don't require a redesign — just attention and consistency. When building a new site, you can prevent all of these by incorporating accessibility from day one. That's exactly what a headless CMS approach enables: complete control over the HTML output.

Self-audit checklist — 15 points

Before hiring an agency, you can run a first audit yourself. Work through these 15 points:

1. Tab through your entire website — can you reach every interactive element using only the keyboard?
2. Check alt text — does every image have descriptive alt text (or an empty alt="" if it's decorative)?
3. Measure contrast ratios — minimum 4.5:1 for normal text, 3:1 for large text. Use the free WebAIM Contrast Checker.
4. Test with a screen reader — VoiceOver on Mac/iOS, NVDA on Windows (free). Navigate your site and check whether all content is read aloud intelligibly.
5. Check form labels — does every input field have a visible label (not just placeholder text)?
6. Verify heading hierarchy — does your site progress from H1 to H2 to H3 without skipping levels?
7. Test video captions — if you have videos, are there captions?
8. Check skip-to-content link — is there a "skip to main content" link at the top of the page for keyboard users?
9. Inspect focus indicators — is there a visible outline when tabbing through interactive elements?
10. Test at 200% zoom — is all content still readable and usable when you set the browser to 200%?
11. Check language attribute — is lang="en" (or the correct language) set on the HTML element?
12. Verify error messages — are form errors descriptive ("Enter a valid email address" rather than "Error")?
13. Test all interactive elements — dropdowns, modals, accordions, sliders: all operable with keyboard?
14. Check ARIA roles — do custom components (non-standard HTML) have the correct ARIA attributes?
15. Run a Lighthouse audit — open Chrome DevTools, go to "Lighthouse", and run the Accessibility audit. Aim for 90+.

What it costs — retrofitting vs building accessible

Costs depend heavily on your website's current state. Here are realistic ranges for a typical European SMB:

Making an existing website accessible (retrofit)

Building a new website with accessibility from the start

Including accessibility from the beginning adds 10-15% to project costs. On a typical SMB website project, that means:

• Brochure website: +€500 – €1,000
• Business website: +€1,000 – €2,000
• E-commerce: +€1,500 – €3,000

The math is clear: building it in from the start costs a fraction of fixing it later. Curious about total website costs? Our article on website development costs in 2026 gives a full overview.

Comparing with the risk

Non-compliance costs more than the fix. The risks:

• Fines: The EAA provides for sanctions determined by each member state. The EU directive requires penalties to be "effective, proportionate, and dissuasive."
• Legal claims: Consumers can take legal action if your site isn't accessible.
• Lost revenue: 15-20% of your potential customers have a condition that affects how they use the web.

Testing tools you can use today

Automated tools catch 30-40% of all accessibility issues. The rest requires manual checking. Use this combination:

Free tools

• axe DevTools — browser extension for Chrome and Firefox. Scans the current page and displays WCAG violations with explanations and fix suggestions. The best free tool available.
• WAVE — web-based tool from WebAIM. Visual overlay that marks issues directly on the page. Good for a quick first scan.
• Lighthouse — built into Chrome DevTools. The accessibility audit gives a score from 0-100 with specific improvement points.

Screen readers (manual testing)

• VoiceOver — built into macOS and iOS. Activate with Cmd + F5 on Mac.
• NVDA — free, open-source screen reader for Windows. The standard for professional testing.
• TalkBack — built into Android. Activate via Settings > Accessibility.

The 30/70 rule

Automated tools are essential but not sufficient. They detect objective problems (contrast, missing alt text, missing labels), but miss subjective issues (is the alt text descriptive enough? Is the tab order logical? Is the content understandable?).

Always plan manual testing alongside automated scans. The choice between no-code and custom development is relevant here too: custom-built sites give you full control over HTML output, while no-code platforms sometimes limit what you can adjust for accessibility.

Dutch enforcement context

The Toezichthouder Digitale Toegankelijkheid (Digital Accessibility Regulator), part of the Dutch Ministry of Internal Affairs, oversees compliance. Here's the enforcement landscape:

Public sector (required since 2018): The Dutch public sector has been required to meet WCAG 2.1 AA since 2018, under the Besluit digitale toegankelijkheid. This covers national government, municipalities, provinces, water boards, and other government bodies. Active monitoring is in place.

Private sector (EAA — since June 2025): Commercial websites and apps have been required to comply since June 28, 2025. Enforcement is in its startup phase and primarily complaint-driven: action is taken mainly after consumer reports. Expect oversight to intensify in the coming years, similar to how GDPR enforcement gradually became stricter.

Market surveillance: The European Commission coordinates enforcement across member states. Large platforms operating in multiple EU countries are monitored at the European level.

This follows a pattern similar to AI legislation in the Netherlands — rules first, then awareness, then enforcement.

The business case beyond compliance

Accessibility isn't a cost center — it's an investment with measurable returns:

Reach: 1.3 billion people worldwide live with a disability. In the Netherlands alone, that's over 2 million people. If your website isn't accessible, you're excluding 15-20% of your potential audience.

SEO: There's direct overlap between accessibility and search engine optimization. Heading structure, alt text, semantic HTML, mobile-friendly design — all factors that improve both accessibility and your search rankings. Getting your website security in order also benefits SEO — and the same applies to accessibility.

Mobile: Accessible design is inherently better mobile design. Large touch targets, clear labels, readable text, logical navigation — exactly what mobile users expect.

Conversion: Clearer CTAs, better forms, readable content, and logical navigation lead to 20-30% higher conversion rates. Accessibility is essentially UX optimization for everyone.

App accessibility

The EAA doesn't apply only to websites. Mobile apps fall under it too. Here are the key considerations per platform:

iOS

• VoiceOver support: Every interactive element needs an accessibility label and hint.
• Dynamic Type: Text must scale when the user sets a larger font size in iOS settings.
• Touch targets: Minimum 44x44 points for buttons and links. Smaller elements are unreliable for users with motor impairments.
• Color blindness: Information must not be conveyed through color alone. Use icons, patterns, or text as well.

Android

• TalkBack support: Content descriptions on all visual elements, correct focus order.
• Font scaling: Respect the system setting for text size.
• Focus management: Navigation with the d-pad or external keyboard must be logical and complete.

Cross-platform (React Native / Flutter)

Both frameworks provide accessibility APIs. React Native has accessibilityLabel, accessibilityRole, and accessibilityState. Flutter has Semantics widgets. The risk with cross-platform: you need to manually test on both platforms, because the translation of accessibility properties differs per platform.

For more on app development and choosing between native and cross-platform, read our complete guide to app development.

Next steps

Website accessibility isn't a one-time project but an ongoing process. Start with the self-audit, prioritize the highest-impact issues (contrast, alt text, keyboard navigation), and build accessibility into your development workflow.

If you're commissioning a new website or app, include accessibility in your brief. The difference between an accessible and a non-accessible website isn't visible at first glance — but it determines whether 100% or 80% of your visitors can actually use your site.

We build websites and apps that meet WCAG 2.1 AA by default. No extra charges after the fact, no retrofit. If you're unsure whether your current website complies with the EAA, we start with a free accessibility scan.