Wenn ich eine WordPress-Seite zum Audit bekomme, höre ich vorab fast immer denselben Satz: „Wir nutzen ein barrierefreies Theme und haben ein Accessibility-Plugin installiert, also sind wir auf der sicheren Seite.“ Und fast immer fällt die Seite trotzdem durch. Denn ein WordPress barrierefrei zu machen ist keine Frage eines einzigen Häkchens, sondern das Zusammenspiel von vier Ebenen: Theme, Inhalte, Erweiterungen und laufender Betrieb. In diesem Leitfaden zeige ich Ihnen, an welcher dieser Ebenen Barrierefreiheit in der Praxis wirklich scheitert, welche aktuellen Entwicklungen Sie kennen müssen – etwa die verschärften Theme-Anforderungen von 2026 – und warum gerade bei WordPress „einmal gemacht“ nie „fertig“ bedeutet. Mit Code, einer konkreten Checkliste und Beispielen aus echten Audits.

Ist WordPress barrierefrei – oder müssen Sie nachhelfen?

WordPress ist nicht automatisch barrierefrei – aber es gibt Ihnen ein gutes Fundament. Das Projekt unterhält ein eigenes Accessibility-Team, und der Kern von WordPress sowie der Adminbereich streben aktiv die Konformität mit den WCAG 2.2 auf Stufe AA an. Jeder neue Code im Core muss diesen Standards entsprechen. Das heißt aber nur, dass das Werkzeug selbst zugänglich ist – nicht automatisch die Seite, die Sie damit bauen. Ob Ihre Website am Ende barrierefrei ist, entscheidet sich auf vier Ebenen, die Sie alle im Griff haben müssen.

Wer nur an einer dieser vier Schichten arbeitet – meist am Theme – und die anderen drei ignoriert, baut die typische WordPress-Seite, die im Audit scheitert.

Dass sich die Mühe lohnt, steht für mich außer Frage. Wer sein WordPress barrierefrei macht, vergrößert die erreichbare Zielgruppe, verbessert die Lesbarkeit für Suchmaschinen und erfüllt zugleich die gesetzlichen Anforderungen, die seit Geltung des BFSG auch private Unternehmen treffen. Der Haken steckt im „vorausgesetzt“: Diesen Nutzen bekommen Sie nur, wenn Sie alle vier Ebenen angehen – ein gutes Theme allein verschenkt ihn wieder.

Schicht 1: Das richtige Theme als Fundament

Wenn Sie Ihr WordPress barrierefrei aufsetzen, beginnt alles beim Theme – es legt das Grundgerüst, und hier sollten Sie auf das Tag accessibility-ready achten. Themes mit diesem Kennzeichen werden vom Theme-Review-Team geprüft und folgen den WordPress Accessibility Coding Standards – sie bringen also eine saubere Überschriften-Struktur (Kriterium 1.3.1), ausreichende Kontraste (1.4.3), sichtbare Fokus-Markierungen (2.4.7) und Skip-Links (2.4.1) von Haus aus mit. Sie finden diese Themes über den Feature-Filter im offiziellen Verzeichnis. Moderne Block-Themes wie Twenty Twenty-Five, GeneratePress oder Kadence liefern Landmarks und barrierefreie Farbpaletten direkt mit.

Zwei Dinge müssen Sie dabei wissen. Erstens werden die Anforderungen an das Tag gerade verschärft: Theme-Autoren haben bis zum 30. Juni 2026 Zeit, ihre Themes zu aktualisieren oder das Kennzeichen zu entfernen. Verlassen Sie sich also nicht blind auf ein älteres „accessibility-ready“-Theme, sondern prüfen Sie, ob es noch gepflegt wird. Zweitens hat selbst das beste Theme Grenzen – im Block-Editor können Sie einzelnen Elementen keine semantischen HTML5-Bereiche wie <section> oder <article> zuweisen, und bei komplexen Layouts brauchen Sie ohnehin zusätzliche Sorgfalt. Das Theme ist das Fundament, nicht das fertige Haus.

