EN 301 549 is the standard that tells you what "accessible" means under the EU Web Accessibility Directive. The directive itself, Directive (EU) 2016/2102, is the law: since 2016 it has required the websites and mobile apps of public sector bodies across the EU to be accessible. It does not spell out the technical checks. Instead, Article 6 says content that meets the relevant harmonised standard is presumed to conform, and the standard the EU named for that job is EN 301 549. So the division of labour is clean. The directive sets the obligation and the process: publish an accessibility statement, offer a feedback route, submit to regular monitoring. EN 301 549 sets the pass/fail criteria, which for web content are WCAG 2.1 Level AA. If you run a government website, a university portal, or a city's mobile app in the EU, EN 301 549 is the yardstick your national monitoring body measures you against. This guide covers which version applies, what the directive asks of you beyond the code, and where meeting the standard still leaves gaps a scanner will never catch.
Is the Web Accessibility Directive the same as the European Accessibility Act?
No. They are two separate EU laws with different targets, and public sector teams get them confused constantly. The Web Accessibility Directive (2016/2102) covers the public sector: government departments, municipalities, public universities, hospitals, and the bodies that run public services. The European Accessibility Act, Directive (EU) 2019/882, covers the private sector, and applies to products and services like e-commerce, banking, and e-books.
The confusion is understandable because both lean on the same technical standard. EN 301 549 is the harmonised standard behind the public sector directive, and it is also the standard the EAA relies on for web and app conformity. Same yardstick, two different laws pointing at it. If you are a public body, the Web Accessibility Directive is your law. If you sell to consumers in the EU, the EAA is yours. Some organisations, a public transport operator with a commercial ticketing app for example, land under both.
What does EN 301 549 have to do with the Web Accessibility Directive?
It fills in the detail the law deliberately leaves blank. Article 4 of the directive states the outcome in four words borrowed from WCAG: websites and apps must be perceivable, operable, understandable, and robust. That is the whole technical requirement in the legal text. It names no success criteria and no contrast ratios.
Article 6 is where EN 301 549 enters. It creates a presumption of conformity: meet the relevant harmonised standard, or the relevant parts of it, and you are presumed to satisfy the accessibility requirements. The European Commission then names which standard counts. It did that in Commission Implementing Decision (EU) 2018/2048, which cited EN 301 549 in the Official Journal as the harmonised standard for the directive.
The practical effect is that "compliant with the Web Accessibility Directive" and "conforms to the relevant clauses of EN 301 549" mean the same thing for a public sector website. For web content, those clauses sit in Chapter 9 of the standard, which is WCAG 2.1 Level AA renumbered with a "9." prefix. Clause 9.1.4.3 is WCAG 1.4.3 Contrast (Minimum); clause 9.2.4.7 is WCAG 2.4.7 Focus Visible. Mobile apps pick up Chapter 11 on top.
Which version of EN 301 549 applies to the public sector?
Today it is EN 301 549 v3.2.1, published in March 2021. The version matters, because the law tracks a specific edition of the standard rather than "whatever is newest". The original 2018 decision cited an earlier version, and Commission Implementing Decision (EU) 2021/1339 amended it in August 2021 to reference v3.2.1 instead. That is the edition your monitoring body works from now.
A newer draft, EN 301 549 v4.1.0, went out for public comment in November 2025 and is expected to bring WCAG 2.2 into the standard. Until a version citing WCAG 2.2 is published in the Official Journal, the working bar for the public sector stays at v3.2.1 and WCAG 2.1 AA. I'd still design new public services against WCAG 2.2 now. The extra criteria, accessible authentication and a 24-by-24-pixel minimum target size among them, are cheap to build in from the start and painful to retrofit once the standard moves. Our WCAG checklist tracks 2.1 AA and flags where 2.2 adds something new.
What must a public sector body actually do?
Meeting the code is one part. The directive attaches a process around it, and two of those obligations trip up teams that focused only on the scan.
The first is the accessibility statement. Article 7 requires every in-scope site and app to publish a detailed, current statement of how accessible it is, including the parts that fall short and any accessible alternatives. This is not free text. Commission Implementing Decision (EU) 2018/1523 sets a model template that member states adopt, so monitors know exactly what to look for. The statement also has to carry a feedback mechanism: a way for any user to report a barrier, plus a link to the enforcement procedure if the body does not respond. You can draft a compliant one with our accessibility statement generator.
The second is honesty about scope. A statement that claims full conformity while the site has unlabelled form fields is worse than one that lists the gaps, because monitors read these documents and the whole point is to be truthful about what works. State what conforms, what does not, and what you are doing about it.
Article 5 allows one relief valve: the disproportionate burden exemption. A body can scope out a requirement where meeting it would impose a genuinely disproportionate load, but it has to assess that, document it, and still provide the information by another route on request. It is a reasoned exception, not a blanket opt-out.
How is public sector accessibility monitored?
Member states monitor it themselves and report to Brussels on a fixed cycle. Article 8 sets this up, and Commission Implementing Decision (EU) 2018/1524 defines the method. There are two depths of check. A simplified method runs mostly automated tests across a broad sample of sites. An in-depth method puts a human through whole user journeys with assistive technology, testing the criteria a scanner cannot reach.
Each member state designates a national monitoring body, samples public sector sites and apps, and files a report to the European Commission. The first reports were due by 23 December 2021, with a fresh report every three years after that. The reports cover monitoring results, how often the feedback and enforcement mechanisms were used, and the training and awareness work behind them. This is the enforcement backbone: unlike a private site that might only hear from a monitor after a complaint, an in-scope public body sits in a sampling frame that gets checked on a schedule.
The compliance dates that feed this cycle were staggered. New public sector websites, meaning those published after 23 September 2018, had to comply by 23 September 2019. Existing websites had until 23 September 2020. Mobile apps had until 23 June 2021. Those dates have all passed, so every in-scope site and app is expected to be accessible today, not working toward it.
Does meeting EN 301 549 make my public sector site compliant?
For the web clauses, conforming to EN 301 549 v3.2.1 is what the directive asks of you. The catch is proving you actually conform, because a large share of the standard cannot be checked by machine. Deque's analysis of more than 2,000 audits found automated testing caught about 57% of issues by volume, and estimates based on how many success criteria a scanner can even evaluate put the figure closer to 30% (Deque). The rest, keyboard traps, focus order, meaningful alt text, form errors announced to a screen reader, needs a person to confirm.
That is also why no scanner or overlay widget can declare your site conformant on its own. Claiming otherwise is what earned the overlay vendor accessiBe a $1 million order from the US Federal Trade Commission for representing that its product made sites WCAG compliant (FTC). For a public body under a monitoring regime, that risk is sharper still, because the in-depth method is designed to find exactly the barriers automation misses. The honest workflow is the same as it has always been: scan to find the machine-detectable issues, fix them, review the rest by hand, and record where you stand in your published statement.
Frequently asked questions
Is EN 301 549 mandatory for the public sector?
Effectively, yes. The Web Accessibility Directive requires public sector websites and apps to be accessible, and EN 301 549 is the harmonised standard that gives a presumption of conformity. Meeting the relevant clauses is the recognised way to demonstrate compliance, so in practice the public sector works to EN 301 549.
Which WCAG version does the Web Accessibility Directive require?
WCAG 2.1 Level AA, through EN 301 549 v3.2.1. That is the version of the standard currently cited in the Official Journal. A draft update aligning with WCAG 2.2 is in progress, but 2.1 AA is the working requirement until a new version is formally referenced.
What is the difference between the Web Accessibility Directive and the EAA?
Scope. The Web Accessibility Directive (2016/2102) covers public sector websites and mobile apps. The European Accessibility Act (2019/882) covers private sector products and services. Both use EN 301 549 as the technical standard, which is why they are easy to mix up.
Do public sector bodies need an accessibility statement?
Yes. Article 7 of the directive requires a published, regularly updated accessibility statement following the model set in Commission Implementing Decision (EU) 2018/1523, including a feedback mechanism and a link to the enforcement procedure.
Who checks whether a public sector site complies?
Each EU member state designates a national monitoring body. It samples public sector sites and apps using the methodology in Commission Implementing Decision (EU) 2018/1524 and reports results to the European Commission every three years.
Check your public sector site against WCAG 2.1 AA
Since the web part of EN 301 549 is WCAG 2.1 AA, the useful first step is to measure your site against that bar. Run a free scan to surface the machine-detectable issues on your key pages and public service journeys, then work through the manual checks the monitoring method will also apply. You will have a real baseline for the web clauses of EN 301 549, and the evidence to write a truthful accessibility statement instead of a guess.
Pavel Charkasau, founder, wcagc.com. Last updated 24 July 2026.
Sources
- Directive (EU) 2016/2102, EUR-Lex — the Web Accessibility Directive: scope, Article 4 requirements, Article 5 disproportionate burden, Article 6 presumption of conformity, Article 7 accessibility statement, Article 8 monitoring, and the compliance deadlines. Accessed 24 July 2026.
- Commission Implementing Decision (EU) 2018/2048, EUR-Lex — cited EN 301 549 as the harmonised standard for the directive. Accessed 24 July 2026.
- Commission Implementing Decision (EU) 2021/1339, EUR-Lex — amended the 2018 decision to reference EN 301 549 v3.2.1. Accessed 24 July 2026.
- Commission Implementing Decision (EU) 2018/1523, EUR-Lex — model accessibility statement. Accessed 24 July 2026.
- Commission Implementing Decision (EU) 2018/1524, EUR-Lex — monitoring methodology and reporting arrangements. Accessed 24 July 2026.
- European Union accessibility policy overview, W3C Web Accessibility Initiative — relationship between the directive, EN 301 549, and the implementing decisions. Accessed 24 July 2026.
- EN 301 549 v3.2.1 (2021-03), ETSI — Chapter 9 incorporation of WCAG 2.1 AA and Chapter 11 for mobile software. Accessed 24 July 2026.
- Automated testing identifies 57% of accessibility issues, Deque — automated coverage figures. Accessed 24 July 2026.
- FTC approves final order requiring accessiBe to pay $1 million, Federal Trade Commission — deceptive WCAG-compliance claims. Accessed 24 July 2026.