The new version of EN 301 549 goes beyond WCAG 2.2

For those of us who regularly work with web accessibility, documents and applications, the most noticeable change in the newly published EN 301 549 V4.1.1, released in September 2026, is probably the update from WCAG 2.1 to WCAG 2.2.

And it is not a minor change. Clauses 9, 10 and 11 now incorporate, where applicable, the new Level A and AA success criteria introduced in WCAG 2.2:

• Focus Not Obscured (Minimum)
• Dragging Movements
• Target Size (Minimum)
• Consistent Help
• Redundant Entry
• Accessible Authentication (Minimum)

At the same time, the section corresponding to Parsing is now left empty following the removal of this success criterion from WCAG 2.2.

However, after comparing EN 301 549 V4.1.1 with EN 301 549 V3.2.1, published in March 2021, focusing only on WCAG 2.2 would mean overlooking some of the most interesting changes.

Updating an evaluation methodology from V3.2.1 to V4.1.1 is not simply a matter of replacing WCAG 2.1 with WCAG 2.2. It also changes what we consider to be part of the information and communication technology (ICT) being evaluated, how we determine which requirements apply, and what evidence can be used to demonstrate conformity.

Functional criteria become part of the evaluation

One of the changes that may be easiest to overlook appears in Clause 4.

The previous version contains eleven functional performance statements covering needs such as the absence or limitation of vision, hearing, speech capability, manipulation, reach or certain cognitive abilities. However, Annex C explicitly states that this clause is informative and does not contain requirements that need to be tested.

The new version takes a different approach. They are now referred to as Functional Performance Criteria and, although 4.1 remains informative, Clauses 4.2.1 to 4.2.11 use shall, indicating a requirement, and are supported by evaluation procedures in C.4.2.

What does this mean in practice?

The new version provides two ways to meet each of these criteria:

• The first is to meet all the technical requirements identified for that criterion in Annex B with either a P or an S. P indicates a primary relationship: the requirement directly contributes to satisfying the functional criterion. S indicates a secondary relationship: it provides partial support that may be useful to some people or in certain situations.
• The second option is to provide direct evidence that the ICT delivers the required functional outcome.

As a result, functional accessibility is no longer used solely as context for understanding technical requirements. It now plays a much more direct role in the evaluation model.

“Not applicable” and “I cannot use this test” are not the same thing

Perhaps one of the most significant changes for those of us carrying out evaluations is the way the new version formalises applicability and the demonstration of conformity.

The new version explicitly defines concepts such as applicable requirement, applicable scenario and applicable test. It also establishes that each requirement determines its own scope, an approach the standard refers to as self-scoping.

This means that each requirement begins with a precondition that determines whether it applies to the ICT being evaluated. If the precondition is true, the requirement must be met. If it is false, the requirement does not apply.

There is, however, another particularly important distinction in 14.1: the role of Annex C.

In the previous version, conformity is linked to passing the corresponding test in Annex C. In the new version, the tests in Annex C (which remains normative) are considered sufficient means of demonstrating conformity, but other evaluation approaches are explicitly permitted where they can be justified.

This is an important distinction: Annex C provides a sufficient route for evaluating a requirement, but not necessarily the only possible one.

An example makes this easier to understand. Imagine that, because of the characteristics of a particular technology, the conditions required to perform the test defined in Annex C are not met. That does not automatically mean that the requirement is “not applicable”.

These are two separate questions. If the requirement’s precondition is not met, the requirement does not apply. If the requirement does apply, but the conditions needed to use a particular test are not met, then that evaluation approach is not valid and another one must be used.

In fact, the new version no longer uses the exceptional result not testable, which appeared in the previous version. When the conditions required for a test are not met, the result is now Test approach cannot be used: the evaluation approach cannot be used and another method will be required.

Overlays are also included in the evaluation

Another particularly interesting detail in the new version is the explicit treatment of overlay tools, add-ons and other extensions.

The new version establishes that these elements form part of the ICT being evaluated. It is the complete combination that must satisfy the applicable requirements.

This distinction matters. The standard is not saying that an overlay must necessarily be audited independently as though it were a separate product. What it does prevent is excluding it from the scope of the evaluation when it forms part of the solution being assessed.

Consider, for example, an overlay that modifies a page in an attempt to address certain accessibility issues. If it changes focus management, adds new controls, modifies accessible names or alters keyboard behaviour, those changes also form part of the outcome being evaluated.

If it successfully removes a barrier, that improvement forms part of the result. But if it introduces a new barrier in the process, that issue does too.

In practice, evaluating the full combination may therefore reveal issues that can be attributed specifically to the overlay itself, even though the object of the evaluation remains the complete ICT.

This may also introduce a new concern for companies developing these types of solutions. They will no longer need only to convince customers of how many issues their tool can fix. They will also need to ensure that their intervention does not introduce new barriers that cause the final result to fail applicable requirements and potentially lead to incidents or complaints.

The fact that the new version explicitly mentions overlays does not mean that it gives them a special route to conformity. It means something much simpler: if they form part of the solution, they also form part of what is evaluated and may also form part of the barriers identified.

EN 301 549 is still more than WCAG

The move to WCAG 2.2 should not make us forget that EN 301 549 contains requirements of its own.

The new version provides some particularly relevant examples in the areas we work with most frequently. User preferences, which the previous version already addressed for software, are now extended to web content in 9.7 and non-web documents in 10.7.

The way certain WCAG success criteria are adapted to different technologies also changes. A criterion that exists for web content is not automatically carried over in the same way to documents or software. Consistent Help, for example, is incorporated where relevant but remains empty for non-web software.

This distinction matters when defining evaluation methodologies. Assessing conformity with EN 301 549 is not simply a matter of performing a WCAG audit and changing the title of the report. The preconditions, adaptations and additional requirements defined by the standard for each type of ICT also need to be taken into account.

Updating the methodology, not just the checklist

Of course, the new version contains many other changes. The revision also affects communications, hardware, information about products and services, and the annexes that connect the standard with the European regulatory framework.

But for those of us who mainly evaluate websites, documents and applications, there is a more immediate consequence: moving from V3.2.1 to V4.1.1 should involve more than simply adding six WCAG 2.2 success criteria to our checklists.

We will need to review:

• How do we determine which requirements apply?
• How do we document evidence?
• How do we incorporate functional criteria into the evaluation?
• What do we do when the method defined in Annex C is not suitable?
• What exactly do we consider part of the ICT being evaluated, including add-ons and overlays?

WCAG 2.2 changes some requirements. V4.1.1 also changes, in a much subtler way, how we need to reason about and justify an evaluation of conformity. And that may ultimately be the change that deserves the most attention.

Ainara Blanco 
Digital Accessibility Specialist
Accessibility audits, consulting and development