Barrierefreiheit (WCAG 2.2) in 2026: Ist Ihre WordPress-Site legal?

Seit dem 28. Juni 2025 wenden die EU-Mitgliedstaaten die nationalen Gesetze zum European Accessibility Act (EAA), der Richtlinie (EU) 2019/882, an. In Deutschland ist das das Barrierefreiheitsstärkungsgesetz (BFSG). Für viele Onlineshops, Bankdienstleistungen und Verkehrsangebote ist digitale Barrierefreiheit damit eine gesetzliche Anforderung.

Für WordPress-Entwickler und Website-Betreiber ist WCAG 2.2 Level AA der praktische technische Maßstab. Dieser Leitfaden zeigt, welche WCAG-2.2-Kriterien WordPress-Themes am häufigsten verletzen, was Richtlinie und BFSG tatsächlich verlangen und wie Sie vor jedem Release testen. Er ersetzt keine Rechtsberatung für Ihren Fall.

Offizielle Quellen: die WCAG-2.2-Empfehlung, der Text der Richtlinie 2019/882, das BFSG und das WordPress-Handbuch zur Barrierefreiheit.

#Für wen gilt der European Accessibility Act

Früher galten Gesetze zur Barrierefreiheit vor allem für den öffentlichen Sektor. Der EAA erweitert die Anforderungen auf die Privatwirtschaft, aber nur für bestimmte Kategorien. Artikel 2 Absatz 2 der Richtlinie nennt die Dienstleistungen, die nach dem 28. Juni 2025 für Verbraucher erbracht werden:

• elektronische Kommunikationsdienste;
• Dienste, die Zugang zu audiovisuellen Mediendiensten bieten;
• Elemente von Personenbeförderungsdiensten im Luft-, Bus-, Schienen- und Schiffsverkehr (Websites, Apps, elektronische Tickets, Reiseinformationen);
• Bankdienstleistungen für Verbraucher;
• E-Books und die dafür bestimmte Software;
• Dienstleistungen im elektronischen Geschäftsverkehr.

Die Richtlinie definiert den elektronischen Geschäftsverkehr als Dienstleistungen, die über Websites und mobile Anwendungen elektronisch im Fernabsatz auf individuelle Anfrage eines Verbrauchers erbracht werden, um einen Verbrauchervertrag abzuschließen. Ein WooCommerce-Shop, der an Verbraucher in der EU verkauft, fällt unter diese Definition. Die Website einer Beratung, die nur Unternehmen bedient und online keine Verbraucherverträge schließt, steht nicht auf der Liste.

#Welche Ausnahmen die Richtlinie vorsieht

• Kleinstunternehmen, die Dienstleistungen erbringen (Art. 4 Abs. 5), sind von den Barrierefreiheitsanforderungen für Dienstleistungen befreit. Die Richtlinie definiert ein Kleinstunternehmen als Unternehmen mit weniger als 10 Beschäftigten und einem Jahresumsatz oder einer Jahresbilanzsumme von höchstens 2 Millionen Euro. Für Produkte gilt die Ausnahme nicht.
• Grundlegende Veränderung und unverhältnismäßige Belastung (Art. 14): Die Anforderungen gelten nur, soweit sie die Dienstleistung nicht grundlegend verändern und den Wirtschaftsakteur nicht unverhältnismäßig belasten. Die Beurteilung muss dokumentiert und fünf Jahre aufbewahrt werden.
• Ausgenommene Inhalte (Art. 2 Abs. 4): etwa aufgezeichnete zeitbasierte Medien und Büro-Dateiformate, die vor dem 28. Juni 2025 veröffentlicht wurden, sowie Inhalte Dritter, die der Akteur weder finanziert noch entwickelt oder kontrolliert.

#Fristen aus der Richtlinie

Die Richtlinie nennt keine Bußgeldbeträge. Artikel 30 verpflichtet die Mitgliedstaaten zu wirksamen, verhältnismäßigen und abschreckenden Sanktionen, die Schwere des Verstoßes, die Zahl der betroffenen Produkte oder Dienstleistungen und die Zahl der betroffenen Personen berücksichtigen.

