WordPress-Barrierefreiheitsleitfaden: WCAG 2.2 und das EU-BFSG

Die Kernaussage: WCAG 2.2 AA ist der technische Standard, auf den die meisten EU-Barrierefreiheitsgesetze verweisen, und er läuft auf vier Prinzipien hinaus — wahrnehmbar, bedienbar, verständlich, robust —, aber in der Praxis scheitern die meisten WordPress-Sites an einer kleinen, wiederkehrenden Reihe von Problemen: Farbkontrast, fehlender Alt-Text, Lücken in der Tastaturnavigation und kaputte Überschriftenhierarchie.

Warum das jetzt zählt, nicht irgendwann

Der European Accessibility Act (Richtlinie (EU) 2019/882) gilt seit dem 28. Juni 2025 und verlangt von bestimmten Kategorien von Produkten und Dienstleistungen, die an EU-Verbraucher verkauft werden — darunter E-Commerce, Banking, E-Books, Verkehrsdienstleistungen und Telekommunikation —, Barrierefreiheitsanforderungen zu erfüllen. Es ist keine zukünftige Frist mehr; es ist bereits geltendes Recht in EU-Mitgliedstaaten.

Das Gesetz verweist auf WCAG 2.2 auf der Konformitätsstufe AA als den praktischen technischen Standard, den die meisten Organisationen zum Nachweis der Konformität nutzen, selbst wo das EAA selbst in breiterer Rechtssprache verfasst ist. Das macht WCAG 2.2 AA zum konkreten Ziel, auf das hingearbeitet werden sollte, unabhängig davon, ob eine bestimmte Site genau in den Geltungsbereich des EAA fällt.

Was WCAG 2.2 AA tatsächlich verlangt

WCAG organisiert seine Anforderungen um vier Prinzipien, gängig abgekürzt als POUR:

• Wahrnehmbar — Inhalte müssen so präsentiert werden können, dass Nutzer sie wahrnehmen können, darunter Alt-Text für Bilder und ausreichender Farbkontrast für Text.
• Bedienbar — Interface-Komponenten müssen allein per Tastatur nutzbar sein, nicht nur per Maus, und Nutzer brauchen genug Zeit, um Inhalte zu lesen und mit ihnen zu interagieren.
• Verständlich — Inhalt und Interface-Verhalten müssen vorhersehbar und lesbar sein, einschließlich klarer Formularbeschriftungen und konsistenter Navigation.
• Robust — Inhalte müssen zuverlässig über assistive Technologien wie Screenreader hinweg funktionieren, was stark von sauberem, semantischem HTML und korrekter ARIA-Nutzung abhängt.

WCAG 2.2 fügte neun neue Erfolgskriterien zu 2.1 hinzu, mehrere davon zielen speziell auf mobile und kognitive Barrierefreiheit — eine Mindestgröße für klickbare Elemente, konsistente Platzierung von Hilfsmechanismen über Seiten hinweg, und klarere sichtbare Fokusindikatoren für Tastaturnutzer.

Die häufigsten WordPress-Barrierefreiheitsfehler

Wir haben einen vollständigen axe-core-plus-Playwright-Barrierefreiheitsaudit über diese Site laufen lassen — 14 Seiten in Dunkel- und Hellmodus —, und es ist eine nützliche reale Stichprobe genau dafür, wo WordPress-Sites typischerweise scheitern, da die gefundenen Probleme völlig typisch statt sitespezifisch waren.

• Farbkontrast bei dekorativen Elementen. Kategorie-Tags und farbige Badges verwendeten rohe Markenfarben direkt als Textfarbe auf getönten Hintergründen und erreichten nur etwa 3,3-4,0:1 — unter dem 4,5:1-Minimum für normalen Text bei AA. Die Lösung war, separate, zweckgebundene "textsichere" Farb-Tokens zu definieren, statt Markenfarben direkt als Text wiederzuverwenden.
• Übersprungene Überschriftenhierarchie. Eine Übersichtsseite sprang von einem H1 direkt zu H3-Abschnitten ohne H2 dazwischen, was visuell unsichtbar ist, aber die logische Dokumentgliederung bricht, auf die sich Screenreader-Nutzer bei der Navigation verlassen.
• Nur farblich unterschiedene Links. Inline-Links in längeren Textblöcken hatten eine andere Farbe als der umgebende Text, waren aber nicht unterstrichen, was die Anforderung verletzt, dass die Unterscheidung Link-vs-Text nicht allein von Farbwahrnehmung abhängen darf.
• Fehlende ARIA-Attribute bei benutzerdefinierten interaktiven Komponenten. Ein benutzerdefiniertes FAQ-Akkordeon hatte kein aria-expanded, aria-controls oder role="region" — funktional für einen Mausnutzer, aber mehrdeutig für einen Screenreader-Nutzer ohne Signal über den Zustand des Akkordeons.

