EN 301 549 Version 4.1.1: Was sich 2026 mit WCAG 2.2 ändert

Digitale Barrierefreiheit in der Europäischen Union bekommt 2026 ein bedeutendes Update: Die EN 301 549 wird im Dezember durch die Version 4.1.1 ersetzt. Für viele Fachleute war das nur eine Frage der Zeit, für viele Unternehmen, Agenturen und Websitebetreiber wird es aber konkret anspruchsvoller. Denn mit der neuen Version ändern sich die Umsetzungspflichten – und zwar nicht nur auf dem Papier.

Wer digitale Produkte, Websites oder Apps in Deutschland und der EU betreibt, muss sich künftig an WCAG 2.2 AA orientieren. Hinzu kommen sechs neue Erfolgskriterien und weitere Anpassungen in anderen Kapiteln der Norm. In diesem Artikel erkläre ich, was sich wirklich ändert, für wen das relevant ist und wie du deine Projekte schrittfit vorbereitest.

Was ist die EN 301 549?

Die EN 301 549 ist die europäische Norm für die Barrierefreiheit von Informations- und Kommunikationstechnik (IKT). Sie definiert Anforderungen an digitale Produkte und Dienstleistungen, damit sie von möglichst vielen Menschen genutzt werden können – unabhängig von Alter, Behinderung oder eingesetzter Hilfstechnologie.

Die Norm ist die technische Grundlage für viele europäische Regelungen, darunter:

den European Accessibility Act (EAA) – die EU-Richtlinie 2019/882 für Barrierefreiheit,
das deutsche Barrierefreiheitsstärkungsgesetz (BFSG) und
die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) für den öffentlichen Sektor.

Bislang bezog sich die EN 301 549 auf die WCAG 2.1 auf Konformitätsstufe AA. Mit Version 4.1.1 wird das technische Fundament auf WCAG 2.2 AA gehoben – und damit kommen neue Pflichten hinzu, die bisher nur „Best Practice“ waren.

Was ändert sich mit Version 4.1.1?

Die wichtigste Änderung auf einen Blick: Die EN 301 549 Version 4.1.1 verpflichtet zur Einhaltung von WCAG 2.2 auf Stufe AA. Das bedeutet, dass alle Erfolgskriterien der WCAG 2.1 AA weiterhin gelten und zusätzlich neue Anforderungen aus WCAG 2.2 hinzukommen.

Hinzu kommen Aktualisierungen in weiteren Kapiteln der Norm, die über reine Webinhalte hinausgehen. Dazu gehören Anforderungen an Echtzeitkommunikation und der Schutz von Barrierefreiheits-Einstellungen der Nutzerinnen und Nutzer.

Zeitplan und Rechtswirkung

Die neue Version soll laut aktuellem Stand am 16. Dezember 2026 harmonisiert werden. Ab diesem Zeitpunkt gilt sie auf europäischer Ebene. Bis dahin ist sie zwar veröffentlicht, aber noch nicht rechtsverbindlich in vollem Umfang. Das ist aber kein Grund, abzuwarten – gerade weil viele der neuen Kriterien technisch und gestalterisch bereits jetzt umsetzbar sind.

Die 6 neuen WCAG 2.2-Kriterien im Detail

Die folgenden sechs Erfolgskriterien aus WCAG 2.2 werden mit der EN 301 549 Version 4.1.1 verbindlich. Sie betreffen unterschiedliche Bereiche der Bedienbarkeit – von der Tastatursteuerung bis zur Authentifizierung.

1. 2.4.11 Fokus nicht verdecken (Minimum)

Wenn ein Nutzer mit der Tastatur durch eine Seite navigiert, muss das aktuell fokussierte Element sichtbar bleiben. Das klingt selbstverständlich, wird aber in der Praxis häufig vernachlässigt – etwa durch fixierte Header, Sticky-Footer, Cookie-Banner oder modale Dialoge, die den Fokus überdecken.

Was du tun solltest:

Prüfe, ob fokussierte Links, Buttons oder Formularfelder bei Tastaturnutzung immer im sichtbaren Bereich liegen.
Vermeide Layout-Komponenten, die den Fokusring verdecken.
Setze auf scroll-padding oder gleichwertige Techniken, um fixierte Elemente auszugleichen.