#Wie das BFSG den EAA umsetzt und welche Bußgelder drohen

Das Barrierefreiheitsstärkungsgesetz vom 16. Juli 2021 (BGBl. I S. 2970) setzt die Richtlinie 2019/882 in deutsches Recht um. Für WordPress-Betreiber sind vier Paragrafen zentral:

• § 1 Abs. 2 und 3: Das Gesetz gilt für Produkte, die nach dem 28. Juni 2025 in Verkehr gebracht werden (Abs. 2), und für die in Abs. 3 genannten Dienstleistungen, die nach diesem Datum für Verbraucher erbracht werden, darunter der elektronische Geschäftsverkehr.
• § 3 Abs. 3: Kleinstunternehmen, die Dienstleistungen anbieten oder erbringen, sind von den Anforderungen nach Absatz 1 ausgenommen.
• § 37: Wer entgegen § 14 Abs. 1 eine Dienstleistung anbietet oder erbringt, die die Anforderungen nicht erfüllt (§ 37 Abs. 1 Nr. 8), riskiert eine Geldbuße bis zu 100.000 Euro. Für die übrigen Fälle, etwa fehlende oder falsche Informationen, liegt die Obergrenze bei 10.000 Euro (§ 37 Abs. 2).
• § 38: Dienstleister dürfen Produkte, die sie schon vor dem 28. Juni 2025 rechtmäßig eingesetzt haben, bis zum 27. Juni 2030 weiter nutzen. Für Selbstbedienungsterminals gilt eine Grenze von fünfzehn Jahren nach Inbetriebnahme, kürzer als die zwanzig Jahre, die die Richtlinie erlaubt.

Mehr zur Umsetzung in Shops finden Sie im Beitrag zur BFSG-Frist für WordPress-Shops. Wer auch in andere Länder verkauft, trifft auf andere Gesetze. Einen ausführlichen Vergleich bietet der Beitrag zu Bußgeldern und Pflichten nach Land. Kurzüberblick:

#Auf welche technische Norm sich der EAA stützt

Der EAA erwähnt WCAG nicht. Anhang I verlangt, Websites und mobile Anwendungen einheitlich und angemessen wahrnehmbar, bedienbar, verständlich und robust zu gestalten: dieselben vier Prinzipien, auf denen WCAG aufbaut. Artikel 15 regelt die Konformitätsvermutung für Dienstleistungen, die harmonisierten Normen entsprechen, deren Fundstellen im Amtsblatt veröffentlicht wurden.

WordPress hat seine Version bereits gewählt. Die Codierstandards zur Barrierefreiheit erwarten, dass Code im WordPress-Ökosystem, also Core, WordPress.org-Websites und offizielle Plugins, WCAG 2.2 auf Level AA erfüllt. Neue Redaktionsoberflächen sollen zusätzlich ATAG 2.0 berücksichtigen.

#Was sich zwischen WCAG 2.1 und WCAG 2.2 geändert hat

WCAG 2.2 wurde am 5. Oktober 2023 W3C-Empfehlung, die aktuelle Fassung datiert vom 12. Dezember 2024. Laut What’s new in WCAG 2.2 kommen neun Erfolgskriterien hinzu:

Für ein AA-Ziel zählen sechs davon. Die drei AAA-Kriterien sind als Designvorgabe trotzdem nützlich.

#Warum WCAG 2.2 das Kriterium 4.1.1 gestrichen hat

4.1.1 Syntaxanalyse (Parsing) gilt als überholt und wurde entfernt. Das W3C begründet das damit, dass assistive Technologien HTML nicht mehr selbst parsen, sondern sich auf den Browser stützen. Fehler, die früher 4.1.1 verletzten, fallen heute unter 1.3.1 Info und Beziehungen oder 4.1.2 Name, Rolle, Wert. Nationale Regelwerke auf Basis von WCAG 2.1 können es weiterhin verlangen.

#Wie man die neuen WCAG-2.2-Kriterien in WordPress-Themes erfüllt

#2.4.11 Fokus nicht verdeckt (Minimum) (AA)

