WordPress barrierefrei: Theme, Builder und Redaktion

Die kurze Antwort: WordPress ist weder barrierefrei noch das Gegenteil davon. Es ist ein Baukasten, und das Ergebnis hängt davon ab, was man hineinstellt. WordPress läuft auf 39,5 % aller Websites und auf 58,3 % der Websites mit bekanntem Content-Management-System ^[1]. Entsprechend groß ist die Spannweite: Eine durchschnittliche WordPress-Startseite hatte im Februar 2026 52,8 automatisch erkennbare Barrierefreiheits-Fehler, 5,8 % weniger als der Schnitt aller geprüften Startseiten von 56,1 ^[2]. Das ist etwas besser als der Durchschnitt und weit entfernt von konform. Dieser Artikel ist eine Orientierung, keine Rechtsberatung.

Das WordPress-Projekt selbst setzt sich klare Ziele: Admin-Oberfläche und mitgelieferte Themes sollen die WCAG 2.2 auf Stufe AA erfüllen, soweit möglich, und neuer oder geänderter Code muss den Accessibility Coding Standards des Projekts entsprechen ^[3]. Zugleich benennt das Projekt die Grenzen: Für Themes von Dritten kann es keine Konformität garantieren, das Label „accessibility-ready“ bestätigt nur, dass das Theme Review Team grundlegende Anforderungen geprüft hat, und die ATAG 2.0, die Richtlinien für Werkzeuge, die barrierefreie Inhalte fördern, erfüllt WordPress derzeit nicht ^[3].

Für Agenturen heißt das: Der Core ist eine brauchbare Grundlage, aber alles, was eine Website ausmacht, kommt von außerhalb des Cores. Theme, Builder, Plugins und die Redaktion entscheiden. Die gute Nachricht dabei: Keine dieser Schichten ist unveränderlich. Ein Theme lässt sich bereinigen, Builder-Elemente lassen sich austauschen, Plugins lassen sich reduzieren, und eine Redaktion lässt sich schulen. Die schlechte Nachricht: Niemand macht das für Sie, und ein nachträglich eingebautes Overlay-Skript ändert am Quelltext nichts; warum das nicht reicht, steht unter Overlay-Tools. Wer wissen will, wie dieselben Fragen bei einem CMS ohne Theme-Markt aussehen, findet den Vergleich unter Statamic barrierefrei; die systemunabhängige Prüfliste ist die Checkliste.

Vier Schichten, vier Fehlerquellen:

Theme. Das Theme bestimmt Dokumentstruktur, Überschriften-Hierarchie, Landmarken, Fokus-Stile und Kontraste. Ein Theme aus dem Marktplatz optimiert für Vorschaubilder, nicht für Screenreader. Typisch: Überschriften nach Größe statt nach Logik, entfernte Fokus-Rahmen, Grau auf Hellgrau. „Accessibility-ready“ ist hier ein Mindestmaß, kein Nachweis ^[3].

Builder. Slider, Akkordeons, Tabs, Mega-Menüs und Lightboxen sind die Stellen, an denen Tastatur und Screenreader am häufigsten scheitern. Die WebAIM-Auswertung zeigt den Zusammenhang über Bibliotheken: Seiten mit Lightbox hatten 70,5 Fehler, mit OWL Carousel 70,7, mit Slick 70,9, mit Swiper 74,0, mit Slider Revolution 67,2, jeweils deutlich über dem Schnitt von 56,1 ^[2]. Ein Builder kann sauberes HTML erzeugen; Bricks etwa legt Header, Main und Footer als Landmarken an, liefert seit Version 1.3 Skip-Links und einen Standard-Fokusrahmen mit und macht Menüs per Tastatur bedienbar ^[6]. Ob das Ergebnis barrierefrei ist, entscheidet aber, welche Elemente man einsetzt und wie man sie konfiguriert.

Plugins. Formulare, Cookie-Banner, Shop, Terminbuchung, Chat: Jedes Plugin bringt eigenes HTML, eigenes JavaScript und eigene Fehler mit. Je mehr Plugins, desto mehr Quellen, die bei jedem Update neu geprüft werden müssen.

Redaktion. Alt-Texte, Überschriften-Ebenen, Linktexte, Tabellen, hochgeladene PDFs: Das beste Theme hilft nicht, wenn im Editor jede Zwischenüberschrift eine H4 ist, weil die am schönsten aussah, und jedes Bild „IMG_4711“ heißt. Genau hier greift die fehlende ATAG-Konformität: Ein Werkzeug, das die ATAG 2.0 erfüllt, müsste Redakteure zum Erstellen barrierefreier Inhalte anleiten und ihnen beim Beheben von Fehlern helfen; WordPress erfüllt die ATAG 2.0 nach eigener Aussage derzeit nicht ^[3].