Ein praktischer Rat, der später viel Ärger spart: Nehmen Sie eigene Korrekturen am Theme – etwa nachgebesserte Kontraste oder Fokus-Stile – grundsätzlich in einem Child-Theme vor und dokumentieren Sie sie. Sonst überschreibt das nächste Theme-Update Ihre mühsam erarbeitete Barrierefreiheit spurlos, und Sie beginnen von vorn.

Aus der Praxis: Ein mittelständischer Dienstleister hatte bewusst ein hochwertiges accessibility-ready-Theme gewählt und war überzeugt, damit alles getan zu haben. Im Audit war das Theme tatsächlich tadellos – aber die Startseite bestand fast vollständig aus einem Page-Builder-Layout, das die saubere Theme-Struktur komplett überschrieb. Das gute Fundament war unter einer Schicht unsemantischen Markups begraben. Ein Theme schützt Sie nicht vor dem, was Sie darauf bauen.

Schicht 2: Inhalte im Block-Editor richtig pflegen

Hier entstehen in der Praxis die meisten Barrieren, und zwar von Menschen ohne technischen Hintergrund. Der Block-Editor (Gutenberg) wurde gebaut, um Inhalte semantischer zu machen – doch viele nutzen ihn wie ein Design-Werkzeug: Sie stapeln Absatz-Blöcke übereinander, statt Überschriften zu verwenden, fügen Listen als reinen Text ein und gestalten optische Überschriften, indem sie Text einfach fett und groß formatieren. Visuell sieht das ordentlich aus. Für einen Screenreader ist es eine strukturlose Wand. Besonders häufig passiert das in Blogbeiträgen und in WooCommerce-Produktbeschreibungen.

Der Unterschied entscheidet darüber, ob blinde Nutzer Ihre Seite überfliegen können oder nicht. Ein Screenreader navigiert über die Überschriften-Struktur – fehlt sie, fehlt jede Orientierung:

<!-- Falsch: sieht aus wie eine Überschrift, ist aber nur ein fetter Absatz -->
<p><strong>Unsere Leistungen</strong></p>

<!-- Richtig: echte Überschrift, die als Struktur erkannt wird -->
<h2>Unsere Leistungen</h2>

Die gute Nachricht: Gutenberg gibt Ihnen die Werkzeuge dafür. Verwenden Sie genau eine h1 für den Seitentitel und gliedern Sie den Rest lückenlos mit h2 und h3 (Kriterien 1.3.1 und 2.4.6). Bei modernen Block-Themes gibt die Vorlage den Seitentitel oft bereits als h1 aus – fügen Sie dann im Inhalt keine zweite h1 hinzu, sonst trägt die Seite zwei. Das Outline-Panel im Editor zeigt Ihnen die Überschriften-Struktur auf einen Blick und deckt Sprünge sofort auf. Pflegen Sie außerdem für jedes informative Bild einen aussagekräftigen Alt-Text (1.1.1), schreiben Sie sprechende Linktexte statt „hier klicken“ (2.4.4) und setzen Sie Listen als echte Listen-Blöcke. Dasselbe gilt für Datentabellen: Verwenden Sie den Tabellen-Block mit echten Kopfzeilen, statt Tabellen aus einzelnen Spalten-Blöcken nachzubauen – sonst kann ein Screenreader den Zusammenhang zwischen Zelle und Überschrift nicht herstellen. Das kostet keine Entwicklerstunden – nur Disziplin bei der Redaktion.

Einen WordPress-spezifischen Stolperstein bei Bildern übersehen selbst erfahrene Redakteure: Der Alt-Text, den Sie in der Mediathek hinterlegen, dient nur als Vorgabe – jeder Bild-Block hat ein eigenes Alt-Feld, das diese Vorgabe überschreibt. Fügen Sie dasselbe Bild an zwei Stellen ein, kann es einmal einen sinnvollen und einmal gar keinen Alt-Text tragen. Und für rein dekorative Bilder gehört das Alt-Feld bewusst leer (Kriterium 1.1.1) – nicht etwa der Dateiname –, damit ein Screenreader sie überspringt, statt „IMG_2024.jpg“ vorzulesen.

