Europas Barriere­freiheits­standard bekommt ein Update – was steckt in der neuen EN 301 549?

Hinter dem sperrigen Namen verbirgt sich ein Dokument, das für Millionen Menschen in Europa einen echten Unterschied macht. Die EN 301 549 ist der verbindliche technische Standard, der regelt, wie zugänglich digitale Produkte und Dienste in der EU sein müssen. Websites, Apps, Software, Geldautomaten, Fahrscheinautomaten.
Nun steht eine neue Version ins Haus. Oder genauer: Sie ist auf dem Weg und müsste gleich ankommen.

Im November 2025 veröffentlichte ETSI – das Europäische Institut für Telekommunikationsnormen – den Entwurf der Version 4.1.0. Auf dem Papier ein großer Schritt, juristisch aber noch keiner: Eine Norm entfaltet ihre volle Rechtswirkung erst dann, wenn die Europäische Kommission sie im Amtsblatt der Europäischen Union referenziert. Diesen Schritt nennt man ‚Harmonisierung‘.
Die Publikation der finalen Version unter der Bezeichnung V4.1.1 ist für das Jahr 2026 geplant – intern wurde zeitweise der 15. Februar 2026 als Zieldatum genannt. Ob und wann genau die Aufnahme ins Amtsblatt folgt, ist aber noch offen. Ich tippe weiterhin auf das erste Quartal 2026.

Der Hauptantrieb ist das Wachstum mobiler Nutzung. Immer mehr Menschen greifen über Smartphones auf digitale Dienste zu – und die bisherige Norm basierte im Wesentlichen auf Richtlinien, die ursprünglich für Webseiten am Desktop-Computer entwickelt wurden. Die Web Content Accessibility Guidlines 2.1, auf der EN 301 549 v3.2.1 aufbaut, wurde 2018 verabschiedet. Inzwischen gibt es WCAG 2.2 – und die neue Norm soll diese aktuelleren Anforderungen endlich ins europäische Recht überführen.
Das ist für uns der wichtigste Punkt. Fast alle digitalen Lösungen werden bei der Barrierefreiheit im Hinblick auf den internationalen Standard der WCAG umgesetzt. Hier gibt es mehr Informationen, mehr Hilfen und Werkzeuge. Die EN 301 549 bleibt aber die rechtlich bindende Norm.

Die inhaltlichen Änderungen lassen sich grob in drei Gruppen einteilen:

• neue Erfolgskriterien aus den Web Content Accessibility Guidlines, (WCAG) 2.2 (für Level A und AA) werden aufgenommen
• schärfere Definition von Regeln für mobile Anwendungen
• eine Klärung des Schichtenprinzips und der dahinter liegenden Verantwortungen

Sechs Erfolgskriterien, die mit WCAG 2.2 eingeführt wurden, halten nun Einzug in die europäische Norm. Einige davon klingen nach technischen Feinheiten, haben aber spürbare Auswirkungen:

• Interaktions-Ziele müssen mindestens 24 × 24 Pixel groß sein. Wer mit zitternden Händen oder eingeschränkter Motorik navigiert, kennt das Problem winziger Schaltflächen aus leidvoller Erfahrung. Das folgende Bild (vom W3C) zeigt das recht anschaulich.
• Wischgesten (drag & drop) brauchen eine Alternative. Alles, was sich durch Ziehen bedienen lässt, muss auch per einfachem Antippen funktionieren – etwa das Umsortieren von Listen.
• Der Fokus darf nicht verdeckt werden. Wenn Nutzerinnen und Nutzer per Tastatur navigieren, darf das aktuell markierte Element nicht vollständig hinter Kopfzeilen oder Overlays verschwinden.
• Keine doppelte Dateneingabe. Wer in einem mehrstufigen Prozess, etwa bei einer Registrierung, Informationen bereits eingegeben hat, soll diese nicht erneut eintippen müssen.
• Zugängliche Authentifizierung. Logins dürfen nicht ausschließlich darauf beruhen, dass sich Nutzerinnen und Nutzer ein Passwort merken oder ein Rätsel lösen. Alternativen wie biometrische Verfahren oder Passwortmanager müssen möglich sein.

Hier liegt der vielleicht bedeutendste konzeptionelle Schritt. Bislang war nicht immer eindeutig, welche Anforderungen auf App-Inhalte anzuwenden sind, die intern als Webansicht (sogenannte WebViews) in einer App dargestellt werden. Die neue Version stellt unmissverständlich klar: Solche Inhalte gelten als Teil der App und nicht als Webseite. Es gilt ausschließlich Kapitel 11 (Software), nicht Kapitel 9 (Web) der EN 301 549. Das beseitigt eine Grauzone, die in der Praxis für einige Verwirrung gesorgt hat.

Zu erwähnen ist noch 11.2.4.2 „Non-web software titled„. Diese Regel lehnt sich an WCAG 2.2, 2.4.2 „Page Titled“ (Level A) an und verlangt von Apps, dass sie Überschriften enthalten müssen, die den Namen, das Thema oder den Zweck jedes Fensters oder Bildschirms beschreiben.

V4.1.0 betont explizit, dass Barrierefreiheit Aufgabe jeder Schicht im System ist – von der Hardware über das Betriebssystem bis zur App. Eine Anforderung gilt nur für die Schicht, die das betreffende Verhalten tatsächlich steuert. Für App-Entwicklerinnen und -Entwickler bedeutet das konkret: Wenn das Betriebssystem die Schriftgröße skaliert, muss die App diese Einstellung respektieren, sie muss sie aber nicht selbst neu erfinden. Spannend ist dieser Teil insbesondere für Anwendungen die auf Kiosk-Systemen laufen. Hier werden Hardware, Betriebsystem und Anwendung von unterschiedlichen Entwicklern geliefert und bisher war nicht klar, wer hier welche Aufgaben hat.

WCAG 2.2 ist rückwärtskompatibel. Wer heute WCAG 2.1 Level AA einhält, erfüllt alle bisherigen Anforderungen auch weiterhin. Hinzu kommen lediglich die neuen Kriterien.
Außerdem gilt: Solange die neue Normenversion nicht im Amtsblatt harmonisiert ist, bleibt rechtlich v3.2.1 der maßgebliche Standard. Wer heute eine Konformitätserklärung erstellt, bezieht sich weiterhin auf diese Version. Das gibt Unternehmen und Behörden Zeit, sich vorzubereiten und es empfiehlt sich, diese Zeit zu nutzen.

Die wichtigste Empfehlung lautet: den Entwurf kennenlernen, ohne in Aktionismus zu verfallen. Tauschen Sie sich mit Ihrer Expertin oder Ihrem Experten für Barrierefreiheit aus. Wer Websites oder Apps verantwortet, sollte prüfen, ob die neuen Anforderungen, insbesondere zu Tipp-Zielgrößen, Wischgesten und Authentifizierung, bereits erfüllt werden oder Anpassungsbedarf besteht. Viele dieser Punkte sind gar nicht schwer umzusetzen, wenn man sie frühzeitig einplant.