Erhält eine Komponente den Tastaturfokus, darf sie nicht vollständig durch vom Autor erstellte Inhalte verdeckt sein. Die AAA-Variante (2.4.12) verlangt, dass kein Teil verdeckt ist.

• Das Problem: Sie tabben eine Seite hinunter. Ein Element erhält den Fokus, aber Ihr Sticky Header oder Cookie-Banner verdeckt es. Der Benutzer weiß, dass der Fokus irgendwo ist, kann aber nicht sehen wo.
• Die Lösung: Verwenden Sie scroll-padding-top auf dem html-Element, damit fokussierte Elemente in den sichtbaren Bereich unterhalb des Sticky Headers scrollen.

html {
  scroll-padding-top: 80px; /* Höhe Ihres Sticky Headers */
}

Lassen Sie das Cookie-Banner in der Tab-Reihenfolge, mit sichtbarem Schließen-Button, und vermeiden Sie overflow: hidden auf Containern, die den Fokusrahmen abschneiden.

#2.4.7 Fokus sichtbar und 2.4.13 Fokus-Erscheinungsbild

Viele Themes entfernen outline aus optischen Gründen und ersetzen es nicht. Das verletzt 2.4.7 Fokus sichtbar, das weiterhin Stufe AA ist. Kriterium 2.4.13 (AAA) liefert eine messbare Designvorgabe: Die Fläche des Indikators soll mindestens so groß sein wie ein 2 CSS-Pixel dicker Rahmen um die unfokussierte Komponente, mit einem Kontrast von mindestens 3:1 zwischen denselben Pixeln im fokussierten und unfokussierten Zustand.

In Block-Themes gehört der :focus-visible-Stil in die theme.json oder in ein kleines Stylesheet, das im Editor und im Frontend geladen wird.

#2.5.7 Ziehbewegungen (AA)

Jede Funktion, die per Ziehen bedient wird, muss sich auch mit einem einzelnen Zeiger ohne Ziehen ausführen lassen, außer das Ziehen ist wesentlich. Das betrifft sortierbare Menüs, Schieberegler und Kanban-artige Builder. Gutenberg bietet für viele Interaktionen Alternativen; eigene Blöcke, die nur auf Drag-Events reagieren, brauchen Buttons oder Eingabefelder.

#2.5.8 Zielgröße (Minimum) (AA)

Zeigerziele müssen mindestens 24 mal 24 CSS-Pixel groß sein. Das Kriterium kennt fünf Ausnahmen:

• Abstand: Ein kleineres Ziel besteht, wenn ein Kreis mit 24 CSS-Pixeln Durchmesser um seine Mitte kein anderes Ziel und keinen Kreis eines anderen kleinen Ziels schneidet.
• Äquivalent: Dieselbe Funktion ist über ein anderes Bedienelement auf der Seite erreichbar, das die Größe erfüllt.
• Inline: Das Ziel steht in einem Satz oder seine Größe wird durch die Zeilenhöhe des Textes begrenzt.
• Steuerung durch den User Agent: Der Browser bestimmt die Größe und der Autor ändert sie nicht.
• Wesentlich: Eine bestimmte Darstellung ist wesentlich oder rechtlich vorgeschrieben.

Prüfen Sie kleine „X“-Buttons in Popups, Paginierungspfeile, Social-Icon-Leisten, Checkboxen und Karussell-Steuerungen. Mit padding, min-width und min-height wächst die Klickfläche, ohne dass sich das Icon optisch ändert.

#3.2.6 Konsistente Hilfe (A)

Wiederholen sich Hilfemechanismen auf mehreren Seiten, müssen sie in derselben Reihenfolge relativ zum übrigen Inhalt erscheinen. Gemeint sind Kontaktdaten einer Person, ein Kontaktmechanismus zu einer Person, eine Selbsthilfe-Option und ein vollautomatischer Kontaktmechanismus wie ein Chatbot. Halten Sie Support-Link oder Chat-Widget im WordPress-Template auf jeder Seite an derselben Stelle.

#3.3.7 Redundante Eingaben (A)

