Government Website Accessibility: The EU Directive, EN 301 549 and Your Obligations

The Web Accessibility Directive (Directive (EU) 2016/2102) applies to the websites and mobile applications of public-sector bodies: state, regional and local authorities, and bodies governed by public law. It reaches public-facing pages, intranets and extranets, office document formats such as PDFs, and third-party content embedded in your pages. There are narrow exemptions (for example, certain pre-recorded media published before applicable deadlines), but the default assumption should be that your service is in scope.

The Directive does not invent its own technical rules. It points to a harmonised European standard, EN 301 549, which in turn references the Web Content Accessibility Guidelines (WCAG). Meeting the relevant WCAG success criteria is how you demonstrate conformance. This is separate from the European Accessibility Act, Directive (EU) 2019/882, whose requirements apply from 28 June 2025 and which targets private-sector products and services such as e-commerce, banking and e-books. Many organisations are touched by both, but the public-sector Directive is the one that governs government sites.

EN 301 549 is the technical anchor for government website accessibility across the EU. For web content it adopts WCAG Level A and Level AA as the conformance baseline; the current reference is WCAG 2.2. WCAG is built on four principles: content must be Perceivable, Operable, Understandable and Robust.

WCAG 2.2 added several success criteria that public-sector teams should test against explicitly:

• 2.4.11 Focus Not Obscured (Minimum, AA) — the keyboard focus indicator must not be entirely hidden behind sticky headers, cookie banners or chat widgets.
• 2.5.7 Dragging Movements (AA) — any drag action (sliders, map panning, reordering) needs a single-pointer alternative such as tap or click.
• 2.5.8 Target Size (Minimum, AA) — interactive targets should be at least 24 by 24 CSS pixels, or have adequate spacing.
• 3.2.6 Consistent Help (A) — help links, contact details or chat must appear in the same relative order across pages.
• 3.3.7 Redundant Entry (A) — do not force users to re-enter information they already provided in the same process.
• 3.3.8 Accessible Authentication (Minimum, AA) — do not rely on a cognitive test, such as solving a puzzle or transcribing characters, as the only way to log in.

WCAG 2.2 also removed the old 4.1.1 Parsing criterion, which is now obsolete because modern browsers handle the malformed-markup cases it addressed. Criteria such as 2.4.13 Focus Appearance remain Level AAA and sit above the legal baseline, though they are good practice.

In practice, a handful of issues account for the majority of conformance failures on public-sector services. Prioritise these:

• Colour contrast. Body text needs a ratio of at least 4.5:1; large text (18pt, or 14pt bold) and meaningful UI components and graphics need 3:1 (WCAG 1.4.3 and 1.4.11). Government palettes and link colours frequently fall short.
• Form labels and errors. Every input needs a programmatic label, and errors must be announced and described — critical for tax filings, benefit applications and appointment booking.
• Keyboard operability. Every function must work without a mouse, with a visible focus order. Test menus, date pickers and modal dialogs, which are common trap points.
• PDF documents. Tagged structure, correct reading order and real text (not scanned images) are required for the policy documents and forms that dominate government sites.
• Meaningful alt text on charts, maps, scanned notices and infographics that carry information.

The Directive requires every in-scope website and app to publish an accessibility statement in a prescribed model format, set out in Commission Implementing Decision (EU) 2018/1523. A generic 'we care about accessibility' paragraph does not satisfy it. Your statement must include:

• A clear compliance status: fully compliant, partially compliant, or non-compliant with EN 301 549.
• A specific, honest list of non-accessible content and the reason — non-conformance, a disproportionate-burden claim, or content outside scope.
• A feedback mechanism so users can report barriers and request information in an accessible format.
• A link to the enforcement (complaints) procedure of the relevant national authority, for when a response is unsatisfactory.
• The date of preparation and of the last review, plus the method used (self-assessment or third-party evaluation).

Crucially, 'disproportionate burden' is not a blanket excuse — you must justify it per item with an actual assessment, and you cannot rely on it merely because of cost or lack of priority. You can draft and structure yours with the accessibility statement generator.

The Directive sets up ongoing monitoring, not a one-off certification. Each member state designates a monitoring body that samples public-sector sites and apps periodically using a defined methodology — a more detailed evaluation for some sites and a simplified check across a larger sample. Member states report results to the European Commission. Penalties and enforcement vary by country, but persistent non-compliance can lead to formal complaints, corrective orders and reputational consequences.

Two obligations are continuous. First, the feedback mechanism in your statement must actually work — someone must monitor it and respond within a reasonable period, including providing the requested content in an accessible form. Second, you must keep the statement current as your site changes; a statement that describes a site from three redesigns ago is itself a finding. Build accessibility into your release process so new components are checked before they ship.

You do not need a year-long programme to start. A pragmatic sequence works for most public-sector teams:

• Run an automated baseline scan to find high-volume, machine-detectable issues. Start a free check with AccessScan to surface contrast, label and structure problems across key templates.
• Follow up with manual keyboard and screen-reader testing on your most-used journeys — login, search, forms and payment.
• Triage findings against the WCAG 2.2 AA criteria and fix the journeys that carry statutory services first.
• Document residual issues honestly and publish or update your accessibility statement.
• Schedule re-testing on every significant release so regressions are caught before they reach the public.

Automated tools catch a meaningful share of issues quickly, but they cannot judge whether a focus order makes sense or whether alt text is accurate — manual testing remains essential. The same baseline applies whether your service sits under the public-sector Directive or, for adjacent commercial offerings, the European Accessibility Act.