Barrierefreiheit mit WordPress

WordPress ist nicht das Problem – und auch nicht die Lösung. Der Kern liefert brauchbares HTML, aber über 90 % dessen, was am Ende ausgeliefert wird, entscheiden Theme, Page-Builder, Plugins und die tägliche Redaktion. Genau dort entstehen die Barrieren, und genau dort lassen sie sich mit überschaubarem Aufwand beseitigen.

Das Wichtigste in Kürze

• Der WordPress-Kern folgt eigenen Accessibility Coding Standards mit WCAG 2.2 auf Stufe AA als Zielmarke. Für den ausgelieferten Quelltext einer Seite ist er aber nur zu einem kleinen Teil verantwortlich.
• Der Theme-Tag accessibility-ready im offiziellen Theme-Verzeichnis ist das einzige geprüfte Qualitätssignal, das WordPress anbietet – er sagt etwas über das Theme aus, nichts über deine fertige Website.
• Page-Builder sind die teuerste Einzelentscheidung. Elementor, Divi und WPBakery erzeugen Verschachtelungen aus div-Elementen, in denen Überschriftenebenen, Landmarks und Fokusreihenfolge nachträglich mühsam repariert werden müssen.
• Die vier Plugin-Kategorien mit dem höchsten Risiko: Consent-Banner, Slider, Formular-Plugins und Overlay-Werkzeuge. Jede davon setzt eigenes Markup und eigenes JavaScript in deine Seite.
• Redaktionsentscheidungen wiegen schwerer als Code: Überschriftenebenen, Alt-Texte, Linktexte und Tabellenköpfe entstehen im Block-Editor, nicht im Theme.
• Von Overlay-Plugins rate ich ab. Sie ändern nichts an den Ursachen im Markup und gelten unter dem BFSG nicht als Konformitätsnachweis.
• Stand August 2026 gibt es kein Plugin und kein Theme, das eine WordPress-Website automatisch BFSG-konform macht. Wer das verspricht, verkauft ein Versprechen.

Kein Rechtsrat. Ob deine WordPress-Website unter das BFSG fällt, hängt von Angebot und Unternehmensgröße ab – das klärt der BFSG-Schnelltest und im Zweifel eine juristische Prüfung. Hier geht es um die technische Umsetzung.

Was WordPress selbst schon richtig macht

Der Kern hat eine lange Geschichte im Thema, und das merkt man. Das WordPress-Accessibility-Handbuch schreibt für Kern, Standard-Themes und Bundle-Plugins WCAG 2.2 auf Stufe AA vor; ein eigenes Team prüft Patches darauf. Konkret bekommst du ohne eigenes Zutun:

• einen sauberen Dokumentkopf mit lang-Attribut und sinnvollem Seitentitel,
• semantische Grundstruktur in den mitgelieferten Themes – Landmarks, Überschriften, Listen,
• einen Skip-Link zum Hauptinhalt in den Standard-Themes,
• Formularfelder im Kommentarbereich mit verknüpften Labels.

Das ist mehr, als die meisten selbstgebauten Systeme mitbringen. Es beschreibt aber einen Auslieferungszustand, den kaum jemand behält.

Die drei Stellen, an denen es fast immer bricht

Wenn ich eine WordPress-Seite prüfe, finde ich die Befunde mit erstaunlicher Regelmäßigkeit in derselben Reihenfolge: erst das Theme, dann die Plugins, dann die Inhalte. Das ist auch die Reihenfolge, in der sich Aufwand und Wirkung am besten verhalten – ein Theme-Wechsel repariert Dutzende Seiten auf einmal, ein Alt-Text genau ein Bild.

1. Theme und Page-Builder

Das Theme bestimmt das Markup jeder einzelnen Seite: Überschriftenhierarchie, Landmarks, Fokusringe, Kontraste, Menüverhalten. Ein Theme mit einer h3 als Seitentitel und einer h1 im Logo verursacht auf 300 Unterseiten denselben Fehler.

Im offiziellen Theme-Verzeichnis gibt es dafür den Filter accessibility-ready. Themes mit diesem Tag durchlaufen eine zusätzliche manuelle Prüfung auf Tastaturzugang, Kontrast, Fokussichtbarkeit und Überschriftenstruktur. Das ist ein echtes Signal – mit zwei Einschränkungen, die man kennen muss: Der Tag gilt nur für Themes aus dem offiziellen Verzeichnis, nicht für gekaufte Themes von Marktplätzen. Und geprüft wird das Theme im Auslieferungszustand, nicht deine Website mit deinen Farben, deinen Plugins und deinen Inhalten.

2. Plugins

Jedes Plugin, das etwas ausgibt, kann Barrieren einbauen. Vier Kategorien fallen mir besonders häufig auf:

• Consent-Banner. Sie liegen vor allem anderen und fangen bei schlechter Umsetzung den Fokus ein. Worauf es ankommt, steht unter Cookie-Banner – wichtigster Punkt: Ablehnen muss gleichrangig und mit der Tastatur erreichbar sein.
• Slider und Karussells. Automatisch laufende Slider verstoßen gegen 2.2.2 Pausieren, beenden, ausblenden, wenn sie keinen Stopp-Knopf haben. Die Muster dazu stehen unter Slider und Karussells.
• Formular-Plugins. Hier entscheidet sich, ob Pflichtfelder erkennbar sind und ob Fehler am Feld ankommen. Prüfe das an einem echten Fehlversuch, nicht am Formular-Editor – Details unter Fehlermeldungen barrierefrei.
• Overlay- und „Barrierefreiheits-Widgets“. Dazu unten mehr.

3. Redaktion

Der dritte Block ist der, den kein Entwickler lösen kann: Was im Block-Editor entsteht, entsteht dort endgültig. Eine Überschrift, die nur groß aussehen soll, aber als h2 ausgezeichnet ist, zerstört die Überschriften-Hierarchie – und damit die Sprungnavigation, mit der Screenreader-Nutzer surfen.

Der Page-Builder-Punkt, ausführlich

Page-Builder verkaufen Freiheit im Layout und kaufen sie mit Kontrollverlust über das Markup. Ein per Drag-and-drop gebauter Abschnitt besteht typischerweise aus fünf bis acht geschachtelten div-Containern mit Utility-Klassen; Überschriftenebenen werden im Baukasten als Schriftgröße ausgewählt, nicht als Struktur.

Das ist reparabel, aber die Reparatur ist teuer, weil sie pro Seite anfällt statt einmal im Template. Meine Faustregel für neue Projekte: Wenn Barrierefreiheit eine Anforderung ist, baue das Layout im Block-Editor mit einem Block-Theme und nutze theme.json für die Gestaltung. Wenn ein Page-Builder gesetzt ist, prüfe an genau drei Stellen, bevor du dich festlegst:

1. Erzeugt die Überschriften-Auswahl echte h1–h6, oder nur Schriftgrößen?
2. Sind Akkordeon, Tab und Menü des Builders mit der Tastatur bedienbar und mit aria-expanded versehen?
3. Steht der Fokusring nach einem Klick auf „Vorschau“ noch, oder setzt das Theme outline: none?

Alle drei Fragen beantwortest du in zehn Minuten – und sparst dir damit unter Umständen ein Jahr Nachbesserung.

Was du im Block-Editor selbst steuerst

Diese Punkte gehören in jede Redaktionsschulung; sie machen erfahrungsgemäß den größten Teil der Befunde einer Inhaltsprüfung aus:

• Überschriften nach Bedeutung wählen. Der Editor zeigt die Ebene im Block-Menü an. Genau eine h1 je Seite, keine Ebene überspringen.
• Alt-Texte schreiben, nicht Dateinamen stehen lassen. Der Block-Editor bietet das Feld direkt an; dekorative Bilder bekommen ein leeres Alt-Attribut.
• Linktexte aussagekräftig formulieren. „Mehr erfahren“ dreimal auf einer Seite verstößt gegen 2.4.4 Linkzweck im Kontext.
• Tabellen mit Kopfzeile anlegen. Der Tabellen-Block hat eine Option dafür; ohne sie ist die Tabelle für Screenreader eine Zahlenwolke.
• Keine Bilder von Text hochladen. Preistabellen und Zitatgrafiken als PNG verstoßen gegen 1.4.5 und lassen sich nicht vergrößern.

Overlay-Plugins: warum sie nicht helfen

Es gibt eine ganze Produktkategorie, die verspricht, WordPress-Seiten per Plugin barrierefrei zu machen – meist als eingeblendetes Menü mit Schriftgrößen, Kontrast- und Vorlese-Schaltern. Drei Gründe, warum ich davon abrate:

Sie beheben die Ursache nicht. Ein Overlay ändert nichts daran, dass eine Schaltfläche keinen zugänglichen Namen hat oder ein Formularfeld kein Label. Es legt eine zweite Bedienoberfläche über eine kaputte erste.

Sie stören die vorhandene Hilfstechnik. Wer einen Screenreader nutzt, bringt seine eigene Vorlesefunktion mit. Ein Overlay, das eigene Tastenkürzel belegt oder ARIA nachträglich umschreibt, macht die Bedienung schwerer statt leichter.

Sie sind kein Nachweis. Das BFSG verlangt, dass das Angebot die Anforderungen erfüllt – nicht, dass ein Werkzeug installiert ist. Auch die BFSG-Checkliste und ein BITV-Test prüfen die Seite, nicht das Plugin-Verzeichnis.

So prüfst du deine WordPress-Seite

