WCAG 2.2, BFSG und EAA: Compliance-Stack für WordPress 2026

#WCAG 2.2, BFSG und der EU-Rechtsakt zur Barrierefreiheit: der Konformitäts-Stack 2026 für WordPress

Drei Dokumente bestimmen, was eine WordPress-Site im Jahr 2026 zu tun hat, um in der Europäischen Union rechtlich barrierefrei zu sein: die Web Content Accessibility Guidelines 2.2 des W3C, der Rechtsakt zur Barrierefreiheit der EU (Richtlinie 2019/882) und das deutsche Barrierefreiheitsstärkungsgesetz. Sie sind nicht austauschbar; sie schichten sich. Dieser Artikel ist die Umsetzungskarte.

Der Beitrag passt zur Service-Säule headless WordPress, in der die technische Oberfläche beschrieben wird, sowie zum Vergleich headless vs monolithisch, in dem einige Architekturentscheidungen auch SEO und Barrierefreiheit berühren.

#TL;DR

• WCAG 2.2 ist die aktuelle W3C-Empfehlung, veröffentlicht am 2023-10-05.
• Der EU-Rechtsakt zur Barrierefreiheit gilt ab 2025-06-28 in jedem Mitgliedstaat.
• Das deutsche BFSG setzt den EAA am selben Tag in Bundesrecht um.
• Ausnahmen für Kleinstunternehmen existieren, sind aber enger als angenommen.
• Bußgelder nach BFSG Paragraph 37 erreichen den oberen fünfstelligen Euro-Bereich.

#Die drei Schichten, in der richtigen Reihenfolge

Drei rechtliche und technische Schichten überlagern sich, um die Pflicht der Site zu definieren:

Schicht eins, WCAG 2.2 (technisch). Die Menge messbarer Erfolgskriterien, die barrierefreie Webinhalte definieren. Erstellt von der Web Accessibility Initiative des W3C. WCAG 2.2 wurde am 2023-10-05 als Empfehlung veröffentlicht und führt neun neue Erfolgskriterien gegenüber WCAG 2.1 ein, darunter Fokussichtbarkeit, Ziehbewegungen und konsistente Hilfe.

Schicht zwei, der EU-Rechtsakt zur Barrierefreiheit (EU). Richtlinie 2019/882, 2019 verabschiedet, anwendbar ab 2025-06-28. Sie legt fest, welche Produkte und Dienstleistungen barrierefrei sein müssen, und verweist auf die europäische Norm EN 301 549, die WCAG durch Verweis einbezieht. Der EAA sagt nicht wörtlich “befolgt WCAG 2.2”; er verweist auf die harmonisierte europäische Norm, die derzeit WCAG 2.1 Stufe AA einbezieht. Nationale Umsetzungen können WCAG 2.2 fordern.

Schicht drei, nationale Umsetzung (Mitgliedstaat). Jeder Mitgliedstaat erlässt sein eigenes Gesetz zur Umsetzung des EAA. Deutschlands ist das BFSG, in Kraft am selben Tag wie die Anwendung des EAA. Andere Mitgliedstaaten setzen mit ähnlichen Namen und ähnlichen (manchmal höheren) Anforderungen um. Die Site muss das Umsetzungsgesetz in jedem Markt erfüllen, in dem sie verkauft, nicht nur am Sitzort.

Die Reihenfolge zählt. WCAG ist die technische Hürde. Der EAA ist der rechtliche Rahmen auf EU-Ebene. Das nationale Gesetz ist das lokale Vollzugsinstrument. Audits laufen in dieser Reihenfolge: zuerst technisch, dann rechtlich, lokal zuletzt.

#Was WCAG 2.2 tatsächlich verlangt

WCAG 2.2 hat 86 Erfolgskriterien über 13 Richtlinien unter 4 Prinzipien (Wahrnehmbar, Bedienbar, Verständlich, Robust). Drei Stufen: A, AA, AAA. Der rechtliche und vertragliche Standard ist AA. AAA ist anstrebbar und nicht immer praktikabel für inhaltsstarke Sites.

