EU Web Accessibility Directive: Public Sector Software and WCAG 2.2

The EU Web Accessibility Directive (WAD, Directive (EU) 2016/2102) requires EU public-sector bodies to make their websites and mobile apps accessible to people with disabilities, measured against the harmonized European standard EN 301 549. It is the accessibility law for public-sector software, while the European Accessibility Act (EAA) covers private-sector products and services. The distinction determines which deadlines, standard version, and monitoring regime apply.

This guide explains which law governs public-sector software, which version of EN 301 549 is in force, what the Web Content Accessibility Guidelines (WCAG) 2.2 require in practice, and how to build a public-sector product so accessibility is built in from the start rather than fixed afterward. It is written for product owners and procurement leads.

Atta Systems builds government and public-sector software for public bodies and international organizations, including the World Bank and UNEP-WCMC, where compliance requirements are written into the brief.

EU Web Accessibility Directive vs European Accessibility Act: which applies

The Web Accessibility Directive governs public-sector software, and it is easy to confuse with the European Accessibility Act because both point to the same technical standard. The deciding question is who operates the service.

The WAD covers public-sector bodies, and its website obligations took effect in stages. Websites published on or after September 23, 2018 had to comply from September 23, 2019; websites published before that date had to comply from September 23, 2020; and mobile applications had to comply from June 23, 2021. The EAA (Directive (EU) 2019/882) covers private-sector products and services such as e-commerce, consumer banking, e-books, and transport ticketing, and has applied since June 28, 2025.

If a government department, agency, municipality, or other public body will operate the service, the governing instrument is the WAD as transposed into that member state’s national law. The EAA matters at the edges, for example, where a public body procures a product that falls within EAA scope, but it does not replace the WAD for public-sector websites and apps. Building to the EAA alone can leave a public body short of the monitoring and reporting duties the WAD imposes.

The two laws at a glance

EN 301 549: which version is in force (v3.2.1 vs v4.1.1)

EN 301 549 is the harmonized European standard both laws point to, and it turns the legal duty into testable requirements. It incorporates WCAG and adds requirements WCAG does not cover, such as those for real-time communication and hardware. The standard is mid-transition, so the version matters.

As of October 2026, EN 301 549 v3.2.1 is the version that carries presumption of conformity. For web content, it maps to WCAG 2.1 Level AA, including success criterion 4.1.1 Parsing.

ETSI published EN 301 549 v4.1.1 on September 2, 2026. It adopts WCAG 2.2 Level AA, incorporates the six Level A and AA success criteria WCAG 2.2 added over 2.1, revises the user-preferences and real-time-communication clauses, and maps its requirements to the EAA in its annexes. v4.1.1 carries no presumption of conformity until it is cited in the Official Journal of the EU, and that citation is expected in late 2026. Until then, v3.2.1 remains the legal reference.

The practical approach for a build starting now is to target WCAG 2.2 Level AA, because v4.1.1 is close to becoming the reference, and to meet 4.1.1 Parsing as well while v3.2.1 remains in force. WCAG 2.2 removed Parsing as obsolete, so a product built strictly to WCAG 2.2 could pass it and still miss a requirement of the currently cited standard. Meeting WCAG 2.2 alone doesn’t mean you’ve met EN 301 549, because the standard’s real-time communication and hardware clauses sit outside WCAG.

What WCAG 2.2 requires, by principle

WCAG 2.2 is organized under four principles, known by the acronym POUR: Perceivable, Operable, Understandable, and Robust. Level AA is the conformance level EN 301 549 uses for both EU laws. Here is what each principle asks of a public-sector product, in build terms.

