EN 301 549 (accessibility standard)

The full title is "Accessibility requirements for ICT products and services". For you as a shop or software operator, the standard is above all one thing: the benchmark against which authorities, market surveillance, clients and representative actions measure whether a digital offering is accessible. It is not a checklist for marketing purposes but a technical set of rules with testable requirements and associated conformity tests.

Who publishes the standard and on whose behalf

EN 301 549 originally came into being under mandate M 376 of the European Commission and was initially intended as a procurement standard for the public sector: authorities were to be able to describe accessibility in tenders in such a way that different testers would reach the same result. The first version, V1.1.1, appeared in February 2014. Only with the EU accessibility directives did it become a set of rules with legal leverage.

The decisive mechanism is called the presumption of conformity. A European standard becomes a "harmonised" standard when two conditions are met: it has been drawn up by one of the three standardisation organisations on behalf of the Commission, and its reference has been cited in the Official Journal of the European Union. Both points are explained in detail in the European Commission's overview of standards and harmonisation. Only citation in the Official Journal triggers the legal effect.

Not every version is harmonised

A common misconception is that every new version automatically applies. The opposite is the case: of the versions so far, only two have been harmonised – V2.1.2 in December 2018 and V3.2.1 on 18 August 2021, the latter by Implementing Decision (EU) 2021/1339, which amended Decision (EU) 2018/2048. The intermediate version V3.1.1 from November 2019 was never cited in the Official Journal and therefore had no direct legal effect at European level, even though it was technically usable.

Structure of the standard: clauses 4 to 14 and the annexes

In its current version V4.1.1, the standard consists of fourteen clauses and nine annexes. All requirement clauses are "self-scoping": they begin with the wording "Where ICT …" and only apply if the stated condition applies to your product. A pure online shop without video telephony therefore does not have to meet clause 6, but it must be able to justify why it is not applicable.

The annexes: this is where the legal mapping is

The annexes are not an add-on but the part that testers open first. Annex A contains two parts that make it possible to assess specific products and services against the directives. Annex B shows which technical requirement serves which functional performance statement. Annex C is normative and describes, for each individual requirement, what constitutes sufficient proof of conformity, expressly without prescribing a complete test methodology.

Decisive for legal application are the Z annexes: Annex ZA maps the requirements of the Web Accessibility Directive (EU) 2016/2102, Annex ZB those of Directive (EU) 2019/882 (European Accessibility Act, EAA), and Annex ZC the requirements of further directives under Annex I Section VI of the EAA. Annex ZB is divided into five tables: three for products, one for all covered services and one for specific services, including e-commerce.

Relationship to WCAG 2.1 and WCAG 2.2

Clause 9 of the standard contains no web requirements of its own but refers criterion by criterion to the W3C's WCAG. The numbering follows a simple rule: WCAG success criterion 1.4.3 becomes requirement 9.1.4.3. The standard itself makes it clear that meeting WCAG level AA is equivalent to meeting clauses 9.1 to 9.4 together with the conformance requirements of clause 9.6.

The version currently cited in the Official Journal, V3.2.1 (under the Web Accessibility Directive for public sector bodies), references WCAG 2.1 at level AA. This is the basis for the lower limit from which audits in Germany start in practice. The version V4.1.1, published in September 2026, on the other hand aligns clauses 9, 10 and 11 with WCAG 2.2. WCAG 2.2 is identical in content to ISO/IEC 40500:2025.

The six criteria added with WCAG 2.2

WCAG 2.2 adds nine new success criteria, six of which are at levels A and AA and therefore become mandatory for AA conformance:

