Barrierefreiheitserklärung für WordPress: Vorlage + EN-301-549-Mapping

#Barrierefreiheitserklärung für WordPress: Vorlage + EN-301-549-Mapping

Eine Barrierefreiheitserklärung ist ein eigenständiges rechtliches Ergebnis, getrennt von einem WCAG-Audit. Man kann auf einer WordPress-Website jeden automatisierten Scan bestehen und trotzdem nicht BFSG- oder EAA-konform sein, weil beide die Erklärung selbst verlangen: einen veröffentlichten Konformitätsstatus, die Norm, gegen die getestet wurde, eine Liste bekannter Einschränkungen und einen funktionierenden Feedbackmechanismus, den eine besuchende Person nutzen kann, um eine Beschwerde einzureichen. Dieser Artikel ist ein ergänzender Baustein im Compliance-Stack aus WCAG 2.2, BFSG und europäischem Rechtsakt zur Barrierefreiheit, fokussiert speziell auf das Erklärungsdokument und darauf, wie seine Abschnitte auf EN 301 549 gemappt werden - die europäische Norm, die Vergabeteams tatsächlich zitieren.

#Was Sie in Kürze veröffentlichen müssen

• Eine eigenständige, im Footer verlinkte Seite, kein Absatz in Ihrer Datenschutzerklärung.
• Einen Konformitätsstatus: vollständig, teilweise mit benannten Ausnahmen, oder nicht konform.
• Die Norm, gegen die getestet wurde: in der Praxis WCAG 2.2 AA, referenziert gegen EN 301 549 für Vergabeadressaten.
• Eine Liste bekannter Einschränkungen mit, wo möglich, einem Sanierungsdatum.
• Einen Feedback-Kontakt, der tatsächlich ein überwachtes Postfach erreicht, plus einen Durchsetzungs- oder Eskalationsweg.
• Ein Erstellungsdatum und einen Überprüfungsrhythmus, denn “wir haben das 2023 einmal getestet” ist keine aktuelle Erklärung.

Nichts davon ersetzt ein technisches Audit. Es dokumentiert dessen Ergebnis. Wenn Sie noch kein WCAG-2.2-AA-Audit durchgeführt haben, wird die Erklärung entweder Konformität überbehaupten oder wie ein Platzhalter wirken - und beide Ergebnisse ziehen mehr Aufmerksamkeit auf sich als gar keine Erklärung.

#Wann eine Barrierefreiheitserklärung in der EU verpflichtend ist

Drei sich überschneidende Rechtsgrundlagen setzen eine Barrierefreiheitserklärung auf die Pflichtenliste eines WordPress-Betreibers, und sie richten sich nicht alle an dieselbe Zielgruppe.

Die Richtlinie (EU) 2016/2102, die Web-Zugänglichkeitsrichtlinie, verpflichtet öffentliche Stellen, für jede Website und mobile App, die sie betreiben, eine Barrierefreiheitserklärung zu veröffentlichen und regelmäßig zu aktualisieren. Diese geht dem europäischen Rechtsakt zur Barrierefreiheit voran und gilt unabhängig vom Sektor; eine kommunale WordPress-Website, der Blog einer öffentlichen Universität, das Pressenportal einer Behörde sind alle im Anwendungsbereich, unabhängig von allem Weiteren.

Der europäische Rechtsakt zur Barrierefreiheit (Richtlinie 2019/882), der seit dem 2025-06-28 gilt, erstreckt vergleichbare Pflichten auf private Betreiber bestimmter Produkt- und Dienstleistungskategorien: E-Commerce, Bankdienstleistungen, Verkehr, E-Books und weitere, die in Anhang I der Richtlinie aufgeführt sind. Er schreibt nicht das exakte Erklärungsformat vor, das die Richtlinie 2016/2102 verlangt, aber die Umsetzungen der Mitgliedstaaten fordern generell Konformitätsdokumentation und einen funktionierenden Beschwerdekanal als Teil der Marktüberwachung.