Schicht 3: Page-Builder und Plugins ehrlich einschätzen

Die dritte Schicht ist die heikelste, weil hier zwei verbreitete Irrtümer aufeinandertreffen. Der erste betrifft Page-Builder. Werkzeuge wie Bricks erzeugen schlankes HTML und erlauben es, jedem Element das korrekte Tag zu geben – aber ihre komplexen Widgets sind die Schwachstelle. Akkordeons, Tabs und Slider kommen oft ohne ARIA-Rollen, Schaltflächen werden als <span> statt als echtes Button-Element ausgegeben (ein Verstoß gegen 4.1.2 Name, Rolle, Wert und gegen 2.1.1 Tastaturbedienung), und Formularen fehlt die Gruppierung mit <fieldset> und <legend> (1.3.1). Ein besonders häufiger Bruch betrifft selbstgebaute Menüs: Während das native WordPress-Menü Tastaturbedienung und aria-expanded an Untermenüs mitbringt, erzeugen viele Page-Builder-Mega-Menüs reine Hover-Konstrukte, die per Tastatur gar nicht erst aufklappen. Solche Builder sind mächtig, verlangen aber einen Entwickler, der die ARIA-Lücken kennt und schließt.

<!-- Page-Builder-Falle: ein span als Schaltfläche, für Tastatur unerreichbar -->
<span class="btn" onclick="...">Jetzt anfragen</span>

<!-- Richtig: echtes button-Element, fokussierbar und vorlesbar -->
<button type="button">Jetzt anfragen</button>

Der zweite Irrtum betrifft Accessibility-Plugins. Hier müssen wir klar zwischen zwei Arten unterscheiden. Seriöse Plugins wie WP Accessibility beheben einzelne technische Probleme – sie ergänzen Skip-Links, Fokus-Indikatoren oder Alt-Text-Felder. Das ist nützlich, aber das Plugin selbst stellt ausdrücklich klar, dass es Ihre Seite nicht mit irgendeiner Richtlinie konform macht. Strukturelle Barrieren im Theme, fehlerhafte ARIA in Page-Buildern oder unzugängliche Formulare kann es nicht reparieren. Ein solches Plugin ist ein Baustein, keine Gesamtlösung.

Davon strikt zu trennen sind Overlay-Plugins – jene Symbolleisten, die mit „Ein-Klick-Barrierefreiheit“ oder „KI-gestützter“ Heilung werben und ein Menü für Kontraste und Schriftgrößen einblenden. Sie reparieren den darunterliegenden Code nicht, sie legen nur eine Hülle darüber. In der Barrierefreiheits-Community sind sie zu Recht umstritten, und als alleinige Maßnahme erfüllen sie die WCAG nicht. Ich sage das offen, weil wir bei IFDB selbst ein Widget anbieten – Access Overlay –, es aber ehrlich als deklarierte Übergangslösung kennzeichnen, die den Code nicht heilt. Genau das ist der Unterschied zwischen einem ehrlichen Hilfsmittel und einem Heilsversprechen.

Aus der Praxis: Ein Online-Shop hatte ein Overlay-Plugin installiert und in der Annahme, damit rechtssicher zu sein, sonst nichts unternommen. Im Test scheiterte ein blinder Nutzer schon am Checkout: Die per Page-Builder gebauten Formularfelder hatten keine verknüpften Labels, und das Overlay konnte daran nichts ändern. Die Symbolleiste war sichtbar, die Barriere blieb. Der Shop fiel unter das BFSG und war angreifbar – trotz des vermeintlichen Schutzes.

Sonderfall Shop und Formulare: Wo es konkret wird

Zwei Bereiche verdienen besondere Aufmerksamkeit, wenn Sie Ihr WordPress barrierefrei machen wollen, weil hier Geschäft und Zugänglichkeit unmittelbar zusammentreffen: WooCommerce-Shops und Formulare.