2. 2.5.7 Ziehbewegung

Interaktionen, die eine Ziehbewegung erfordern – wie Slider, Karten-Swipes oder Drag-and-Drop – müssen alternativ auch mit einem einfachen Tippen oder Klicken bedienbar sein. Menschen mit motorischen Einschränkungen können präzise Ziehbewegungen oft nicht ausführen.

Was du tun solltest:

Biete für jede Ziehbewegung eine gleichwertige Alternative an.
Beispiel: Ein Preisslider sollte auch durch Eingabe eines Wertes oder Plus/Minus-Buttons bedienbar sein.
Vermeide Ziehbewegungen als einzige Eingabemethode.

3. 2.5.8 Zielgröße (Minimum)

Klick- und Touch-Elemente müssen eine Mindestgröße von 24 × 24 Pixeln haben – sofern sie nicht durch ausreichenden Abstand zu anderen interaktiven Elementen kompensiert werden. Das reduziert Fehlbedienungen, besonders auf mobilen Geräten.

Was du tun solltest:

Achte bei Buttons, Links und Formularfeldern auf ausreichende Größe.
Vermeide zu kleine Icons oder Textlinks, die dicht beieinanderliegen.
Prüfe die Touch-Elemente auf Smartphones und Tablets.

4. 3.2.6 Konsistente Hilfe

Hilfsangebote wie FAQs, Kontaktmöglichkeiten oder Live-Chats sollen auf allen Seiten einer Website an derselben Stelle zu finden sein. Das erleichtert es Nutzern, Hilfe zu finden, ohne jedes Mal neu suchen zu müssen.

Was du tun solltest:

Platziere Hilfe-Links oder Kontaktpunkte konsistent im Header, Footer oder einer festen Sidebar.
Verwende ein einheitliches Icon oder einen einheitlichen Link-Text.
Vermeide wechselnde Positionen je nach Seitentyp.

5. 3.3.7 Doppelte Eingabe

Wenn Informationen bereits einmal eingegeben wurden, sollen sie nicht noch einmal abgefragt werden müssen – es sei denn, es ist aus Sicherheitsgründen oder der Datenschutz verlangt es. Das betrifft etwa Bestellprozesse, Registrierungsformulare oder Mehrstufige Assistenten.

Was du tun solltest:

Übernehme bereits erfasste Daten in nachfolgende Schritte.
Biete Autofill-Unterstützung für Formularfelder.
Vermeide redundante Eingaben bei Rechnungs- und Lieferadresse, wenn beide identisch sein können.

6. 3.3.8 Barrierefreie Authentifizierung (Minimum)

Beim Login dürfen keine kognitiven Funktionstests verlangt werden – zumindest nicht als einzige Methode. Dazu gehören beispielsweise CAPTCHAs, bei denen Nutzer Bilder erkennen oder Zeichenfolgen aus verzerrten Buchstaben eingeben müssen. Alternativ müssen mindestens eine weitere Authentifizierungsmethode angeboten werden, die keine kognitive Leistung erfordert.

Was du tun solltest:

Biete Passkey-, Magic-Link- oder hardwarebasierte Authentifizierung an.
Vermeide reine Bild-CAPTCHAs ohne Alternative.
Achte darauf, dass Hilfstechnologien den Login-Prozess vollständig unterstützen.

Weitere wichtige Änderungen in der EN 301 549

Neben den neuen WCAG 2.2-Kriterien gibt es auch Anpassungen in anderen Kapiteln der Norm. Zwei davon sind besonders relevant.

Echtzeit-Textkommunikation bei Sprachkommunikation

Wenn ein Produkt oder Dienst Echtzeit-Sprachkommunikation anbietet, muss grundsätzlich auch Echtzeit-Textkommunikation (RTT, Real-Time Text) ermöglicht werden. Das betrifft unter anderem:

Videokonferenzsysteme,
Kommunikationsplattformen,
Notfallkommunikationssysteme,
Kundenservice-Chat- und Anruflösungen.

