EN 301 549: The European Standard for Digital Accessibility

1. What EN 301 549 is and where the standard comes from

EN 301 549 is a harmonized European standard for the accessibility of information and communication technology, published by the European standards body ETSI together with CEN and CENELEC. It originates from a mandate issued by the European Commission (Mandate 376), which tasked the European standards organizations with developing common accessibility requirements for the public procurement of ICT products and services. The first version appeared in 2014 and has been revised several times since, most notably in version 3.2.1, to bring it in line with WCAG 2.1.

Unlike WCAG, which covers web content exclusively, EN 301 549 spans a much broader field: websites and mobile applications as well as hardware, operating systems, documents, real time communication, and even support documentation. For store owners and agencies working in the Magento ecosystem, the practical takeaway is that this standard eventually shows up in every procurement process involving a public buyer and in every conformance check under the BFSG, even though everyday conversation usually only mentions WCAG.

2. The relationship to WCAG 2.1 and 2.2

Clause 9 of EN 301 549 covers web content and adopts the success criteria of the Web Content Accessibility Guidelines almost unchanged as a normative part of the standard. Specifically, the current version references WCAG 2.1 at conformance level AA as the minimum requirement for web content, with individual success criteria copied directly from the WCAG specification and given their own clause numbering, for example 9.1.1.1 for WCAG criterion 1.1.1 Non-text Content. Anyone testing against WCAG 2.1 AA is therefore already testing the core of clause 9.

The crucial difference is that EN 301 549 does not replace WCAG, it embeds it in a larger normative framework. WCAG exists purely as a guideline with no legal force of its own, while EN 301 549, thanks to its status as a harmonized standard published in the EU Official Journal, becomes a document whose compliance triggers a presumption of conformity against legal requirements such as the BFSG. An update toward WCAG 2.2 is already on the horizon but had not yet been finalized as a harmonized standard at the time this article was written, so projects should keep both versions in view.

3. What goes beyond plain WCAG testing

The scope of EN 301 549 reaches far beyond web content. Clause 5 sets out generic requirements that apply to practically any ICT, covering topics such as operability without vision or with limited fine motor control. Clauses 6 through 8 address two way communication, video, and hardware aspects such as controls, key layout, and biometric recognition. Clauses 10 and 11 focus on non web documents, such as PDF invoices, and on software itself, whether it runs in a browser or natively.

Clauses 12 and 13 are especially relevant for online stores: they require documentation and support to be accessible as well. A store whose withdrawal form exists only as an image based PDF without a text layer, or whose customer service can only be reached by phone with no alternative channel, can violate EN 301 549 even if the website itself is fully WCAG conformant. Web content testing alone systematically misses these requirements, because it naturally focuses on the page's HTML output.

4. Scope within public procurement

EN 301 549 was originally designed primarily for public procurement: public buyers in the EU must reference this standard when tendering for ICT products and services, so that the technology they buy is usable by people with disabilities. Agencies or software houses bidding on a tender through the TED portal will regularly find a direct reference to EN 301 549 as a binding technical specification in the procurement documents, often paired with a request for a VPAT or conformance report as supporting evidence.

This procurement logic now radiates well beyond the public sector. EU Directive 2016/2102 on accessible public sector websites also references EN 301 549 as its technical benchmark, and many companies that supply public buyers themselves now require their own suppliers and digital agencies to demonstrate EN 301 549 conformance in order to protect their own supply chain. A Magento store owner who also serves B2B customers from the public sector should not underestimate this ripple effect.

5. The link to the BFSG and the presumption of conformity

Germany's Barrierefreiheitsstärkungsgesetz transposes the European Accessibility Act into national law and requires affected businesses to be accessible according to the state of the art, without spelling out a final technical checklist of its own. This is where EN 301 549 comes in: once the European Commission publishes a harmonized version of the standard in the Official Journal, compliance with it triggers what is known as a presumption of conformity. A company that demonstrably works to EN 301 549 is then, in case of doubt, considered legally compliant without an authority needing to check every single BFSG requirement individually.