Angaben, die der Benutzer im selben Prozess schon gemacht hat, müssen automatisch ausgefüllt oder zur Auswahl angeboten werden. Ausnahmen gelten, wenn die erneute Eingabe wesentlich ist, der Sicherheit dient oder der frühere Wert nicht mehr gültig ist. In WooCommerce deckt die Option „Rechnungsadresse wie Lieferadresse“ den häufigsten Fall ab.

#3.3.8 Barrierefreie Authentifizierung (Minimum) (AA)

Kein Schritt der Anmeldung darf einen kognitiven Funktionstest verlangen, etwa sich ein Passwort merken oder ein Rätsel lösen, es sei denn, der Schritt bietet mindestens eines davon: eine alternative Methode ohne solchen Test, einen unterstützenden Mechanismus (zum Beispiel einen Passwortmanager), einen Test zur Objekterkennung oder das Erkennen von Nicht-Text-Inhalten, die der Benutzer selbst bereitgestellt hat. Die AAA-Variante (3.3.9) streicht die letzten beiden Ausnahmen.

• Die Auswirkung auf WordPress: Blockieren Sie das Einfügen in Passwort- und Einmalcode-Felder nicht, damit Passwortmanager funktionieren. Nutzen Sie, wo das Produkt es erlaubt, Magic Links per E-Mail oder WebAuthn und Passkeys. Prüfen Sie Skripte von Mitgliedschafts-Plugins, die das Einfügen sperren, und Bot-Schutz von Drittanbietern.

#Wie man semantisches HTML in WordPress-Themes einsetzt

Die meisten dauerhaften Korrekturen sind schlicht korrektes HTML, ohne Plugins und Overlays.

• Landmarks: Verwenden Sie <main>, <nav>, <aside>, <footer>. Screenreader-Benutzer springen zwischen diesen Regionen. Ertränken Sie nicht alles in <div>-Suppe.
• Überschriften: h1 bis h6 ist eine Hierarchie, keine Stilwahl. Springen Sie nicht von h2 zu h4, nur weil Sie eine kleinere Schrift wollen. Die Größe regelt CSS.
• Buttons und Links:
  • Führt zu einer neuen URL? Verwenden Sie <a>.
  • Ändert etwas auf der aktuellen Seite (öffnet ein Menü)? Verwenden Sie <button>.
  • Verwenden Sie niemals <div onClick="...">. Es erhält keinen Tastaturfokus, und Screenreader kündigen es nicht als Bedienelement an.
• Bilder: Bilder mit Inhalt bekommen alt, dekorative Bilder ein leeres alt.

ARIA ergänzt HTML, wo natives HTML nicht ausreicht. Ein echter <button> ist besser als role="button" auf einem span.

#Welche Gutenberg-Blöcke bei Barrierefreiheitstests oft durchfallen

Core-Blöcke und der Block-Editor haben die Tastaturbedienung über mehrere Versionen verbessert. Das macht nicht jede veröffentlichte Seite barrierefrei. Muster, die weiterhin scheitern:

• Gruppen- und Cover-Blöcke mit kontrastarmem Text auf unruhigen Bildern. Prüfen Sie den Kontrast nach Anwendung der Theme-Farbpalette.
• Navigationsblock mit Mega-Menüs, die sich nur per Hover öffnen. Öffnen per Klick oder Enter, Schließen per Escape ergänzen.
• Eigene Blöcke, die interaktive Widgets ohne fokussierbare Elemente oder mit falschem aria-expanded ausgeben.
• Patterns aus Marktplätzen mit falsch verschachtelten Überschriften oder doppeltem h1.

Für Redakteure: Prüfen Sie die Überschriftenreihenfolge vor dem Veröffentlichen in der Listenansicht und nutzen Sie die nativen Bild- und Galerie-Blöcke, damit das alt-Feld bearbeitbar bleibt. Für Theme-Entwickler: Testen Sie die Arbeitsfläche des Website-Editors und das Frontend-HTML, denn beide sind nicht immer identisch.

#Wie man klassische und Block-Themes auf Barrierefreiheit prüft