Bei WooCommerce sind die Produktbeschreibungen eine notorische Schwachstelle, weil sie oft von wechselnden Redakteuren ohne Überschriften-Struktur gepflegt werden. Kritischer noch sind Produktfilter und der Checkout. Filter, die sich nur per Maus bedienen lassen, und Bezahlformulare ohne verknüpfte Labels sperren genau die Nutzer aus, die auf Tastatur oder Screenreader angewiesen sind – und das an der Stelle, an der sie kaufen wollen. Jeder ausgesperrte Nutzer ist hier direkt verlorener Umsatz. Die Standard-Felder des WooCommerce-Checkouts sind dabei ordentlich beschriftet (3.3.2) und tastaturbedienbar (2.1.1) – die Probleme entstehen fast immer dort, wo ein Page-Builder oder ein Checkout-Plugin diese Felder durch eigene, unbeschriftete Varianten ersetzt. Prüfen Sie deshalb gezielt den Pfad, den ein Kunde wirklich nimmt, nicht nur eine Beispielseite. Produktfilter sind die zweite Falle: Lassen sie sich nur per Maus ziehen, oder fehlt nach dem Filtern eine Rückmeldung, die ein Screenreader vorliest (4.1.3 Statusmeldungen), bleibt der Filter für einen Teil der Kundschaft unbenutzbar.

Formulare sind die zweite Dauerbaustelle. Ob Kontakt-, Anmelde- oder Bestellformular: Jedes Feld braucht ein sichtbar verknüpftes Label (3.3.2), zusammengehörige Felder gehören mit fieldset und legend gruppiert (1.3.1), und Fehlermeldungen müssen als Text vorliegen (3.3.1), nicht allein als rote Umrandung. Viele Formular-Plugins liefern das nicht von sich aus. Es gibt barrierefreie Erweiterungen, etwa für Contact Form 7 – aber ob ein Formular Ihr WordPress barrierefrei umsetzt, entscheidet sich im konkreten Markup, nicht im Versprechen des Plugins. Prüfen Sie das Ergebnis deshalb immer selbst.

Die WordPress-Barrierefreiheit-Checkliste

Diese Checkliste fasst zusammen, was Sie über alle vier Schichten hinweg prüfen sollten. Sie ersetzt kein vollständiges Audit, gibt Ihnen aber eine belastbare Selbstkontrolle für die häufigsten Fehlerquellen.

Arbeiten Sie diese Punkte einmal sauber ab, sind Sie weiter als die große Mehrheit der WordPress-Seiten. Aber – und das ist der entscheidende Haken – Sie sind damit nicht dauerhaft fertig.

Nachrüsten oder beim Relaunch? Der richtige Zeitpunkt

Eine Frage, die mir oft gestellt wird: Lohnt es sich, eine bestehende Seite nachzurüsten, oder wartet man besser auf den nächsten Relaunch? Die ehrliche Antwort hängt vom Zustand Ihrer Seite ab – aber ein Prinzip gilt immer: Je früher Barrierefreiheit mitgedacht wird, desto günstiger ist sie.

Wenn ohnehin ein Relaunch ansteht, ist das der mit Abstand beste Moment, um WordPress barrierefrei zu gestalten. Ein von Beginn an barrierefrei geplantes Theme, eine saubere Block-Struktur und zugängliche Formulare verursachen beim Neubau nur einen geringen Mehraufwand gegenüber einem Standard-Relaunch. Nachträglich in eine gewachsene Seite eingebaut, wird derselbe Effekt deutlich teurer, weil Sie bestehende Inhalte, Layouts und Plugin-Konfigurationen wieder aufbrechen müssen.

Steht kein Relaunch an, heißt das nicht, dass Sie warten sollten – das BFSG gilt seit Juni 2025, und Untätigkeit ist keine Option. Dann ist der pragmatische Weg, zuerst die schwersten Barrieren zu beheben, die Inhalte ab sofort sauber zu pflegen und Ihr WordPress barrierefrei in Etappen zu entwickeln. Beginnen Sie dabei mit den Seiten, über die echtes Geschäft läuft – Startseite, Kontakt und Checkout –, nicht mit dem Blog-Archiv von 2018. Entscheidend ist, dass Sie anfangen und den Fortschritt nicht dem Zufall überlassen.