Real-Time Text ermöglicht es, Text während der Eingabe zeichenweise zu übertragen – ähnlich wie bei einem Telefon mit Textunterstützung. Das ist essenziell für gehörlose und schwerhörige Nutzer sowie für Menschen, die aus anderen Gründen nicht sprechen können oder wollen.

Respektierung von Nutzerpräferenzen

Ein lange diskutiertes Thema ist nun fixiert: Websites und Anwendungen dürfen dokumentierte Barrierefreiheits-Einstellungen der Nutzerinnen und Nutzer grundsätzlich nicht blockieren oder überschreiben. Dazu gehören beispielsweise:

Kontrast-Einstellungen,
Farb- und Farbschema-Präferenzen,
Textgrößen-Einstellungen,
Bewegungs-Reduktion,
Anpassungen durch assistive Technologien.

Wenn ein Nutzer beispielsweise ein erzwungenes Hochkontrast-Schema oder eine vergrößerte Systemschrift aktiviert hat, darf die Website diese Einstellung nicht einfach ignorieren oder durch eigene Styles überschreiben – es sei denn, der Nutzer hat das ausdrücklich so gewählt.

Was du tun solltest:

Verwende relative Einheiten für Schriftgrößen und Layouts.
Respektiere prefers-reduced-motion für Animationen.
Teste deine Seite mit Browser-Einstellungen für hohen Kontrast oder vergrößerte Schrift.
Vermeide feste Pixelwerte, die Nutzeranpassungen blockieren.

Was bedeutet das für dich und dein Unternehmen?

Die Änderungen betreffen nicht nur den öffentlichen Sektor. Auch private Unternehmen, die digitale Produkte oder Dienstleistungen anbieten, müssen sich mit den neuen Anforderungen auseinandersetzen – insbesondere im Kontext des BFSG und des European Accessibility Act.

Betroffen sind unter anderem:

Websites und Online-Shops,
Mobile Apps,
E-Learning-Plattformen,
E-Banking- und Finanzdienstleistungen,
E-Commerce-Systeme,
Kommunikations- und Videokonferenzlösungen.

Wenn deine Produkte aktuell noch auf WCAG 2.1 basieren, solltest du jetzt mit einer Gap-Analyse starten. Prüfe, welche der neuen Kriterien bereits erfüllt sind und wo Handlungsbedarf besteht.

Praxis-Checkliste für die Umstellung

Sofort prüfen

Welche WCAG-Version liegt aktuell in meinen Projekten zugrunde?
Sind alle interaktiven Elemente per Tastatur erreichbar und sichtbar fokussiert?
Werden Ziehbewegungen durch einfache Alternativen ergänzt?
Sind Touch- und Klickziele groß genug und ausreichend voneinander entfernt?

Kurzfristig umsetzen

Hilfe- und Kontaktpunkte konsistent platzieren.
Doppelte Eingaben in Formularen und Prozessen reduzieren.
Login-Prozesse um barrierefreie Authentifizierungsmethoden erweitern.
Nutzerpräferenzen wie Kontrast, Schriftgröße und Bewegung respektieren.

Langfristig etablieren

Barrierefreiheit fest in Design-System und Entwicklungsprozess verankern.
Regelmäßige Accessibility-Tests in den Release-Prozess integrieren.
Team intern und extern zu WCAG 2.2 und EN 301 549 Version 4.1.1 schulen.
Dokumentation der Barrierefreiheit für Konformitätsnachweise aufbauen.

Accessibility-Tests mit Playwright in der Git-Pipeline

Eine Checkliste allein reicht nicht, um Barrierefreiheit dauerhaft zu sichern. Wer die neuen Anforderungen ernst nimmt, sollte automatisierte Tests direkt in den Entwicklungsprozess integrieren. Dafür eignet sich besonders die Kombination aus Playwright und axe-core.

Wie funktioniert das?

Playwright öffnet Seiten in echten Browsern. Über das Paket @axe-core/playwright wird die Seite anschließend auf WCAG-Verstöße geprüft. Auffälligkeiten werden als Testfehler zurückgegeben und können die Pipeline abbrechen lassen.

Der typische Ablauf in der Git-Pipeline:

Projekt bauen (z. B. npm run build).
Statische Seite lokal servieren.
Playwright öffnet die relevanten URLs.
axe-core analysiert DOM, Kontraste, ARIA, Tastaturfokus und mehr.
Bei Verstößen schlägt der Test fehl.