• 2.4.11 Focus Not Obscured (Minimum), AA – an element focused via the keyboard must not be completely hidden by other content. Classic failure: the sticky header that covers the active form field when tabbing through.
• 2.5.7 Dragging Movements, AA – functions that require dragging movements need an alternative without dragging. This affects price sliders and image comparison controls.
• 2.5.8 Target Size (Minimum), AA – click and tap targets are at least 24 × 24 CSS pixels, unless one of the exceptions applies.
• 3.2.6 Consistent Help, A – help functions appear in the same relative position on all pages.
• 3.3.7 Redundant Entry, A – information already entered is not requested again in the same process but is pre-filled or offered for selection.
• 3.3.8 Accessible Authentication (Minimum), AA – no login step may require a cognitive function test without offering an alternative or assistance.

At the same time, one criterion is dropped: requirement 9.4.1.1 is marked as "Void" in version V4.1.1. It referenced WCAG criterion 4.1.1 Parsing, which was removed in WCAG 2.2 because the problems it addressed either no longer occur or are covered by other criteria. Anyone who still has audit reports with parsing findings lying around should be aware of this.

Versions and legal status: why V3.2.1 is not the EAA standard

This is where most articles on the web get it wrong. Version 3.2.1, cited in the Official Journal, was drawn up under standardisation request C(2017)2585 final (mandate M 554) for the Web Accessibility Directive (EU) 2016/2102, i.e. for public sector bodies. It is not an EAA standard, even though it is constantly cited as such in practice.

The first version created under the EAA mandate is V4.1.1. It was drawn up on the basis of standardisation request C(2022) 6456 final (standardisation mandate M 587), aligns the web clauses with WCAG 2.2, fundamentally revises the real-time text requirements in clause 6 and adds total conversation. Also new are the aforementioned Annex ZB, which maps the EAA requirements, and a clause A.2 on assessing specific products and services against the EAA.

ETSI published version EN 301 549 V4.1.1 in September 2026; it was adopted on 24 August 2026. The document itself formulates the legal position as a condition: only once it has been cited in the Official Journal of the European Union under Directive (EU) 2019/882 does compliance with the normative clauses listed in clause A.2 give rise to a presumption of conformity.

No date has been promised for citation in the Official Journal. As of the status checked here (11 October 2026), no version of EN 301 549 has been cited in the Official Journal under Directive (EU) 2019/882. Anything you read about a specific date is a forecast. The deadlines that V4.1.1 itself names only concern the national standardisation organisations: announcement by 30 November 2026, national adoption by 31 May 2027, withdrawal of conflicting national standards by 31 May 2028. These dates have nothing to do with the presumption of conformity.

What this means in practice for the BFSG

The Accessibility Strengthening Act (BFSG) has applied since 28 June 2025 and transposes the EAA into German law. Section 4 BFSG links the presumption of conformity to exactly the same condition as the European level: it only applies to harmonised standards "whose references have been published in the Official Journal of the European Union". As long as this has not happened for the EAA, there is no automatic presumption effect via EN 301 549 for offerings covered by the BFSG.

This does not make the standard meaningless; on the contrary. The BFSG ordinance requires in Section 3 BFSGV that the state of the art be observed and instructs the Federal Accessibility Agency to publish the relevant standards and conformity tables. The ordinance does not name a specific standard or WCAG version. In practice, EN 301 549 is the reference point for this state of the art, as a technical benchmark and not as a legal automatism. Anyone who complies with it has good arguments for meeting the substantive requirements; in case of doubt, however, they must prove this themselves instead of being able to rely on a presumption.

Under Section 1(3) BFSG, the services affected include "services in electronic commerce", i.e. the classic B2C online shop. Exempt are micro-enterprises providing services, defined as companies with fewer than ten employees and an annual turnover or annual balance sheet total of no more than two million euros. Pure B2B shops do not fall under the law because consumers are not the addressees; hybrid shops should document this distinction properly.

Public sector bodies: BITV 2.0 instead of the BFSG

For authorities, municipalities and other public sector bodies, it is not the BFSG that applies but the Barrier-Free Information Technology Ordinance. Section 3 BITV 2.0 works with the same construction: compliance with the requirements is presumed if offerings correspond to harmonised standards and these are named in the Official Journal. Because V3.2.1 is cited there for the Web Accessibility Directive, the presumption effect works in the public sector today, but not yet in the private sector. That is the practical difference between the two regimes.