Warum „einmal gemacht“ bei WordPress nicht reicht

WordPress ist ein lebendes System, und genau das macht Barrierefreiheit zur Daueraufgabe. Jedes Theme-Update, jedes Plugin-Update, jeder neue Blogbeitrag und jede neue Produktseite kann eine Barriere einführen, die gestern noch nicht da war. Ein Plugin-Update ändert das Markup eines Formulars, ein neuer Mitarbeiter pflegt eine Seite ohne Überschriften-Struktur, ein Theme-Wechsel entfernt unbemerkt den Skip-Link. Fachleute empfehlen deshalb ausdrücklich, kritische Abläufe wie Anmeldung, Checkout und Buchung nach jedem Update erneut zu testen.

In der Realität tut das niemand manuell – dafür ändert sich eine aktive WordPress-Seite zu oft. Ein einmaliges Audit beschreibt einen Zustand, der schon beim nächsten Deploy veraltet sein kann. Hier setzt unser Monitoring Access Guard an: Es prüft Ihre Seite automatisch nach jedem Update und Deployment, meldet neue Barrieren in Echtzeit direkt in Ihre Tools wie Slack oder Jira und liefert fertige Code-Snippets zur Behebung. Andere Lösungen scannen einmal und überlassen Sie danach sich selbst – Sie bemerken den Bruch erst, wenn sich ein Nutzer beschwert oder eine Abmahnung kommt. Access Guard bemerkt ihn am Tag des Deployments und gibt Ihnen den Anschluss, statt Sie allein zu lassen.

Für eine Plattform, die sich mit jedem Plugin und jedem Beitrag verändert, ist das der einzige realistische Weg, WordPress barrierefrei zu halten: nicht ein Zustand, den Sie einmal herstellen, sondern ein Prozess, den ein Monitoring laufend absichert. Access Guard verwandelt Barrierefreiheit so von einem Projekt mit Enddatum in einen verlässlichen Betriebszustand – und genau das unterscheidet eine Seite, die im Audit besteht, von einer, die es auch in einem Jahr noch tut.

Aus der Praxis: Eine Agentur hatte für ihren Kunden eine vorbildlich barrierefreie WordPress-Seite gebaut und korrekt abgenommen. Vier Monate später meldete ein Nutzer, dass die Hauptnavigation per Tastatur nicht mehr funktionierte. Ursache war ein automatisches Update des Menü-Plugins, das die Tastaturlogik verändert hatte. Niemand hatte es bemerkt, weil niemand nach dem Update getestet hatte. Mit einem Monitoring wäre der Fehler am selben Tag aufgefallen – so lag die Seite monatelang im roten Bereich.

Von der einmaligen Umstellung zum dauerhaft konformen Betrieb

Ihr WordPress barrierefrei zu machen ist also zwei Aufgaben in einer: der einmalige Aufbau über alle vier Schichten und der dauerhafte Erhalt im laufenden Betrieb. Den ersten Schritt erledigen Sie mit diesem Leitfaden und einer fachkundigen Prüfung. Den zweiten erledigt kein Mensch zuverlässig von Hand.

Wenn Sie wissen wollen, wo Ihre Seite heute steht, ist ein kostenloser WCAG-Schnelltest mit Access Score der richtige Einstieg – er zeigt Ihnen die automatisch erkennbaren Probleme in verständlicher Sprache. Für den belastbaren Nachweis braucht es danach ein menschliches Tiefen-Audit wie Access Ready, denn ein automatischer Scan erkennt nur einen Teil der WCAG-Kriterien. Und damit Ihre Seite auch nach dem nächsten Update barrierefrei bleibt, ist mit Access Guard ein kontinuierliches Barrierefreiheits-Monitoring für WordPress die ehrliche Antwort auf ein System, das sich ständig verändert. Ich verspreche Ihnen keine perfekte Seite per Knopfdruck – sondern einen Weg, der bei der Diagnose beginnt und beim dauerhaften Schutz ankommt.