Die neun neuen Kriterien in WCAG 2.2 gegenüber WCAG 2.1:

1. Fokussichtbarkeit (AA, Stufe AA nur in 2.2)
2. Fokus nicht verdeckt Minimum (AA)
3. Fokus nicht verdeckt Erweitert (AAA)
4. Ziehbewegungen (AA)
5. Mindestzielgröße (AA, 24 by 24 CSS pixels)
6. Konsistente Hilfe (A)
7. Redundante Eingabe (A)
8. Barrierefreie Authentifizierung Minimum (AA)
9. Barrierefreie Authentifizierung Erweitert (AAA)

Für eine WordPress-Site, die bereits auf WCAG 2.1 AA zielte, besteht die praktische Arbeit 2026 in der Verifikation der neun neuen Kriterien, wobei Zielgröße und Ziehbewegungen die häufigsten Lücken sind (kleine klickbare Symbole, ausschließlich per Ziehen bedienbare Slider).

#EAA: Geltungsbereich, Ausnahmen, Fristen

Der EAA erfasst eine festgelegte Liste von Produkten und Dienstleistungen, die ab 2025-06-28 in Verkehr gebracht werden. Die für die meisten WordPress-Betreiber relevante Liste:

• Verbraucher-Bankdienstleistungen.
• E-Books und dedizierte E-Reader-Software.
• Elektronische Kommunikationsdienste.
• Audiovisuelle Mediendienste.
• Personenverkehrsdienste (Web- und Mobil-Schnittstellen).
• E-Commerce-Dienste (die Auffangkategorie für die meisten WooCommerce-Shops).

Die Richtlinie definiert Ausnahmen für Kleinstunternehmen: weniger als 10 Beschäftigte UND Jahresumsatz oder Bilanzsumme unter 2 Mio. EUR. Diese Ausnahmen gelten für Dienstleister; die Schwelle für Hersteller ist strenger. Die häufige Fehldeutung ist “kleine Site, keine Regeln”; die tatsächliche Regel lautet “kleiner Betreiber, engere Pflicht, engere Ausnahme”.

Übergangsfrist: Vor dem 2025-06-28 geschlossene Dienstleistungsverträge können unter den Vor-EAA-Bedingungen längstens bis 2030-06-28 fortbestehen. Bereits genutzte Selbstbedienungsterminals können bis zum Ende ihrer Nutzungsdauer weiterlaufen, mit einer harten Obergrenze von 20 Jahren.

#BFSG: die deutsche Umsetzung

Deutschland hat das Barrierefreiheitsstärkungsgesetz zur Umsetzung des EAA verabschiedet. Es trat am 2025-06-28 in Kraft.

Drei Dinge, die das BFSG über die EAA-Basis hinaus ergänzt:

Erstens, Vollzug auf Bundesebene. Die Bundesanstalt für Arbeitsschutz und Arbeitsmedizin sowie die Marktüberwachungsbehörden des Bundes überwachen die Einhaltung. Strukturen der Mitgliedstaaten variieren; in Deutschland ist die Bundesaufsicht der Mechanismus.

Zweitens, Bußgeldstruktur (Paragraph 37 BFSG). Bußgelder bei Verstößen sind in BFSG Paragraph 37 geregelt. Bestimmte Verstoßarten ziehen Bußgelder im oberen fünfstelligen Euro-Bereich pro Verstoß nach sich. Wiederholte oder systemische Verstöße kumulieren.

Drittens, Pflicht zur Erklärung zur Barrierefreiheit. Die Site muss eine Erklärung zur Barrierefreiheit veröffentlichen, die von einer auffindbaren Stelle aus verlinkt ist (Footer ist üblich). Die Erklärung benennt das Konformitätsniveau, geltend gemachte Ausnahmen und einen Kontaktmechanismus für Beschwerden zur Barrierefreiheit.

