The EU Web Accessibility Directive: A Practical Guide for Public-Sector Web Teams

The Web Accessibility Directive (2016/2102) applies to *public-sector bodies*: state, regional and local authorities, bodies governed by public law, and associations formed by them. In practice that means central-government departments, municipalities, public universities and schools, public hospitals, courts, regulators, and many publicly funded cultural and transport agencies.

Scope is broader than a single marketing site. It covers your public websites, but also intranets and extranets published or substantially revised after 23 September 2019, and your mobile applications. A few categories sit outside scope — for example, pre-recorded time-based media published before 23 September 2020, live time-based media, third-party content you neither fund, develop nor control, and certain archived documents — but you cannot assume an exemption applies. Each carve-out is narrow and should be documented, not presumed.

If your organisation also sells products or services to the public, note that those consumer-facing services may fall under the European Accessibility Act instead, which applies from 28 June 2025. The two regimes share a technical foundation, so the build work rarely differs — but the legal basis, deadlines and monitoring routes do.

The Directive does not spell out individual success criteria. Instead it presumes conformance when you meet the harmonised European standard EN 301 549, which for web content incorporates the Web Content Accessibility Guidelines at Level A and AA. So the engineering target is concrete: meet every applicable WCAG success criterion at A and AA, plus the EN 301 549 clauses for documents and mobile apps.

The EN 301 549 version cited in your member state's transposed law has tracked WCAG 2.1 Level A and AA. Building and testing to WCAG 2.2 Level A and AA is the safer, forward-looking target — it is also the baseline aligned with the European Accessibility Act — and version 2.2 added six criteria worth flagging for public-sector forms and service journeys:

• 2.4.11 Focus Not Obscured (Minimum, AA) — sticky headers and cookie banners must not hide the focused element.
• 2.5.7 Dragging Movements (AA) and 2.5.8 Target Size (Minimum, AA) — interactions must have a non-drag alternative, and targets should be at least 24x24 CSS pixels.
• 3.2.6 Consistent Help (A) and 3.3.7 Redundant Entry (A) — keep help in a consistent place and stop re-asking for data the user already gave.
• 3.3.8 Accessible Authentication (Minimum, AA) — do not force a cognitive puzzle to log in, which matters for citizen portals and benefit applications.

WCAG 2.2 also removed the old 4.1.1 Parsing criterion. On colour, the thresholds are unchanged and easy to verify: 4.5:1 for normal text, 3:1 for large text (at least 18pt, or 14pt bold) and for UI components and graphics. Many of the highest-frequency failures on government sites are mundane — unlabelled form fields, missing alt text, low contrast — and an automated scan will surface those before you commit time to manual review. Pair it with the accessibility checklist for the manual checks automation cannot see.

Every in-scope site and app must publish an accessibility statement in the prescribed model format. This is a specific document, and partial or vague statements are themselves a compliance gap. It must state one of three compliance levels — fully compliant, partially compliant, or non-compliant — and back that claim up.

• A clear statement of which standard you measured against (EN 301 549 / WCAG A and AA).
• A specific, honest list of non-accessible content and the reason: non-conformance, disproportionate burden, or content outside the Directive's scope.
• Accessible alternatives where you rely on a disproportionate-burden claim.
• A feedback mechanism so users can report problems and request inaccessible content in an accessible form.
• A link to the enforcement procedure in your member state, for when a complaint is not resolved satisfactorily.

Honesty is strategic here. A precise "partially compliant" statement that names known issues and gives dates is defensible; a blanket "fully compliant" claim that monitoring later contradicts is not. An accessibility statement generator produces the model structure clause by clause. Re-date the statement after every substantive change.

Unlike a one-off audit, the Directive builds in continuous oversight. Each member state designates a monitoring body that samples public-sector sites and apps on a recurring basis using a common EU methodology — a smaller in-depth sample tested thoroughly, and a larger simplified sample checked automatically. You do not choose whether you are reviewed; you choose how ready you are when you are.

Member states report results to the European Commission periodically. For your team, that means accessibility cannot be a launch-day milestone that decays afterward. Treat it as a maintained property of the codebase: re-run automated checks in CI, schedule keyboard and screen-reader testing before major releases, and keep a remediation log mapped to specific WCAG criteria so you can show progress between monitoring cycles.

A workable cadence for most public-sector teams: scan continuously and fix machine-detectable issues as they appear; run a structured manual review each quarter and after any redesign; and refresh the accessibility statement whenever its contents change. Done this way, the monitoring review becomes a confirmation of work already in hand rather than an emergency.