EAA und WCAG 2.1: wie digitale Barrierefreiheit umgesetzt wird

Seit dem 28. Juni 2025 sind die nationalen Umsetzungsgesetze des Europäischen Barrierefreiheitsgesetzes (European Accessibility Act, EAA), also der Richtlinie (EU) 2019/882, in den Mitgliedstaaten anzuwenden. In Deutschland ist das das Barrierefreiheitsstärkungsgesetz (BFSG) vom 16. Juli 2021. Die Regelungen erfassen nicht jede beliebige Website, sondern die in Artikel 2 Absatz 2 der Richtlinie genannten Verbraucherdienste, darunter den elektronischen Geschäftsverkehr, Bankdienstleistungen für Verbraucher, elektronische Kommunikationsdienste, Dienste für den Zugang zu audiovisuellen Mediendiensten, E-Books sowie Websites, Apps und elektronische Tickets der Personenbeförderung im Luft-, Bus-, Schienen- und Schiffsverkehr. Kleinstunternehmen, die Dienstleistungen erbringen (weniger als 10 Beschäftigte und ein Jahresumsatz oder eine Jahresbilanzsumme von höchstens 2 Millionen Euro), sind nach Artikel 4 Absatz 5 ausgenommen. Die vollständige Liste, die Ausnahmen und die Bußgelder nach Ländern stehen im Leitfaden zu Barrierefreiheit in WordPress und WCAG 2.2. Dieser Beitrag behandelt etwas anderes: wie die Umsetzung auf einer WordPress-Website abläuft.

Die Richtlinie nennt die Web Content Accessibility Guidelines (WCAG) nicht beim Namen. Anhang I verlangt, Websites und mobile Anwendungen wahrnehmbar, bedienbar, verständlich und robust zu gestalten: dieselben vier Prinzipien, auf denen WCAG aufbaut. Artikel 15 regelt die Konformitätsvermutung für Dienstleistungen, die harmonisierten Normen entsprechen, deren Fundstellen im Amtsblatt veröffentlicht wurden. In der Praxis werden Audits deshalb an den Erfolgskriterien der WCAG 2.1 oder 2.2 auf Konformitätsstufe AA gemessen. Dieser Praxisleitfaden erläutert, wie ein Barrierefreiheitsprojekt auf einer WordPress-Website strukturiert wird: von der Definition des Prüfumfangs über methodische Stichproben nach der W3C-Methodik bis zur Code-Korrektur im Theme und der Veröffentlichung einer Erklärung zur Barrierefreiheit.

#Das Europäische Barrierefreiheitsgesetz (EAA) und die WCAG 2.1 verstehen

Das EAA verfolgt das Ziel, Barrieren im europäischen Binnenmarkt abzubauen, die durch unterschiedliche nationale Vorschriften entstehen. Die technischen Vorgaben orientieren sich an den vier Grundprinzipien der Barrierefreiheit: Digitale Angebote müssen wahrnehmbar, bedienbar, verständlich und robust sein.

Die WCAG 2.1 bilden den internationalen Maßstab für zugängliche Webangebote. Die Sanktionen legt nicht die Richtlinie fest: Artikel 30 überlässt sie den Mitgliedstaaten und verlangt, dass sie wirksam, verhältnismäßig und abschreckend sind. Im BFSG sieht § 37 Geldbußen bis zu 100.000 Euro vor, unter anderem für Dienstleistungen, die die Anforderungen nicht erfüllen, und bis zu 10.000 Euro in den übrigen Fällen.

#Warum digitale Barrierefreiheit für Unternehmen unverzichtbar ist

Neben der rechtlichen Absicherung bietet die konsequente Barrierefreiheit wirtschaftliche und betriebliche Vorteile:

• Erschließung großer Zielgruppen: Laut der Europäischen Kommission leben rund 90 Millionen Menschen mit Behinderungen in der Europäischen Union. Zugängliche Webangebote öffnen Online-Dienste für diese große Gruppe potenzieller Kunden.
• Verbesserte Benutzerfreundlichkeit für alle: Barrierefreies Design steigert die Usability für jeden Besucher. Ausreichende Farbkontraste, logische Menüs, übersichtliche Formulare und verständliche Texte erleichtern älteren Nutzern, Smartphone-Anwendern im Sonnenlicht oder Menschen mit vorübergehenden Einschränkungen die Orientierung.
• Überschneidungen mit Suchmaschinenoptimierung: Zahlreiche WCAG-Kriterien entsprechen etablierten SEO-Praktiken: semantischer HTML-Aufbau, beschreibende Alternativtexte für Grafiken und responsive Darstellung.
• Einfachere Kaufabschlüsse: Zugängliche Eingabefelder mit klarer Fehleranzeige und nachvollziehbarer Tastaturführung machen den Kassenbereich leichter bedienbar.
• Stärkung der Unternehmensreputation: Ein barrierefreier Webauftritt zeigt gesellschaftliche Verantwortung und Kundenorientierung.
• Minimierung rechtlicher Risiken: Strukturierte Audits und dokumentierte Behebungsmaßnahmen reduzieren das Risiko von Kundenbeschwerden und behördlichen Verfahren.

#Was die Konformität mit WCAG 2.1 AA in der Praxis bedeutet

Die praktische Umsetzung von WCAG 2.1 Level AA erfordert konkrete Änderungen im Frontend und im WordPress-Theme:

• Vollständige Tastaturbedienbarkeit: Alle interaktiven Elemente (Menüs, Karussells, Modalfenster, Akkordeons und Buttons) müssen ohne Maus bedienbar sein und einen gut erkennbaren Fokusrahmen aufweisen.
• Kompatibilität mit Screenreadern: Semantische HTML-Strukturen, passende ARIA-Rollen, beschreibende Bildbeschriftungen und eindeutige Formular-Labels sorgen für eine korrekte Sprachausgabe.
• Farbkontraste: Texte und funktionale Bedienelemente müssen festgelegte Mindestkontrastwerte erfüllen (mindestens 4,5:1 bei Standardtext und 3:1 bei großen Schriften und Bedienelementen).
• Alternativen für zeitbasierte Medien: Videos und Audioaufnahmen müssen mit Untertiteln und Texttranskriptionen versehen werden.
• Logische Überschriftenhierarchie: Inhalte müssen durch eine fortlaufende, hierarchische Struktur (h1 bis h6) gegliedert sein.
• Barrierefreie Fehlerrückmeldung: Bei Fehleingaben im Formular muss die Rückmeldung genau angeben, welches Feld betroffen ist, und konkrete Lösungshinweise liefern.
• Zugänglichkeit von Dokumenten: Verlinkte PDF-Dateien, Produktkataloge und Rechnungen müssen als getaggte, barrierefreie Dokumente aufbereitet sein.
• Responsive Darstellung: Die Website muss auf Smartphone, Tablet und Desktop funktionieren.

#Wie der Umsetzungsprozess für Barrierefreiheit bei WordPress abläuft

Eine strukturierte Umsetzung erfolgt in fünf aufeinander aufbauenden Phasen:

1. Technisches Audit: Begutachtung der WordPress-Installation, bestehend aus automatisierten Scans und manuellen Prüfungen mit Screenreadern.
2. Optimierung von Themes und Erweiterungen: Anpassung der vorhandenen Komponenten oder Austausch gegen barrierefreie Alternativen.
3. Code-Korrekturen und Templates: Nachbesserung von ARIA-Attributen, Beseitigung von Tastaturfallen, Wiederherstellung sichtbarer Fokusindikatoren, Korrektur der Überschriftenstruktur und Angleichung von Farbpaletten.
4. Schulung des Redaktionsteams: Vermittlung barrierefreier Arbeitsweisen bei Bildbeschreibungen, Dokumentenstrukturen und Tabellengestaltung.
5. Erklärung zur Barrierefreiheit: Erstellung der Erklärung und Einrichtung eines Feedback-Kanals für Nutzer.