Beispielhafter Playwright-Test

// tests/accessibility.spec.ts
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('Startseite erfüllt WCAG 2.2 AA', async ({ page }) => {
  await page.goto('http://localhost:1313');

  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag22aa'])
    .analyze();

  expect(results.violations).toEqual([]);
});

Mit .withTags(['wcag2aa', 'wcag22aa']) lassen sich gezielt die Regeln anwenden, die für die EN 301 549 Version 4.1.1 relevant sind.

Integration in GitHub Actions

name: Accessibility Tests

on:
  push:
    branches: [main]
  pull_request:

jobs:
  a11y:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npm run build
      - run: |
          npx serve public -l 1313 &
          npx wait-on http://localhost:1313
          npx playwright test

Dieses Beispiel passt zu einem statischen Hugo-Setup: Die Seite wird in public/ gebaut, lokal ausgeliefert und dann geprüft.

Stärken und Grenzen automatischer Tests

Playwright mit axe-core erkennt zuverlässig:

fehlende oder falsche Alt-Texte,
unzureichende Farbkontraste,
fehlende Formularbeschriftungen,
fehlerhafte ARIA-Verwendung,
nicht eindeutige Link-Texte.

Was es nicht allein leisten kann:

Manuelle Tastatur- und Screenreader-Tests ersetzen,
sinnvolle Überschriftenhierarchien bewerten,
neue WCAG 2.2-Kriterien wie „Fokus nicht verdecken“ oder „Ziehbewegung“ vollständig prüfen,
Nutzerpräferenzen wie Kontrast oder Schriftgröße in allen Systemen simulieren.

Automatisierte Accessibility-Tests sind deshalb ein wichtiger erster Schritt, aber kein Ersatz für manuelle und assistive Prüfungen.

Fazit

Die EN 301 549 Version 4.1.1 ist kein kleines Update – sie hebt den technischen Standard für digitale Barrierefreiheit in der EU auf ein neues Level. Mit der Umstellung auf WCAG 2.2 AA und den zusätzlichen Anforderungen zu Echtzeit-Textkommunikation und Nutzerpräferenzen werden Barrierefreiheit und Inklusion noch stärker zur Pflicht für digitale Angebote.

Wer jetzt startet, statt bis Dezember zu warten, handelt nicht nur vorsorglich, sondern auch wirtschaftlich: Barrierefreie Produkte erreichen mehr Nutzer, bieten eine bessere User Experience und reduzieren das Risiko von Abmahnungen und Bußgeldern.

Barrierefreiheit ist längst kein zusätzliches Feature mehr – sie ist ein Qualitätsmerkmal, das zur Grundausstattung jeder professionellen Website und App gehört.

Hast du Fragen zur Umsetzung der EN 301 549 Version 4.1.1 oder möchtest du deine Website auf WCAG 2.2 prüfen lassen? Schreib mir gerne über das Kontaktformular – ich berate dich gerne.

Was ist die EN 301 549?

Was ändert sich mit Version 4.1.1?

Zeitplan und Rechtswirkung

Die 6 neuen WCAG 2.2-Kriterien im Detail

1. 2.4.11 Fokus nicht verdecken (Minimum)

2. 2.5.7 Ziehbewegung

3. 2.5.8 Zielgröße (Minimum)

4. 3.2.6 Konsistente Hilfe

5. 3.3.7 Doppelte Eingabe

6. 3.3.8 Barrierefreie Authentifizierung (Minimum)

Weitere wichtige Änderungen in der EN 301 549

Echtzeit-Textkommunikation bei Sprachkommunikation

Respektierung von Nutzerpräferenzen

Was bedeutet das für dich und dein Unternehmen?

Betroffen sind unter anderem:

Praxis-Checkliste für die Umstellung

Sofort prüfen

Kurzfristig umsetzen

Langfristig etablieren

Accessibility-Tests mit Playwright in der Git-Pipeline

Wie funktioniert das?

Beispielhafter Playwright-Test

Integration in GitHub Actions

Stärken und Grenzen automatischer Tests

Fazit

Weiterführende Links