• Perceivable: users must be able to perceive the information. Text alternatives for images, captions for video, sufficient color contrast (4.5:1 for normal text at AA), and content that still works when text is resized to 200 percent.
• Operable: users must be able to operate the interface. Everything works with the keyboard alone, the focus order is logical, and the focus indicator is visible; nothing flashes in a way that can trigger seizures, and users have enough time to complete tasks.
• Understandable: content and operation must be understandable. Plain language, predictable navigation, clearly labeled form fields, and error messages that say what went wrong and how to fix it.
• Robust: content must work reliably with assistive technologies. Valid, semantic markup and the correct name, role, and value for every interactive component, so screen readers and other tools can interpret it.

WCAG 2.2 adds nine success criteria over 2.1. Three are at Level AAA; the six at Levels A and AA are Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry, and Accessible Authentication (Minimum). The last two matter most for government services. Redundant Entry means a user should not have to re-enter information already provided in the same process. It is easier to meet when a service pre-fills data the government already holds from national registers, an approach covered in integrating with government digital infrastructure. Accessible Authentication means login cannot depend on a cognitive function test, such as transcribing a code or solving a puzzle, unless an alternative or assistance is available.

Building public-sector software to meet the standard

Public-sector accessibility work is cheapest when it starts with the architecture. Scheduled as a pre-launch audit, it arrives after the expensive problems are built in. The work breaks into four stages.

1. Put it in the contract and the definition of done. Name EN 301 549 and WCAG 2.2 Level AA as acceptance criteria. If accessibility isn’t a condition of sign-off for each story, it tends to get deferred.
2. Choose an accessible component foundation early. Many Level AA failures sit in custom interactive widgets such as date pickers, combo boxes, modal dialogs, and data tables. Starting with a tested accessible component library and limiting bespoke controls removes whole categories of defects before you write them.
3. Test continuously, with automation and with people. Automated tools such as axe-core or Lighthouse belong in continuous integration (CI), but only a minority of WCAG success criteria can be fully tested automatically. The rest need manual keyboard and screen-reader testing and, where the budget allows, testing with disabled users. An automated pass alone does not show that a product is usable.
4. Write and maintain the accessibility statement. The WAD requires a published statement that declares conformance status, lists known non-accessible content with reasons, and gives users a feedback mechanism and an enforcement contact. It is a legal document and must be kept current with each release.

Why accessibility is a procurement requirement for public-sector software

For public-sector buyers, accessibility is written into the tender. A vendor that cannot show a working accessibility process, an accessibility statement from a prior build, or how it tests with assistive technology poses a procurement risk because the buyer assumes the legal obligation once the service goes live. Under the WAD, member states monitor public-sector websites and apps periodically and report the results to the European Commission, so the cost of non-conformance falls on the public body, which is why buyers move the requirement into the contract. International organizations apply the same test, scoring evidence of accessibility conformance alongside data protection, as set out in what international organizations evaluate in a software vendor.

For a vendor bidding on public-sector work, accessibility belongs in the technical proposal: named standards, a test approach, and evidence from past delivery, given the same weight as security or data protection. In UN procurement, the technical proposal for a UN software tender is scored against criteria published in the solicitation, and for public-sector software accessibility is frequently one of them.

Atta Systems’ public-sector delivery shows how these requirements arrive. For the World Bank, Atta Systems built e-Cuib, a platform that supports closing large residential centers for children in Romania by collecting data on children, centers, and closure plans for center supervisors, staff, and data collection consultants. The project defined GDPR and legal compliance as requirements and handed the platform over to the Romanian government.

For the UN Environment Programme World Conservation Monitoring Centre (UNEP-WCMC), Atta Systems built the Species+ app, which serves those responsible for implementing the CITES and CMS conventions, including officers on the front line of enforcing wildlife trade legislation, and gives users in the field species search, detailed species information, and offline access. In both projects, the commissioning institution set the requirements, and they had to be met at delivery, which is the position accessibility puts every public-sector vendor in.

Frequently asked questions

Atta Systems builds government and public-sector software, including systems for the World Bank and UNEP-WCMC.

Its work covers public bodies and international organizations whose software has to meet accessibility, data protection, and procurement requirements.