EN 301 549 in an online shop: what you derive in concrete terms

The standard becomes a work plan as soon as you project it onto the purchase path. In Section 12 BFSGV, the BFSG ordinance names general requirements for services: information via more than one sensory channel, findable, understandable, in text formats that assistive technology can process. Section 19 BFSGV adds three points for e-commerce: information on the accessibility of the products sold, accessible identification, security and payment functions, and accessible authentication methods and electronic signatures.

A concrete example: criterion 9.3.3.8 in the login

Take requirement 9.3.3.8 of the standard, which refers to WCAG success criterion 3.3.8 Accessible Authentication (Minimum). Its wording requires that no step of a login process requires a cognitive function test, such as remembering a password or solving a puzzle, unless an alternative, a mechanism to assist, pure object recognition or identification of personal content is offered.

In practice, this means for a Shopware shop: a text CAPTCHA in the registration form is a violation if there is no non-cognitive alternative. So is a password field that prevents pasting from the clipboard via JavaScript; the WCAG expressly names copy and paste and password manager support as mechanisms that satisfy the criterion. Both are lines of code, not architectural questions. Together with 3.3.7 Redundant Entry, there is a further checkpoint: the delivery address from step two must not be requested a second time when the order is completed.

What automated tests can and cannot do

Automated testing tools such as axe, Lighthouse or WAVE reliably find what can be decided by machine: missing alt attributes, insufficient contrast values against the 4.5:1 threshold of criterion 1.4.3, missing form labels, broken heading hierarchies. They are the cheapest first filter and belong in every CI pipeline.

However, a large proportion of the criteria can only be assessed by humans. Whether an alternative text actually describes the purpose of the image, whether the focus order follows the meaningful sequence, whether an error message is understandable, whether 2.4.11 is met in the real behaviour of the sticky header: no scanner decides that. Annex C of the standard provides a sufficient verification procedure for each requirement but explicitly does not formulate a test methodology. A robust audit therefore combines automated scans, manual keyboard tests, screen reader samples and a review of the documents from clause 10. Anyone planning a new web application anyway is best advised to define WCAG 2.2 AA directly as an acceptance criterion.

Common misconceptions

• "EN 301 549 is just WCAG in European." Wrong: clauses 5 to 8 and 11 to 13 contain requirements for hardware, software, real-time text and support that do not appear in the WCAG at all.
• "We meet the standard, so we have legal certainty." Only partly. For services covered by the BFSG, citation in the Official Journal under the EAA, and thus the presumption effect, is still missing.
• "An overlay tool makes us compliant." Overlays address the symptoms that can be checked by machine, not the semantics in the DOM. None of the criteria mentioned is met as a result.
• "Accessibility is a project." Section 14(3) BFSG requires that the requirements are met permanently, expressly also when the harmonised standards change. Every theme update is therefore a reason to re-test.

The documentation obligation is also important: under Section 14(1) no. 2 BFSG, a service may only be offered if the provider has prepared the information in accordance with Annex 3 no. 1 and made it publicly available in an accessible form. Anyone who offers a service in breach of this requirement commits an administrative offence under Section 37(1) no. 8 BFSG; in this case, fines can reach up to one hundred thousand euros. The accessibility statement is therefore not an add-on but itself an obligation subject to fines.

For planning, this means: test your shop today at least against WCAG 2.1 AA and the clauses of EN 301 549 V3.2.1 applicable to you; in practice, this is the lower limit. At the same time, keep an eye on the six new criteria from WCAG 2.2: V4.1.1 builds on them, and as soon as this version is cited in the Official Journal under the EAA, the presumption of conformity will be linked to it. Anyone building against WCAG 2.2 today saves themselves a second pass; the effort for target sizes, obscured focus and login alternatives is considerably smaller in ongoing operation than in a downstream remediation project.