WCAG & BFSG · Recht & Pflicht (privat)
Barrierefreiheit nach Plattform
Die häufigste Frage nach dem BFSG lautet nicht „Was verlangt die WCAG?“, sondern „Was heißt das für meine WordPress-Seite?“. Diese Übersicht ordnet die fünf verbreiteten Systeme nach derselben Logik: Was liefert der Kern schon, wo liegt dein Hebel, und welche Fehler sind für dieses System typisch.
Das Wichtigste in Kürze
- Kein System macht eine Website barrierefrei. Jedes liefert eine Grundlage; über die ausgelieferte Seite entscheiden Theme, Erweiterungen, Farben und Inhalte.
- Der rechtliche Maßstab ist überall derselbe: WCAG Stufe AA über die EN 301 549 – im privaten Sektor über das BFSG, im öffentlichen über BITV und Landesrecht. Stand August 2026 ist die Fassung V3.2.1 (2021) maßgeblich, die auf WCAG 2.1 AA verweist; eine Revision mit WCAG 2.2 ist angekündigt, aber erst mit der Nennung im EU-Amtsblatt verbindlich.
- Selbst gehostet heißt reparierbar. Bei WordPress, Shopware und TYPO3 lässt sich jede Zeile Markup überschreiben – der Aufwand liegt im Template, die Wirkung auf allen Seiten.
- Gehostet heißt begrenzt. Bei Shopify und den Baukästen endet dein Einfluss an der Systemgrenze. Was dort bricht, wird zum Ticket beim Anbieter und zum Eintrag in deiner Erklärung.
- Shops sind der schärfere Fall. Ein Onlineshop ist als Dienstleistung im elektronischen Geschäftsverkehr ausdrücklich vom BFSG erfasst; eine reine Informationsseite häufig nicht.
- Über alle Systeme hinweg gilt: Die meisten Befunde einer Inhaltsprüfung stammen aus Redaktionsentscheidungen – Überschriftenebenen, Alt-Texte, Linktexte, Farbwahl.
- Overlay-Werkzeuge sind in keinem System ein Nachweis. Weder BFSG noch EN 301 549 kennen den Beleg „Widget installiert“.
Kein Rechtsrat. Ob dein Angebot erfasst ist, klärt der BFSG-Schnelltest in vier Fragen; den Einzelfall klärt eine juristische Prüfung.
Die fünf Systeme im Überblick
| System | Kontrolle über das Markup | Größte Fehlerquelle | Typischer erster Schritt |
|---|---|---|---|
| WordPress | vollständig | Page-Builder und Plugins | Theme prüfen, Builder-Nutzung begrenzen |
| Shopware | vollständig (Twig-Overrides) | Checkout-Strecke und Plugins | Kauf per Tastatur durchspielen |
| TYPO3 | vollständig (Fluid) | eigene Templates und Redaktion | Fluid-Partials prüfen |
| Shopify | Theme ja, Checkout kaum | Apps im Frontend | App-Bestand ausmisten |
| Baukästen | gering (außer Webflow) | Layout-Reihenfolge, Text in Bildern | Fokusreihenfolge prüfen |
Was in jedem System gleich bleibt
Bei aller Verschiedenheit finden sich in Prüfungen immer wieder dieselben fünf Befunde, unabhängig vom System. Wer sie abarbeitet, erledigt einen erheblichen Teil der Arbeit:
- Fehlende oder nichtssagende Alt-Texte. Jedes System hat ein Feld dafür; es wird überall gleich selten gefüllt. Siehe Alt-Texte richtig schreiben.
- Zu schwacher Textkontrast. Er entsteht bei der Farbwahl, nicht im Systemkern – nachmessen mit dem Kontrast-Check.
- Überschriften nach Optik statt nach Bedeutung. Der Editor bietet die Ebene an, die Redaktion wählt die Größe. Siehe Überschriften-Hierarchie.
- Unsichtbarer Fokus. Ein
outline: noneim Theme reicht, um Tastaturbedienung unbrauchbar zu machen (2.4.7). - Formularfehler ohne Klartext am Feld. Siehe Fehlermeldungen barrierefrei.
Diese fünf sind auch der Grund, warum ein Systemwechsel selten die Lösung ist: Sie wandern mit.
Selbst gehostet oder gehostet – der entscheidende Unterschied
Die praktisch wichtigste Trennlinie verläuft nicht zwischen CMS und Shop, sondern zwischen „Ich kann das Markup ändern“ und „Ich kann es nicht“.
Selbst gehostet (WordPress, Shopware, TYPO3): Jeder Befund ist grundsätzlich behebbar. Fehlt einem Icon-Button der Name, ist das ein Template-Override. Der Aufwand fällt einmal an und wirkt auf allen Seiten. Der Preis dafür ist, dass niemand anders sich kümmert – auch nicht um Regressionen nach Updates.
Gehostet (Shopify, Wix, Squarespace, Jimdo): Ein Teil der Oberfläche gehört dem Anbieter. Das kann von Vorteil sein, weil zentrale Bausteine gepflegt werden. Es heißt aber auch: Was dort bricht, kannst du nur melden. Dein Umgang damit besteht aus drei Schritten – prüfen, melden, im Angebot benennen.
Webflow liegt zwischen den Welten: gehostet, aber mit voller Kontrolle über Tags, Attribute und Stile. Wer dort baut, trägt dieselbe Verantwortung wie bei handgeschriebenem Code.
Welches System soll ich wählen?
Wenn Barrierefreiheit eine Anforderung ist, würde ich nach dieser Reihenfolge entscheiden – die Systemfrage kommt darin erst an dritter Stelle:
- Was ist das Angebot? Verkauf, Buchung oder Vertragsabschluss macht dich mit hoher Wahrscheinlichkeit BFSG-pflichtig. Eine reine Informationsseite oft nicht – geklärt im BFSG-Schnelltest.
- Wer pflegt die Seite? Systeme mit strengem Block-Modell schützen die Redaktion vor Strukturfehlern; frei positionierende Editoren laden dazu ein.
- Wie viel Kontrolle brauche ich? Je komplexer die Bedienoberfläche – Filter, Konto, Buchung –, desto wichtiger ist der Zugriff aufs Markup.
- Wer prüft am Ende? Im öffentlichen Sektor ein BITV-Test durch eine Prüfstelle. Dann gehört ein System dazu, dessen Ausgabe man vollständig beherrscht.
Was ein Wechsel oder eine Nachbesserung kostet, ordnet Was kostet eine barrierefreie Website? ein.
Häufige Fragen
Gibt es ein barrierefreies CMS?
Nein, und die Frage führt in die Irre. Systeme liefern Grundlagen unterschiedlicher Qualität; über die ausgelieferte Seite entscheiden Theme, Erweiterungen, Farben und Inhalte. Ein sehr gutes System mit einem schlechten Theme ergibt eine schlechte Seite – und umgekehrt.
Muss ich mein System wechseln, um konform zu werden?
Meistens nicht. Die häufigsten Befunde – Alt-Texte, Kontraste, Überschriften, Fokus, Formularfehler – hängen nicht am System. Ein Wechsel lohnt sich, wenn der Kern selbst im Weg steht: etwa wenn sich Überschriftenebenen nicht steuern lassen oder ein Page-Builder das Markup unbrauchbar macht.
Wer haftet, wenn eine zugekaufte Erweiterung nicht barrierefrei ist?
Verpflichtet ist der Anbieter der Dienstleistung, also du. Dass eine Komponente zugekauft ist, entlastet nicht – sie gehört zu deinem Angebot. Praktisch heißt das: Barrierefreiheit gehört in die Auswahlkriterien, und die Konformitätsaussage des Anbieters gehört abgelegt.
Was mache ich mit Barrieren, die das System nicht beheben lässt?
Melden, eine Ausweichlösung anbieten und den Punkt in der Barrierefreiheitserklärung benennen. Eine Erklärung, die bekannte Mängel verschweigt, ist selbst ein Mangel.
Hilft ein Accessibility-Overlay, bis das System besser wird?
Nein. Overlays legen eine zweite Bedienoberfläche über eine kaputte erste, kollidieren mit vorhandener Hilfstechnik und gelten weder nach BFSG noch nach EN 301 549 als Nachweis. Eine echte Ausweichlösung – etwa ein erreichbares Kontaktformular neben einem unbedienbaren Buchungs-Widget – hilft dagegen sofort.
Verwandte Themen
- BFSG-Checkliste für Websites – der systematische Durchgang durch alle Pflichten
- Barrierefreiheit in Onlineshops – die systemunabhängigen Shop-Anforderungen
- Barrierefreiheit selbst testen – der Prüfablauf, auf den alle Plattformseiten verweisen
- Prüfwerkzeuge im Vergleich – was axe, WAVE, Lighthouse und der BITV-Test jeweils finden
- Rechtsprechung & Bußgelder zum BFSG – was bei Verstößen tatsächlich passiert
Quellen
- Barrierefreiheitsstärkungsgesetz (BFSG) (Gesetzestext – Anwendungsbereich und Pflichten)
- EN 301 549 (ETSI – der harmonisierte europäische Standard)
- Interim Repairs to Inaccessible Content (W3C WAI – Umgang mit systembedingten Barrieren)