Die folgenden Abschnitte zerlegen diese Schritte in konkrete Entscheidungen. Maßstab ist WCAG-EM 2.0, die Methodik zur Bewertung der WCAG-Konformität, die das W3C am 23. Juli 2026 als Group Note veröffentlicht hat. Sie unterteilt die Bewertung in fünf Schritte: Prüfumfang festlegen, Website explorieren, repräsentative Stichprobe auswählen, Stichprobe prüfen und Ergebnisse berichten.

#Wie der Prüfumfang eines Barrierefreiheits-Audits festgelegt wird

Der erste Schritt nach WCAG-EM umfasst vier Elemente: den Umfang der Website, das angestrebte Konformitätsziel, die Basis der Barrierefreiheitsunterstützung und optionale Zusatzanforderungen. Auf einer WordPress-Website entspricht jedes davon einer konkreten Entscheidung.

Umfang der Website: Es muss festgelegt werden, welche Bereiche in die Prüfung einbezogen werden. Nur die Hauptdomain oder auch eine Subdomain mit dem Shop, der Kundenbereich, die Sprachversionen und Kampagnenseiten? In einer WordPress-Multisite kann jede Website des Netzwerks eigene Themes und Plugins haben, deshalb muss eine ausgeschlossene Website ausdrücklich dokumentiert werden.

Konformitätsziel: Für Dienstleistungen, die unter das EAA fallen, ist das praktische Ziel die Stufe AA. Ob WCAG 2.1 oder 2.2 herangezogen wird, gehört in den Prüfumfang, weil es festlegt, welche Erfolgskriterien geprüft werden. WordPress selbst hat für seinen eigenen Code WCAG 2.2 AA übernommen, wie die Codierstandards zur Barrierefreiheit festhalten.

Basis der Barrierefreiheitsunterstützung: WCAG-EM verlangt festzulegen, auf welchen Kombinationen aus Browsern und assistiven Technologien die Prüfung beruht, etwa NVDA mit Firefox oder Chrome unter Windows, VoiceOver mit Safari unter macOS und iOS sowie TalkBack mit Chrome unter Android. Ohne diese Liste können zwei Audits derselben Website zu unterschiedlichen Ergebnissen kommen, und keines lässt sich wiederholen.

Optionale Zusatzanforderungen: Hierunter fällt alles, was über die Konformität hinausgeht, beispielsweise ausgewählte Kriterien der Stufe AAA oder ein Usability-Test mit Menschen mit Behinderungen.

#Stichprobenauswahl nach der WCAG-EM-Methodik

Im zweiten Schritt von WCAG-EM wird die Website exploriert: häufig genutzte Ansichten, wesentliche Funktionen, Seitentypen und die Technologien, auf die der Inhalt angewiesen ist. Als häufig genutzte Ansichten gelten solche, die die gesamte Website betreffen und meist direkt vom Einstiegspunkt verlinkt sind: Startseite, Hilfe, rechtliche Informationen und Kontakt.

Bei WordPress lohnt sich die Exploration entlang der Template-Hierarchie, weil ein Template Hunderte von URLs erzeugt:

Im dritten Schritt wird die Stichprobe ausgewählt. WCAG-EM kombiniert drei Teile:

• Strukturierte Stichprobe: Umfasst die häufig genutzten Ansichten, die wesentlichen Funktionen und je ein Beispiel jedes Seitentyps.
• Zufallsstichprobe: Gemäß WCAG-EM beträgt sie 10 Prozent der strukturierten Stichprobe und kommt zu dieser hinzu. Bei 30 strukturierten Seiten werden somit 3 zufällig ausgewählte Seiten zusätzlich geprüft.
• Vollständige Prozesse: Gehört eine Seite zu einem Prozess, gelangen alle Schritte dieses Prozesses in die Stichprobe, einschließlich Ausgangspunkt, Standardablauf und wichtiger Verzweigungen.

