EN 301 549 Explained: Europe's Accessibility Standard

EN 301 549 is the harmonized European standard that defines technical accessibility requirements for information and communications technology, and it’s the standard that gives the European Accessibility Act its technical teeth. In practice, conforming to EN 301 549 is how an organization demonstrates EAA compliance, and its web content requirements are built directly on WCAG 2.1 Level AA. If you’re trying to figure out what “accessible” actually means for EAA purposes, EN 301 549 is the document with the answer.

What EN 301 549 is

EN 301 549 is a European standard (originally developed by ETSI, CEN and CENELEC) that specifies functional accessibility requirements for a wide range of ICT products and services. It was first published in 2014 and has been revised several times since, most notably to keep pace with updates to WCAG. It’s not limited to websites: the standard covers software, mobile applications, hardware such as self-service terminals and ticketing kiosks, electronic documents, and even accessibility requirements for support services like help desks and user documentation.

How it relates to WCAG

For web content, EN 301 549 doesn’t reinvent its own criteria. Version 3.2.1 incorporates WCAG 2.1 Level AA in full, meaning the web-facing part of EN 301 549 compliance is, functionally, WCAG 2.1 AA compliance. This is a deliberate design choice: it means an organization that has already invested in genuine WCAG 2.1 AA conformance has done most of the technical work EN 301 549 requires for its web properties, without needing a parallel, EU-specific checklist. A future revision, v4.1.1, is expected to bring the standard in line with WCAG 2.2, so it’s worth checking the specific version referenced in any contract or procurement document rather than assuming the mapping is static.

How it relates to the European Accessibility Act

The EAA is the legal instrument: it sets out which products and services are covered, who has to comply, and the enforcement timeline. EN 301 549 is the technical instrument that defines what “accessible” means for the purposes of demonstrating that compliance. Conforming to EN 301 549 creates a presumption of conformity with the EAA’s accessibility requirements, which is why organizations preparing for EAA enforcement (which began on June 28, 2025, with later transition deadlines of June 28, 2027 and June 28, 2030 for certain existing contracts and products) generally frame their compliance work as an EN 301 549 project rather than starting from the EAA text itself.

Why the mapping matters for penalties

EAA enforcement and penalties are set at the member state level, and reported maximum fines currently range from around €60,000 to roughly €900,000 depending on the country, with some states allowing additional daily penalties for continued non-compliance. Because EN 301 549 conformance is the practical evidence regulators and courts will look at, a documented EN 301 549 assessment (ideally one that includes manual testing, not only an automated scan) is the strongest position an organization can be in if a complaint arises.

Who this shows up for in practice

EN 301 549 mapping is most visible with vendors that build their positioning around EU compliance specifically. Wawsome explicitly maps its coverage to EN 301 549 and the EAA across several European markets, alongside its widget and monitoring tools. Eye-Able and AccessiWay similarly build their businesses around EN 301 549-aligned compliance for the German and Italian public sectors respectively, pairing a widget with manual audit work. For organizations that want the underlying technical testing done directly against WCAG success criteria rather than through a packaged EU-focused product, Deque Systems offers developer-facing testing tools and expert manual audits that map cleanly onto EN 301 549’s web content clauses, since both ultimately rest on the same WCAG baseline.

What’s covered beyond web content

The non-web clauses of EN 301 549 are easy to overlook if your accessibility work has been web-focused, but they matter for a lot of the products and services the EAA actually covers. There are specific requirements for hardware (physical operability, like ensuring a self-service ticketing terminal or ATM can be used without relying on fine motor control or color perception alone), for software applications outside the browser, for real-time text and captioning in communications services, and for the accessibility of documentation and support services that accompany a product. An organization selling banking terminals, e-book readers, or transport information systems into the EU needs to work through these clauses specifically; the WCAG-based web content section, while the most commonly discussed part of the standard, is only one chapter of it.

Documenting EN 301 549 conformance

Because EN 301 549 has editions aligned with WCAG, Section 508 and its own EU-specific requirements, it’s the standard referenced in the EU edition of a VPAT (Voluntary Product Accessibility Template), the same style of standardized conformance document used in U.S. federal procurement. Enterprise and public-sector buyers evaluating software or services for purchase in the EU increasingly expect a completed EN 301 549 VPAT as part of the sales process, not just a general accessibility claim in marketing material. If you’re a vendor selling into EU public-sector procurement, having this document ready, backed by real testing rather than an untested self-assessment, has become close to a practical requirement even where it isn’t universally mandated by name.

How EN 301 549 has changed over time

The standard has been revised repeatedly since its original 2014 publication, largely to keep its WCAG reference current as WCAG itself evolved from 2.0 to 2.1 and, eventually, 2.2. That revision pattern is worth understanding because it means EN 301 549 compliance isn’t a one-time technical target; a product assessed against an older version of the standard may need re-testing against a newer version if a contract, tender or renewal references it. Public-sector procurement in particular tends to cite a specific version number rather than “EN 301 549” generically, so it’s worth checking the exact version named in any tender document or framework agreement rather than assuming the most recent one applies automatically.

What EN 301 549 doesn’t cover on its own

Because EN 301 549 is a technical standard, it doesn’t tell you how to run an accessibility program, set internal policy, or handle user complaints; those are organizational decisions layered on top of the technical baseline. It also doesn’t replace the need for real user testing with assistive technology. Meeting the letter of a WCAG success criterion and having a website that actually works well for a screen reader or keyboard-only user are related but not identical goals, which is one reason manual review by someone experienced with assistive technology remains part of any serious EN 301 549 compliance effort, whether that testing is done in-house, through a testing vendor, or through a provider that bundles it with a widget.

The practical takeaway for most organizations is that EN 301 549 conformance work should be planned as an ongoing program, not a single project with a defined end date. Sites and products change continuously, and a passed assessment against one version of a page or app doesn’t guarantee the next release stays conformant unless accessibility checks are built into the regular development and content workflow, alongside periodic re-testing as the standard itself gets revised.