In practice this means a store that only tests against WCAG 2.1 AA covers most of the technical substance of EN 301 549 but not the full presumption of conformity, because documentation, support channels, and any hardware in use, such as point of sale systems, are part of the standard as well. Anyone aiming for legal certainty under the BFSG should therefore treat EN 301 549 as the more complete reference document, with WCAG as its central but not sole building block.

6. The structure of the standard at a glance

EN 301 549 is organized into clearly separated clauses, each with its own clause numbering. Clause 4 sets out functional performance requirements that describe what a person with a given impairment must be able to accomplish, such as operation without vision or with limited hearing, independent of the specific technology involved. Clause 5 translates these requirements into generic technical provisions that apply to practically any ICT, covering keyboard operability, biometric authentication, and status indicators.

Building on that foundation, clauses 6 through 13 address specific technology areas: two way communication, video, hardware, web, non web documents, software, documentation and support, and ICT in emergency situations. This modular structure allows a project to pull only the relevant clauses for a given product: a pure online store without its own hardware mainly needs to watch clauses 4, 5, 9, 11 for apps, plus 10, 12 and 13, while clauses 6 through 8 usually stay irrelevant for it.

7. Why WCAG testing alone is not enough

A WCAG audit typically tests automatically and manually against the 50 success criteria at levels A and AA and returns a list of concrete violations in the HTML output. This method is necessary but not sufficient for EN 301 549 conformance, because it systematically leaves out questions like the accessibility of PDF invoices, confirmation emails, support chat widgets, or phone reachability. A store can present a technically flawless WCAG audit and still fail several clauses of EN 301 549, simply because the test methodology is narrower than the standard.

On top of that, EN 301 549 describes its own test procedure in an annex that goes beyond a pure success criteria check and, among other things, calls for documented test methods and evidence for every applicable clause. Anyone pursuing an EN 301 549 presumption of conformity therefore needs, in addition to the WCAG test report, a structured mapping of their own test results to the standard's clauses, usually in the form of a VPAT or Accessibility Conformance Report that bridges the gap between plain web testing and full standard conformance.

8. Demonstrating conformance for a Magento store in practice

For a Magento store, a two step approach works well: first, a complete WCAG 2.1/2.2 AA audit of category pages, the product detail page, the cart, and checkout, complemented by automated regression tests. Second, these results are mapped to the relevant clauses of EN 301 549, in particular clause 9 for web, clause 11 for native apps where they exist, and clauses 10, 12 and 13 for PDF documents, order confirmations, and support reachability. This mapping can be documented in a structured, machine readable format.

The following structure shows what a single entry in such a mapping can look like, here as a simplified JSON example documenting one reviewed criterion inside an internal evidence system that links WCAG results to EN 301 549 clauses.

{
  "clause": "9.1.1.1",
  "wcagCriterion": "1.1.1 Non-text Content",
  "level": "A",
  "conformance": "Supports",
  "testMethod": "Automated scan + manual sampling",
  "evidence": "audit-report-2026-08.pdf, section 3.2",
  "remarks": "All product images have alt text, icon buttons carry aria-label"
}

9. Common misconceptions and pitfalls

The most common misconception is that WCAG 2.1 AA conformance automatically equals EN 301 549 conformance. That holds largely true for the web portion of the standard but entirely ignores the remaining clauses. A second widespread mistake is overlooking support documentation and order confirmation emails altogether, even though clause 12 explicitly requires this content to be provided in an accessible format too, for example as a tagged PDF or a plain HTML email rather than a scanned image.

A third pitfall concerns currency: because EN 301 549 is revised regularly and the harmonized version published in the EU Official Journal can lag behind the standard's actual latest edition, companies should check the currently valid harmonized version at every major audit rather than relying on a report produced once. Given that WCAG 2.2 is expected to feed into a new edition of the standard in the foreseeable future, a periodic look at the official ETSI publications pays off far more than a one time check.

10. Summary

11. FAQ: EN 301 549: Key Facts at a Glance