Nationale Umsetzungen füllen die operativen Details. Das deutsche BFSG trat am 28. Juni 2025 in Kraft, am selben Tag wie der EAA EU-weit, und verlangt von betroffenen Unternehmen, Informationen zur Barrierefreiheit verfügbar zu machen. Seine Durchsetzungsstruktur - Marktüberwachungsbehörden der Länder plus die Schlichtungsstelle BGG auf Bundesebene - erwartet einen dokumentierten Prozess für den Umgang mit Beschwerden, was in der Praxis heißt: eine veröffentlichte Erklärung ist der einfachste Weg, um zu zeigen, dass dieser Prozess existiert, bevor überhaupt eine Beschwerde eingeht. Paragraph 37 BFSG sieht Bußgelder im oberen fünfstelligen Eurobereich pro Verstoß vor, verhängt durch die zuständige Landesbehörde.

Die vor dem Verfassen wichtigen Ausnahmen: Kleinstunternehmen (unter 10 Beschäftigte, Jahresumsatz oder Bilanzsumme unter 2 Mio. EUR) sind von mehreren Dienstleistungspflichten des EAA befreit, wobei die Ausnahme für Produkthersteller enger gefasst ist. Öffentliche Stellen erhalten nach der Richtlinie 2016/2102 keine Größenausnahme. Ansprüche auf unverhältnismäßige Belastung existieren in beiden Regimen, erfordern aber eine dokumentierte Bewertung, keine Fußnote mit “nicht anwendbar”.

Der Pillar-Artikel zu WCAG 2.2, BFSG und dem europäischen Rechtsakt zur Barrierefreiheit deckt den vollständigen Compliance-Stack ab, einschließlich des Audit-Rhythmus, der den in dieser Erklärung dokumentierten Konformitätsstatus produziert.

#EN 301 549 vs. WCAG 2.2 AA: was Vergabestellen tatsächlich verlangen

WCAG 2.2 AA ist das, wogegen Ihr Entwicklungsteam testet. EN 301 549 ist das, was eine Vergabestelle, ein Ausschreibungsdokument oder eine Prüfung des öffentlichen Sektors zitiert, weil es die harmonisierte europäische Norm für ICT-Barrierefreiheit generell ist, nicht nur für Web-Inhalte.

Die derzeit rechtlich gültige Fassung ist EN 301 549 V3.2.1, veröffentlicht im März 2021 und im Amtsblatt der EU zitiert auf Grundlage der Richtlinie 2016/2102 über den Durchführungsbeschluss (EU) 2021/1339 der Kommission. Ihr Web-Kapitel, Kapitel 9, übernimmt per Verweis die Erfolgskriterien von WCAG 2.1 Stufe A und AA. Eine Überarbeitung mit WCAG 2.2 wird in der gemeinsamen ETSI/CEN/CENELEC-Fachgruppe erarbeitet, mit einer für 2026 erwarteten Veröffentlichung im Rahmen des Normungsauftrags M/587 der Europäischen Kommission, ist aber noch nicht die im Amtsblatt zitierte Fassung.

Das schafft eine praktische Lücke, die Vergabedokumente selten klar auflösen: Die rechtlich referenzierte Basis ist WCAG 2.1 AA, während das aktuelle Best-Practice-Ziel, an dem sich die meisten Agenturen (auch wir) tatsächlich orientieren, WCAG 2.2 AA ist. Da 2.2 eine strikte Obermenge von 2.1 mit neun zusätzlichen Erfolgskriterien ist, erfüllt das Testen und Dokumentieren gegen 2.2 AA auch die 2.1-AA-Basis, auf die EN 301 549 derzeit verweist. Es besteht kein Versionsrisiko, wenn man auf den neueren Standard baut; das Risiko liegt umgekehrt, wenn man nur auf 2.1 baut und die EN-301-549-Überarbeitung mitten im Vertrag veröffentlicht wird.

Neben dem Web-Kapitel hat EN 301 549 elf weitere Kapitel. Die drei, die für ein typisches WordPress-Deployment über den Web-Inhalt hinaus wichtig sind:

• Kapitel 10, Nicht-Web-Dokumente. PDFs, Tabellen und Präsentationen, die über die Website veröffentlicht werden (Preislisten, Geschäftsberichte, Ausschreibungsunterlagen), brauchen korrekte Tagging, Lesereihenfolge und barrierefreie Tabellen, unabhängig davon, wie barrierefrei die umgebende Seite selbst ist.
• Kapitel 11, Software. Relevant, wenn das WordPress-Backend selbst das zu bewertende Produkt ist, etwa wenn ein Redaktionsteam des öffentlichen Sektors den Block-Editor als Autorentool nutzt, oder ein individuelles Plugin ein Formular-Interface für Endnutzerinnen bereitstellt.
• Kapitel 12, Dokumentation und Support-Dienste. Hilfeseiten, Onboarding-Guides und von der Website verlinkte Support-Kanäle sollen die gleiche Barrierefreiheits-Messlatte erfüllen wie der Hauptinhalt, und die Support-Kommunikation selbst muss über mehr als einen Kanal verfügbar sein.

