So machen Sie WordPress BFSG-konform
Kurzantwort: Eine WordPress-Website wird nicht durch ein einzelnes Plugin barrierefrei. Entscheidend sind ein zugängliches Theme, semantisch korrekt konfigurierte Blöcke oder Page Builder, bedienbare Plugins sowie manuelle Prüfungen mit Tastatur und Screenreader. Der folgende Leitfaden trennt diese vier Ebenen und zeigt, was Sie selbst prüfen können.
Auf einen Blick:
- WordPress-Core ist eine gute Basis. Die eigentlichen Probleme entstehen durch Themes, Plugins und Page Builder.
- Theme-Wahl ist der größte Hebel. Ein Theme ohne semantisches HTML lässt sich kaum nachträglich reparieren.
- Page Builder: Gutenberg + barrierefreies Block-Theme ist der sicherste Weg. Bricks liefert den saubersten Code, braucht aber ARIA-Handarbeit. Elementor funktioniert, erfordert aber ständige Kontrolle.
- Overlay-Tools (AccessiBe, UserWay) sind keine Lösung. Sie beheben keine strukturellen Barrieren. Die Überwachungsstellen des Bundes und der Länder halten fest, dass ein Overlay eine nicht barrierefreie Website nicht barrierefrei macht.
- Kosten: Was eine Umstellung kostet, ordnet der Kostenratgeber ein. Für eine KMU-Site mit 20–50 Seiten: 4.000–12.000 €; ein Teil davon ist über Zuschüsse förderbar.
Ist WordPress von Haus aus barrierefrei?
Kurze Antwort: Nein. Aber WordPress bietet eine der besten Ausgangspositionen unter allen CMS.
Der WordPress-Core hat Barrierefreiheit als offizielles Entwicklungsziel. Seit September 2024 verlangen die WordPress Accessibility Coding Standards für neuen und geänderten Code WCAG 2.2 AA, vorher war es WCAG 2.1 AA. Die Release-Notizen zu den Versionen 6.7 bis 6.9 zählen zusammen über 250 Barrierefreiheits-Verbesserungen in Core und Block-Editor. Core-Blöcke geben sauberes, semantisches HTML aus: Überschriften als <h1>–<h6>, Listen als <ul>/<ol>, Absätze als <p>.
Das Problem liegt nicht im Core. Es liegt in den drei Schichten, die darüber kommen: Theme, Plugins und Page Builder. Eine Standard-WordPress-Installation mit einem beliebigen Theme aus dem Repository ist fast nie BFSG-konform.
Wo entstehen die Barrieren?
Themes: Das Fundament entscheidet
Ein Theme bestimmt die HTML-Struktur Ihrer gesamten Website: welche Bereiche als Navigation ausgezeichnet sind, in welcher Reihenfolge der Fokus wandert, ob Überschriften eine Gliederung ergeben. Fehlt hier die Basis, hilft kein Plugin.
Deshalb ist die Reihenfolge nicht verhandelbar: erst Theme, dann Page Builder, dann Plugins. Wer umgekehrt vorgeht, repariert Symptome.
→ Die Theme-Frage im Detail: Welche Rolle das Label „accessibility-ready” wirklich spielt, wie Sie jedes Theme in 15 Minuten selbst prüfen und wann ein Wechsel günstiger ist als die Reparatur, steht in Barrierefreie WordPress-Themes auswählen und prüfen.
Plugins: Die unsichtbaren Barrieren
Der häufigste Denkfehler ist, Plugins als Lösung zu sehen. In der Praxis sind sie zuerst eine Ursache: Slider, Pop-ups und Kontaktformulare erzeugen mehr Barrieren, als ein Accessibility-Plugin je beheben kann.
Slider sind oft nicht pausierbar und für Screenreader nicht lesbar. Pop-ups erzeugen „Keyboard Traps”: Der Nutzer bleibt mit der Tab-Taste im Hintergrund hängen, während das Overlay im Vordergrund liegt. Formulare nutzen häufig Placeholder statt echte <label>-Elemente. Sobald der Nutzer tippt, verschwindet die Feldbeschreibung.
Wenn Sie Plugins evaluieren: Testen Sie jedes Plugin einzeln mit der Tastatur. Kommen Sie überall hin? Können Sie alles bedienen, ohne die Maus zu berühren? Wenn nicht: ersetzen oder konfigurieren.
→ Die Plugin-Frage im Detail: Welche Prüf- und Fix-Tools sich für welche Aufgabe eignen und welche Kombination zu Ihrer Website passt, steht in WordPress Barrierefreiheit Plugins.
Welcher Page Builder ist am besten für Barrierefreiheit?
Die Wahl des Builders bestimmt, wie viel Nacharbeit Sie für BFSG-Konformität brauchen. Der Equalize Digital Page Builder Accessibility Report 2025 hat 19 Builder und Block-Bibliotheken zwischen Juni und August 2025 mit mehr als 300 automatisierten und manuellen Prüfpunkten verglichen.
| Kriterium | Gutenberg (Block-Editor) | Bricks Builder | Elementor |
|---|---|---|---|
| HTML-Qualität | Sauber, semantisch | Schlank, HTML-Tag je Element frei wählbar | „Div-Suppe” aus verschachtelten Wrappern |
| Landmarks | Automatisch via Block-Themes | Automatisch (<header>, <main>, <footer>) |
Nur bei „Default”-Layout, nicht bei „Full Width” |
| Skip-Links | Ja (via Theme) | Im Equalize-Test 2025 nicht vorhanden | Im Equalize-Test 2025 vorhanden (Hello Elementor) |
| ARIA-Widgets | Core-Blöcke korrekt | Tabs und Akkordeon mit ARIA, Mängel bei Slidern und Buttons | Bekannte Bugs in Nested Accordion |
| Lernkurve | Niedrig | Mittel–Hoch | Niedrig |
Gutenberg: Der sicherste Weg
Block-Themes wie Twenty Twenty-Five bringen Landmarks, Skip-Links und barrierefreie Farbpaletten automatisch mit. Das Theme Kadence ist kein Block-Theme, trägt aber das Merkmal „accessibility-ready“. Da WordPress-Core ein dediziertes Accessibility-Team hat, profitieren Gutenberg-Nutzer von kontinuierlichen Verbesserungen.
Schwäche: Sie können Block-Elementen keine semantischen HTML5-Tags (<section>, <article>) zuweisen. Für komplexe Layouts brauchen Sie Add-ons wie Kadence Blocks (Platz 1 im Equalize Digital Report).
Bricks: Der sauberste Code, aber Handarbeit
Bricks erzeugt das schlankste HTML aller Builder. Jedes Element kann manuell mit dem korrekten HTML-Tag versehen werden. Der Menu Builder erlaubt volle Kontrolle über aria-expanded-Zustände und Tastatur-Events.
Aber: Im Equalize-Test 2025 fielen beim Slider fehlende Pause-Schaltfläche, unbenannte Buttons und fehlende Fokus-Sichtbarkeit auf. Nicht alle Bedienelemente mit Button-Funktion waren als Button ausgezeichnet, Formularen fehlte die <fieldset>/<legend>-Gruppierung, und ein Skip-Link fehlte. Tabs und Akkordeons bestanden die ARIA-Prüfpunkte. Bricks ist ein mächtiges Werkzeug, verlangt aber einen Entwickler, der die ARIA-Lücken kennt und schließt.
Wenn Sie Bricks einsetzen: Planen Sie Budget für ARIA-Nachrüstung ein. Im Equalize-Ranking 2025 liegt Bricks mit 63,57 % bestandenen Prüfpunkten auf Platz 8 von 19, also im Mittelfeld. Der Builder selbst bietet aber alle Werkzeuge für eine vollständig barrierefreie Umsetzung.
Elementor: Funktioniert, aber braucht Disziplin
Elementor rangiert im Equalize Digital Report auf Platz 4 von 19. Die „Optimized DOM Output”-Option reduziert verschachtelte Container deutlich. Die Erweiterung „Web Accessibility“ (früher Ally, davor One Click Accessibility) erkennt laut Hersteller über 180 häufige Probleme auf Basis von WCAG 2.1 AA.
Risiken: Das „Full Width”-Layout entfernt alle semantischen Landmarks. JavaScript-basierte Widgets (Slider, Modale) verwalten den Fokus oft nicht korrekt. Die Barrierefreiheitserklärung für Elementors eigene Website (Stand August 2025) nennt nur WCAG 2.0 AA, nicht die für das BFSG maßgebliche Version 2.1 AA.
Wenn Sie Elementor nutzen: Verwenden Sie immer das „Default”-Seitenlayout, nie „Full Width” oder „Elementor Canvas”. Setzen Sie semantische HTML-Tags manuell in den erweiterten Einstellungen.
Warum Accessibility-Overlays keine Lösung sind
Tools wie AccessiBe, UserWay oder Eye-Able Widgets versprechen BFSG-Konformität per JavaScript-Snippet. Das ist irreführend.
Overlays legen eine Korrekturschicht über die Website, reparieren aber den Code nicht. Fehlende Alt-Texte, nicht-navigierbare Formulare und kaputte Seitenstruktur bleiben bestehen. In einer WebAIM-Umfrage unter Barrierefreiheits-Fachleuten von 2021 bewerteten 72 % der Befragten mit eigener Behinderung Overlays als wenig oder gar nicht wirksam. Die US-Handelsbehörde FTC hat im April 2025 einen Vergleich mit AccessiBe endgültig bestätigt: Das Unternehmen zahlt 1 Million Dollar und darf nicht mehr behaupten, sein Tool mache jede Website WCAG-konform.
Unsere Position: Wir listen in unserem Verzeichnis keine reinen Overlay-Anbieter. Wir empfehlen ausschließlich Agenturen, die den tatsächlichen Code Ihrer Website barrierefrei machen.
Warum Overlays auch technisch mit den Hilfsmitteln der Nutzer:innen kollidieren, ist im Plugin-Vergleich ausgeführt.
Was können Sie selbst tun, wo brauchen Sie eine Agentur?
| Aufgabe | Eigenleistung möglich? | Agentur nötig? |
|---|---|---|
| Alt-Texte für Bilder | ✅ Ja | Nur Schulung |
| Überschriften-Hierarchie prüfen | ✅ Ja | Nur Schulung |
| Linktexte verbessern („Hier klicken” → „Zum BFSG-Ratgeber”) | ✅ Ja | Nein |
| Farbkontraste prüfen | ✅ Mit Tools (WAVE, Lighthouse) | Nein |
| Theme-Struktur anpassen (Landmarks, ARIA) | ❌ Zu komplex | ✅ Ja |
| Page-Builder korrekt konfigurieren | ⚠️ Mit Anleitung | ✅ Empfohlen |
| Barrierefreiheitserklärung erstellen | ⚠️ Mustertexte möglich | ✅ Für Rechtssicherheit |
| Vollständiges WCAG-Audit | ❌ Nein | ✅ Pflicht |
Konkreter Aktionsplan
Phase 1 (sofort, Eigenleistung): Installieren Sie WP Accessibility. Navigieren Sie Ihre Website nur mit der Tab-Taste. Notieren Sie, wo Sie nicht hinkommen oder den Fokus verlieren. Prüfen Sie die 10 meistbesuchten Seiten mit WAVE oder Lighthouse.
Wo steht Ihre WordPress-Seite konkret? Unser kostenloser KI-Check prüft Ihre Seite automatisch auf alle hier genannten Schwachstellen: Themes, Plugins, Alt-Texte, Kontrast, Tastatur-Navigation. Sie erhalten eine deutsche Auswertung in 2 Minuten mit konkreten Quick-Wins, die Sie ohne Entwickler beheben können.
Phase 2 (1–4 Wochen, Eigenleistung + Agentur): Beauftragen Sie eine Experten-Kurzanalyse (490–1.200 €). Beheben Sie Content-Barrieren selbst: Alt-Texte, Überschriften, Linktexte. Wie das bei Bildern, Videos und PDFs in der Mediathek geht, steht in WordPress-Mediathek BFSG-konform machen. Details zu den Kosten einer barrierefreien Website.
Phase 3 (1–3 Monate, Agentur): Theme-Struktur bereinigen oder Builder korrekt konfigurieren. ARIA-Landmarks, Fokus-Management, Formular-Zugänglichkeit. Barrierefreiheitserklärung erstellen.
Phase 4 (laufend): Redaktionsteam schulen. Neue Inhalte von Anfang an barrierefrei erstellen. Jährlicher Re-Audit (700–2.500 €).
Prüfen Sie zuerst, ob Sie vom BFSG überhaupt betroffen sind. Falls Sie einen Online-Shop betreiben, gelten verschärfte Anforderungen für Checkout und Produktfilter.
→ Für WooCommerce-Shops im Detail (Varianten-Auswahl, AJAX-Warenkorb, Checkout und Zahlungs-Iframes): WooCommerce barrierefrei
Wie dringend ist das?
Das BFSG gilt seit dem 28. Juni 2025. Es gibt keine Übergangsfrist für Websites und Online-Shops.
Seit September 2025 ist die Marktüberwachungsstelle MLBF in Magdeburg tätig, seit Ende Januar 2026 prüft sie zusätzlich nach beschlossenen Marktüberwachungsstrategien. Bußgelder reichen bis 100.000 €. Ein verhängtes Bußgeld hat die MLBF bis zum 25. September 2026 nicht bekanntgegeben. Nach eigenen Angaben vom Juni 2026 bearbeitet sie aber fast 700 eingegangene Meldungen.
Parallel dazu berichten Fachkanzleien seit Sommer 2025 über Abmahnungen wegen fehlender Barrierefreiheit, vor allem gegen Online-Shops. Belastbare Beträge nennen wir nicht, weil es dafür keine überprüfbare Primärquelle gibt. Ob solche Abmahnungen rechtmäßig sind, ist ungeklärt. Mehr dazu unter BFSG-Abmahnung: Was tun?.
Häufige Fragen
Was kostet es, eine WordPress-Website barrierefrei zu machen?
Das hängt vom Ausgangszustand ab. Ein Audit kostet 490–8.000 €, die Umsetzung für eine KMU-Website (20–50 Seiten) liegt bei 4.000–12.000 €. Steht ohnehin ein Relaunch an, ist Barrierefreiheit von Anfang an in der Regel günstiger als eine spätere Nachrüstung. Details und Fördermöglichkeiten unter Barrierefreie Website: Kosten 2026.
Wie stelle ich in WordPress eine barrierefreie Schriftgröße ein?
Entscheidend ist nicht die absolute Größe, sondern die Skalierbarkeit. Definieren Sie Schriftgrößen in relativen Einheiten (rem, em) statt in festen Pixelwerten, in Block-Themes zentral über die theme.json. Zwei WCAG-Kriterien sind der Maßstab: Text muss sich auf 200 % vergrößern lassen, ohne dass Inhalte verloren gehen (1.4.4), und die Seite muss bei 400 % Zoom ohne horizontales Scrollen umbrechen (1.4.10). Ein eigener Schriftgrößen-Umschalter auf der Website ist dafür nicht nötig: Die Zoom-Funktion des Browsers ist das Werkzeug, das Nutzer:innen ohnehin verwenden.
Ist Elementor barrierefrei?
Elementor kann BFSG-konform konfiguriert werden, ist es aber nicht automatisch. Im Equalize Digital Report 2025 rangiert Elementor auf Platz 4 von 19 Buildern. Voraussetzung: „Default”-Seitenlayout verwenden (nicht „Full Width”), semantische HTML-Tags manuell setzen, und JavaScript-Widgets auf Fokus-Management prüfen. Ohne diese Schritte erzeugt Elementor tief verschachtelte <div>-Strukturen, die assistiven Technologien keine Kontextinformationen bieten.
Gilt das BFSG auch für kleine Unternehmen mit WordPress-Website?
Die Kleinstunternehmen-Ausnahme greift bei weniger als 10 Beschäftigten und höchstens 2 Mio. € Jahresumsatz oder Jahresbilanzsumme, und nur für Dienstleistungen. Ein Online-Shop ist eine Dienstleistung im elektronischen Geschäftsverkehr; auch dafür kann die Ausnahme gelten. Davon getrennt bestehen Pflichten für erfasste Produkte. Mehr unter BFSG-Pflicht: Bin ich betroffen?.
Macht eine automatische Vorlesefunktion meine Website BFSG-konform?
Nein. Menschen, die auf Vorlesefunktionen angewiesen sind, nutzen bereits eigene Screenreader (NVDA, VoiceOver, JAWS), die wesentlich leistungsfähiger sind als jede Website-eigene Sprachausgabe. Das BFSG fordert die Zugänglichkeit für assistive Technologien des Nutzers, nicht die Bereitstellung eigener Tools.
Quellen und Stand
Stand: 25. September 2026. Primärquellen:
- WordPress Theme Handbook: Accessibility-Ready-Prüfung: erklärt ausdrücklich, dass „accessibility-ready“ Mindestanforderungen bezeichnet und keine vollständige WCAG-AA-Konformität garantiert.
- WordPress Accessibility Coding Standards: offizielle Anforderungen für WordPress-Core und gebündelte Themes, verlangt WCAG 2.2 AA. Abgerufen am 25.09.2026.
- GitHub: Änderung der Accessibility Coding Standards von WCAG 2.1 auf 2.2: Commit vom 01.09.2024 im offiziellen Repository der Coding Standards. Abgerufen am 25.09.2026.
- WordPress 6.7 Field Guide: 21 Core-Tickets und 55 Block-Editor-Verbesserungen zur Barrierefreiheit. Abgerufen am 25.09.2026.
- Accessibility Improvements in WordPress 6.8: 33 Core-Fixes und über 70 Block-Editor-Verbesserungen. Abgerufen am 25.09.2026.
- Accessibility Improvements in WordPress 6.9: 33 Core-Verbesserungen und 44 Block-Editor-Fixes. Abgerufen am 25.09.2026.
- WordPress.org Theme-API, Schlagwort „accessibility-ready“: 104 Themes am 25.09.2026; Kadence mit, GeneratePress ohne Merkmal, beide ohne Block-Theme-Kennzeichnung „full-site-editing“. Abgerufen am 25.09.2026.
- Equalize Digital: WordPress Page Builder Accessibility Comparison 2025: 19 Builder, Tests Juni bis August 2025, über 300 Prüfpunkte; Kadence Platz 1 (100 %), Elementor Platz 4 (75,55 %), Bricks Platz 8 (63,57 %). Equalize legt eine Geschäftsbeziehung zum Kadence-Hersteller StellarWP offen. Abgerufen am 25.09.2026.
- WordPress.org: Web Accessibility (früher Ally): Herstellerangabe „180+“ erkennbare Probleme auf Basis von WCAG 2.1 AA. Abgerufen am 25.09.2026.
- Elementor: Website Accessibility Statement: Erklärung für elementor.com, verweist auf den israelischen Standard 5568 und WCAG 2.0 AA, Stand August 2025. Abgerufen am 25.09.2026.
- § 2 BFSG und § 3 BFSG: Definition des Kleinstunternehmens (Nr. 17) und Ausnahme für Dienstleistungen (Abs. 3). Abgerufen am 25.09.2026.
- W3C: Web Content Accessibility Guidelines 2.2: normative Grundlage für Kontraste, Tastaturbedienung, Reflow und semantische Struktur.
- WebAIM: Survey of Web Accessibility Practitioners #3: Umfrage vom Januar 2021, 758 Antworten, Abschnitt zur Wirksamkeit von Overlays. Abgerufen am 25.09.2026.
- FTC: Final Order gegen accessiBe: Pressemitteilung zur endgültigen Vergleichsanordnung vom April 2025. Abgerufen am 25.09.2026.
- MLBF: Aktuelles: Mitteilungen der Marktüberwachungsstelle, darunter die Pressemitteilung vom 01.06.2026 mit dem Stand der Meldungen. Abgerufen am 25.09.2026, ohne Mitteilung zu verhängten Bußgeldern.
Theme-, Plugin- und Builder-Versionen verändern sich. Prüfen Sie deshalb nach Updates erneut die tatsächlich gerenderte Website, nicht nur die Einstellungen im WordPress-Backend.