What changes with the new EN 301549 4.1.1

Hier ist die englische Übersetzung im gewünschten HTML-Format mit Absatz-Tags (`

`): ```html

EN 301 549 Version 4.1.1 is pending publication. It must be published in the Official Journal of the EU, at which point it will automatically become legally binding. Until then, Version 3.2.1 remains in effect. Nevertheless, it makes sense to start engaging with it now.

A quick note: You will frequently read about Version 4.1.1, which is the current draft version. Upon official publication, the version number will jump to 4.1.1 (that is standardization magic—no need to try to understand it).

What is changing

The biggest change is the inclusion of WCAG 2.2 requirements.

This adds six new testable WCAG 2.2 success criteria at Level A/AA. At the same time, EN 301 549 becomes significantly more precise in several areas—particularly regarding software, mobile apps, and documents.

New WCAG 2.2 Requirements

In V3.2.1, the requirements for web content were based on WCAG 2.1. V4.1.1, on the other hand, references WCAG 2.2. ETSI explicitly states that WCAG 2.2 is the normative reference for web requirements.

For a website that already complies with WCAG 2.1 AA, this practically translates to these six additional requirements:

2.4.11 Focus Not Obscured (Minimum) (Level AA)
Keyboard focus must not be completely hidden by sticky headers, dialogs, cookie banners, etc.
2.5.7 Dragging Movements (Level AA)
Dragging movements must generally be operable without dragging, using a single-pointer action.
2.5.8 Target Size (Minimum) (Level AA)
Target controls generally require a size of at least 24 × 24 CSS pixels or sufficient spacing, with certain exceptions.
3.2.6 Consistent Help (Level A)
Repeatedly occurring help options must be consistently located across pages.
3.3.7 Redundant Entry (Level A)
Information should not need to be re-entered unnecessarily within the same process.
3.3.8 Accessible Authentication (Minimum) (Level AA)
Authentication must not force unnecessary cognitive function tests; for example, password managers and copy/paste functionality should work.

These six criteria represent the most immediately visible difference for web teams currently testing against WCAG 2.1 AA.

PDFs and Other Non-Web Documents Are Also Affected

V4.1.1 updates not only Chapter 9 (Web), but also Chapter 10 – Non-web documents and Chapter 11 – Non-web software.

Both areas are aligned with WCAG 2.2.

This means for PDFs, Office documents, and other digital documents that the new WCAG 2.2 requirements are not simply a web-only topic.

Particularly Relevant: Software and Apps

For apps and desktop software, the changes are even more extensive than for traditional websites.

V4.1.1 adopts many concepts from WCAG2ICT (the application of WCAG principles to non-web software and documents). As a result, requirements that were previously considered "Void" or interpreted differently for non-web software are now more concrete.

Examples include:

  • Windows and screens must be appropriately labeled.
  • Functions with the same functionality must be consistently identifiable.
  • Focus Not Obscured also applies to relevant software interfaces.
  • Dragging Movements gets a corresponding requirement for non-web software.
  • Additional WCAG 2.2 requirements are mapped onto software.

New and Refined Requirements for Assistive Technologies

Another crucial area is interoperability with assistive technologies.

V4.1.1 retains Chapter 11.5, but refines the requirements for platform accessibility services. Platform software must provide documented accessibility services through which assistive technologies can interact with the software.

This positions the standard even more strongly as a matter of technical accessibility architecture, rather than just UI design.

User Preferences Are Defined Differently

V4.1.1 leans more heavily on the concept of "documented accessibility features".

This applies to, for instance:

  • Font size
  • Contrast
  • Color schemes
  • Cursor/focus display
  • Other accessibility settings provided by the operating system

Rather than specifying an exclusive, fixed list of settings, requirements are now tied to whichever accessibility features a platform or software actually documents and provides.

Real-Time Communication Has Been Revised

Another major block addresses Real-Time Communication.

Chapter 6 covers topics such as:

  • Real-time voice communication
  • Real-Time Text (RTT)
  • Video
  • Subtitles/Captions
  • Sign language communication
  • Total Conversation
  • Communication with emergency services

V4.1.1 contains extensive requirements and scenarios for these capabilities. This is particularly relevant for telecommunications, video conferencing systems, communication platforms, and emergency systems.

Conclusion

For ongoing projects, it is already worthwhile to account for the requirements of Version 4.1.1. By next year at the latest, you should also look into the requirements for existing services.

Read more

```