Betreiber, die ohne deutsche Eintragung nach Deutschland verkaufen, unterliegen weiterhin dem BFSG, sobald ihre Produkte oder Dienstleistungen auf den deutschen Markt gebracht werden. Die Verteidigung “ich bin kein deutsches Unternehmen” gibt es nicht.

#Was das für eine WordPress-Site bedeutet

Die Umsetzungsarbeit teilt sich in vier Spalten.

Theme und Core. Wählen Sie ein als accessibility-ready auf WordPress.org gekennzeichnetes Theme und prüfen Sie es gegen WCAG 2.2 AA. Auditieren Sie das WordPress-Backend, nicht nur das Frontend; das BFSG erfasst auch die Benutzeroberfläche, die Beschäftigte nutzen, sofern sie unter inklusive Beschäftigungsanforderungen fallen. Der WordPress-Core ist generell barrierefreiheits-bewusst (das Accessibility-Team ist aktiv), aber Plugins und Eigencode brechen die Hürde regelmäßig.

Plugins. Auditieren Sie die Frontend-Ausgabe jedes aktiven Plugins. Konkrete Fehlerbilder, die wir Audit für Audit sehen:

• Page Builder (Elementor, Divi, WPBakery): geben <h1> für Hero-Text in jeder Sektion aus und brechen damit die Überschriftshierarchie. WCAG 2.4.6 (Überschriften und Beschriftungen) und 1.3.1 (Info und Beziehungen) scheitern. Fix: Überschriftsebenen auf Theme-Template-Ebene überschreiben oder zum Block-Editor wechseln.
• WooCommerce Standard-Warenkorb-Button auf Archiven: nur Icon mit aria-label, ohne sichtbaren Text und ohne sichtbaren Fokusindikator. WCAG 2.4.7 (Sichtbarer Fokus) und 2.5.8 (Mindestgröße der Zielelemente, 24×24 CSS-Pixel in WCAG 2.2). Fix: Klickbereich auf mindestens 24×24 vergrößern, sichtbarer Fokusring mit 3:1-Kontrast, sichtbaren Text wo möglich wiederherstellen.
• Slideshow-Plugins (Slick, Owl Carousel, MetaSlider, Smart Slider): keine Pfeiltasten-Unterstützung, keine Pausen-Steuerung bei automatisch rotierenden Slides. WCAG 2.2.2 (Pausieren, Stoppen, Ausblenden) und 2.1.1 (Tastatur) scheitern. Fix: nach Möglichkeit durch ein statisches Bildraster ersetzen; falls erforderlich, sichtbare Pause- und Vor-/Zurück-Buttons mit korrekten Beschriftungen ergänzen.
• Formular-Plugins (Contact Form 7, Gravity Forms, Ninja Forms): überspringen <label for>-Verknüpfungen und verwenden Platzhalter als einzige Beschriftung. WCAG 1.3.1 und 3.3.2 (Beschriftungen oder Anweisungen) scheitern. Fix: explizites <label for="id">, Fehlermeldungen via aria-describedby, Pflichtfelder mit aria-required="true".

Auditieren Sie auch das Backend, wenn Nicht-Entwicklerpersonal es nutzt.

Inhalt und redaktionelle Disziplin. Die Durchsetzung von WCAG auf redaktioneller Ebene erfordert stehende Regeln: Jedes Bild braucht Alt-Text, jeder Link beschreibenden Text (nicht “hier klicken”), jede Überschriftshierarchie ist sequenziell, jedes Video hat Untertitel, jedes auf einer Seite eingebettete PDF wird selbst getestet. Das CMS macht die technische Konformität möglich; das Redaktionsteam macht sie tatsächlich Wirklichkeit.

