Barrierefreie Websites nach WCAG, BFSG und EAA: Was Unternehmen jetzt umsetzen müssen

Jetzt beraten lassen!

Seit dem 28. Juni 2025 ist digitale Barrierefreiheit für weite Teile der Privatwirtschaft keine Kür mehr, sondern Pflicht. Der European Accessibility Act und seine nationalen Umsetzungen – in Deutschland das BFSG, in Österreich das BaFG – haben aus einem Nice‑to‑have eine gesetzliche Anforderung gemacht. Damit hat sich die eigentliche Frage verschoben: Es geht längst nicht mehr darum, ob eine Website barrierefrei sein muss, sondern darum, wie Unternehmen das technisch sauber umsetzen – und dauerhaft halten.

Genau hier setzt dieser Beitrag an. Er erklärt kompakt, was gilt, gibt eine erste Orientierung zur Frage „Bin ich überhaupt betroffen?", macht WCAG Level AA als den technischen Maßstab hinter den Gesetzen greifbar und zeigt, warum die Wahl des CMS, gut gebaute Templates und klare redaktionelle Workflows darüber entscheiden, ob Barrierefreiheit ein einmaliges Projekt bleibt oder zum verlässlichen Standard wird.

Inhaltsverzeichnis

• TLDR
• Kurz zur Rechtslage: Was seit dem 28. Juni 2025 gilt
• Bin ich betroffen? Eine erste Orientierung
• WCAG Level AA: der technische Maßstab hinter dem Gesetz
• Warum Overlays und Plugins keine Lösung sind
• Die drei Ebenen der Barrierefreiheit: Technik, Redaktion, Prozess
• Wie die CMS‑Wahl die Umsetzung erleichtert
• Barrierefreiheit als Daueraufgabe, nicht als Projekt
• Wie Cyber‑Solutions bei der Umsetzung unterstützt
• Fazit: Der Wechsel ist eine Rechenaufgabe, keine Glaubensfrage

TLDR

• Seit 28. Juni 2025 gilt der European Accessibility Act – in Deutschland umgesetzt als BFSG, in Österreich als BaFG. Betroffen sind vor allem B2C‑Onlineangebote wie Shops, E‑Banking, Online‑Buchung und E‑Ticketing.
• Die Betroffenheit hängt an drei Fragen: Richtet sich das Angebot an Verbraucher, fällt es unter die im Gesetz genannten Dienstleistungen oder Produkte, und greift die Kleinstunternehmer‑Ausnahme?
• Der technische Maßstab ist die Norm EN 301 549, die auf die WCAG (Level AA) verweist. Wer WCAG Level AA erfüllt, ist auf der sicheren Seite.
• Accessibility‑Overlays und „Barrierefreiheits‑Plugins" stellen keine Konformität her – sie überdecken Probleme, statt sie zu lösen.
• Barrierefreiheit hat drei Ebenen: technische Grundlage (Templates, Komponenten), Redaktion (Alt‑Texte, Überschriften, Linktexte) und Prozess (Audit, Fix, Nachtest, Schulung).
• Die CMS‑Wahl entscheidet mit: Barrierefreie Templates und strukturierte Inhalte sorgen dafür, dass die Konformität im Redaktionsalltag erhalten bleibt.

Kurz zur Rechtslage: Was seit dem 28. Juni 2025 gilt

Der European Accessibility Act (Richtlinie 2019/882) verpflichtet die EU‑Mitgliedstaaten, Barrierefreiheit für bestimmte Produkte und Dienstleistungen verbindlich zu regeln. In Deutschland ist das über das Barrierefreiheitsstärkungsgesetz (BFSG) geschehen, in Österreich über das Barrierefreiheitsgesetz (BaFG). Beide gelten seit dem 28. Juni 2025 und weiten die Pflicht zur Barrierefreiheit erstmals auf die Privatwirtschaft aus.

Betroffen sind vor allem digitale B2C‑Angebote: Onlineshops, E‑Banking, Online‑Buchungs‑ und Ticketsysteme, bestimmte Endgeräte sowie E‑Books. Eine wichtige Ausnahme gilt für Kleinstunternehmen mit weniger als zehn Beschäftigten und unter zwei Millionen Euro Jahresumsatz – allerdings nur bei Dienstleistungen, nicht beim Vertrieb von Produkten. In Österreich sieht das BaFG bei Verstößen nach Unternehmensgröße gestaffelte Verwaltungsstrafen vor, die bis zu 80.000 Euro reichen können; die Marktaufsicht liegt beim Sozialministeriumservice.

