On 2 September 2026, the new edition of the European standard EN 301 549, version 4.1.1, was published. At first glance, this is news for specialists. However, for organisations covered by the Accessibility Enhancement Act (BFSG), it has a very practical implication: WCAG 2.2 will become the benchmark against which digital accessibility is measured in Europe.
Here at ifdb, this news came as no surprise to us. From the very beginning, we have been testing against WCAG 2.2, never against WCAG 2.1, because it was clear that the older version would eventually be superseded. In this guide, I’ll explain what’s changing with the new standard, when it comes into effect, which six new requirements have been added, and what you should do if your most recent compliance report is still based on WCAG 2.1. You can find the basics of the standard on our page on EN 301 549, and all the WCAG 2.2 criteria on the WCAG 2.2page.
In a nutshell: What EN 301 549 v4.1.1 means for your organisation
- The new standard adopts WCAG 2.2 at Levels A and AA. The previous version, 3.2.1, still referred to WCAG 2.1.
- Six new success criteria have been added at Levels A and AA, including target size, hidden focus and accessible login.
- The standard has been published. It will take full legal effect as soon as it is published in the Official Journal of the EU. This is expected to happen in December 2026 (the Irish National Disability Authority expects 16 December 2026; as of 10 November 2026).
- From then on, the following will apply: anyone who complies with the standard will be presumed to meet the requirements of the European Accessibility Act – and thus also those of the BFSG.
- Anyone still testing against WCAG 2.1 should switch to WCAG 2.2 and plan for the development work required to meet the new criteria now.
What is EN 301 549?
EN 301 549 is the European standard for the accessibility of information and communication technology. It is published jointly by the European standardisation organisations ETSI, CEN and CENELEC. Unlike the WCAG, which focuses on web content, it covers the entire digital world: websites, apps, software, documents, hardware and real-time communication.
For websites and apps, the standard essentially refers to the Web Content Accessibility Guidelines. Which version of the WCAG applies therefore depends on which version of EN 301 549 is authoritative. This is precisely what is now changing.
What changes with version 4.1.1
In 2022, the European Commission commissioned the standardisation organisations to revise EN 301 549 so that it could serve as the central harmonised standard for the European Accessibility Act. The result is version 4.1.1. The most important changes are:
| Area | Previously (v3.2.1) | New (v4.1.1) |
|---|---|---|
| Web and Apps | WCAG 2.1, Levels A and AA | WCAG 2.2, Levels A and AA |
| New success criteria | – | six additional criteria at Levels A and AA |
| Relation to the European Accessibility Act | not explicitly stated | separate mapping of the EAA requirements in the annexes |
| User settings | previous version | fundamentally revised |
| Real-time communication | previous version | updated, for example to include text alongside speech and video |
| Scope | Web, documents, software, hardware | remains broad; all sections have been adapted |
For most organisations, it is the first line that matters most. With version 4.1.1, WCAG 2.2 becomes the European standard for websites, apps and digital documents. The reverse is also true: meeting WCAG 2.2 at Level AA does not mean that the entire standard has been met. EN 301 549 sets out its own requirements for software, documents and communication functions.
An overview of the six new requirements
WCAG 2.2 has introduced a total of nine new success criteria, three of which are at the highest level, AAA. For EN 301 549 – and therefore for the BFSG – the six criteria at Levels A and AA are relevant. Furthermore, criterion 4.1.1 (syntax analysis) has been omitted, as modern browsers and assistive technologies now automatically correct faulty HTML themselves.
| Criteria | Level | What it requires | Typical pitfalls |
|---|---|---|---|
| 2.4.11 Focus not obscured (minimum) | AA | An element that has keyboard focus must not be completely obscured by other content. | Fixed headers and cookie banners that overlap the focused element |
| 2.5.7 Drag gestures | AA | Anything operated by dragging must also work with a simple click or tap. | Sliders, sortable lists, map views |
| 2.5.8 Target size (minimum) | AA | Click and tap areas must be at least 24 × 24 CSS pixels in size or have sufficient spacing between them. | Small icons, closely spaced links in footers and tables |
| 3.2.6 Consistent help | A | Support options such as ‘Contact’ or ‘Chat’ are located in the same place on every page. | ‘Contact’ links that appear in different places depending on the page type |
| 3.3.7 Redundant input | A | Information that has already been entered does not need to be typed in again; instead, it is automatically carried over or offered as a selection option. | Multi-step forms and checkouts that ask for addresses twice |
| 3.3.8 Accessible authentication (minimum) | AA | The login process must not require a cognitive test, such as memorising something or solving a puzzle, without an alternative. | Fields that block paste operations or password managers, or captchas that are difficult to solve |
None of these criteria are unusual. They relate to elements that almost every website has: a header, a cookie banner, a form, a login, icons. That is why it is worth not treating them as an afterthought.
When does the new standard come into force?
The standardisation organisations adopted version 4.1.1 at the end of August 2026, and it was published on 2 September 2026. It is therefore now official. However, it will only take full legal effect once its reference has been published in the Official Journal of the European Union. This is expected to happen in December 2026 (the Irish National Disability Authority expects 16 December 2026; as of 10 November 2026).
From this point onwards, the so-called ‘presumption of conformity’ applies: anyone who complies with the harmonised standard is presumed to be in compliance with the accessibility requirements of the European Accessibility Act. The BFSG, which implements the European Accessibility Act in Germany, builds on precisely this mechanism. The standard itself does not specify how long older assessments based on WCAG 2.1 will continue to be accepted in practice. However, I would not rely on this.
What this means for the BFSG and BITV 2.0
For private-sector companies falling under the scope of the BFSG, WCAG 2.2 will become the benchmark as soon as the new standard is published in the Official Journal. Anyone offering a product or service to which the Act applies should have their website, app and customer documents assessed against WCAG 2.2 by then at the latest.
BITV 2.0 applies to public bodies. It refers to the harmonised standards that are applicable to the public sector. Regardless of when the new version comes into force in that sector, one simple rule applies: WCAG 2.2 is backwards compatible. Content that complies with WCAG 2.2 also complies with WCAG 2.1. So, anyone who validates against WCAG 2.2 today is well-prepared for both standards. You can read more about the differences between the laws in our overview of which laws apply in Germany.
Why we validate against WCAG 2.2 from the outset
When we were setting up ifdb, we were faced with a choice: to test against WCAG 2.1, because that was what the legislation at the time required, or to test against WCAG 2.2 straight away. We opted for WCAG 2.2. The reason was simple: it was clear to us that WCAG 2.1 would eventually be superseded. A compliance report based on a standard that will become obsolete in the foreseeable future is of no help to our clients.
Today, all our clients are assessed against WCAG 2.2. That is why there are no new criteria in our audits that would suddenly cause a site to fail. We have never treated the six additional requirements separately; they have been part of every assessment from the outset. For our clients, therefore, the new standard does not entail any additional work. It simply confirms the standard they have already achieved.
Is your audit report still based on WCAG 2.1? Here’s what to do
Many companies have had an audit carried out in accordance with WCAG 2.1 in recent years. That was not the wrong thing to do at the time. However, with the new standard, it is no longer sufficient as a basis. My advice is clear: switch to WCAG 2.2 and prioritise the development work. Here’s how to proceed:
- Have your current status assessed against WCAG 2.2. The aim is not to re-test everything, but to highlight the gap between your previous report and the new requirements.
- Prioritise the findings by impact: what is preventing people from completing a purchase, a registration or an application? That comes first.
- Incorporate the development work into your regular releases, rather than setting up a separate major project.
- Update your accessibility statement. It should specify the current standard and the current status.
- Ensure the current status is maintained so that new releases do not introduce new barriers.
How much work does the transition to WCAG 2.2 involve?
There is no one-size-fits-all answer to this, but experience shows a clear pattern. Some criteria can be met with little effort, whilst others require changes to the logic of an application.
| Effort | Criteria | Why |
|---|---|---|
| usually low | 3.2.6 Consistent help, 2.5.8 Target size | Adjustments to the template and design that apply centrally to all pages |
| medium | 2.4.11 Focus not obscured, 3.3.7 Redundant input | Headers, banners and form logic must be adapted |
| rather high | 2.5.7 Drag gestures, 3.3.8 Accessible authentication | User interface concepts and login procedures must be provided with an alternative |
It is important not to tackle everything at once. A prioritised list of measures ensures that the barriers with the greatest impact are removed first, allowing your team to work in a structured manner.
Practical tip: You can check for yourself in two minutes whether your website meets the new criterion 2.4.11. Load your homepage, leave the cookie banner open and navigate through the page using the Tab key. If the focus eventually disappears beneath the fixed header or beneath the banner, you have identified an issue that no scanner can reliably detect.
EN 301 549 also applies to your documents
One point often gets overlooked in the discussion about WCAG 2.2: EN 301 549 does not only cover websites. It contains specific requirements for documents that are not on the web, such as PDFs that customers download or receive by email. Invoices, contracts, forms and annual reports are included as soon as they form part of a digital offering.
PDF/UA is the technical standard for PDFs. You can check whether your documents comply with it free of charge using Access Read. Our page on Access Doc shows you how to make an entire collection accessible, whilst the ‘Accessible PDFs’ overview explains the basics.
How ifdb supports you with the transition
You can see your website’s initial compliance status against WCAG 2.2 in just a few minutes using Access Score’s free BFSG Check. Access Ready, our in-depth audit in accordance with WCAG 2.2 and EN 301 549, involving real users of assistive technologies, provides robust evidence of compliance. The result is a prioritised list of actions for your team or agency to implement, and we’ll support you every step of the way. To ensure compliance is maintained, Access Guard checks every release before any new barriers go live.
This means the new standard isn’t just another project for you, but a step in a process you’re already following: resource-efficient, legally compliant and cost-effective.
Frequently asked questions about EN 301 549 v4.1.1
Do I have to convert everything to WCAG 2.2 straight away?
No. It makes sense to assess your current compliance with WCAG 2.2 now and prioritise the findings according to their impact. Address the most significant barriers first; the rest can follow in your regular releases.
Is my WCAG 2.1 certificate now invalid?
A certificate reflects the status at the time of the audit. As soon as the new standard is published in the Official Journal, WCAG 2.2 will be the benchmark for presumption of conformity. A certificate based on WCAG 2.1 does not cover the six new criteria. I therefore recommend closing this gap now.
Does EN 301 549 also apply to small businesses?
The standard itself does not distinguish between different sizes of business. Whether you fall under the scope of the BFSG is determined by the law: micro-enterprises that provide services are exempt. You can read the specific details on our page about the BFSG.
My advice to anyone still testing against WCAG 2.1
“Switch to WCAG 2.2 and prioritise the development effort. We’ve been testing against WCAG 2.2 from the outset because it was clear that WCAG 2.1 was due to be superseded. Now the time has come, and those who make the switch early will have the effort under control rather than playing catch-up.”