#Vorlagenabschnitte mit copy-fertigen Überschriften

Die folgende Abschnittsreihenfolge ist die Struktur, die in den meisten EU-Barrierefreiheitserklärungen auftaucht, die auf dem EN-301-549-/EAA-/BFSG-Rahmen aufbauen. Sie ist illustrativ: Füllen Sie sie mit Ihren tatsächlichen Audit-Ergebnissen, nicht mit Platzhaltertext, und lassen Sie sie von der für die Compliance-Freigabe verantwortlichen Stelle in Ihrer Organisation prüfen, bevor Sie sie veröffentlichen.

# Barrierefreiheitserklärung für [Name der Website]

## Konformitätsstatus
[Name der Website] ist [vollständig konform / teilweise konform / nicht
konform] mit WCAG 2.2 Stufe AA, bewertet anhand der in EN 301 549
referenzierten Anforderungen. [Wählen Sie eines:]
- Vollständige Konformität bedeutet, dass der Inhalt die Norm ohne
  Ausnahmen vollständig erfüllt.
- Teilweise Konformität bedeutet, dass Teile des Inhalts die Norm nicht
  vollständig erfüllen, aufgelistet unter "Bekannte Einschränkungen"
  unten.

## Angewandte Norm
Diese Erklärung basiert auf einer Selbsteinschätzung / einer Bewertung,
durchgeführt von [Name oder Funktion der bewertenden Person] am [Datum],
gegen:
- Web Content Accessibility Guidelines (WCAG) 2.2, Stufe AA
- EN 301 549, [Version], Kapitel 9 (Web)
[Kapitel 10, 11, 12 hier nur aufführen, wenn auch Nicht-Web-Dokumente,
Software oder Support-Dienste bewertet wurden.]

