Was EAA und WCAG 2.1 für WordPress-Websites bedeuten
Seit dem 28. Juni 2025 gilt das europäische Barrierefreiheitsgesetz (EAA, Richtlinie 2019/882) für Produkte und Dienstleistungen, die neu auf den EU-Markt gebracht werden. Für eine Website oder Webanwendung bedeutet das die Einhaltung von WCAG 2.1 AA, einem W3C-Standard, der festlegt, wie digitale Inhalte wahrnehmbar, bedienbar, verständlich und robust gestaltet sein müssen. Der EAA nennt die WCAG-Erfolgskriterien nicht selbst; er verweist auf die europäische harmonisierte Norm EN 301 549, die derzeit WCAG 2.1 Stufe AA enthält. WCAG 2.2 ist inzwischen die aktuelle W3C-Empfehlung, aber die rechtliche Untergrenze, an der sich die meisten WordPress-Websites heute messen müssen, ist immer noch 2.1 AA - und genau deshalb lohnt es sich, diesen Standard aus eigenem Recht zu verstehen, bevor man tiefer einsteigt.
Dieser Artikel ist der Einstiegspunkt. Er beschreibt, wer tatsächlich betroffen ist, welche Ausnahmen tragfähig sind und welche nicht, wie WCAG 2.1 AA auf einem realen WordPress-Projekt aussieht und wohin es von hier aus weitergeht. Erfahren Sie mehr über WordPress-Entwicklungsdienstleistungen bei WPPoland, wenn Sie ein Team brauchen, das barrierefreie Projekte tatsächlich baut, statt sie nur zu prüfen.
Zwei Zahlen erklären, warum das kein Nischenthema ist. Rund 15 Prozent der EU-Bevölkerung lebt mit einer Form von Behinderung, und ein deutlich größerer Anteil profitiert situativ davon: ältere Nutzerinnen und Nutzer, Menschen mit einer vorübergehenden Verletzung, jeder, der auf einem kleinen Bildschirm bei hellem Sonnenlicht liest. Barrierefreiheitsarbeit überschneidet sich außerdem stark mit SEO-Grundlagen - semantische Struktur, beschreibender Alt-Text und saubenes Markup helfen Suchmaschinen und KI-Antwortsystemen genauso wie assistiven Technologien. Beide Themenstränge ziehen sich durch den Rest dieses Leitfadens.
Wichtige Termine und wer betroffen ist
Das Inkrafttreten des EAA ist ein fester Termin, aber “betroffen” ist keine einfache Ja-Nein-Frage - es hängt von der Produkt- oder Dienstleistungskategorie, dem Vertragsdatum und der Art der bedienten Kundschaft ab. Die folgende Tabelle ist die praktische Zusammenfassung; rechtliche Feinheiten bei Grenzfällen gehören zu einem Anwalt, nicht zu einem Blogartikel.
| Frist | Was sie umfasst | B2C-vs-B2B-Nuance |
|---|---|---|
| 2025-06-28 | Die Barrierefreiheitsanforderungen des EAA gelten für Produkte und Dienstleistungen, die neu auf den EU-Markt gebracht werden: E-Commerce, Verbraucherbanking, E-Books, elektronische Kommunikation, Zugangsdienste zu audiovisuellen Mediendiensten und Schnittstellen für den Personenverkehr (Anhang I) | Die E-Commerce-Kategorie ist über einen Verbrauchervertrag definiert (Artikel 3(30)); andere Kategorien wie Banking und elektronische Kommunikation kennen diese Beschränkung auf Verbraucher nicht |
| 2025-06-28 bis 2030-06-28 | Übergangsfenster: Dienstleistungsverträge, die vor dem 2025-06-28 abgeschlossen wurden, können höchstens bis zu diesem Datum auf den ursprünglichen Konditionen weiterlaufen | Gilt unabhängig vom Kundentyp - entscheidend ist das Vertragsdatum, nicht ob der Käufer Verbraucher oder Unternehmen ist |
| Einsatzdatum + bis zu 20 Jahre | Selbstbedienungsterminals (Geldautomaten, Fahrkartenautomaten, Check-in-Kioske), die vor der Frist installiert wurden, können bis zum Ende ihrer Nutzungsdauer weiterlaufen, maximal 20 Jahre | Betrifft überwiegend Hardware bei physischen Terminals; für ein reines WordPress-Projekt selten relevant, außer es steuert einen Kiosk im Ladengeschäft |
| Laufend, pro Geschäftsjahr | Neubewertung des Kleinstunternehmens: Überschreitet Belegschaft oder Umsatz eines Dienstleisters die Schwelle aus Artikel 4(5), entfällt die Befreiung ab diesem Geschäftsjahr | Gilt nur für Dienstleister - produktseitige Pflichten waren von dieser Ausnahme nie erfasst, unabhängig von der Größe |
| Nationale Umsetzungstermine | Die meisten Mitgliedstaaten haben nahe am EU-Termin umgesetzt - das deutsche BFSG trat am selben Tag in Kraft, dem 2025-06-28 - aber lokale Durchsetzungsbehörden, Bußgeldstrukturen und Regeln für Barrierefreiheitserklärungen unterscheiden sich von Land zu Land | Gilt für den Markt, auf dem das Produkt oder die Dienstleistung angeboten wird, nicht für das Land, in dem der Betreiber ansässig ist |
Die praktische Lesart: Wenn eine WordPress-Website an EU-Verbraucher verkauft, einen WooCommerce-Checkout betreibt oder eine Dienstleistung aus einer der Anhang-I-Kategorien anbietet, ist die Frist bereits verstrichen und die Pflicht besteht jetzt, nicht irgendwann in der Zukunft.
Ausnahmen und Kleinstunternehmens-Regelung
Das ist der Abschnitt, der am häufigsten falsch verstanden wird. “Wir sind klein, also sind wir befreit” ist eine verbreitete Annahme und öfter falsch als richtig. Die Richtlinie 2019/882 definiert mehrere enge Ausnahmeregelungen, keinen allgemeinen Freifahrtschein für kleine Unternehmen.
| Ausnahme | Wer sie beanspruchen kann | Bedingungen | Was sie NICHT abdeckt |
|---|---|---|---|
| Kleinstunternehmens-Ausnahme (Artikel 4(5)) | Unternehmen mit unter 10 Beschäftigten UND Jahresumsatz oder Bilanzsumme unter 2 Mio. EUR | Beide Bedingungen müssen gleichzeitig erfüllt sein; die Ausnahme entfällt ab dem Geschäftsjahr, in dem eine der beiden Schwellen überschritten wird | Befreit nur Dienstleistungen. Pflichten aus Herstellung, Import oder Vertrieb von Produkten gelten unabhängig von der Unternehmensgröße |
| Unverhältnismäßige Belastung (Artikel 14, Anhang VI) | Jeder Wirtschaftsakteur, unabhängig von der Größe | Erfordert eine dokumentierte Bewertung anhand der Kriterien in Anhang VI, die Kosten gegen Nutzen für die Nutzer abwägt; muss mindestens alle fünf Jahre erneuert und Behörden auf Anfrage vorgelegt werden | Kein pauschaler Freifahrtschein - der Betreiber muss weiterhin jede Anforderung erfüllen, die nicht nachweislich unverhältnismäßig ist |
| Grundlegende Änderung (Artikel 14) | Jeder Wirtschaftsakteur, unabhängig von der Größe | Gilt nur, wenn die Erfüllung einer Anforderung die Art des Produkts oder der Dienstleistung grundlegend verändern würde | Selten anwendbar auf typische WordPress-Funktionen (Navigation, Formulare, Inhalte); eher relevant für spezialisierte Hardware oder Individualsoftware |
| Bestehende Dienstleistungsverträge (Artikel 32) | Jede Größe | Vor dem 2025-06-28 abgeschlossene Dienstleistungsverträge können höchstens bis 2030-06-28 auf den ursprünglichen Konditionen weiterlaufen | Gilt nicht für neue Verträge, die nach der Frist unterschrieben werden, auch nicht bei bestehender Kundschaft |
| Bereits im Einsatz befindliche Selbstbedienungsterminals (Artikel 32) | Jede Größe, meist Hardware-Betreiber | Vor der Frist installierte Terminals können bis zum Ende ihrer Nutzungsdauer weiterlaufen, maximal 20 Jahre | Gilt nicht für neue Terminals, die nach der Frist gekauft oder installiert werden |
| Vor dem 28. Juni 2025 veröffentlichte Aufzeichnungen (Artikel 2(4)) | Jede Größe | Zeitbasierte Medien (Audio/Video), die vor der Frist veröffentlicht wurden, sind rückwirkend vom Anwendungsbereich ausgenommen | Neue zeitbasierte Medien, die nach der Frist veröffentlicht werden, müssen die Anforderungen von Anfang an erfüllen |
Ein realer Abgrenzungsfall, Schritt für Schritt. Nehmen wir einen WooCommerce-Shop mit vier Beschäftigten und einem Umsatz weit unter 2 Mio. EUR, der direkt an Verbraucher verkauft. Nach Artikel 4(5) ist das ein Kleinstunternehmen im Dienstleistungsbereich, sodass die Barrierefreiheitspflichten für die Einkaufs- und Checkout-Dienstleistung selbst nicht für ihn gelten. Diese Ausnahme entfällt in dem Moment, in dem der Shop den fünften bis zehnten Beschäftigten einstellt und die Zehnergrenze überschreitet, oder der Umsatz die 2-Mio.-EUR-Marke übersteigt - die Richtlinie selbst sieht keine Übergangsfrist vor, daher ist die sicherere Planungsannahme, die Ausnahme ab dem Geschäftsjahr zu verlieren, in dem die Schwelle überschritten wird, nicht ab einem späteren Erneuerungsdatum.
Jetzt ändern wir eine Tatsache: derselbe Vier-Personen-Shop agiert stattdessen als Großhandelslieferant im Rahmen eines ausgehandelten Vertrags mit einem größeren Unternehmen, ohne jeden direkten Verbraucher-Checkout. Hier passieren zwei getrennte Dinge, nicht nur eines. Erstens ist die E-Commerce-Kategorie im EAA über den Abschluss eines Verbrauchervertrags definiert (Artikel 3(30), Erwägungsgrund 42) - ein rein B2B-Vertriebskanal kann allein deshalb außerhalb dieser Kategorie liegen, unabhängig von der Kleinstunternehmens-Ausnahme. Zweitens, und das ist der Teil, der Menschen stolpern lässt: außerhalb der eigenen E-Commerce-Pflicht des EAA zu stehen bedeutet nicht, dass der Shop in dieser Geschäftsbeziehung frei von Barrierefreiheitsanforderungen ist. Wenn der größere Käufer selbst dem EAA, NIS2 oder Vergabeklauseln zur Barrierefreiheit unterliegt, kann sein eigenes Compliance-Programm vertraglich WCAG-konforme Zuliefertools verlangen, unabhängig davon, ob der Zulieferer ein Kleinstunternehmen ist oder außerhalb der E-Commerce-Kategorie nach EU-Recht liegt. Die EAA-Ausnahme schützt vor der Durchsetzung des EAA selbst; sie bewirkt nichts gegen eine vertragliche Barrierefreiheitsklausel eines Kunden.
In Deutschland heißt das konkret: Das Barrierefreiheitsstärkungsgesetz (BFSG) trat am 28. Juni 2025 in Kraft, am selben Tag wie der EAA EU-weit, und setzt die Richtlinie 2019/882 in nationales Recht um. Paragraph 37 BFSG sieht Bußgelder im oberen fünfstelligen Eurobereich pro Verstoß vor, verhängt durch die zuständige Marktüberwachungsbehörde der Länder. Wer im BFSG-Sinn Kleinstunternehmen ist und nur Dienstleistungen erbringt, profitiert von derselben in Artikel 4(5) verankerten Ausnahme - aber ein Onlineshop, der Produkte selbst herstellt, importiert oder vertreibt, bleibt auf der Produktseite in der Pflicht, wie klein er auch sein mag.
Das ist eine sachliche Einordnung, keine Rechtsberatung - wenn eine konkrete Einstufung strittig ist oder die Umsatzzahlen nahe an der Schwelle liegen, sollte das vor der Nutzung einer Ausnahme in einer öffentlichen Erklärung oder einer Vergabeantwort mit einem Anwalt abgeklärt werden.
WCAG 2.1 AA in der Praxis auf WordPress
WCAG 2.1 AA ist keine Checkliste, die man einmal abhakt; es ist eine Reihe testbarer Erfolgskriterien, die auf einer gegebenen Seite, einem Formular oder einer Komponente entweder erfüllt sind oder nicht. Vier Bereiche machen den Großteil der realen Arbeit auf einer WordPress-Website aus.
Tastaturbedienbarkeit. Jedes interaktive Element - Menü, Dropdown, Modal, Karussell-Steuerung, Warenkorb-Button - muss ausschließlich mit Tab, Umschalt+Tab, Enter und den Pfeiltasten erreichbar und bedienbar sein, mit einem sichtbaren Fokusindikator bei jedem Schritt. Genau hier scheitern Page-Builder und Slider-Plugins am häufigsten: eine Slideshow, die nur bei Mouse-Hover weiterläuft, oder ein Mega-Menü, das sich bei Hover öffnet, aber nie bei Fokus, sperrt lautlos jeden aus, der keine Maus benutzen kann. Die Lösung ist selten ein Rewrite; meist reicht es, die fehlenden Keyboard-Event-Handler und einen sichtbaren :focus-Stil mit ausreichendem Kontrast hinzuzufügen.
Farbkontrast. WCAG 2.1 AA verlangt ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text gegenüber dem Hintergrund. Markenpaletten, die für ein Logo entworfen wurden, nicht für Fließtext, sind der häufigste Fehler: ein helles Grau auf Weiß, das in einem Mockup elegant wirkt, aber für Menschen mit Sehbehinderung das Kontrastverhältnis verfehlt. Kontrastfehler sind billig zu beheben, sobald sie erkannt sind, und teuer, wenn sie bleiben, weil sie jede Seite betreffen, die die Typografie-Einstellungen des Themes erbt.
Formulare. Jedes Eingabefeld braucht eine programmatisch verknüpfte Beschriftung (<label for="id">, nicht nur einen Platzhaltertext, der beim Fokussieren verschwindet), jedes Pflichtfeld muss ansagen, dass es Pflicht ist, und jeder Validierungsfehler muss in Textform in der Nähe des Feldes beschrieben werden, nicht nur über einen roten Rahmen vermittelt. Checkout- und Kontaktformulare sind hier die Bereiche mit dem höchsten Risiko, weil ein Formular, das eine Screenreader-Nutzerin nicht abschließen kann, eine verlorene Transaktion ist, nicht nur eine Compliance-Lücke.
Medien. Videos brauchen Untertitel, Audio braucht ein Transkript, und jedes bedeutungstragende Bild braucht einen Alt-Text, der seine Funktion oder seinen Inhalt beschreibt, statt den Dateinamen zu wiederholen. Dekorative Bilder (Hintergrundtexturen, Abstandshalter) sollten ein leeres alt="" tragen, damit assistive Technologie sie überspringt, statt Lärm anzusagen. Das ist einer der Bereiche, in denen redaktionelle Disziplin genauso wichtig ist wie Code: ein Entwickler kann eine barrierefreie Bildkomponente bauen, aber nur eine geschulte Redaktion hält jeden neuen Upload konform.
Häufige WordPress-Fehlermuster aus unseren Audits
Ein paar Muster wiederholen sich in fast jedem WordPress-Audit, das wir durchführen, unabhängig von Theme oder Branche. Die Überschriftenhierarchie bricht als Erstes: Page-Builder geben häufig für jeden Hero-Text einer Sektion ein <h1> oder <h2> aus, unabhängig von der tatsächlichen Position in der Dokumentgliederung, sodass eine Seite fünf h1-Tags und darunter keine logische h2/h3-Verschachtelung tragen kann. Screenreader-Nutzerinnen navigieren über die Überschriftenstruktur; eine kaputte Gliederung macht die Seite deutlich schwerer zu überblicken, als es sehenden Nutzern je auffallen würde.
Reine Icon-Steuerelemente kommen als Nächstes - ein Warenkorb- oder Such-Button, der als bloßes Icon ohne sichtbaren Text und oft auch ohne aria-label gerendert wird, lässt assistiver Technologie nichts zum Ansagen. Automatisch rotierende Karussells sind ein enger Dritter: keine Pause-Steuerung, keine Tastaturnavigation und Inhalte, die sich alle vier Sekunden ändern, unabhängig davon, ob die Leserin den aktuellen Slide zu Ende gelesen hat.
Das vierte Muster ist leiser, aber genauso folgenreich: Cookie-Consent-Banner und Newsletter-Modals, die den Tastaturfokus einfangen. Eine Nutzerin tabbt in das Modal hinein und kann nie mehr zum Seiteninhalt zurücktabben, weil der Entwickler nie eine Fokusfalle eingebaut hat, die sich per Escape oder über eine Schließaktion löst. In einem mausgesteuerten QA-Durchgang ist das unsichtbar und beim ersten Test ausschließlich mit der Tastatur sofort offensichtlich.
Keines dieser Muster ist ein exotischer Bug. Sie sind das direkte, wiederholbare Ergebnis beliebter Plugins und Themes, so eingesetzt, wie die meisten Websites sie einsetzen - genau deshalb findet ein Audit über nicht miteinander verbundene Projekte hinweg dieselbe Handvoll Muster. Der Artikel zum Compliance-Stack 2026 geht die Fehlerliste Plugin für Plugin durch - Page-Builder, WooCommerce-Templates, Slider-Plugins, Formular-Plugins - mit dem jeweils verletzten WCAG-Erfolgskriterium und der konkreten Lösung dafür.
Umsetzungspfad: Audit, Beheben, Erklärung, Monitoring
“Wir müssen konform werden” in ein geliefertes, verteidigbares Ergebnis zu verwandeln, folgt in jedem Projekt, das wir betreuen, demselben vierstufigen Pfad.
Audit. Beginnen Sie mit einer abgegrenzten WCAG-2.1-AA-Prüfung entlang der tatsächlichen Customer Journeys der Website - Startseite, Navigation, Suche, Formulare und jeder umsatzkritische Checkout-Schritt - nicht nur mit einem automatisierten Scan der Startseite. Automatisierte Tools (axe-core, Lighthouse, WAVE) erfassen etwa die Hälfte der realen Probleme; den Rest muss eine menschliche Testperson mit Tastatur und Screenreader finden.
Beheben. Beheben Sie in der Reihenfolge, die zuerst die wertvollsten Journeys schützt: Tastaturfallen und unbeschriftete Checkout-Steuerelemente vor kosmetischen Kontrastanpassungen an einem Footer-Link. Eine einzelne Korrektur an einer gemeinsam genutzten Komponente - der Fokusstil des Themes, das Label-Markup des Formular-Plugins - räumt oft Dutzende wiederkehrender Befunde auf einmal aus, weshalb sich Korrekturen zuerst auf gemeinsame Templates und dann auf einzelne Seiten richten sollten.
Barrierefreiheitserklärung veröffentlichen. Eine Erklärung, die den Konformitätsgrad, bekannte Einschränkungen und einen funktionierenden Kontaktkanal für Beschwerden zur Barrierefreiheit angibt, ist nach mehreren nationalen Umsetzungsgesetzen (darunter das deutsche BFSG) verpflichtend und überall sonst gute Praxis. Sie gibt Vergabeteams außerdem etwas Konkretes zu den Akten.
Monitoring. Barrierefreiheit driftet in dem Moment ab, in dem ein neues Plugin-Update, ein neues Page-Builder-Template oder eine neue Redakteurin ohne Schulung einsteigt. Eine automatisierte Prüfung in der CI fängt Regressionen bei jedem Deploy ab; ein jährlicher manueller Retest fängt das ab, was Automatisierung nicht sehen kann.
Für den vollständigen rechtlichen Stack - die neun neuen Erfolgskriterien von WCAG 2.2, das Verhältnis von EAA und BFSG und die Details der Plugin-Korrekturen - lesen Sie den Compliance-Stack 2026 für WordPress. Wenn Sie ein abgegrenztes, schriftliches Audit statt einer Selbstbedienungs-Checkliste wollen, deckt der EU-Konformitätsaudit für WordPress Barrierefreiheit zusammen mit NIS2/DORA- und AI-Act-Exposition in einem Auftrag ab, mit individuellem Angebot je nach tatsächlichem Umfang Ihrer Website.
Warum sich Barrierefreiheit mit SEO und KI-Lesbarkeit überschneidet
Der Großteil der technischen Arbeit hinter WCAG 2.1 AA ist gleichzeitig, unabhängig davon, gutes SEO und gute Hygiene für KI-Antwortsysteme - deshalb lassen sich Barrierefreiheitsbudgets leichter rechtfertigen, als es zunächst scheint. Eine klare, sequenzielle Überschriftenhierarchie ist genau das, was Suchmaschinen-Crawler und zusammenfassende Sprachmodelle nutzen, um zu verstehen, worum es auf einer Seite tatsächlich geht; dieselbe Korrektur, die einer Screenreader-Nutzerin hilft, eine Seite zu navigieren, hilft auch einem KI-System, den richtigen Abschnitt zu extrahieren, wenn es eine Frage dazu beantwortet. Beschreibender Alt-Text leistet doppelte Arbeit - als Signal für die Bildersuche und als Ersatzbeschreibung, die jedes KI-System, das das Markup der Seite liest, nutzen kann, wenn das Bild selbst nicht verarbeitet wird.
Semantisches HTML - echte <button>- und <nav>-Elemente statt gestylter <div>-Suppe, korrekte <label>-Verknüpfungen in Formularen - erzeugt Markup, das gleichzeitig barrierefrei und für automatisierte Systeme verlässlicher zu parsen ist, egal ob dieses System ein Screenreader, ein Suchcrawler oder eine Retrieval-Pipeline hinter einem KI-Assistenten ist. Das ist kein Zufall: Barrierefreiheit und Maschinenlesbarkeit konvergieren auf dieselbe zugrunde liegende Anforderung, nämlich Inhalte, die ihre eigene Struktur und Bedeutung im Markup tragen, statt sich ausschließlich auf visuelles Styling zu verlassen. Wer ein WCAG-Sanierungsprojekt rein als rechtliche Kostenstelle behandelt, übersieht, dass sich ein großer Teil der Arbeit über organische Sichtbarkeit selbst amortisiert.
Wie es weitergeht
Bereit, von der Bewertung in die Umsetzung zu gehen? Kontaktieren Sie uns, um ein Barrierefreiheits-Review für Ihre WordPress-Website abzugrenzen, oder starten Sie mit der Ressource, die zu Ihrem aktuellen Stand passt:
- Brauchen Sie die tiefere rechtliche und technische Landkarte, inklusive WCAG 2.2 und BFSG? Lesen Sie den Artikel zum Compliance-Stack 2026.
- Brauchen Sie ein abgegrenztes, schriftliches Audit mit einem Sanierungsbacklog, den Sie an eine Entwicklerin übergeben können? Sehen Sie sich den EU-Konformitätsaudit für WordPress an.
- Brauchen Sie ein Team, das die Korrektur baut, statt sie nur zu diagnostizieren? Entdecken Sie unsere WordPress-Entwicklungsdienstleistungen.