Ein Hinweis vorab: Dieser Beitrag gibt einen praxisorientierten Überblick und ersetzt keine Rechtsberatung im Einzelfall. Ob und in welchem Umfang Ihr konkretes Angebot betroffen ist, sollte im Zweifel rechtlich geprüft werden. Der Rest dieses Beitrags widmet sich der technischen und organisatorischen Umsetzung – dort, wo die meisten Projekte tatsächlich scheitern oder gelingen.

Bin ich betroffen? Eine erste Orientierung

In der Praxis ist das die erste Frage, die im Raum steht – und sie lässt sich mit drei Prüfschritten für die meisten Unternehmen zumindest grob einordnen. Erstens: Richtet sich das digitale Angebot an Verbraucherinnen und Verbraucher? Die Gesetze zielen auf den B2C‑Bereich. Eine rein interne Anwendung oder ein Portal, das ausschließlich Geschäftskunden bedient, ist in der Regel nicht direkt vom BFSG erfasst. Zweitens: Fällt das Angebot unter die im Gesetz benannten Dienstleistungen oder Produkte? Dazu gehören unter anderem der elektronische Geschäftsverkehr – also Onlineshops und Buchungsstrecken –, Bankdienstleistungen für Verbraucher, Telekommunikations‑ und Personenverkehrsdienste sowie E‑Books und bestimmte Endgeräte. Drittens: Greift die Kleinstunternehmer‑Ausnahme mit unter zehn Beschäftigten und unter zwei Millionen Euro Jahresumsatz? Sie gilt für Dienstleistungen, nicht für den Vertrieb von Produkten.

Drei Konstellationen führen dabei besonders häufig zu Fehleinschätzungen. Die klassische Corporate Website ohne Verkaufs‑ oder Buchungsfunktion ist als reines Informationsangebot meist nicht unmittelbar erfasst – sobald darauf jedoch ein Shop, eine Terminbuchung oder ein Kundenkonto liegt, verschiebt sich die Bewertung. B2B‑Unternehmen wiegen sich schnell in Sicherheit, betreiben aber häufig doch verbraucherzugängliche Elemente wie einen Ersatzteil‑Shop oder ein Serviceportal. Und wer als Auftragnehmer oder Zulieferer für die öffentliche Hand arbeitet, trifft ohnehin auf eigene Regelwerke: Öffentliche Stellen sind über die Web‑Zugänglichkeits‑Richtlinie und ihre nationalen Umsetzungen – in Deutschland etwa die BITV 2.0 – bereits seit Jahren verpflichtet, und diese Anforderung wird in Ausschreibungen konsequent weitergegeben.