Keines davon wurde durch bloßes Betrachten der Seite entdeckt — sie kamen durch kombiniertes automatisiertes Scannen und manuelle Überprüfung ans Licht, das Muster, das es wert ist, auf jeder WordPress-Site wiederholt zu werden.

Ein praktischer Audit-Prozess

Schritt	Tool/Methode	Erfasst
Automatisierter Scan	axe-core oder WAVE-Browsererweiterung	Fehlender Alt-Text, Kontrastfehler, fehlende Formularbeschriftungen
Reiner Tastaturdurchgang	Ohne Maus durch die gesamte Seite tabben	Kaputte Fokusreihenfolge, unerreichbare interaktive Elemente
Screenreader-Stichprobe	VoiceOver (Mac) oder NVDA (Windows)	Mehrdeutiges ARIA, verwirrende Überschriftenstruktur
Manuelle Kontrastprüfung	Browser-Entwicklertools oder ein Kontrastprüfer	Kontrastprobleme in Zuständen, die automatisierte Tools übersehen (Hover, Fokus)
Beide Farbmodi	Alles Obige in Dunkel- und Hellmodus wiederholen	Kontrastregressionen, die nur in einem Theme auftreten

Häufige WordPress-spezifische Problemstellen

• Theme- und Page-Builder-Standardeinstellungen kommen oft mit in Templates eingebackenen Kontrast- oder Überschriftenstrukturproblemen, die sich dann auf jeder Seite mit diesem Template wiederholen.
• Von Plugins hinzugefügte Widgets (Slider, Akkordeons, Tabs) fehlen häufig korrekte ARIA-Attribute, da nicht jeder Plugin-Autor mit assistiver Technologie testet.
• Hochgeladene Bilder ohne Alt-Text sind eine der häufigsten und am leichtesten zu behebenden Verletzungen — eine Medienbibliothek auf fehlenden Alt-Text massenhaft zu prüfen, erfasst jahrelang angesammelte Lücken auf einmal. Erdo Image Optimizer enthält einen eingebauten Audit, der Bilder mit fehlendem Alt-Text über die gesamte Medienbibliothek hinweg markiert, neben der Dateigrößenoptimierung, die wir in unserem Bilder-SEO-Leitfaden behandeln.
• Cookie-Consent-Banner und Modals werden bei Tastaturfokus-Tests häufig übersehen, da sie nach dem Laden der Hauptseite hinzugefügt werden und leicht außerhalb der regulären Tab-Reihenfolge einer Site fallen.

Barrierefreiheit ist Wartung, kein einmaliges Projekt

Ein WCAG-Audit korrigiert, was in dem Moment existiert, in dem er durchgeführt wird; jeder neue Blogbeitrag, jedes neue Plugin und jede Template-Änderung ist eine frische Gelegenheit, ein Problem wieder einzuführen, das dieser Audit bereits geschlossen hat. Barrierefreiheitsprüfungen als Teil des regulären Publishing- und Entwicklungsworkflows zu behandeln — nicht als ein Projekt, das einmal als erledigt markiert wird — ist das, was eine Site sechs Monate später noch konform hält, nicht nur am Launch-Tag.

Häufige Fehler

• Sich allein auf einen automatisierten Scanner verlassen, wodurch manuelle Tastatur- und Screenreader-Probleme übersehen werden, die kein Scanner beurteilen kann.
• Kontrast nur im Hellmodus korrigieren, während eine Site mit Dunkelmodus-Umschalter beide unabhängig prüfen muss.
• Annehmen, ein populäres Theme oder ein Page-Builder sei standardmäßig barrierefrei, während Kontrast- und Überschriftenprobleme auf Template-Ebene sich auf jeder daraus gebauten Seite wiederholen.
• Einen Barrierefreiheitsaudit als einmalige Aufgabe behandeln statt als laufende Prüfung, die auf neue Inhalte und Funktionen bei ihrer Veröffentlichung angewendet wird.
• Alt-Text bei neuen Bild-Uploads überspringen, selbst nachdem ein Massenaudit den bestehenden Rückstand behoben hat, wodurch sich die Lücke leise wieder aufbaut.

Zusammenfassung

Kurz gesagt: WCAG-2.2-AA-Konformität für eine WordPress-Site läuft auf eine kurze, wiederkehrende Liste realer Fehlerpunkte hinaus — Farbkontrast, fehlender Alt-Text, Tastaturnavigation, Überschriftenstruktur und ARIA-Nutzung bei benutzerdefinierten Komponenten —, die zuverlässig nur durch eine Kombination aus automatisiertem Scannen und manuellem Testen erfasst und durch laufende Gewohnheit statt einen einzelnen Audit aufrechterhalten werden. Da das EU-Barrierefreiheitsgesetz jetzt in Kraft ist statt anzustehen, macht die Behandlung als Routinewartung statt als zukünftige Aufgabe den Unterschied zwischen einer konformen Site und einem Haftungsrisiko.