Public-sector website accessibility Colabs

Find and prioritise barriers in an existing website, or set testable accessibility requirements for a new one.

Public-sector websites covered by the EU Web Accessibility Directive must meet accessibility requirements, publish and maintain an accessibility statement, provide a way to report accessibility barriers and explain how to use the relevant enforcement procedure. For most websites, conformity is assessed against the applicable requirements in EN 301 549 v3.2.1. This includes WCAG 2.1 Level AA and additional requirements. Coverage, exemptions and enforcement depend on the law implementing the Directive in your country, which we confirm before proposing the work.

Audit fragmentWCAG 2.2 AA
Keyboard focusHigh priority
Form labelsShared component

Choose the route that fits

Existing website

Receive a prioritised register of barriers, recommended fixes and evidence from an agreed test sample.

New website or procurement

Set measurable accessibility requirements, check progress during delivery and test them before supplier acceptance.

Not sure which route fits?

Replacing or substantially redesigning an existing site? We can combine a baseline audit with procurement requirements and staged acceptance checks.

Help me choose a scope

The standard we test against

A WCAG 2.1 AA review alone is not a complete EN 301 549 assessment. We test the applicable web requirements in the harmonised standard and record the exact scope used. We provide technical accessibility advice, not legal advice.

How the work is run

You work with one lead reviewer from scoping through handover. Before work starts, the proposal fixes the sample, method, deliverables, exclusions, timetable and price. Reports and meetings are available in Dutch or English. The same reviewer scopes the work, tests the site and explains the findings to your team or supplier, so decisions do not pass through an account-management layer.

Audit an existing website

Get an audit scope and price

1. Agree the scope

We select the journeys, pages and shared components that matter most, together with the browser and assistive-technology combinations. Documents, authenticated areas and third-party tools are included only when named in the proposal.

2. Test the website

We manually test the selected journeys and shared components with keyboard navigation, zoom and reflow, screen readers and code inspection. Automated checks support the review but do not replace manual testing. The proposal names the browser and assistive-technology combinations.

3. Handover and next steps

You receive an issue register, a concise assessment report and a findings meeting with the lead reviewer. Each issue includes reproduction steps, evidence, user impact, affected pages or components, the relevant standard reference, priority and a recommended fix. The report records the test date, sample, method and results. It can inform the accessibility statement, but the reported results apply only to the agreed sample and do not certify the entire service.

Audit report extract

What a useful finding looks like

Finding
A11Y-017
Status
Open
Scope
Shared component
Priority
High
Observed issue

Missing visible focus in the main menu

Impact
Keyboard users cannot see which menu link is active. The problem occurs in the shared menu component and affects every page that uses it.
Requirement
EN 301 549 clause 9.2.4.7, which incorporates WCAG 2.1 success criterion 2.4.7.
Recommended fix
Add a clearly visible focus style and verify every supported menu state.

Optional fixes and retesting

If requested, we support your team or supplier while they fix the issues, then retest selected items and record whether they have been resolved.

Build or procure an accessible website

1. Before tender

We review an existing specification or turn EN 301 549 into tender language, required supplier evidence and testable acceptance criteria. For example: which journeys must pass keyboard and screen-reader testing, which document types are included and what must be resolved before acceptance.

2. During delivery

We track findings and supplier responses at agreed design and development stages. Suppliers can discuss findings directly with the reviewer.

3. Before acceptance

We independently test the agreed journeys and criteria. The report distinguishes passed requirements, unresolved failures and verified fixes, giving your organisation evidence for its acceptance decision.

Example acceptance criterion

A user must be able to complete the permit application using keyboard-only navigation and the agreed screen-reader combination. No unresolved high-priority failure may remain in this journey at acceptance.

Review my procurement documents

Technical assessment and user research

Standards testing identifies failures against agreed requirements. Research with disabled users answers a different question: how well people can complete real tasks. It is not included by default, but we can help define it for critical or complex services.

Accessibility statement support

We can review or draft the technical content of your accessibility statement using the applicable national model. Your organisation remains responsible for approving, publishing and maintaining it. The European Commission’s model says its accuracy should be reviewed regularly and at least once a year; national rules may be more specific.

If you are still gathering the basic information, the free helper can create a first draft structure. Treat it as a starting point; the final statement should reflect real findings, known limitations and the applicable national requirements.

Use the statement helper

Official references

Standards information

Legal and standards references checked on 6 October 2026.

Get a scoped estimate

Send the website URL or procurement documents, country, target date and priority journeys. Within two business days, we either send a fixed-scope proposal or tell you exactly what information is still needed.