Klassische PHP-Themes scheitern, wenn Templates unzugängliche Menüs fest einbauen oder style.css die Fokusstile entfernt. Hybride Setups (klassisches Theme mit Block-Template-Teilen) brauchen dieselben Sticky- und Fokus-Tests in PHP- und HTML-Templates.

Block-Themes (theme.json, Template-Teile) bündeln Farben und Typografie. Das hilft beim Kontrast, wenn die Palette mit AA-Verhältnissen geplant ist. Es macht aber auch einen globalen Sticky Header leicht, der 2.4.11 auf jeder Seite verletzt: Die Korrektur erfolgt einmal im Header-Template-Teil.

WooCommerce und Formular-Plugins setzen auf das Theme auf. Checkout, Kundenkonto und Kontaktformular brauchen jeweils einen eigenen Tastaturtest.

#Was das Tag accessibility-ready von einem WordPress-Theme verlangt

Das Theme-Verzeichnis auf WordPress.org vergibt das Tag accessibility-ready nur nach einer zusätzlichen Prüfung. Das Handbuch des Themes-Teams nennt 18 Pflichtpunkte:

1. Link zum Überspringen der Navigation;
2. Landmarks mit sinnvollen Rollen und Namen;
3. vollständige Tastaturbedienung;
4. Bedienelemente mit zugänglichem Namen, Rolle und Zustand;
5. beschriftete Formularfelder;
6. Überschriften mit sinnvoller Struktur;
7. unterstrichene Links im Fließtext;
8. keine mehrdeutigen Linktexte;
9. ausreichender Kontrast von Text und Bedienelementen;
10. Alternativtext für Bilder und Grafiken;
11. barrierefreies Audio, Video und Animationen;
12. Unterstützung für Reflow, Vergrößerung und geänderte Textabstände;
13. keine unerwarteten Kontextwechsel;
14. keine Links, die ohne Hinweis neue Fenster oder Tabs öffnen;
15. barrierefreie Inhalte bei Hover oder Fokus;
16. eine Erklärung zur Barrierefreiheit;
17. keine Empfehlung oder Voraussetzung unzugänglicher Plugins;
18. Unterstützung für Screenreader-Text.

Das Tag zertifiziert Ihre Website nicht, denn Plugins, Patterns und Inhalte können ein geprüftes Theme brechen. Es liefert eine geprüfte Basis und eine Checkliste für eigene Themes.

#Helfen Overlay-Plugins bei der Barrierefreiheit

Sie haben sie gesehen: das kleine Personen-im-Kreis-Icon in der Ecke, das ein Menü zum Ändern von Kontrast oder Schriftgröße öffnet.

Setzen Sie sie nicht als Weg zur Konformität ein.

• Falsche Sicherheit: Sie versprechen Konformität mit einer Zeile JavaScript, reparieren aber kein semantisches HTML.
• Reibung für Benutzer: Blinde Benutzer haben ihre Screenreader bereits eingerichtet. Ein Overlay kann mit diesen Werkzeugen kollidieren.
• Regulatorisches Risiko: Am 22. April 2025 hat die US-Handelsbehörde FTC eine endgültige Anordnung bestätigt, nach der accessiBe eine Million Dollar zahlen muss. Die FTC wertete die Behauptung, das Widget mache jede Website WCAG-konform, als falsch, irreführend oder unbelegt.

Der einzige verlässliche Weg ist barrierefreier Code von Anfang an oder die Korrektur des bestehenden Codes.

#Wie man Barrierefreiheit vor jedem Release testet

Sie können Barrierefreiheit nicht zu 100 % automatisieren. Automatische Tools sind der erste Schritt, übersehen aber die meisten Tastaturfallen und viele verdeckte Fokuszustände.

#Test-Workflow für Barrierefreiheit in drei Schritten

