Digital accessibility: what is required?

An accessible website works for visitors who use a screen reader, navigate by keyboard only, struggle with low contrast or find complex language hard to process. In practice it comes down to alt texts on images, sufficient colour contrast, a logical heading structure, forms with clear labels and buttons you can operate without a mouse.

The four base principles come from the international WCAG guidelines: perceivable, operable, understandable and robust. Meeting WCAG level AA covers the vast majority of the legal requirements. The current version is WCAG 2.2; it adds criteria on focus, drag movements and touch targets that also weigh heavily on mobile.

Accessibility is not an 'extra layer' on top of design. It is the question whether someone can finish the task: order a product, book an appointment, submit a form. What is a hard blocker for one group is often simply poor UX for others. That is why it pays off even without a legal duty.

For the public sector the Dutch government accessibility decree applies: websites and apps of central government, provinces, municipalities, water boards and public-law bodies must be accessible and publish an accessibility statement. Digitoegankelijk is the central Dutch explanation of that duty.

For businesses the European Accessibility Act (EAA) has applied since 28 June 2025. The Dutch government summarises that products and services must become more accessible for people with impairments. The EAA covers e-commerce services among others: websites and apps where consumers can buy, book, reserve or sign up.

According to the guidance from the Dutch regulator ACM, the obligation applies to businesses with 10 or more employees or an annual turnover above 2 million euros. Micro-enterprises below both thresholds are exempt. Note: a quality mark or external audit is not legally required. The law demands that your service is accessible, not that you hold a certificate for it. An independent check does help you find out where you stand.

The technical yardstick is WCAG level AA. In Europe, legislation refers to those criteria through EN 301 549: EN 301 549 is the broader ICT standard; for web content the WCAG success criteria are the relevant part. ACM uses WCAG AA as the practical reading of the requirements for e-commerce services and advises starting with WCAG 2.2.

If you are building or rebuilding now, test against WCAG 2.2 AA straight away. The differences with 2.1 are limited, and the new criteria mainly matter for mobile use and forms. Testing against an outdated version means rework later.

An accessibility statement is mandatory for government organisations. E-commerce services under the EAA also have a statement obligation: you explain how your service meets the rules, in a place that is easy to find. The statement does not replace real accessibility; it documents the status, including known gaps and a plan.

Start by measuring. An automated scan shows within minutes which basic problems exist: missing alt texts, insufficient contrast, empty links and buttons, missing form labels. Fix the blockers first: navigation that cannot be operated, forms without labels and contrast below the standard.

Then plan a manual review for what a machine cannot judge: the logic of error messages, the order of keyboard navigation, whether alt texts are meaningful, whether a checkout can be completed with keyboard only. Have someone who did not build the product walk the core flows; blind spots appear faster inside the team.

Tie accessibility into your release process. Every new page, cookie banner or chat widget can introduce new barriers. Add checks in pull requests or staging, and re-test periodically on production. That way compliance is not a one-off project for 28 June 2025, but ongoing maintenance.

Accessibility is one of the four pillars of the WebYes scan, alongside speed, security and mobile. We run automated checks based on WCAG 2.2 AA. Automated checks do not catch everything (roughly 30 to 50 percent of the criteria can be tested by a machine), but they do find the most common problems that visitors and regulators notice first.

The scan covers up to six pages per run. The quality mark requires an average score of at least 80 and at least 60 per pillar. A site that scores 'almost fine' on accessibility but drops below 60 does not get GEKEURD status, even if the other pillars are high. That forces honest priority: a11y is not a side issue.

In the report you see per finding what is wrong and how to fix it, often with a link to the fix guide. Use the scan as a starting point, not a full WCAG audit. For legal certainty on complex flows, a manual audit with experts and users with impairments remains the next step.

Do not send findings as one long list to 'the developer'. Group by ownership: content (alt text, headings), design (contrast, target size), engineering (labels, ARIA, keyboard traps). That stops three people fixing the same button while nobody owns the cookie banner.

Tie the WebYes accessibility pillar to your sprint board. A score below 60 is a blocker for the keurmerk (average ≥80 still applies as well). Plan re-audit after fixes: free scan up to six pages, full audit up to fifteen. Without a repeated measurement you do not know whether the pillar truly sits above the floor.

Beside the technical backlog, keep a short list of manual checks (checkout with keyboard, screen reader on forms). That list is what the law effectively asks of you on top of automated rules; the scan alone is never full proof.