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 und werden von Fachleuten und Behörden nicht als BFSG-konform anerkannt.
- Kosten: WordPress-Umstellungen liegen typischerweise 20–30 % unter proprietären Systemen. 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 Version 6.8 orientiert sich das Projekt an WCAG 2.2 AA. Allein in den letzten drei Major-Releases (6.7–6.9) wurden über 250 Barrierefreiheits-Tickets geschlossen. 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 mit über 200 Stunden automatisierter und manueller Tests verglichen.
| Kriterium | Gutenberg (Block-Editor) | Bricks Builder | Elementor |
|---|---|---|---|
| HTML-Qualität | Sauber, semantisch | Am saubersten aller Builder | „Div-Suppe“, ~4 Wrapper pro Element |
| Landmarks | Automatisch via Block-Themes | Automatisch (<header>, <main>, <footer>) |
Nur bei „Default“-Layout, nicht bei „Full Width“ |
| Skip-Links | Ja (via Theme) | 2 Skip-Links ab Werk | Manuell hinzufügen |
| ARIA-Widgets | Core-Blöcke korrekt | Akkordeon/Tabs ohne ARIA-Rollen | Bekannte Bugs in Nested Accordion |
| Performance-Impact | Minimal | Minimal | ~32 MB zusätzliches Seitengewicht |
| Lernkurve | Niedrig | Mittel–Hoch | Niedrig |
Gutenberg: Der sicherste Weg
Block-Themes wie Twenty Twenty-Five oder Kadence bringen Landmarks, Skip-Links und barrierefreie Farbpaletten automatisch mit. 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: Komplexe Widgets wie Akkordeons, Tabs und Slider haben keine ARIA-Rollen. Das Button-Element nutzt <span> statt <button>, und Formulare fehlt <fieldset>/<legend>-Gruppierung. 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. Die Standard-Templates sind nur „durchschnittlich“ (Equalize Digital), 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 Ally-Erweiterung (ehemals One Click Accessibility) erkennt über 180 Probleme.
Risiken: Das „Full Width“-Layout entfernt alle semantischen Landmarks. JavaScript-basierte Widgets (Slider, Modale) verwalten den Fokus oft nicht korrekt. Elementors Accessibility Statement referenziert nur WCAG 2.0, nicht die vom BFSG geforderte 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 WebAIM-Umfragen bewerten 72 % der betroffenen Nutzer Overlays als unwirksam. Im April 2025 wurde AccessiBe von der US-Handelsbehörde FTC zu einer Strafe von 1 Million Dollar wegen irreführender Werbung verurteilt.
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. 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 Januar 2026 führt die Marktüberwachungsstelle MLBF in Magdeburg (ca. 70 Mitarbeiter) aktive Kontrollen durch. Bußgelder reichen bis 100.000 €. Stand März 2026 sind keine öffentlichen Bußgelder bekannt, die Kontrollintensität steigt aber.
Parallel dazu läuft seit August 2025 eine Abmahnwelle. Eine Kanzlei verschickt pauschale Abmahnungen an Online-Shops (ca. 595 € pro Fall). Die Rechtmäßigkeit ist umstritten, erste Gerichtsurteile werden 2026 erwartet. 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 €. Wenn ein Relaunch ansteht, kostet Barrierefreiheit nur 10–15 % mehr als ein Standard-Relaunch. 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: 30. Juli 2026. Technische 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.
- W3C: Web Content Accessibility Guidelines 2.2: normative Grundlage für Kontraste, Tastaturbedienung, Reflow und semantische Struktur.
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.