Erklärung zur Barrierefreiheit und Beschwerdemechanismus. Die Erklärung ist in Deutschland nach BFSG verpflichtend. Der Beschwerdemechanismus (Kontakt-E-Mail oder Formular) muss funktional sein, nicht rudimentär. Beschwerden zur Barrierefreiheit müssen bestätigt und in angemessener Zeit bearbeitet werden.

#Warum headless WordPress nicht automatisch barrierefrei ist

Ein Headless-WordPress-Build mit einem Astro- oder Next.js-Frontend erbt die Barrierefreiheit nicht vom WordPress-Ursprung. Das Frontend-Framework ist verantwortlich für das gerenderte HTML, das Tastaturinteraktionsmodell, das Fokusmanagement und die ARIA-Semantik. Die Wahl des richtigen Frameworks hilft (sowohl Astro als auch Next.js haben starke Barrierefreiheits-Communities), aber die Arbeit muss explizit geleistet werden.

Laut unserem Tech Radar (Q4 2026) befinden sich Astro 5+ und Next.js 15 beide im Adopt-Ring. Keiner ist automatisch WCAG-2.2-konform. Das Barrierefreiheits-Audit ist ein eigener Arbeitsstrang neben der Framework-Auswahl.

Der Headless-Build kauft eines: Per-Route-Kontrolle über das gerenderte HTML, was Barrierefreiheits-Patches landbar und vorhersehbar macht. Ein monolithisches WordPress-Build, vermittelt durch einen schweren Pagebuilder, lässt sich schwerer ausbessern, wenn der Builder die Quelle des nicht barrierefreien Markups ist.

#Audit-Kadenz und Werkzeuge

Zwei Audits, zwei Kadenzen:

Automatisiert, bei jedem CI-Lauf. axe-core oder pa11y, ausgeführt auf einer repräsentativen Auswahl von Routen. Bricht den Build bei jeder neuen Verletzung ab. Erfasst etwa die Hälfte der WCAG-Probleme; verfehlt die Hälfte, die menschliche Beurteilung erfordert (Qualität des Alt-Textes, Absicht der Fokusreihenfolge, Absicht der ARIA-Landmarken).

Manuell, jährlich plus bei größeren Änderungen. Geschulter Barrierefreiheits-Tester, der ein vollständiges WCAG 2.2 AA-Audit mit Tests assistiver Technologien (Screenreader, Sprachsteuerung, ausschließlich Tastatur) durchführt. Das Ergebnis ist ein Lückenbericht, gekoppelt an spezifische Erfolgskriterien.

Eine Site, die nur das automatisierte Audit fährt, ist nicht WCAG 2.2 AA-konform. Eine Site, die nur das manuelle Audit fährt, driftet zwischen jährlichen Reviews. Beide sind notwendig.

#Geltungsbereich vor dem Audit sauber einordnen

Der erste Schritt ist kein Scan, sondern eine nachvollziehbare Einordnung des Betriebsmodells. Halten Sie Betreiber, Zielmärkte, angebotene Dienstleistung, Kundengruppe, Beschäftigtenzahl, die für eine mögliche Kleinstunternehmensausnahme verwendete Umsatz- oder Bilanzgrundlage sowie relevante Vertragsdaten fest. Unsichere Rechtsfragen gehören zur qualifizierten Rechtsberatung. Besucherzahl, Seitenumfang und der Einsatz von WordPress entscheiden nicht über den Geltungsbereich.

Danach wird die reale Kundenreise kartiert. Bei WooCommerce umfasst sie typischerweise Suche, Produktvergleich, Konto, Anmeldung, Warenkorb, Checkout, Zahlungsübergabe, Bestätigung, Retoure und Support. Drittanbieterflächen wie Zahlungs-Iframes, Terminbuchung, Consent-Manager, eingebettete Karten und PDF-Dokumente gehören ebenfalls in die Bestandsaufnahme. Ein fehlerfreier Homepage-Scan hilft wenig, wenn ein Tastaturnutzer den Kauf nicht abschließen kann.