1. Automatisiert: Verwenden Sie axe-core oder das Lighthouse-Audit zur Barrierefreiheit auf Startseite, Archiv, Beitrag, Suche, Formular und Checkout. Das findet fehlenden alt-Text, geringen Kontrast und fehlerhafte ARIA-Attribute und lässt sich bei jedem Deployment in der CI ausführen.
2. Manuell mit Tastatur: Ziehen Sie die Maus ab. Können Sie das Menü durchlaufen, Untermenüs öffnen und das Kontaktformular nur mit Tab, Enter und Leertaste absenden? Prüfen Sie, ob der Fokus sichtbar ist, die Tab-Reihenfolge logisch ist und Modale sich mit Escape schließen.
3. Screenreader: Schalten Sie VoiceOver (Mac) oder NVDA (Windows) auf demselben Pfad ein. Haben Formulare beschreibende Labels, werden Statusänderungen angesagt?

Testen Sie nach Theme-Updates, nach Plugin-Updates, die Markup ändern, und nach Template-Änderungen im Website-Editor erneut. Viele Regressionen kommen mit einem CSS-Commit, der outline: none setzt.

Werkzeuge für den WordPress-Alltag: axe DevTools im Browser, WAVE von WebAIM, Pa11y auf der Kommandozeile in der CI und das Plugin Accessibility Checker im Editor.

#Wie man barrierefreie Formulare in WordPress baut

Contact Form 7, Gravity Forms und eigene Formulare folgen denselben Regeln.

• Labels: Jedes Eingabefeld braucht ein programmatisch verknüpftes <label>. Platzhalter sind keine Labels, sie verschwinden beim Tippen.
• Fehlermeldungen: „Fehler gefunden“ ist nutzlos. „In der E-Mail-Adresse fehlt das @-Zeichen“ ist barrierefrei. Verknüpfen Sie die Meldung per aria-describedby mit dem Feld.
• Fokus-Management: Kommt das Formular mit Fehlern zurück, setzen Sie den Tastaturfokus auf das erste fehlerhafte Feld oder auf eine Zusammenfassung mit Links zu den Feldern.
• Pflichtfelder: Nutzen Sie das Attribut required, nicht nur ein rotes Sternchen.
• Einfügen: Sperren Sie das Einfügen in Passwort- und Einmalcode-Feldern nicht.

#Wie man WooCommerce und Headless WordPress barrierefrei macht

Der WooCommerce-Checkout muss vollständig per Tastatur funktionieren: in den Warenkorb legen, Menge ändern, Gutschein einlösen, bezahlen, Bestätigung lesen. Produktvergleiche brauchen echte <table>-Elemente mit <th> und scope. Warenkorbhinweise sollten aria-live="polite" nutzen, damit Screenreader „in den Warenkorb gelegt“ ansagen, ohne den Benutzer zu unterbrechen.

Headless-Frontends mit React, Next.js oder Astro haben ein Problem, das klassische Themes nicht kennen: Routenwechsel in einer Single-Page-Anwendung laden die Seite nicht neu. Setzen Sie nach jedem Routenwechsel den Fokus auf den Hauptinhalt, sagen Sie den neuen Seitentitel über eine aria-live-Region an und aktualisieren Sie document.title. Serverseitiges Rendering hilft, weil der Inhalt schon im ersten HTML steht.

#WCAG-2.2-AA-Checkliste für WordPress-Websites

• Sichtbare :focus-visible-Stile im ganzen Theme, nie verdeckt von Header oder Banner.
• Ziele mit 24 mal 24 CSS-Pixeln oder dem Abstand, den 2.5.8 erlaubt.
• Eine Alternative ohne Ziehen für jedes ziehbare Bedienelement.
• Hilfe in derselben Reihenfolge auf allen Templates.
• Keine doppelte Eingabe derselben Daten im selben Prozess.
• Anmeldung, die eingefügte Passwörter und Codes akzeptiert.
• Eine schriftliche Beurteilung nach Art. 14, wenn Sie sich auf unverhältnismäßige Belastung berufen.

Wenn Sie Theme-Templates, Block-Markup oder den Checkout gegen WCAG 2.2 AA prüfen lassen wollen, beginnt ein Barrierefreiheits-Audit nach BFSG bei WPPoland mit den Templates, die Sie tatsächlich ausliefern, nicht mit einem Overlay. Eine breitere Prüfung der EU-Pflichten beschreibt das EU-Konformitätsaudit.