WCAG 2.2, BFSG und der EU-Rechtsakt zur Barrierefreiheit: der Compliance-Stack 2026 für WordPress

#WCAG 2.2, BFSG und der EU-Rechtsakt zur Barrierefreiheit: der Compliance-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 zur Checkliste SEO-Muster für headless WordPress, bei der einige Barrierefreiheits-Muster auch SEO 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 unser Tech Radar (Q3 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.

#Wo das hinpasst

Diese Säule verankert sich am Cluster der headless WordPress-Leistung als Compliance-Dimension. Zur Framework-Wahl siehe die Entscheidungsmatrix Next.js vs Astro. Zu SEO-Migrationsrisiken (einige Barrierefreiheits-Muster betreffen auch SEO, insbesondere Überschriftshierarchie und Linktext) siehe die Checkliste SEO-Muster. Zur NIS2- und DORA-Compliance, die häufig in derselben Beschaffungs-Scorecard auftaucht, siehe den eigenen Artikel zu NIS2 und DORA auf WordPress.