## Bekannte Einschränkungen
Folgende Inhalte sind noch nicht vollständig barrierefrei:
- [Konkrete Einschränkung, z. B. "das eingebettete Buchungswidget auf
  /kontakt/ kann nicht allein per Tastatur bedient werden"], betrifft
  [welches Erfolgskriterium], Sanierungsziel: [Datum oder "in Prüfung"].
- [Für jedes bekannte Problem wiederholen. Fassen Sie nicht mehrere
  Probleme in einer vagen Zeile zusammen; listen Sie sie einzeln auf.]

## Erstellung dieser Erklärung
Diese Erklärung wurde am [Datum] erstellt und zuletzt am [Datum]
überprüft. Sie basiert auf [Selbsteinschätzung / Audit durch Dritte] und
deckt [Umfang: z. B. "die öffentlichen Seiten unter example.com,
ausgenommen eingebetteter Inhalte Dritter"] ab.

## Feedback und Kontaktinformationen
Wenn Sie auf eine Barriere auf dieser Website stoßen, kontaktieren Sie
uns:
- E-Mail: [überwachte Adresse]
- [Optional: Telefon, URL des Kontaktformulars]
Wir bemühen uns, innerhalb von [X] Werktagen zu antworten.

## Durchsetzungsverfahren
Wenn Sie mit unserer Antwort nicht zufrieden sind, können Sie
eskalieren an:
[Nationale Durchsetzungs- oder Streitbeilegungsstelle, mit URL,
zuständig für die Jurisdiktion, in der der Betreiber ansässig ist oder
tätig ist.]

## Technische Spezifikationen
Diese Website stützt sich für die Konformität auf folgende
Technologien: HTML, CSS, JavaScript, WAI-ARIA.

Zwei Abschnitte verdienen mehr Sorgfalt, als eine generische Vorlage leisten kann. Bekannte Einschränkungen ist der Abschnitt, den die meisten Erklärungen falsch machen, entweder indem sie ihn ganz weglassen (volle Konformität behaupten, während ein automatisierter Scan Fehler zeigt) oder indem sie ihn so vage formulieren, dass er keinen Beleg für eine tatsächliche Bewertung liefert. Durchsetzungsverfahren braucht ein reales Ziel, nicht “kontaktieren Sie Ihre nationale Behörde”, denn der Sinn des Abschnitts ist, dass eine unzufriedene besuchende Person ohne weitere Recherche handeln kann.

#Mapping-Tabelle: EN-301-549-Anforderung zu WordPress-Umsetzung

Kapitel 4 von EN 301 549 legt funktionale Leistungsanforderungen fest (Nutzung ohne Sehvermögen, Nutzung mit eingeschränkter manueller Geschicklichkeit und Ähnliches), die verwendet werden, wenn ein bestimmtes Erfolgskriterium sich nicht saubereinem neuartigen Interface zuordnen lässt. Für ein Standard-WordPress-Frontend findet die meiste Mapping-Arbeit in den Kapiteln 9, 10, 11 und 12 statt.

Diese Tabelle ist das Rückgrat eines VPAT-artigen Konformitätsberichts, falls ein Kunde aus dem öffentlichen Sektor danach fragt; jede Zeile wird zu einem Posten mit Status bestanden, teilweise oder nicht bestanden, sobald Ihr Audit gelaufen ist.

#Wo die Erklärung auf WordPress veröffentlicht wird: Footer, eigene Seite, Schema

Footer-Link, auf jeder Seite. Das am häufigsten geprüfte Signal in einer Durchsetzungsprüfung ist, ob die Erklärung von jeder Stelle der Website ohne Suche erreichbar ist. Ein Footer-Link, neben Datenschutzerklärung und AGB, erfüllt das ohne zusätzliche Entwicklungsarbeit. Wird der Footer Ihres Themes über einen Widget-Bereich oder ein globales Footer-Template-Teil verwaltet, fügen Sie den Link dort einmal hinzu, statt pro Seite.

Eigenständige Seite, eigene URL. Fassen Sie die Erklärung nicht in die Datenschutzerklärung oder die AGB. Geben Sie ihr eine eigene URL wie /barrierefreiheitserklaerung/, eingerichtet über eine normale WordPress-Seite (oder einen MDX-Content-Eintrag, in diesem Stack), damit sie unabhängig von anderem rechtlichen Content überprüft und versioniert werden kann.

Strukturierte Daten, optional aber nützlich für Vergabeprüfungen. Ein WebPage-JSON-LD-Block auf der Erklärungsseite, dessen dateModified mit Ihrem letzten Überprüfungsdatum übereinstimmt, gibt einem automatisierten Crawler oder einem Vergabe-Checklist-Tool eine maschinenlesbare Bestätigung, dass die Erklärung existiert und wann sie zuletzt angefasst wurde. Das ersetzt nicht den menschenlesbaren Inhalt; es ist eine kleine Ergänzung, die Unklarheit beseitigt, wenn jemand einen automatisierten Compliance-Scan gegen Ihre Domain durchführt.

Überprüfungsrhythmus, in der Erklärung selbst dokumentiert. Geben Sie an, wie oft die Erklärung überprüft wird (jährlich oder nach jedem größeren Redesign) und halten Sie sich an diesen Rhythmus. Eine vor drei Jahren datierte Erklärung mit einem “zuletzt überprüft”-Feld, das niemand angefasst hat, ist eines der Ersten, was eine Prüferin oder die Rechtsabteilung eines Wettbewerbers markieren wird.

#Beschwerde- und Feedback-Workflow

Der Feedback-Mechanismus ist der Teil von BFSG und EAA, den ein reines Frontend-Audit nicht erfüllen kann, weil er eine Prozessanforderung ist, keine Code-Anforderung.

1. Annahme. Eine überwachte E-Mail-Adresse oder ein Kontaktformular, getrennt vom allgemeinen Support, damit Barrierefreiheitsbeschwerden nicht in einer generischen Warteschlange untergehen. Leiten Sie sie an die Person weiter, die für Compliance verantwortlich ist, nicht nur an die Webmasterin.
2. Bestätigung. Bestätigen Sie den Eingang innerhalb eines angegebenen Zeitfensters (üblicherweise wenige Werktage). Die Bestätigung sollte die gemeldete Barriere wiedergeben, damit die besuchende Person weiß, dass sie korrekt verstanden wurde.
3. Untersuchung. Reproduzieren Sie die Barriere, prüfen Sie sie gegen das relevante WCAG-Erfolgskriterium und dokumentieren Sie das Ergebnis, egal ob es eine bereits in der Erklärung gelistete bekannte Einschränkung bestätigt oder eine neue aufdeckt.
4. Antwort und Sanierungsplan. Teilen Sie der besuchenden Person mit, was gefunden wurde und, falls es sich um eine echte Barriere handelt, wann sie behoben wird oder warum nicht (unverhältnismäßige Belastung, Inhalte Dritter außerhalb Ihrer Kontrolle und Ähnliches, dokumentiert statt nur behauptet).
5. Eskalationsweg. Ist die besuchende Person nicht zufrieden, verweisen Sie sie an die zuständige Durchsetzungs- oder Streitbeilegungsstelle. In Deutschland ist das für Bundesbelange die Schlichtungsstelle BGG, mit länderspezifischen Äquivalenten für regionale öffentliche Stellen; andere Mitgliedstaaten benennen ihre eigene Marktüberwachungsbehörde nach dem EAA.
6. Interne Protokollierung. Führen Sie ein Protokoll jeder eingegangenen Beschwerde und ihrer Lösung. Dieses Protokoll ist es, das “wir haben einen Prozess” von einer Behauptung in der Erklärung zu einem Beleg bei einem Audit oder einer Durchsetzungsanfrage macht.

Keiner dieser Schritte erfordert neue Software. Ein gemeinsam genutztes Postfach, eine einfache Tabelle oder ein Ticket-Tag und eine benannte verantwortliche Person decken die Anforderung für die meisten WordPress-Betreiber ab. Wichtig ist, dass der Prozess in der Erklärung dokumentiert ist und beim Eintreffen einer Beschwerde tatsächlich befolgt wird, nicht rückwirkend erfunden, nachdem eine eingetroffen ist.

#Wie das in den EU-Konformitätsaudit passt

Eine Barrierefreiheitserklärung ist ein Ergebnis unter mehreren innerhalb eines breiteren EU-Konformitätsaudits für WordPress, das auch NIS2/DORA-Lieferantenmapping und AI-Act-Pflichten zur Inhaltskennzeichnung abdeckt, wo relevant. Innerhalb des Barrierefreiheitsteils dieses Audits ist die Erklärung das Ergebnis, das einen technischen WCAG-2.2-AA-Bericht in etwas verwandelt, worauf eine Compliance-Verantwortliche, eine Prüferin der öffentlichen Vergabe oder eine Durchsetzungsstelle handeln kann, ohne das zugrunde liegende Scan-Ergebnis zu lesen.

Die Abfolge, die eine belastbare Erklärung produziert, in der Reihenfolge, in der wir sie durchführen:

1. Technisches WCAG-2.2-AA-Audit, automatisiert plus manuell, über die im WCAG/BFSG/EAA-Compliance-Stack beschriebene repräsentative Seitenauswahl.
2. Lückenliste, zugeordnet zu konkreten Erfolgskriterien, keine generische Zusammenfassung “einige Probleme gefunden”, weil der Abschnitt “Bekannte Einschränkungen” der Erklärung konkrete, benannte Posten braucht.
3. Entwurf der Erklärung anhand der oben beschriebenen Abschnittsstruktur, gefüllt mit dem tatsächlichen Audit-Ergebnis statt einer Platzhalter-Konformitätsbehauptung.
4. Einrichtung des Feedback-Workflows, verdrahtet mit einem echten Postfach und einer benannten verantwortlichen Person, getestet mit einer Dummy-Beschwerde vor der Veröffentlichung.
5. Veröffentlichung, im Footer verlinkt, auf einer eigenen URL, mit einem für den nächsten Zyklus festgelegten Überprüfungsdatum.

Wenn Sie das als Teil eines breiteren EAA/WCAG-Readiness-Projekts durchführen, ist der Überblick zum europäischen Rechtsakt zur Barrierefreiheit und WCAG der Einstiegspunkt für Fragen zum Anwendungsbereich (wer ist befreit, was bedeutet “auf den Markt gebracht” bei einem Dienstleistungsvertrag), während dieser Artikel speziell das Erklärungsdokument abdeckt, sobald das zugrunde liegende Audit erledigt ist.

#Weiterführende Artikel im Cluster

• Pillar: WCAG 2.2, BFSG und der europäische Rechtsakt zur Barrierefreiheit: der Compliance-Stack 2026 für WordPress
• Europäisches Barrierefreiheitsgesetz und WCAG 2.1: digitale Barrierefreiheit richtig umsetzen
• EU-Konformitätsaudit für WordPress: Barrierefreiheit, NIS2/DORA, AI Act