Die Triage liefert einen dokumentierten Prüfumfang, eine Liste rechtlich zu bestätigender Annahmen und ein technisches Inventar. Sie ist noch keine Konformitätserklärung. Sie sorgt dafür, dass das Budget zuerst die für Nutzer und Geschäft entscheidenden Barrieren beseitigt.

#Ein belastbares Nachweispaket erstellen

Ein Audit ist dann verwertbar, wenn ein anderer Prüfer das Ergebnis reproduzieren kann. Für jeden geprüften Stand sollte das Nachweispaket mindestens enthalten:

• Produktions-URL, Build-Kennung, Prüfdatum und verantwortliche Person;
• Stichprobe der Routen, Komponenten und Zustände, einschließlich geschützter Abläufe;
• Browser, Viewport, Betriebssystem und Kombinationen assistiver Technologien;
• Werkzeugversionen und Rohberichte automatisierter Prüfungen;
• protokollierte Tastaturpfade, Screenreader-Beobachtungen sowie Zoom- und Reflow-Prüfungen;
• Zuordnung jedes Befunds zu WCAG-Erfolgskriterium, Schweregrad, Eigentümer und Nachteststatus;
• bereinigte Screenshots oder kurze Aufzeichnungen, wenn sie den Fehler verständlicher machen;
• bekannte Grenzen, Abhängigkeiten von Dritten und begründete Ausnahmeentscheidungen.

Ein Prozentwert aus Lighthouse oder axe eignet sich für die Beobachtung von Regressionen, ist aber kein Konformitätszertifikat. Der Nachweis muss erkennen lassen, was geprüft wurde, was außerhalb der Stichprobe lag und wie das Urteil zustande kam. Das ist bei Beschaffung, Übergabe und späteren Nachbesserungen wesentlich hilfreicher als ein einzelner Score.

#Prüf- und Abnahmekriterien für einen WordPress-Release

Legen Sie die Abnahme fest, bevor die Entwicklung mit Reparaturen beginnt. Prüfen Sie repräsentative Templates und vollständige Aufgaben: Navigation, Suche, Beitrag, Archiv, Kontaktformular, Fehlerseite sowie jeden umsatzrelevanten WooCommerce-Schritt. Ergänzen Sie Beispiele aller Gutenberg-Blöcke, individuellen Komponenten und Plugin-Interaktionen, die im produktiven System vorkommen.

Automatisierte Prüfungen sollten bei neuen erkennbaren Verstößen, fehlerhaften Landmark-Strukturen und regressiven unbeschrifteten Bedienelementen scheitern. Die manuelle Abnahme prüft eine logische Fokusreihenfolge, sichtbaren Fokus, Bedienung ohne Tastaturfalle, aussagekräftige zugängliche Namen, Fehlererkennung und -korrektur, Zoom auf 200 und 400 Prozent, Reflow bei schmalem Viewport sowie Rückmeldungen nach dynamischen Änderungen. Die Screenreader-Matrix richtet sich nach Zielgruppe und vereinbartem Prüfumfang.

Ein Befund gilt erst als geschlossen, wenn der Fix in der geprüften Umgebung bereitsteht, der ursprüngliche Reproduktionsweg funktioniert und ein benachbarter Ablauf nicht verschlechtert wurde. Restrisiken werden getrennt dokumentiert. Eine bestandene Stichprobe stützt die Freigabe, garantiert jedoch nicht, dass jede künftige Seite, redaktionelle Änderung oder Plugin-Aktualisierung konform bleibt.

#Reparaturen in der richtigen Reihenfolge