Unabhängig von der reinen Rechtspflicht lohnt der Blick auf die zweite Ebene: Vertragspartner, Konzernrichtlinien und Ausschreibungen setzen WCAG Level AA immer häufiger als Standard voraus. Nicht betroffen zu sein bedeutet also nicht automatisch, dass Barrierefreiheit kein Thema ist. Eine belastbare Antwort auf die Betroffenheitsfrage im Einzelfall gibt am Ende nur die rechtliche Prüfung – die technische Antwort ist dagegen in allen Fällen dieselbe und Gegenstand der folgenden Abschnitte. (Redaktionshinweis: Sobald der Folgebeitrag „Bin ich vom BFSG betroffen? Ein Prüfschema für Unternehmen" online ist, hier verlinken.)

WCAG Level AA: der technische Maßstab hinter dem Gesetz

Die Gesetze selbst beschreiben kaum technische Details – sie verweisen auf die harmonisierte europäische Norm EN 301 549, und diese wiederum auf die Web Content Accessibility Guidelines (WCAG) des W3C. Die WCAG kennen drei Konformitätsstufen: A, AA und AAA. Maßgeblich für die Praxis ist Stufe AA – wer sie erfüllt, deckt die gesetzlichen Anforderungen in aller Regel ab. Als harmonisierte Referenz gilt derzeit WCAG 2.1 Level AA; da die aktuelle Version 2.2 die 2.1 vollständig einschließt, ist es sinnvoll und zukunftssicher, gleich auf WCAG 2.2 Level AA zu zielen.

Inhaltlich ruhen die WCAG auf vier Prinzipien, oft mit POUR abgekürzt: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein. Übersetzt in den Alltag heißt das: ausreichende Farbkontraste (mindestens 4,5:1 für normalen Text), Alternativtexte für informative Bilder, vollständige Bedienbarkeit per Tastatur, ein sichtbarer Fokus, eine logische Überschriftenstruktur, aussagekräftige Linktexte, Skalierbarkeit auf 200 Prozent Zoom ohne Layoutbruch und Formulare, die Fehler nicht nur über Farbe signalisieren. Keines dieser Kriterien ist für sich genommen kompliziert – die Herausforderung liegt darin, sie über die gesamte Website und dauerhaft einzuhalten.

Warum Overlays und Plugins keine Lösung sind

Mit der Frist ist ein Markt an vermeintlichen Abkürzungen entstanden: Accessibility‑Overlays und „Barrierefreiheits‑Plugins", die per Skript über die Website gelegt werden und Kontrast‑Schalter oder Vorlese‑Buttons einblenden. Das Versprechen, damit auf Knopfdruck konform zu sein, ist verlockend – und irreführend.

Ein Overlay ersetzt keine saubere Struktur. Die WCAG‑Konformität hängt an Semantik, Markup, Inhalten und Bedienlogik – also an Dingen, die im HTML und im Content selbst stecken, nicht in einer darübergelegten Schicht. Schlimmer noch: Manche Overlays stören assistive Technologien wie Screenreader zusätzlich und verschlechtern die Zugänglichkeit. Nachhaltige Barrierefreiheit entsteht nur an der Wurzel: in einem sauber gebauten Frontend und in strukturiert gepflegten Inhalten.

Die drei Ebenen der Barrierefreiheit: Technik, Redaktion, Prozess

Wer Barrierefreiheit dauerhaft erreichen will, muss drei Ebenen zusammendenken. Die erste ist die technische Grundlage: semantisches HTML, barrierefrei gebaute Templates und Komponenten, korrekte Fokus‑Führung, tastaturbedienbare Navigation und Formulare. Diese Ebene wird einmal richtig gebaut – und trägt danach jede Seite, die auf ihr aufsetzt.

Die zweite Ebene ist die Redaktion. Selbst das beste Template nützt wenig, wenn im Alltag Bilder ohne Alt‑Text hochgeladen, Überschriften als reine Design‑Elemente missbraucht oder Linktexte wie „hier klicken" gesetzt werden. Barrierefreiheit entsteht oder zerbricht täglich an genau diesen redaktionellen Entscheidungen. Genau hier können KI‑gestützte Funktionen im Backoffice entlasten, etwa bei der Erzeugung von Alt‑Text‑Vorschlägen – wie wir sie im AI Essentials Toolkit für Umbraco umgesetzt haben. Die Verantwortung für die Qualität bleibt dabei in der Redaktion; die Technik senkt nur die Hürde.

Die dritte Ebene ist der Prozess: ein anfängliches Audit, das Beheben der Befunde, ein Nachtest, dokumentierte Content‑Regeln und die Schulung der Redaktion. Ohne diesen Kreislauf fällt eine Website nach wenigen Monaten in alte Muster zurück.

Wie die CMS‑Wahl die Umsetzung erleichtert

Genau an der Schnittstelle dieser drei Ebenen zeigt sich der Wert eines gut gewählten und gut aufgesetzten CMS. Ein durchdachtes System nimmt der Redaktion die Möglichkeit, Barrierefreiheit versehentlich zu brechen: Alt‑Text‑Felder lassen sich als Pflichtfelder definieren, Überschriftenebenen werden über strukturierte Inhaltstypen vorgegeben statt frei formatiert, und die im Design hinterlegten Farben und Komponenten sind von vornherein kontrast‑ und fokus‑sicher gebaut. Barrierefreiheit wandert so von der täglichen Willensentscheidung in die Struktur der Plattform.

Strukturierte, präsentationsunabhängige Inhalte helfen zusätzlich: Wenn Inhalte sauber modelliert sind, lassen sich barrierefreie Ausgabemuster zentral steuern und konsistent über die gesamte Website ausspielen. Das ist im Übrigen dieselbe Grundlage, die auch über die Architekturfrage entscheidet – wir haben sie im Beitrag Headless, Composable oder klassisches CMS? ausführlich behandelt. Ob Umbraco, Sitecore oder Kentico – entscheidend ist nicht das Logo auf der Plattform, sondern dass Templates, Komponenten und Redaktionsmasken von Anfang an auf WCAG Level AA ausgelegt sind. Ein gutes CMS macht den barrierefreien Weg zum einfachsten Weg.

Barrierefreiheit als Daueraufgabe, nicht als Projekt

Der häufigste Denkfehler ist, Barrierefreiheit als einmaliges Projekt mit Enddatum zu behandeln. Websites leben aber: Es kommen neue Seiten, Kampagnen, PDFs, Videos und Redakteurinnen und Redakteure hinzu. Jede dieser Änderungen kann neue Barrieren einführen. Compliance ist deshalb kein Zustand, den man einmal erreicht, sondern einer, den man hält.

Praktisch bedeutet das: regelmäßige Audits, verbindliche Redaktionsrichtlinien, eine Barrierefreiheitserklärung, die den aktuellen Stand transparent macht, und Schulungen, die das Team befähigen, barrierefrei zu publizieren. Perfektion ist dabei selten realistisch – entscheidend sind ein nachvollziehbarer Stand, klare Prioritäten und die konsequente Umsetzung der kritischen Punkte. Wer aktiv und dokumentiert an der Barrierefreiheit arbeitet, steht auch im Fall einer Prüfung deutlich besser da als jemand, der auf ein Overlay vertraut hat. Steht ohnehin ein größerer Umbau an, ist der günstigste Zeitpunkt für die saubere technische Grundlage der Website‑Relaunch – dort kostet Barrierefreiheit einen Bruchteil dessen, was das nachträgliche Reparieren gewachsener Templates verursacht.

Wie Cyber‑Solutions bei der Umsetzung unterstützt

Wir betrachten Barrierefreiheit nicht als nachträgliches Add‑on, sondern als Teil einer sauberen Web‑Architektur. In der Praxis heißt das: Wir prüfen bestehende Websites im Accessibility‑Audit gegen WCAG Level AA, setzen die Befunde in barrierefrei gebauten Templates und Komponenten um und verankern die Konformität über Redaktionsrichtlinien und Schulungen so, dass sie im Alltag hält. Als Umbraco Platinum Partner sowie Partner für Sitecore, Storyblok und Kentico setzen wir das plattformübergreifend um.

Dass das funktioniert, zeigt die Praxis: Der Webauftritt der VERBUND AG etwa folgt einem Corporate Design, das den Barrierefreiheitsrichtlinien nach WCAG 2.2 AA entspricht und regelmäßig auditiert wird – Barrierefreiheit, die von der Template‑Ebene bis in den Redaktionsalltag durchdacht ist. Wie dieses Projekt aufgebaut ist, lesen Sie in der Case Study zum VERBUND Website‑Relaunch. Mit über 15 Jahren Erfahrung in Enterprise‑Webprojekten begleiten wir Unternehmen von der ersten Bestandsaufnahme bis zum dauerhaft konformen Betrieb.

Fazit: Aus Pflicht wird Qualität

Die gesetzliche Pflicht ist der Auslöser – der eigentliche Gewinn liegt woanders. Eine barrierefreie Website ist besser bedienbar, in Suchmaschinen sichtbarer, für KI‑Systeme leichter lesbar und erreicht schlicht mehr Menschen. Wer Barrierefreiheit über die richtige CMS‑Grundlage, gute Templates und gelebte Redaktionsprozesse angeht, erfüllt nicht nur EAA und BFSG, sondern baut eine Website, die für alle funktioniert. Aus einer Lästpflicht wird so ein echtes Qualitätsmerkmal.

Sie möchten wissen, wie barrierefrei Ihre Website wirklich ist – und was zu tun ist?

Jetzt beraten lassen