1. Eine Inhaltsseite und eine Formularseite auswählen – nicht die Startseite, die ist meist die am besten gepflegte.
2. Maus weglegen und mit Tab durchgehen. Kommst du an jedes Bedienelement? Ist der Fokus sichtbar? Details unter Tastaturbedienung & sichtbarer Fokus.
3. Überschriftenstruktur ansehen – mit der Browser-Erweiterung HeadingsMap oder dem Firefox-Accessibility-Inspector. Ergibt die Folge ein Inhaltsverzeichnis?
4. Auf 400 % zoomen und prüfen, ob die Seite umbricht (Reflow). Page-Builder-Raster mit festen Breiten fallen hier auf.
5. Ein Formular absichtlich falsch absenden. Steht die Fehlermeldung am Feld und im Klartext?
6. Das Consent-Banner mit der Tastatur bedienen – inklusive Ablehnen.
7. axe DevTools laufen lassen und die Befunde nach Vorlage sortieren: Was aus dem Theme kommt, meldest du dem Theme-Anbieter; was aus einem Plugin kommt, dem Plugin-Anbieter.

Den vollständigen Ablauf beschreibt Barrierefreiheit selbst testen.

Häufiger Fehler in der Praxis

Das Theme gewechselt und die Inhalte vergessen. Ein accessibility-ready-Theme repariert keine falschen Überschriftenebenen in 400 Beiträgen. Der Theme-Wechsel ist der erste Schritt, nicht der letzte.

Plugin-Updates als Risiko unterschätzt. Eine vorher saubere Seite bekommt mit einem Slider-Update plötzlich eine Tastaturfalle. Wer Barrierefreiheit einmal erreicht hat, braucht einen kurzen Regressionstest nach größeren Updates – die sechs Schritte oben reichen dafür.

Der Redaktion die Werkzeuge, aber nicht die Regeln gegeben. Das Alt-Text-Feld im Block-Editor wird konsequent leer gelassen, solange niemand erklärt hat, wofür es da ist und was ein guter Alt-Text ausmacht.

WooCommerce wie ein normales Plugin behandelt. Ein Shop ist rechtlich der schärfere Fall, weil er als Dienstleistung im elektronischen Geschäftsverkehr direkt vom BFSG erfasst ist. Checkout, Varianten und Filter gehören eigens geprüft – siehe Barrierefreiheit in Onlineshops.

Häufige Fragen

Gibt es ein Plugin, das WordPress barrierefrei macht?

Nein. Es gibt Plugins, die einzelne Punkte erleichtern – etwa fehlende Alt-Texte auflisten oder Kontraste im Backend prüfen. Barrierefreiheit entsteht aber aus dem Markup deines Themes, dem Verhalten deiner Plugins und der Qualität deiner Inhalte. Ein Werkzeug kann dabei helfen, es kann die Arbeit nicht ersetzen.

Woran erkenne ich ein barrierefreies WordPress-Theme?

Am zuverlässigsten am Filter accessibility-ready im offiziellen Theme-Verzeichnis – diese Themes durchlaufen eine zusätzliche manuelle Prüfung. Bei gekauften Themes hilft nur der eigene Test: Demo-Seite aufrufen, mit Tab durchgehen, Überschriftenstruktur ansehen, auf 400 % zoomen. Das dauert zehn Minuten und sagt mehr als jede Produktbeschreibung.

Ist der Block-Editor barrierefreier als ein Page-Builder?

In der Ausgabe meistens ja, weil er echte Überschriften, Listen und Tabellen erzeugt statt gestylter div-Container. Für die Bedienung des Editors selbst gilt das nicht uneingeschränkt – dort gibt es weiterhin bekannte Schwächen, die das Accessibility-Team schrittweise abarbeitet.

Muss ich mein WordPress-Backend barrierefrei machen?

Wenn Beschäftigte damit arbeiten, ist das eine arbeitsrechtliche Frage der behinderungsgerechten Ausstattung des Arbeitsplatzes, keine des BFSG – das Gesetz zielt auf Angebote gegenüber Verbrauchern. Für öffentliche Stellen sieht es anders aus: Die BITV 2.0 erfasst auch elektronisch unterstützte Verwaltungsabläufe und damit interne Anwendungen.

Reicht es, wenn mein Theme WCAG AA erfüllt?

Nein. Das Theme liefert das Gerüst, nicht die Seite. Über die fertige Website entscheiden zusätzlich deine Farbwahl (Kontraste ändern sich mit eigenen Farbwerten), deine Plugins und deine Inhalte. Geprüft wird immer die ausgelieferte Seite.

Verwandte Themen

• Barrierefreiheit nach Plattform – die Übersicht mit Shopware, TYPO3, Shopify und Baukästen
• Barrierefreiheit in Onlineshops – der schärfere Fall, wenn WooCommerce im Spiel ist
• BFSG-Checkliste für Websites – der systematische Durchgang durch die Pflichten
• Cookie-Banner – die erste Barriere auf fast jeder WordPress-Seite
• Was kostet eine barrierefreie Website? – Größenordnungen für Theme-Wechsel und Nachbesserung

Quellen

• WordPress Accessibility Handbook (WordPress Accessibility Team – Coding Standards und Zielmarke WCAG 2.2 AA)
• Accessibility-ready Theme Requirements (WordPress Theme Review Team – Prüfkriterien für den Theme-Tag)
• Understanding WCAG 2.2 (W3C – die Erfolgskriterien im Original)
• Barrierefreiheitsstärkungsgesetz (BFSG) (Gesetzestext auf gesetze-im-internet.de)