EN 301 549 – the European standard that makes digital accessibility measurable.

What EN 301 549 is – and why it goes beyond web guidelines alone

EN 301 549 is officially titled “Accessibility requirements for ICT products and services” and is the harmonised European standard for the accessibility of information and communication technology. It was developed jointly by the European standardisation organisations CEN, CENELEC and ETSI. Its scope is deliberately broader than that of a web accessibility guideline alone: it covers websites and mobile apps as well as software, documents, hardware, telecommunications equipment and support services.

The key area that most managers look at first is digital services. Yet this is precisely where the most common misconception lies: anyone who simply checks their website has only half understood the standard. An inaccessible PDF in the customer portal, a tariff calculator that cannot be operated using a keyboard, or a support chat without screen reader support are just as much covered by EN 301 549 as a contrast error in the page header.

From legislation to standard: how the BFSG, EAA and EN 301 549 work together

Laws set out obligations – but they rarely specify how these should be met from a technical perspective. EN 301 549 fills this gap. In Germany, the Accessibility Strengthening Act (BFSG), which transposes the European Accessibility Act into national law, requires certain products and services to be accessible. The European Accessibility Act has been in force since 28 June 2025, and EN 301 549 is regarded as the technical standard underpinning both sets of regulations.

In practical terms, this means that if your digital offering meets the requirements of EN 301 549, the legal obligation is generally deemed to have been fulfilled – this is known as the ‘presumption of conformity’. For the public sector, this requirement has long been established through the Web Accessibility Directive and BITV 2.0. With the BFSG, the same technical benchmark now also applies to large parts of the private sector: e-commerce, banking, insurance, telecommunications and transport services. The standard has thus evolved from a niche issue in the public sector into a binding benchmark for the market.

The presumption: the legal leverage behind the provision

The fact that the legal obligation is ‘generally deemed to have been met’ if you comply with EN 301 549 sounds like a formality. It is the most important tool that the standard provides you with.

EN 301 549 is a harmonised standard — it is referenced in the Official Journal of the EU. This is precisely what gives rise to the presumption of conformity: anyone who can demonstrate that their products and services are designed in accordance with the standard is presumed to meet the requirements of the legal act in which it is cited. This is not an argument you need to construct yourself, but rather the approach expressly provided for by the legislator.

The true value of this only becomes apparent in a crisis. Without reference to EN 301 549, in the event of a complaint or an inspection by market surveillance authorities, you would have to demonstrate in detail that your product meets the abstract requirements of the law — criterion by criterion, off the top of your head, under time pressure. With documented evidence in accordance with the standard, the balance shifts in your favour: you demonstrate compliance with the standard, and compliance with the law is presumed.

The true value of this only becomes apparent in a crisis. Without reference to EN 301 549, in the event of a complaint or an inspection by market surveillance authorities, you would have to demonstrate in detail that your product meets the abstract requirements of the law — criterion by criterion, off the top of your head, under time pressure. With documented evidence in accordance with the standard, the balance shifts in your favour: you demonstrate compliance with the standard, and compliance with the law is presumed.

EN 301 549 and WCAG – why the standard sets higher requirements than the guidelines

The two terms are often used synonymously, and this regularly leads to gaps in compliance evidence. The W3C’s WCAG (Web Content Accessibility Guidelines) are the internationally recognised basis for accessible web content. EN 301 549 adopts these criteria – and then adds its own, more stringent requirements on top. Specifically, the currently referenced version, EN 301 549 V3.2.1, fully incorporates WCAG 2.1 at Level AA. This means that every WCAG success criterion is also an integral part of the standard.

However, the standard does not stop there. Among other things, it sets out requirements for hardware, biometric procedures, speech output and real-time communication, as well as for software and documents that WCAG does not address at all. So, even if a site is ‘only’ WCAG-compliant, it may still fail an EN 301 549 audit – for example, because a PDF is not tagged in accordance with PDF/UA or because an application outside the browser contains barriers. In practical terms, this means that WCAG is the foundation and EN 301 549 is the building. Both must be evaluated.

How the standard is structured – the key chapters

EN 301 549 is structured in a modular way, and certain sections are particularly relevant for digital services. Chapter 5 brings together the generic requirements – principles that apply to almost every product, such as operability without the need for specific physical abilities or usability with assistive technologies. Chapter 9 is devoted to the web and refers directly to the WCAG success criteria; this is the part most people refer to when they talk about an ‘accessible website’. Chapter 10 focuses on non-web documents, such as PDFs, Office files and similar formats – this is often where the biggest hidden gap lies in public authorities and large organisations, as existing document archives are rarely checked. Chapter 11 deals with software, native apps and user interfaces outside the browser, and Chapter 12 makes it clear that documentation and support services – help pages, guides and customer service – must also be accessible.

The breadth of this issue is the reason why an automated scanner alone cannot provide a reliable assessment in accordance with EN 301-549. Tools can detect some technical errors, but they cannot assess whether a screen reader reads out the ordering process clearly or whether a complex document is structured logically.

Modular design: They do not comply with the entire standard, but with the relevant sections

At first glance, the list of chapters in EN 301 549 seems overwhelming, and we regularly hear the same phrase: ‘We’ll never manage that.’ But nobody has to. The standard has a modular structure, and depending on the products and services you offer, different chapters will apply to you — an online shop will have different requirements to a hardware manufacturer, and a bank will have different requirements to a streaming service. You do not need to comply with the entire standard, but only with the specific parts that apply to your offering.