In einem WooCommerce-Shop besteht der vollständige Kaufprozess aus Warenkorb, Kundendaten, Wahl von Versand und Zahlung, Bestellbestätigung und dem Weg mit einem Validierungsfehler. Bei einem Kontaktformular sind es das leere Formular, das Formular mit Fehlern und die Meldung nach dem Absenden. Ein Audit, das den Fehlerzustand überspringt, überspringt genau die Stelle, an der Screenreader-Nutzer am häufigsten hängen bleiben.

#Was Zufallsstichproben bei Webseiten-Audits aufdecken

Der vierte Schritt von WCAG-EM prüft die ausgewählten Seiten und Prozesse und vergleicht danach die Ergebnisse der strukturierten mit denen der zufälligen Stichprobe. Tauchen auf zufällig ausgewählten Seiten Barrieren auf, die in der strukturierten Stichprobe nicht vorhanden waren, war die Auswahl nicht repräsentativ und muss erweitert werden.

Bei WordPress passiert das meist, wenn die Exploration einen Inhaltstyp übersehen hat: einen älteren Beitrag aus dem Classic Editor, eine mit einem anderen Page Builder gebaute Seite oder ein Plugin, das sein eigenes Widget nur auf einigen Unterseiten einfügt.

Die Methodik setzt außerdem voraus, dass die prüfende Person WCAG 2, assistive Technologien und die Art, wie Menschen mit Behinderungen Websites nutzen, gut kennt. Ein automatisches Werkzeug erfüllt diese Voraussetzung nicht: Es erkennt formale Syntaxfehler und Kontrastmängel, kann aber nicht beurteilen, ob ein Alternativtext das Bild beschreibt oder ob die Fokusreihenfolge in einem Modal sinnvoll ist. Manuelle Tests bleiben daher erforderlich.

#Wie Barrierefreiheits-Korrekturen priorisiert werden sollten

Ein Audit-Bericht listet meist Dutzende Fehler auf. Bei WordPress lässt sich die Reihenfolge der Korrekturen besser nach dem Ort festlegen, an dem ein Fehler entsteht, als nach der Reihenfolge der Liste:

1. Vollständige Prozesse, die das Ziel blockieren: Fehler, die den Abschluss einer Bestellung oder das Absenden eines Formulars verhindern, schließen eine ganze Nutzergruppe vom Dienst aus und kommen deshalb zuerst.
2. Gemeinsame Vorlagenteile: Header, Navigation, Footer, Cookie-Banner und Suche erscheinen auf jeder Seite. Eine Korrektur im Template-Teil oder in der Theme-Datei beseitigt den Fehler auf der gesamten Website.
3. Wiederverwendete Komponenten: Eigene Blöcke, Patterns, Shortcodes und Plugin-Widgets. Hier stellt sich die Frage: korrigieren, durch eine barrierefreie Alternative ersetzen oder entfernen.
4. Redaktionelle Inhalte: Alternativtexte, Überschriften in Beiträgen, Linktexte und PDF-Dateien. Diesen Teil korrigiert die Redaktion, deshalb sollten die Korrekturen von Regeln und Beispielen begleitet werden.

Diese Aufteilung wirkt sich auch auf das Budget aus: Korrekturen aus den Punkten 2 und 3 erfolgen einmal und gelten für Tausende URLs, während Punkt 4 mit dem Umfang der Inhalte wächst.

#Usability-Tests mit Nutzern assistiver Technologien

Ein Audit nach WCAG zeigt, ob die Website die Kriterien erfüllt. Es zeigt nicht, ob sie bequem zu bedienen ist. Das W3C WAI empfiehlt in “Involving Users in Evaluating Web Accessibility”, Menschen mit Behinderungen während der gesamten Arbeit einzubeziehen und nicht erst am Ende, und hält fest, dass informelle Prüfungen während der Entwicklung mehr bringen als nur ein formaler Usability-Test am Projektende.

