When the BFSG refers to the "recognized rules of technology", one concrete document sits behind that phrase: the harmonized European standard EN 301 549. It is the bridge between the abstract legal right to accessibility and the technical success criteria that developers actually implement. Around 87 million people (European Commission) in the EU live with a disability, and the European Accessibility Act has made removing digital barriers mandatory since 28 June 2025 (European Commission: European Accessibility Act). Anyone who wants to understand what a conformity claim under the BFSG really covers needs to know the chain from directive to standard to WCAG.
Key takeaways
- The chain of rules: Directive (EU) 2019/882 sets the frame, the BFSG makes it binding in Germany, and EN 301 549 supplies the testable requirements, referring to WCAG for web content.
- Harmonised standards carry legal weight: meeting the relevant clauses creates a presumption of conformity with the statutory requirements (Article 15 of Directive 2019/882), leaving proof of the opposite to the authority.
- The standard spans ten chapters: web (9), non-web documents such as PDF (10), desktop and mobile software (11), hardware such as terminals and kiosks (8), documentation and support (12) and two-way voice with real-time text (6).
- The version in force is V3.2.1 of March 2021 with WCAG 2.1 AA; V4.1.1, planned for 2026, raises web requirements to WCAG 2.2 AA and reworks real-time text in clause 6.2 (ETSI EN 301 549).
- WCAG 2.2 added nine new success criteria in October 2023 (W3C Web Accessibility Initiative), covering focus visibility, target size and accessible authentication among others; remediation projects can plan them in now.
- Evidence covering the website alone falls short: 94.8 percent of home pages showed WCAG failures, averaging 51 errors, and 96 percent of them fall into six categories (WebAIM Million Report, 2025). Documents, apps and support belong in the test list.
From the Directive to the Standard: the Chain
Digital accessibility in Europe follows a clear hierarchy. At the top sits Directive (EU) 2019/882, better known as the European Accessibility Act (EAA). It defines which products and services must be accessible, such as online shops, banking services, e-books, ticket machines and electronic communication services. As a directive, however, the EAA does not address companies directly but the member states, which transpose it into national law. In Germany, this happens through the Barrierefreiheitsstärkungsgesetz (BFSG).
Neither the directive nor the BFSG describes in detail how an accessible button or a usable form must look technically. Both formulate functional requirements: content must be perceivable, operable, understandable and robust. Translating these principles into testable technical criteria is the job of the EN 301 549 standard. It is maintained by the European standardization organizations ETSI, CEN and CENELEC and is the reference point that supervisory authorities rely on.
- Directive (EU) 2019/882 (EAA): defines scope and functional accessibility requirements at EU level.
- Barrierefreiheitsstärkungsgesetz (BFSG): transposes the directive in Germany and makes it binding for companies.
- EN 301 549: provides the concrete, testable technical requirements and references the WCAG for web content.
- WCAG 2.x AA: the actual success criteria for websites, web apps and many digital documents.
This chain explains why looking only at the law rarely suffices. The BFSG and its requirements name the goal, but the testing benchmark lies in the standard and the WCAG it references. Those who understand this document accessibility in a defensible way rather than merely asserting it.
Presumption of Conformity: Why Harmonized Standards Count
The decisive legal lever is the presumption of conformity. A harmonized standard is not an ordinary technical recommendation but a standard officially listed in the Official Journal of the EU and tied to a specific directive. Anyone who complies with the relevant parts of such a standard is presumed to meet the corresponding legal requirements. This presumption of conformity is anchored in Article 15 (European Commission) of Directive 2019/882.
What presumption of conformity means in practice
For companies, this is good news: instead of treating accessibility as an elusive legal concept, it can be pinned to a clearly defined, published checklist. The Federal Accessibility Agency accordingly treats EN 301 549 as the authoritative technical reference point for assessing digital services (Bundesfachstelle Barrierefreiheit). The presumption of conformity only arises, however, when the relevant version of the standard is actually cited in the Official Journal for the respective directive, which is why the version question is gaining importance in the coming months.
The Structure of EN 301 549: More Than Just Web
A widespread misconception is that EN 301 549 is essentially just another name for the WCAG. That is not the case. The standard is divided into ten chapters (ETSI EN 301 549), comprising clauses 4 to 13, and thus covers a far broader field than web content alone. It addresses information and communication technology (ICT) as a whole, from hardware and software to documentation and accompanying support services.
Clause 9: Web
Websites and web applications. This clause adopts the WCAG success criteria at levels A and AA almost verbatim and is the central test area for most companies.
Clause 10: Documents
Non-web documents such as PDF and office files. WCAG-based requirements apply here too, for example for tagged structure, reading order and alternative text.
Clause 11: Software
Desktop and mobile applications, including native apps. Accessibility APIs, focus management and keyboard operation are the focus here.
Clause 8: Hardware
Physical devices such as ticket and payment machines, terminals and routers. Controls, labeling and tactile features are examined.
Clause 12: Docs and support
Product documentation and support services themselves must be accessible, from the manual and the help page to the hotline and contact channel.
Clause 6: Two-way voice
ICT with voice communication, including real-time text (RTT). Clause 6.2 governs real-time text transmission alongside the voice channel.
Clauses 4 (functional performance statements), 5 (generic requirements), 7 (video capabilities) and 13 (emergency and relay services) complete the picture. For a typical online shop or corporate website, clauses 9, 10 and 11 are most relevant, but as soon as apps, PDF invoices, machines or a support center are involved, the standard reaches further. This is precisely why a pure web test rarely suffices for a complete conformity claim.
EN 301 549 and WCAG: the Technical Bridge
For web content, EN 301 549 is not a standalone rulebook but a bridge to the Web Content Accessibility Guidelines of the W3C. Clause 9 adopts the WCAG success criteria and makes them compatible with European law. Which WCAG version applies depends on the version of the standard, and this is exactly where the current dynamic lies.
| EN version | Year | Referenced WCAG | Status |
|---|---|---|---|
| V1.1.2 | 2015 | WCAG 2.0 AA | historical |
| V2.1.2 | 2018 | WCAG 2.1 AA | superseded |
| V3.2.1 | 2021 | WCAG 2.1 AA | currently in force |
| V4.1.1 | 2026 (planned) | WCAG 2.2 AA | in preparation |
The version currently in force, V3.2.1 from March 2021 (ETSI EN 301 549), references WCAG 2.1 Level AA. WCAG 2.2 was published in October 2023 (W3C Web Accessibility Initiative) and extends the standard with nine new success criteria (W3C Web Accessibility Initiative), covering focus visibility, target sizes and accessible authentication, among others. In practice, many supervisory bodies already test against WCAG 2.2 as the current state of the art, which makes a forward-looking WCAG 2.2 audit sensible. We have covered the details of the new criteria in our article on the new WCAG 2.2 success criteria.
The standard is the point where a political goal becomes a testable engineering task. Those who follow the chain from directive to clause document accessibility in a defensible way rather than merely asserting it.
Version 4.1.1 from 2026: WCAG 2.2 AA and Real-Time Text
The next stage of the standard is already underway. A draft of version V4.1.0 (ETSI EN 301 549) was published in late 2025, the final V4.1.1 is planned for 2026 (ETSI EN 301 549) and is being produced specifically to support Directive 2019/882. Two changes are particularly relevant for companies.
The two key changes in V4.1.1
In practice, this means: anyone remediating to WCAG 2.1 AA today should factor in the nine additional 2.2 criteria straight away, to avoid having to retrofit once the new version is cited in the Official Journal. Accessible authentication in particular is a recurring topic; how logins and CAPTCHAs can be solved in a BFSG-compliant way is covered in our article on accessible authentication and CAPTCHA. The stronger RTT requirement also affects not only telecommunications providers but any company that integrates video or voice communication into its digital services.
What a Conformity Claim Must Really Cover
The broad scope of the standard has a practical consequence: a conformity claim that considers only the website often falls short. The current WebAIM Million Report shows how much work remains in the web alone. 94.8 percent (WebAIM Million Report, 2025) of all analyzed home pages showed detectable WCAG failures, with an average of 51 errors per page (WebAIM Million Report, 2025). Notably, 96 percent (WebAIM Million Report, 2025) of all errors fall into just six recurring categories that can be addressed in a targeted way.
- Web (clause 9): website and web applications tested against WCAG 2.2 AA, including keyboard operation, contrast and focus.
- Documents (clause 10): PDF invoices, forms and downloads prepared as accessible PDF documents.
- Software and apps (clause 11): native iOS and Android applications with correct focus and label structure.
- Documentation and support (clause 12): help pages, manuals and contact channels themselves accessible.
- Accessibility statement: a defensible accessibility statement with a feedback mechanism as part of the claim.
How far the scope reaches beyond the web is especially clear with mobile applications. Native apps are subject to their own requirements from clause 11, which we cover in detail in our article on accessible apps under the BFSG. Companies should also know the legal consequences of a gap; enforcement and market surveillance can range from remediation to a ban on offering the service.
From the Standard to a Testable Requirements List
EN 301 549 is extensive and written in standards language, which makes getting started difficult. The decisive step for companies is to derive from the abstract standard a concrete requirements list tailored to their own offering. Not every clause is relevant to every product, but every relevant clause must be addressed and documented.
In our projects, we translate the applicable clauses into a testable checklist, map them to the specific building blocks of the digital offering and support implementation through to a documented claim. The BFSG obligation thus becomes a series of clear, testable tasks. This ranges from accessible web development and document preparation to ongoing BFSG monitoring that catches regressions early. A digital offering only becomes legally sound once it is documented in a traceable way which clause was met and how. Adjacent topics such as accessible cookie banners belong to this picture too, because they determine the very first page view.
Practical tip