Seit dem 28. Juni 2025 gilt in Deutschland das Barrierefreiheitsstärkungsgesetz (BFSG) – und viele Unternehmen sind noch nicht vorbereitet. Während öffentliche Stellen bereits seit Jahren unter die WCAG-Pflicht fallen, trifft das neue Gesetz erstmals auch privatwirtschaftliche Anbieter digitaler Produkte und Dienstleistungen. Wer eine WordPress-Seite betreibt und unter die Regelungen fällt, muss handeln – oder riskiert Abmahnungen und Bußgelder.
Dieser Artikel beantwortet die relevanten Fragen für technisch versierte Betreiber: Welche gesetzlichen Anforderungen gelten konkret im DACH-Raum? Was bedeuten WCAG 2.1 und 2.2 in der Praxis für WordPress? Wie aufwändig ist eine nachträgliche Accessibility-Optimierung wirklich? Und welche Test-Tools liefern verlässliche Ergebnisse – und welche nicht?
Vollständige Barrierefreiheit ist kein Plugin-Install, sondern ein Prozess. Wer das realistisch einschätzt, geht strukturiert vor und vermeidet teure Nacharbeit.
Die gesetzliche Lage: Was das BFSG für WordPress-Betreiber bedeutet
BFSG, EAA und die WCAG-Grundlage
Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die europäische European Accessibility Act (EAA, EU-Richtlinie 2019/882) in deutsches Recht um. Stichtag für die Anwendung auf neue Produkte und Dienstleistungen ist der 28. Juni 2025. Für Dienstleistungen, die bereits vor diesem Datum erbracht wurden, gilt eine Übergangsfrist bis 2030 – allerdings nur unter bestimmten Bedingungen.
Die technische Referenz ist die EN 301 549, die ihrerseits auf den WCAG 2.1 Level AA-Kriterien des W3C basiert. Mit WCAG 2.2 (Oktober 2023 veröffentlicht) wurden neun neue Erfolgskriterien ergänzt, darunter Anforderungen an Fokus-Indikatoren und Authentifizierungsprozesse. Die EN 301 549 wird voraussichtlich auf WCAG 2.2 aktualisiert – wer heute neu implementiert, berücksichtigt diesen Stand bereits.
Wer fällt unter das BFSG?
Nicht jede WordPress-Seite ist betroffen. Das BFSG richtet sich an Wirtschaftsakteure, die folgende digitale Dienstleistungen erbringen:
- E-Commerce (Online-Shops mit Verbraucherverträgen)
- Banking und Finanzdienstleistungen
- E-Book-Reader und zugehörige Dienste
- Telekommunikationsdienste
- Personenbeförderungsdienste (Ticketing, Check-in)
Reine Informationswebsites ohne transaktionalen Charakter fallen nicht direkt unter das BFSG. Allerdings gilt für öffentliche Stellen weiterhin die EU-Webseitenrichtlinie (2016/2102), umgesetzt über die BITV 2.0 in Deutschland, die WCAG 2.1 AA vorschreibt.
Ausnahme für Kleinstunternehmen: Unternehmen mit weniger als 10 Mitarbeitern und einem Jahresumsatz unter 2 Millionen Euro sind von den BFSG-Pflichten ausgenommen – aber nicht von der allgemeinen Sorgfaltspflicht oder potenziellen AGG-Klagen. Wer einen WooCommerce-Shop als Kleinunternehmen betreibt, sollte dennoch prüfen, ob eine grundlegende Accessibility-Optimierung sinnvoll ist.
Österreich und Schweiz: Parallele Entwicklungen
In Österreich wurde der EAA durch das Barrierefreiheitsgesetz (BaFG) umgesetzt, ebenfalls mit Stichtag 28. Juni 2025. Die Anforderungen sind strukturell identisch mit dem deutschen BFSG.
Die Schweiz ist kein EU-Mitglied und kennt keine direkte Umsetzung des EAA. Das Behindertengleichstellungsgesetz (BehiG) richtet sich primär an Bundesbehörden und konzessionierte Unternehmen. Für privatwirtschaftliche Anbieter existiert bislang keine vergleichbare gesetzliche Verpflichtung – allerdings wächst der Druck durch Kundenanforderungen und Ausschreibungskriterien.
WCAG-Anforderungen für barrierefreie WordPress-Websites im Überblick
Die vier WCAG-Prinzipien und ihre WordPress-Relevanz
WCAG 2.1 AA strukturiert sich nach vier Prinzipien – Wahrnehmbar, Bedienbar, Verständlich, Robust (POUR). Für WordPress-Betreiber sind folgende Bereiche besonders kritisch:
Wahrnehmbar:
- Alle nicht-textuellen Inhalte (Bilder, Icons) brauchen Alt-Texte
- Videos benötigen Untertitel und ggf. Audiodeskription
- Farbkontrast: Mindest-Kontrastverhältnis von 4,5:1 für normalen Text, 3:1 für großen Text
Bedienbar:
- Vollständige Tastaturbedienbarkeit – kein Inhalt darf ausschließlich per Maus erreichbar sein
- Fokus-Indikatoren müssen sichtbar sein (WCAG 2.2 verschärft dies mit Kriterium 2.4.11)
- Keine Zeitlimits ohne Verlängerungsoption
Verständlich:
- Sprache des Dokuments im
<html lang="de">-Attribut korrekt gesetzt - Fehlermeldungen in Formularen müssen beschreibend sein
Robust:
- Valides HTML – ARIA-Attribute korrekt eingesetzt, nicht als Ersatz für semantisches HTML
- Kompatibilität mit assistiven Technologien (Screenreader, Braille-Displays)
Wo WordPress-Standardinstallationen typischerweise scheitern
Ein frisches WordPress mit einem nicht-zertifizierten Theme erfüllt WCAG 2.1 AA in der Regel nicht aus dem Stand. Häufige Schwachstellen:
- Page Builder-generiertes HTML: Elementor, WPBakery und ähnliche Tools produzieren oft nicht-semantisches Markup mit fehlenden ARIA-Rollen
- Slider und Karussells: Nahezu alle populären Implementierungen scheitern an Tastaturnavigation und Auto-Play-Anforderungen
- WooCommerce-Checkout: Formularfelder ohne korrekte
<label>-Zuordnung, Fehlermeldungen nicht per Screenreader erfassbar - Mega-Menüs: Komplexe Navigationsstrukturen ohne ARIA-Attribute (
aria-expanded,aria-haspopup) - Cookie-Consent-Banner: Viele populäre Lösungen sind selbst nicht barrierefrei – wer die besten WordPress Cookie-Banner-Plugins sucht, sollte explizit auf Accessibility-Kriterien achten
Barrierefreie WordPress-Themes: Zertifizierung und Realität
Was „accessibility-ready“ im WordPress-Kontext bedeutet
Das WordPress-Theme-Repository vergibt das Tag „accessibility-ready“ an Themes, die einen definierten Kriterienkatalog erfüllen. Dieser umfasst u.a.:
- Sichtbare Fokus-Stile für alle interaktiven Elemente
- Skip-Navigation-Links
- Korrekte Heading-Hierarchie
- Ausreichende Farbkontraste
- ARIA-Landmarks in der Grundstruktur
Wichtig: Das „accessibility-ready“-Tag ist kein WCAG-2.1-AA-Zertifikat. Es ist eine Mindestanforderung, die die Grundlage schafft – aber nicht garantiert, dass Ihr fertiges Projekt compliant ist. Sobald Sie Custom-CSS, Plugins oder Inhalte hinzufügen, liegt die Verantwortung bei Ihnen.
Themes mit solider Accessibility-Basis
Folgende Themes gelten in der WordPress-Community als solide Ausgangsbasis für barrierefreie Projekte:
- Twenty Twenty-Four / Twenty Twenty-Five (WordPress Core Themes): Solide semantische Grundstruktur, block-basiert, accessibility-ready
- Astra (mit Accessibility-Addon): Weit verbreitet, aktive Accessibility-Entwicklung, regelmäßige WCAG-Tests
- GeneratePress: Schlankes, semantisch korrektes Markup, bekannt für gute Accessibility-Basis
- Kadence: Block-Theme mit zunehmendem Accessibility-Fokus
Explizit zu prüfen bei Page-Builder-Themes: Divi, Avada und ähnliche All-in-One-Themes erzeugen komplex verschachteltes HTML. Accessibility-Optimierung ist hier erheblich aufwändiger als bei schlanken Themes. Wer das richtige WordPress-Theme systematisch auswählen möchte, sollte Accessibility von Anfang an als Auswahlkriterium behandeln.
Nachträgliche Accessibility-Optimierung: Aufwand realistisch einschätzen
Der tatsächliche Aufwand – keine Schönrednerei
Nachträgliche Accessibility-Optimierung an einer bestehenden WordPress-Site ist signifikant aufwändiger als ein barrierefreier Neuaufbau. Realistische Einschätzung nach Projekttyp:
Einfache Informationsseite (5–15 Seiten, Standard-Theme):
- Aufwand: 8–20 Stunden
- Schwerpunkte: Alt-Texte, Farbkontraste, Fokus-Stile, Heading-Struktur
- Erreichbares Level: WCAG 2.1 AA mit vertretbarem Aufwand möglich
Mittelgroße Website (20–50 Seiten, Page Builder, mehrere Custom Post Types):
- Aufwand: 40–80 Stunden
- Schwerpunkte: Markup-Überarbeitung, ARIA-Integration, Formular-Accessibility, Navigationsprüfung
- Realität: Oft ist ein partieller Rebuild einzelner Komponenten günstiger als Flickwerk
WooCommerce-Shop mit individuellem Theme:
- Aufwand: 60–150+ Stunden
- Schwerpunkte: Checkout-Flow, Produktseiten, Filternavigation, Warenkorb-Interaktionen
- Kritischer Punkt: WooCommerce-Templates müssen ggf. überschrieben werden; Plugin-Updates können Fixes revertieren
Was Plugins leisten können – und was nicht
Plugins wie WP Accessibility (von Joe Dolson, einem anerkannten Accessibility-Experten) adressieren spezifische, klar abgrenzbare Probleme:
- Automatisches Hinzufügen von
lang-Attributen - Skip-Link-Generierung
- Entfernung von
tabindex="-1"an unerwünschten Stellen - Erzwingen sichtbarer Fokus-Stile via CSS
Was kein Plugin lösen kann:
- Fehlende Alt-Texte (Content-Problem, keine technische Lösung)
- Nicht-semantisches Theme-Markup (Theme-Problem)
- Komplexe ARIA-Patterns in Custom Components
- Untertitel für Videos (redaktioneller Prozess)
Vorsicht vor „One-Click Accessibility“-Overlays: Tools wie AccessiBe, UserWay oder ähnliche Overlay-Lösungen werben mit automatischer WCAG-Compliance. Die National Federation of the Blind, das Disability Rights Advocates-Team und zahlreiche Accessibility-Experten (u.a. Adrian Roselli) dokumentieren seit Jahren, dass diese Overlays echte Barrieren nicht beseitigen und Screenreader-Nutzer aktiv beeinträchtigen können. Die juristische Schutzwirkung ist umstritten – mehrere US-Klagen wurden trotz aktivem Overlay eingereicht.
Accessibility-Testing: Welche Tools für WordPress wirklich verlässlich sind
Automatisierte Tests: Einstieg, kein Ersatz
Automatisierte Test-Tools können nach Expertenschätzungen (u.a. Deque Systems) 30–40% der WCAG-Fehler aufdecken. Der Rest erfordert manuelle Prüfung und Nutzer-Tests mit assistiven Technologien.
Zuverlässige automatisierte Tools:
| Tool | Typ | Besonderheit |
|---|---|---|
| axe DevTools (Deque) | Browser-Extension + API | Branchenstandard, geringe False-Positive-Rate, WCAG 2.1/2.2 |
| WAVE (WebAIM) | Browser-Extension + Web | Visuelle Darstellung, gut für Einstieg |
| Lighthouse (Google) | Chrome DevTools integriert | Accessibility-Score als Indikator, nicht als Compliance-Nachweis |
| IBM Equal Access Checker | Browser-Extension | Offene WCAG-Abdeckung, WCAG 2.2 Support |
| Siteimprove Accessibility | SaaS-Plattform | Crawling ganzer Sites, Reporting für Teams |
Wichtige Einschränkung zu Lighthouse: Der Accessibility-Score ist kein Compliance-Indikator. Ein Score von 100 bedeutet lediglich, dass alle automatisch prüfbaren Kriterien bestanden wurden – nicht, dass die Seite WCAG-konform ist.
Manuelle Testing-Checkliste für WordPress a11y
Folgende Checks lassen sich ohne spezialisiertes Accessibility-Wissen durchführen:
- Tastaturnavigation: Nur Tab, Shift+Tab, Enter, Pfeiltasten – ist jede Funktion erreichbar?
- Fokus-Sichtbarkeit: Ist der aktuelle Fokuspunkt immer sichtbar?
- Zoom auf 200%: Ist der Inhalt bei 200% Vergrößerung noch nutzbar ohne horizontales Scrollen?
- Farbe als einzige Information: Werden Fehler oder Status nur durch Farbe kommuniziert?
- Formular-Labels: Ist jedes Eingabefeld eindeutig beschriftet?
Screenreader-Testing: Minimalsetup
Für ein erstes Screenreader-Testing ohne Spezialwissen:
- Windows: NVDA (kostenlos) + Firefox oder Chrome
- macOS/iOS: VoiceOver (integriert) + Safari
- Ziel: Navigiere durch Hauptnavigation, Formulare und Kernprozesse ausschließlich per Tastatur und Screenreader
Praxis-Beispiele: Accessibility-Projekte in WordPress
Beispiel 1: WooCommerce-Shop, nachträgliche WCAG-Optimierung
Ausgangslage: Mittelgroßer B2C-Online-Shop, Avada-Theme, WooCommerce, ca. 500 Produkte. Axe DevTools identifizierte 847 automatisch erkennbare Fehler beim initialen Scan.
Vorgehen:
- Phase 1 (Theme-Ebene): Wechsel auf child-theme-basierte Overrides für kritische Templates, ARIA-Ergänzungen in Navigation und Produktliste – 25 Stunden
- Phase 2 (Content-Ebene): Systematische Alt-Text-Pflege für 500+ Produktbilder via WooCommerce-Bulk-Edit – 12 Stunden
- Phase 3 (Checkout): WooCommerce-Formular-Templates überschreiben, korrekte Label-Zuordnung, Fehlermeldungen mit ARIA-live-Regionen – 18 Stunden
- Phase 4 (Testing): Manuelles Testing mit NVDA/Firefox, Nacharbeiten – 10 Stunden
Ergebnis: Axe-Fehler von 847 auf 23 reduziert (verbleibende Fehler: Video-Inhalte ohne Untertitel, redaktionelle Aufgabe). WCAG 2.1 AA für Kernprozesse erreichbar.
Erkenntnis: Der Wechsel des Themes wäre bei Neuprojekt wirtschaftlicher gewesen. Avada-spezifisches Markup hat den Aufwand in Phase 1 verdoppelt. Wer einen WooCommerce-Shop effektiv optimieren möchte, sollte Accessibility als festen Bestandteil der Optimierungsstrategie einplanen – nicht als nachträgliches Add-on.
Beispiel 2: Behördliche Website, WordPress mit BITV-2.0-Anforderung
Ausgangslage: Kommunale Website, Pflicht zur BITV-2.0-Konformität, Twenty Twenty-Two als Basis-Theme, Gutenberg-Editor.
Vorgehen: Block-basierter Aufbau mit konsequenter Semantic-HTML-Nutzung, Accessibility-Überprüfung als Teil des Publishing-Workflows, Redakteurs-Schulung für Alt-Texte und Heading-Hierarchie.
Ergebnis: BITV-Test durch externen Prüfer bestanden. Aufwand für Erstaufbau ca. 15% höher als bei nicht-accessibility-fokussiertem Aufbau.
Erkenntnis: Accessibility von Anfang in den Workflow zu integrieren ist erheblich günstiger als nachträgliche Optimierung. Block-Themes bieten hier strukturell bessere Voraussetzungen. Mehr zu den Grundlagen barrierefreier Umsetzung findet sich in diesem Überblick zur inklusiven Website-Gestaltung.
Fazit: WordPress Barrierefreiheit – Gesetz und Handlungsrahmen
Wer unter das BFSG fällt, muss handeln. Für WordPress-Betreiber bedeutet das eine ehrliche Bestandsaufnahme:
Key Takeaways:
- Prüfe zunächst deine Betroffenheit: Nicht jede WordPress-Seite fällt unter das BFSG. E-Commerce und Transaktionsdienste sind primär betroffen. Reine Informationsseiten folgen anderen Regelungen.
- Automatisierte Tools sind der Einstieg, nicht das Ziel: Axe DevTools oder WAVE decken 30–40% der Probleme auf. Manuelle Tests und Screenreader-Testing sind unersetzlich.
- Overlay-Lösungen sind keine Compliance-Strategie: Sie lösen keine Barrieren, sie überdecken sie. Juristische Absicherung ist damit nicht gegeben.
- Theme-Wahl ist die kritischste Entscheidung: Semantisch schlanke Themes reduzieren den Accessibility-Aufwand erheblich. Page-Builder-lastige Setups bedeuten strukturell mehr Aufwand.
- Nachträgliche Optimierung ist machbar, aber teuer: Je komplexer das Setup, desto höher der Aufwand. Ein realistisches Budget für eine WooCommerce-Site liegt bei 60–150+ Entwicklerstunden.
Nächster Schritt: Führen Sie einen initialen Axe-DevTools-Scan durch und priorisieren Sie nach Schweregrad der Fehler. Fehler der Kategorien „Critical“ und „Serious“ haben sowohl die höchste WCAG-Relevanz als auch die größte Auswirkung auf Nutzbarkeit.
Häufig gestellte Fragen
Gilt das BFSG auch für meinen kleinen WooCommerce-Shop?
Kleinstunternehmen mit weniger als 10 Mitarbeitern und einem Jahresumsatz unter 2 Millionen Euro sind vom BFSG explizit ausgenommen. Diese Ausnahme muss aber aktiv dokumentiert werden können. Wichtig: Die Ausnahme gilt nur für die BFSG-Pflicht, nicht für andere rechtliche Risiken wie AGG-basierte Klagen oder vertraglich vereinbarte Accessibility-Anforderungen. Eine grundlegende Accessibility-Optimierung bleibt auch für Kleinstunternehmen empfehlenswert – insbesondere wenn öffentliche Auftraggeber oder Ausschreibungen relevant sind.
Was ist der Unterschied zwischen WCAG 2.1 und WCAG 2.2 – und welchen Standard muss ich erfüllen?
WCAG 2.2 (Oktober 2023) ergänzt WCAG 2.1 um neun neue Erfolgskriterien, darunter verbesserte Anforderungen an Fokus-Indikatoren (Kriterien 2.4.11 und 2.4.12) und ein Verbot kognitiver Funktionstests bei Authentifizierung (3.3.7, 3.3.8). Die gesetzlich referenzierte Norm EN 301 549 basiert aktuell noch auf WCAG 2.1 AA, eine Aktualisierung auf 2.2 ist in Arbeit. Wer heute neu implementiert, sollte WCAG 2.2 AA als Zielstandard nehmen – der Mehraufwand gegenüber 2.1 ist überschaubar, und ein späteres Retrofit lässt sich so vermeiden.
Sind Accessibility-Overlays wie AccessiBe eine legale Compliance-Lösung?
Nein – zumindest nicht zuverlässig. Overlay-Lösungen adressieren keine strukturellen Barrieren im Quellcode. Führende Accessibility-Organisationen wie die National Federation of the Blind und anerkannte Experten wie Adrian Roselli dokumentieren, dass Overlays Screenreader aktiv stören können. Mehrere Klagen in den USA wurden trotz aktivem Overlay eingereicht und nicht abgewiesen. Als einzige oder primäre Compliance-Strategie sind diese Produkte ungeeignet. Eine strukturelle Accessibility-Optimierung des Quellcodes ist der einzige verlässliche Weg.
Welches WordPress-Theme ist die beste Basis für eine barrierefreie Website?
Es gibt kein WCAG-zertifiziertes Theme, da die Theme-Wahl nur ein Faktor ist. Themes mit accessibility-ready-Tag im WordPress-Repository – etwa Twenty Twenty-Four, GeneratePress oder Astra mit Accessibility-Addon – bieten eine solide semantische Grundlage. Entscheidend ist das generierte HTML: Schlankes, semantisch korrektes Markup ohne übermäßige div-Verschachtelung ist die Voraussetzung. Page-Builder-Themes wie Divi oder Avada erhöhen den Optimierungsaufwand erheblich und sind für Accessibility-fokussierte Projekte keine erste Wahl.
Kann ich mit automatisierten Tools feststellen, ob meine Seite WCAG-konform ist?
Nur eingeschränkt. Automatisierte Tools wie axe DevTools, WAVE oder Lighthouse decken nach Angaben von Deque Systems ca. 30–40% der WCAG-Verstöße auf. Sie sind unverzichtbar als erster Schritt, aber kein Compliance-Nachweis. Ein sauberes Lighthouse-Ergebnis bedeutet ausdrücklich nicht WCAG-AA-Konformität. Für eine belastbare Einschätzung sind manuelle Tests – Tastaturnavigation, Farbkontraste, Formular-Labels – und Tests mit echten Screenreadern wie NVDA oder VoiceOver erforderlich. Automatisierte Tests und manuelle Prüfung ergänzen sich.
Wie aufwändig ist es, eine bestehende WooCommerce-Site WCAG-konform zu machen?
Der Aufwand hängt stark vom bestehenden Setup ab. Eine WooCommerce-Installation auf einem schlanken, semantisch korrekten Theme erfordert realistisch 40–80 Stunden für Level AA. Eine Installation auf einem komplexen Page-Builder-Theme mit viel Custom-Code: 80–150+ Stunden. Kritische Treiber sind das Theme-Markup, die Anzahl benutzerdefinierter Komponenten und fehlende Alt-Texte bei Mediendateien. Ein initialer axe-DevTools-Scan gibt eine erste Orientierung für die Priorisierung und Aufwandsschätzung.
Gibt es eine Übergangsfrist beim BFSG für bestehende Dienste?
Ja, mit Einschränkungen. Für Dienstleistungen, die bereits vor dem 28. Juni 2025 erbracht wurden, gilt eine Übergangsfrist bis zum 28. Juni 2030. Diese Frist gilt jedoch nicht automatisch – der Dienstleister muss nachweisen können, dass eine grundlegende Änderung unverhältnismäßigen Aufwand bedeutet. Für neue Dienste und Produkte, die nach dem 28. Juni 2025 auf den Markt kommen, gilt die Anforderung ohne Übergangsfrist. Produkte und Dienstleistungen werden dabei unterschiedlich behandelt.
Muss ich als WordPress-Betreiber eine Accessibility-Erklärung veröffentlichen?
Für öffentliche Stellen ist die Barrierefreiheitserklärung nach BITV 2.0 verpflichtend. Für privatwirtschaftliche Unternehmen unter dem BFSG ist eine formale Erklärung aktuell nicht explizit vorgeschrieben. Eine dokumentierte Selbstauskunft über den Compliance-Status und ein Feedback-Mechanismus für Nutzer sind jedoch empfehlenswert und werden von Aufsichtsbehörden als positives Signal gewertet. Im B2B-Bereich verlangen öffentliche Auftraggeber zunehmend Accessibility-Statements als Teil von Ausschreibungsanforderungen.