Daraus ergeben sich konkrete Regeln für die Organisation des Tests:

• Expertenprüfung zuerst: Offensichtliche Barrieren werden vor den Nutzertests beseitigt, damit die Zeit der Teilnehmenden nicht für Probleme verloren geht, die das Audit schon gefunden hat.
• Wenige Personen, unterschiedliche Bedürfnisse: Das WAI empfiehlt, einige Menschen mit Behinderungen einzubeziehen und, je nach Zielgruppe, auch ältere Nutzer. Der Erfahrungsgrad sollte zur Zielgruppe passen: Bei einem öffentlichen Dienst zählen auch Screenreader-Einsteiger.
• Lautes Denken: Die Teilnehmenden sagen, was sie tun und was sie erwarten, und die Testleitung notiert, wo eine Barriere einen Fehler auslöst.
• Vorsichtige Schlüsse: Das WAI warnt: “Gehen Sie nicht davon aus, dass die Rückmeldung einer Person mit Behinderung für alle Menschen mit Behinderungen gilt” (W3C WAI, eigene Übersetzung). Das Problem kann im Inhalt, im Browser, in der assistiven Technologie oder darin liegen, wie vertraut die Person mit ihr ist.

Der Nutzertest ersetzt das Audit nicht. Das WAI schreibt, dass die Einbeziehung von Nutzern allein nicht feststellen kann, ob eine Website barrierefrei ist, deshalb wird sie mit der Prüfung nach WCAG kombiniert. In einem WordPress-Projekt ist ein guter Zeitpunkt für den Test, wenn die Template-Korrekturen bereits auf Staging liegen und der Inhalt echt ist, keine Platzhalter.

#Was eine Erklärung zur Barrierefreiheit enthalten muss

Das W3C WAI nennt im Leitfaden zu Erklärungen zur Barrierefreiheit ein Minimum: das Bekenntnis zur Barrierefreiheit, die angewandte Norm (zum Beispiel WCAG 2.2) und Kontaktdaten für den Fall, dass Probleme auftreten. Empfohlen werden außerdem bekannte Einschränkungen, von der Organisation ergriffene Maßnahmen, technische Voraussetzungen, die Umgebungen, in denen der Inhalt getestet wurde, und Verweise auf die geltenden Rechtsvorschriften.

Der kostenlose W3C Accessibility Statement Generator führt durch diese Felder. Am meisten Arbeit macht der Abschnitt zu Einschränkungen, weil der Generator für jedes bekannte Problem fünf Angaben verlangt: welchen Teil des Inhalts es betrifft, worin es besteht, warum es auftritt, was die Organisation dagegen tut und was Nutzer in der Zwischenzeit tun können. Diesen Abschnitt ehrlich auszufüllen erfordert die Audit-Ergebnisse, deshalb wird die Erklärung nach der Prüfung geschrieben und nicht davor. Der Generator hat außerdem Felder für den Konformitätsstatus (vollständig konform, teilweise konform, nicht konform, nicht bewertet) und für die Art der Bewertung: Selbstbewertung oder externe Bewertung.

Für Dienstleistungen, die unter das EAA fallen, kommt eine Pflicht aus der Richtlinie selbst hinzu. Artikel 13 Absatz 2 der Richtlinie (EU) 2019/882 verlangt, dass der Dienstleistungserbringer die Informationen nach Anhang V erstellt und erläutert, wie die Dienstleistung die Barrierefreiheitsanforderungen erfüllt. Die Informationen müssen der Öffentlichkeit schriftlich und mündlich zur Verfügung stehen, auch in einer für Menschen mit Behinderungen zugänglichen Form, und so lange aufbewahrt werden, wie die Dienstleistung angeboten wird. Nach Anhang V gehören die Informationen in die allgemeinen Geschäftsbedingungen oder ein gleichwertiges Dokument und enthalten, soweit zutreffend:

• eine allgemeine Beschreibung der Dienstleistung in barrierefreien Formaten,
• die Beschreibungen und Erläuterungen, die zum Verständnis der Funktionsweise der Dienstleistung erforderlich sind,
• eine Beschreibung, wie die Dienstleistung die Barrierefreiheitsanforderungen aus Anhang I erfüllt.

Für einen Shop auf WordPress bedeutet das in der Regel zwei Dokumente: eine Seite mit der Erklärung zur Barrierefreiheit für die Nutzer und einen Abschnitt in den AGB mit den nach Anhang V erforderlichen Informationen. Beide sollten im Footer verlinkt sein, damit sie von jeder Seite aus erreichbar sind.

#Wie die Barrierefreiheit langfristig gesichert wird

Die Barrierefreiheit einer WordPress-Website ändert sich mit jedem Update von Theme und Plugins und mit jedem neuen Beitrag. Die Richtlinie sieht das in Artikel 13 Absatz 3 vor: Der Dienstleistungserbringer muss Verfahren haben, die die Konformität der Dienstleistung sicherstellen, und Änderungen an der Dienstleistung, an den Anforderungen und an den Normen, auf die er sich beruft, berücksichtigen. Absatz 4 ergänzt, dass er bei Nichtkonformität Korrekturmaßnahmen ergreift und die zuständigen nationalen Behörden unverzüglich informiert.

In der Praxis hat dieses Verfahren auf einer WordPress-Website einige feste Bestandteile:

• Erneute Prüfung der Stichprobe nach Änderungen: Die Audit-Stichprobe (häufig genutzte Ansichten, Seitentypen, vollständige Prozesse) wird zur Checkliste nach einem Update des Themes, der Formular- oder Shop-Plugins und nach einer Änderung an einem Template-Teil.
• Dokumentation der Ergebnisse: WCAG-EM empfiehlt im fünften Schritt, die Ergebnisse jedes Schritts zu dokumentieren, optional auch als maschinenlesbaren Bericht. Das kostenlose WCAG-EM Report Tool führt durch die Schritte der Methodik und erzeugt einen Bericht, der sich mit dem nächsten Audit vergleichen lässt.
• Regeln für die Redaktion: Die meisten neuen Fehler nach der Umsetzung stammen aus Inhalten: fehlender Alternativtext, eine übersprungene Überschriftenebene, ein als Bild eingescanntes PDF.
• Bearbeitung von Anfragen: Der Kontaktkanal aus der Erklärung braucht eine verantwortliche Person und eine Antwortfrist, denn der W3C-Generator fragt genau danach: nach der typischen Antwortdauer.

Beruft sich ein Unternehmen auf die unverhältnismäßige Belastung nach Artikel 14, muss es die Beurteilung dokumentieren und die relevanten Ergebnisse fünf Jahre lang aufbewahren, gerechnet ab der letzten Erbringung der Dienstleistung. Ein weiterer Grund, Audit-Ergebnisse und Entscheidungen über Korrekturen an einem Ort zu sammeln.

#Technische Begleitung bei der Umsetzung der europäischen Vorgaben

Die Umsetzung barrierefreier Websites erfordert Kenntnisse der WordPress-Architektur, der Frontend-Entwicklung und assistiver Technologien:

• WordPress-Spezialisierung: Wir begleiten Unternehmen bei der technischen Überarbeitung von individuellen Themes, WooCommerce-Shops und Unternehmensportalen.
• Strukturierte Methodik: Unsere Audits basieren auf der W3C-Methodik WCAG-EM und liefern praxistaugliche Handlungsempfehlungen.
• Langfristige Sicherheit: Wir unterstützen bei der Erstellung von Erklärungen zur Barrierefreiheit und schulen Redaktionsteams.

Die Frist ist bereits abgelaufen. Sprechen Sie mit unserem Team über Ihre Barrierefreiheitsstrategie. Informieren Sie sich über unsere Leistungen als WordPress-Entwickler oder erfahren Sie, wie wir als WooCommerce-Entwickler Shops für alle Kunden bedienbar machen.