Priorisieren Sie nach Nutzerschaden und technischer Abhängigkeit, nicht nach der Anzahl der Scanner-Meldungen. Zuerst kommen Blockaden: Tastaturfallen, nicht zugängliche Anmeldung, unbeschriftete Checkout-Felder, fehlende Fehlerrückmeldung, unkontrollierbare Zeitlimits und für assistive Technik unsichtbare Inhalte. Danach folgen gemeinsame Ursachen im Theme, Designsystem, Formular-Renderer oder WooCommerce-Template. Ein korrigierter Baustein kann hunderte wiederholte Fehler entfernen.

Im dritten Schritt wird die Inhalts- und Dokumentenschuld bearbeitet: Überschriften, Linkzweck, Alternativtexte, Untertitel, Tabellen und nicht zugängliche PDFs. Anschließend folgen weniger schwere Darstellungsprobleme und sinnvolle Verbesserungen über den Mindestumfang hinaus. Nach jedem Komponentenpaket und vor dem Release wird nachgetestet. Liegt der Fehler in einem Drittanbieter-Plugin, muss entschieden werden, ob Konfiguration, Patch, Austausch oder Isolation tragfähig ist. Ein Ticket beim Anbieter stellt den Kundenweg noch nicht wieder her.

#Laufende Steuerung statt einmaligem Projekt

Barrierefreiheit braucht einen Platz im Release-Prozess. Jede gemeinsam verwendete Komponente erhält einen Eigentümer und zugängliche Abnahmekriterien. Automatisierte Prüfungen laufen in Pull Requests; ein kurzer manueller Regressionstest deckt die kritischen Kundenwege ab und wird bei Änderungen an Theme, Checkout, Consent-Schicht oder wichtigen Plugins wiederholt. Für Redakteure braucht es konkrete Regeln zu Überschriften, Links, Bildern, Tabellen, Video und Dokumenten.

Prüfen Sie Erklärung und Rückmeldekanal regelmäßig. Dokumentieren Sie Eingang, Bestätigung, Untersuchung, Lösung und wiederkehrende Ursache einer Meldung, ohne unnötige personenbezogene Daten zu speichern. Eine vierteljährliche Sicht auf wiederholte Komponentenfehler und Lieferantenrisiken ergänzt die breitere Prüfung nach einem Redesign oder einer wesentlichen Änderung der Transaktion. Dieser Prozess verspricht keine dauerhafte Konformität, macht Abweichungen aber früh sichtbar.

#Aus dem Befund einen schriftlichen Umsetzungsauftrag machen

Für eine technische Prüfung und priorisierte Nachbesserung nutzen Sie den WordPress Barrierefreiheits-Audit-Service. Schicken Sie eine schriftliche Kurzbeschreibung mit Produktions- und Staging-URL, Zielmärkten, wesentlichen Kundenwegen, Theme oder Pagebuilder, Plugins mit kundenseitiger Ausgabe, geschützten Bereichen, geplantem Release-Termin sowie vorhandenen Berichten oder Beschwerden. Zugangsdaten gehören nicht in die erste Nachricht; nennen Sie zunächst die geschützten Pfade, damit ein sicherer Zugriff vereinbart werden kann.

Das sinnvolle erste Ergebnis ist ein abgegrenztes Audit mit reproduzierbaren Befunden, Abnahmekriterien und einer nach Wirkung geordneten Reparaturliste. Es ist keine pauschale Rechts- oder Konformitätsgarantie. Wenn Geltungsbereich oder Ausnahme strittig sind, bleibt die rechtliche Einordnung bei qualifizierter Beratung; das technische Audit liefert die belastbaren Tatsachen zum Verhalten der Site.

#Wo das hinpasst

Diese Säule verankert sich am Cluster der headless WordPress-Leistung als Konformitäts-Dimension. Zur Framework-Wahl siehe die Entscheidungsmatrix Next.js vs Astro. Zu SEO-Migrationsrisiken und Informationsarchitektur siehe den Vergleich headless vs monolithisch. Zur NIS2- und DORA-Konformität, die häufig in derselben Beschaffungs-Scorecard auftaucht, siehe den eigenen Artikel zu NIS2 und DORA auf WordPress.