The sequence of the standard also follows a logic that is worth understanding: it begins with the question of what people need to be able to do. Only then does the question arise as to how the relevant technology makes this possible. It is not the technology that sets the standard, but its use.

There is a downside to this approach: the scope must be right. Anyone who only checks the ‘Web’ chapter – simply because it is the best known – has not worked in a modular way, but has taken the easy option. The first step in any robust audit is therefore not a test, but an honest assessment: which chapters actually apply to us?

A case study: A service provider was convinced that a website thoroughly tested for compliance with WCAG met all the requirements. An audit against the full EN 301 549 standard revealed the shortcoming: all contractual documents and forms were available as PDFs that were neither tagged in accordance with PDF/UA nor otherwise made accessible, and the only support channel was a telephone hotline with no text-based alternative. The website was compliant, but the overall service offering was not.

Functional performance characteristics: the core of the standard

The conceptual core of EN 301 549 is missing from almost every superficial description — and it is no coincidence that it features right at the start of the standard: the functional performance characteristics. These do not describe technical details, but rather the overarching uses that a product must enable. These include, amongst others:

• Use without sight
• Use by people with impaired vision
• Use without colour perception
• Use without hearing
• Use by people with hearing impairments
• Use without the ability to speak
• Use with limited grip and operating ability
• Use by people with impaired cognitive function

This functional approach is more sensible than it sounds at first. It ensures that, in the end, it is not just a case of ticking off individual criteria, but that the product is actually usable by real people with real disabilities. A website may meet every single technical criteria and still fail because nobody without sight can use it effectively.

This is also why the standard can hardly be fully assessed without the perspective of real users. The functional requirements call for practical usability, not formal compliance — and this question cannot be answered by software, but only by a person who actually uses the service with their technology. This is precisely why, in our audits, we work with a panel of users of assistive technologies rather than relying on a standardised test report from the toolbox.

V3.2.1 today, V4.1.1 tomorrow: the version status of EN 301 549

Standards are not static documents, and EN 301 549 in particular warrants closer scrutiny. The most recently published version, which is legally referenced, is V3.2.1 from March 2021; it is based on WCAG 2.1. At the same time, the standardisation committees are working on the next version: version V4.1.1, which incorporates WCAG 2.2, is expected in 2026 and will only become binding once it has been referenced in the Official Journal of the EU.

For businesses, this leads to a clear strategic recommendation: those who are already testing for and rectifying issues in line with WCAG 2.2 today will avoid having to undergo a second, full re-audit once the new version of the standard comes into force. That is precisely why we at ifdb are already conducting audits against the current WCAG 2.2 standards – not against yesterday’s minimum requirements.

A case study: A client was unsure because their agency had implemented ‘WCAG 2.2’, whilst a consultant insisted on ‘WCAG 2.1 as per the standard’. Both were right in their own way — and the solution was simpler than either of them realised: WCAG 2.2 builds on 2.1 and adds further success criteria. There is one exception, and it is the reason for the confusion: Criterion 4.1.1 (Parsing) was removed in 2.2 as obsolete, because modern browsers and assistive technologies resolve the issue themselves. In practical terms, this means that anyone working to version 2.2 meets the standard referenced in the specification and is, at the same time, prepared for the upcoming version. The supposed version issue wasn’t an issue at all.”

Who EN 301 549 applies to – and why public tenders are based on it

The standard becomes mandatory in three ways, and the third is often overlooked.

Under the BFSG and the European Accessibility Act, it applies to private companies offering certain digital products and services — from online shops and banks to telecoms providers. Under the Web Accessibility Directive and the BITV 2.0, it applies to public sector bodies across Europe. Both approaches are well known.

Added to this is public procurement. Any company wishing to supply public sector clients must be able to demonstrate on a regular basis that its ICT products comply with EN 301 549 as being accessible — regardless of whether the company itself falls under the scope of the BFSG. For many B2B software providers, the standard is therefore not a matter of compliance, but simply a prerequisite for being allowed to bid in the first place. Those who cannot provide this evidence will watch as contracts go to competitors who can.

A case study: A software provider wanted to take part in a public tender but failed to meet a single requirement: proof of accessibility in accordance with EN 301 549. The product was technically sound, but no one had ever checked whether it met the standard — there was simply no documented evidence. The contract went to a competitor who was able to provide such evidence. In this case, accessibility was not a ‘nice-to-have’, but the entrance ticket.

There is no official seal: how reliable evidence is created

There’s one question that always comes up in every initial consultation: who actually determines whether we are compliant? The honest answer surprises most people: no official body does. There is no authority that issues an official certificate of compliance with EN 301 549. You must provide the evidence yourself.

In principle, this can be done by means of a self-declaration. However, a simple self-assessment is of little value in the event of a dispute — it is exactly what it says: your own assertion about yourself. The evidence only becomes robust through a thorough, documented assessment against the requirements of the standard. This is not a form of harassment, but rather the difference between ‘we believe we meet the standard’ and ‘we can prove it’. When in doubt, only the latter counts. Our guide to accessibility certification explains in detail what such evidence looks like.

And this is where automated tools reach a limit that cannot be overcome through optimisation. Software can detect whether an ‘alt’ attribute exists; only a human can determine whether the description actually helps a blind person. Such judgement calls accumulate across the entire scope of the standard — and the additional ICT requirements beyond the web are, in any case, beyond the scope of pure software testing. An automated test will quickly show you where your website stands. It’s a good starting point. However, it does not constitute full compliance with the standard.