Barrierefreiheitsgesetz (Österreich) und Barrierefreiheitsstärkungsgesetz (Deutschland) gelten seit dem 28. Juni 2025. Dieser Leitfaden erklärt Geltungsbereich, den technischen Standard WCAG 2.1 AA, den Audit-Prozess, Pflichtdokumente und die häufigsten Fehler — damit Sie wissen, was tatsächlich zu tun ist.
Audit, Code-Fix per Pull-Request, Erklärung — alles unter einem Dach bei tablegray.
Die Richtlinie (EU) 2019/882 — der European Accessibility Act (EAA) — verpflichtet Mitgliedstaaten, Barrierefreiheitsanforderungen für bestimmte Produkte und Dienstleistungen einzuführen. In Österreich wurde sie als Barrierefreiheitsgesetz (BaFG, BGBl. I Nr. 76/2023) umgesetzt, in Deutschland als Barrierefreiheitsstärkungsgesetz (BFSG). Beide Gesetze sind seit dem 28. Juni 2025 wirksam.
Was bedeutet „digitale Barrierefreiheit" konkret? Eine Website, App oder digitale Dienstleistung gilt als barrierefrei, wenn sie von Menschen mit Behinderungen — darunter Sehbehinderungen, Hörbehinderungen, motorische Einschränkungen und kognitive Beeinträchtigungen — wahrgenommen, bedient, verstanden und robust genutzt werden kann. Das ist kein Designkonsens, sondern ein technischer Standard: WCAG 2.1 Level AA.
Die BaFG und das BFSG sind keine Empfehlungen — sie sind Gesetze mit Sanktionen. Marktüberwachungsbehörden können bei festgestellten Verstössen Bußgelder verhängen (bis 80.000 Euro in Österreich, bis 100.000 Euro in Deutschland) und Marktverbote aussprechen. Die Prüfung erfolgt reaktiv — meist auf Beschwerde hin. Das bedeutet: Wer keine Beschwerde erhält, kann trotzdem nicht-konform sein.
„Barrierefreiheit ist kein Thema für Grossunternehmen mit eigener Accessibility-Abteilung. Jeder Online-Shop, jede App, jede Buchungsplattform fällt seit Juni 2025 unter die Pflicht — und die meisten wissen es noch nicht." Mag. iur. Richard Gschank, tablegray services gmbh
Ein wichtiger Unterschied: BaFG und BFSG haben denselben technischen Standard, aber unterschiedliche Durchsetzungsbehörden. In Österreich ist das Sozialministeriumservice für viele Bereiche zuständig; in Deutschland sind es die Marktüberwachungsbehörden der Länder. Für Unternehmen, die in beiden Märkten aktiv sind, genügt technisch ein Ansatz — rechtlich müssen beide Erklärungen vorhanden sein. Für unsere Beratungsleistungen: Barrierefreiheits-Überblick für Unternehmen.
Der Geltungsbereich ist breit und trifft die meisten Unternehmen mit digitaler B2C-Präsenz. Erfasst sind: E-Commerce-Websites und Online-Shops (jeder Online-Shop, der Verbraucher anspricht), mobile Apps (iOS und Android, sofern an Verbraucher gerichtet), Dienstleistungen über Websites (Banking, Versicherungen, Ticketing, Streaming, Reiseportale), Selbstbedienungs-Terminals (Geldautomaten, Check-in-Automaten, Fahrkartenautomaten), Telefondienste und zugehörige Endgeräte.
Nicht erfasst sind (in der aktuellen Fassung): reine B2B-Websites, die ausschliesslich an Unternehmen gerichtet sind, sowie Kleinstunternehmen bei Dienstleistungs-Pflichten (weniger als 10 Mitarbeitende und weniger als 2 Millionen Euro Jahresumsatz oder Bilanzsumme). Diese Kleinstunternehmen-Ausnahme gilt aber nur für Dienstleistungen, nicht für Produkte. Ein Kleinstunternehmen, das eine Software-App entwickelt und verkauft, unterliegt den Produkt-Pflichten auch ohne die Grössen-Schwellenwerte zu überschreiten.
Besondere Aufmerksamkeit verdient die Frage, ob Bestandsinhalte sofort konform sein müssen. Neue Inhalte und neue Funktionen, die nach dem 28. Juni 2025 online gegangen sind, müssen sofort WCAG 2.1 AA erfüllen. Bestandsinhalte, die vor diesem Datum erstellt wurden, haben Übergangsfristen (in vielen Fällen bis 2030). Das bedeutet aber nicht, dass Altinhalte ignoriert werden dürfen — eine „Barrierefreiheits-Roadmap" für schrittweise Überarbeitung ist die empfohlene Strategie.
WCAG (Web Content Accessibility Guidelines) ist ein Standard des World Wide Web Consortium (W3C) — nicht der EU, nicht des Gesetzgebers. Die EU verweist in BaFG und BFSG auf WCAG 2.1 Level AA als technischen Mindeststandard. Der Standard ist in vier Prinzipien gegliedert:
Wahrnehmbar: Inhalte müssen für alle Nutzer wahrnehmbar sein. Das bedeutet: Bilder brauchen Alt-Texte (1.1.1), Videos brauchen Untertitel (1.2.2) und gegebenenfalls Audiodeskription (1.2.5), Inhalte müssen auch ohne Farbe verständlich sein (1.4.1), und Texte müssen ausreichend Kontrast aufweisen (1.4.3: mindestens 4,5:1 für normalen Text).
Bedienbar: Die gesamte Oberfläche muss mit der Tastatur bedienbar sein, ohne Maus (2.1.1). Nutzer brauchen ausreichend Zeit (2.2.1). Bewegende Inhalte können pausiert werden (2.2.2). Kein Inhalt blinkt häufiger als dreimal pro Sekunde (2.3.1). Navigation muss konsistent und verständlich sein (2.4.x).
Verständlich: Sprache muss programmatisch erkennbar sein (3.1.1), Fehlereingaben in Formularen müssen erklärt werden (3.3.1/3.3.2), Navigation und Labels müssen konsistent sein. Formulare sind ein besonders häufiger Problembereich: Felder müssen im HTML-Code mit korrekten Labels verbunden sein, nicht nur visuell.
Robust: Inhalte müssen mit aktuellen Hilfstechnologien kompatibel sein (4.1.x). Das betrifft ARIA-Attribute, semantisches HTML und die korrekte Nutzung von Rollen und Zuständen für interaktive Elemente.
WCAG 2.1 AA umfasst insgesamt 50 Erfolgskriterien auf Level A und AA. Die meisten sind mit solidem HTML-Handwerk zu erfüllen — aber es ist viel Detailarbeit. Ein automatisiertes Tool (Axe, WAVE, Lighthouse) findet nur 30–40 % der Probleme; manuelle Tests mit realen Screenreadern (NVDA, JAWS) sind für eine vollständige Prüfung unumgänglich.
Ein vollständiger WCAG-2.1-AA-Audit kombiniert automatisierte Scans mit manuellen Tests. Bei tablegray umfasst ein Standard-Audit folgende Prüfbereiche:
Jedes bedeutungsvolle Bild — Produktfotos, Infografiken, Icons mit Funktion — braucht einen beschreibenden Alt-Text. Dekorative Bilder bekommen alt="". Kein Alt-Text bedeutet: Screenreader-Nutzer hören den Dateinamen, was oft wertlos oder verwirrend ist.
Normaler Text: mindestens 4,5:1. Grosse Texte (>18pt oder >14pt fett): mindestens 3:1. UI-Komponenten und Grafiken: mindestens 3:1. Grauer Text auf weissem Hintergrund ist einer der häufigsten Verstösse.
Alle interaktiven Elemente — Links, Buttons, Formulare, Dropdowns, Modals — müssen per Tab erreichbar und per Enter/Space bedienbar sein. Die Tab-Reihenfolge muss logisch sein. Focus-Indikatoren müssen sichtbar sein (WCAG 2.4.7).
Jedes Eingabefeld braucht ein programmatisches Label: <label for="email">E-Mail</label><input id="email">. Placeholder-Text allein genügt nicht — er verschwindet beim Eintippen und ist für Screenreader unzuverlässig.
Überschriften (h1–h6) müssen eine logische Hierarchie bilden. Landmark-Elemente (header, nav, main, footer) müssen korrekt eingesetzt sein. Listen müssen als ul/ol ausgezeichnet sein.
Alle voraufgezeichneten Videos mit Ton brauchen Untertitel. Live-Videos brauchen Echtzeit-Untertitel. Bei reinen Audio-Inhalten (Podcasts) ist ein Texttranskript Pflicht.
Interaktive Elemente auf mobilen Geräten müssen mindestens 24x24 CSS-Pixel gross sein (WCAG 2.2: 24px; empfohlen: 44x44px nach iOS/Android-Guidelines). Zu kleine Buttons sind eine häufige Barriere für Nutzer mit motorischen Einschränkungen.
In der Praxis sehen wir bei österreichischen KMU regelmässig dieselben Fehler. Keiner davon ist schwer zu beheben — aber keiner verschwindet von selbst.
Fehler 1: „Wir haben einen Tool-Report — das genügt." Nein. Automatisierte Tools (Axe, Lighthouse, WAVE) finden rund 30–40 % der WCAG-Verstösse. Die restlichen 60–70 % — Logik-Fehler, schlechte Screenreader-Erfahrung, fehlerhafte Tastatur-Navigation — finden nur manuelle Tests. Ein Tool-Report ist ein Einstieg, kein Nachweis.
Fehler 2: „Grauer Text sieht besser aus." Zu wenig Kontrast ist eine der häufigsten und am leichtesten zu behebenden Barrieren. Texte auf hellgrauem Hintergrund, weisser Text auf hellblauem Hintergrund — das scheitert regelmässig an der 4,5:1-Anforderung. Die Lösung ist in CSS ein Farbwechsel: eine Aufgabe von Minuten, nicht Tagen.
Fehler 3: „Formular-Labels sind visuell vorhanden." Visuelle Labels, die nur per CSS positioniert sind, aber nicht im HTML-Code mit dem Eingabefeld verbunden sind, sind für Screenreader unsichtbar. Das richtige Muster ist <label for="feldname">Bezeichnung</label><input id="feldname"> — ohne diese Verbindung spricht der Screenreader „edit" oder den Feldnamen, nicht die Bezeichnung.
Fehler 4: „Alte Inhalte sind von Übergangsfristen geschützt." Stimmt für Bestandsinhalte, die vor dem 28.06.2025 erstellt wurden. Stimmt nicht für neue Funktionen, die nach diesem Datum hinzugefügt wurden. Und: Übergangsfristen schützen vor Bußgeldern, nicht vor Beschwerden. Ein funktionierender Beschwerdemechanismus signalisiert, dass Sie aktiv an Compliance arbeiten — das ist Behörden gegenüber viel wertvoller als eine Bestandsinhalte-Ausrede.
Fehler 5: „Wir bauen Websites für Kunden, aber Barrierefreiheit ist nicht im Scope." Das ist ein Haftungsrisiko für Agenturen. Wenn ein Auftraggeber eine nicht-konforme Website erhält und dafür ein Bußgeld kassiert, wird er sich fragen, warum die Agentur ihn nicht informiert hat. Barrierefreiheit gehört seit Juni 2025 in den Standard-Scope jedes Web-Projekts.
„Wir haben in 2025 mehr als zehn Websites auditiert, die nach der BaFG eigentlich compliant sein müssten. Im Durchschnitt fanden wir 40 bis 80 Verstösse pro Website — die meisten davon behebbar in einem einzelnen Sprint." Ing. Mag. Günter Omer, tablegray services gmbh
BaFG § 14 und BFSG § 16 ff. verlangen eine Barrierefreiheits-Erklärung auf der Website. Diese Erklärung ist kein PR-Text — sie ist ein Compliance-Dokument, das im Beschwerdefall als erstes gelesen wird. Sie muss folgende Elemente enthalten:
Erfüllungsgrad: Eine der drei Aussagen: „Diese Website erfüllt den Standard WCAG 2.1 AA vollständig", „...teilweise" oder „...nicht erfüllt". Für die meisten Unternehmen ist „teilweise" die ehrliche Antwort — und das ist akzeptabel, wenn die bekannten Mängel dokumentiert sind.
Liste bekannter Mängel: Welche Teile der Website sind nicht konform, warum nicht, und welche Alternativen gibt es (Ersatzmechanismen)? Beispiel: „PDFs auf /downloads sind nicht barrierefrei. Bis zur Überarbeitung können Sie die Inhalte per E-Mail an office@tablegray.com anfordern." Diese Liste zeigt, dass Sie die Situation kennen und aktiv adressieren.
Beschwerdemechanismus: Name und Kontakt der zuständigen Kontaktstelle (E-Mail-Adresse genügt). Link zur EU-Durchsetzungsstelle oder nationalen Beschwerdeinstanz. Ein funktionierender Prozess hinter der E-Mail-Adresse: Wer liest die Meldungen? In welchem Zeitrahmen wird reagiert? Kein Beschwerdemechanismus ist ein Compliance-Verstoß für sich.
tablegray textet die Barrierefreiheits-Erklärung auf Basis des Audit-Ergebnisses und baut den Kontakt-Workflow ein. Das dauert üblicherweise zwei Tage — aber es setzt voraus, dass ein Audit stattgefunden hat, damit die Mängelliste ehrlich befüllt werden kann. Eine leere Erklärung ist schlechter als keine Erklärung.
Wer ebenfalls an Compliance-Dokumentationen arbeitet, findet strukturelle Parallelen: Die Barrierefreiheits-Erklärung ist analog zur technischen Dokumentation unter der Cyber Resilience Act und zu den GF-Beschlüssen unter dem NISG 2024 — ein Nachweis, dass das Unternehmen aktiv mit Compliance umgeht.
BaFG und BFSG richten sich an „Wirtschaftsakteure" — das sind Hersteller, Importeure, Händler und Dienstleister, je nach Art des betroffenen Produkts oder der Dienstleistung. Im digitalen Bereich ist das in der Regel das Unternehmen, das die Website oder App betreibt und anbietet.
Website-Betreiber: Primär verantwortlich für die Barrierefreiheit der eigenen Website oder App. Unabhängig davon, wer die Seite entwickelt hat oder auf welchem CMS sie läuft. Wer eine Shopify-, WordPress- oder Magento-Site betreibt, ist für die Barrierefreiheit der gesamten Seite verantwortlich — einschliesslich zugekaufter Plugins und Themes.
Werbeagenturen und Entwicklungsagenturen: Nicht primär gesetzlich verantwortlich, aber vertraglich haftbar. Wenn eine Agentur eine Website liefert, die nicht WCAG-2.1-AA-konform ist, und der Auftraggeber deswegen ein Bußgeld erhält, kann der Auftraggeber Schadenersatz fordern — wenn Barrierefreiheit im Auftrag war. Und ab 2025 sollte sie in jedem Web-Auftrag implizit enthalten sein.
Software-Hersteller: Wer eine Software als Produkt herstellt und vertreibt (z.B. eine SaaS-Anwendung, eine mobile App), ist als Hersteller direkt verantwortlich für die Barrierefreiheit des Produkts — unabhängig davon, wie der Endkunde die Software einsetzt.
Ein Spezialfall sind B2B-Software-Lösungen, die auch von Privatpersonen genutzt werden können: Wenn ein Tool, das nominell B2B ist, faktisch von Endverbrauchern genutzt wird (z.B. ein Kundenportal, das Privatpersonen über das Unternehmen ihrer Wahl erreicht), kann die B2B-Ausnahme nicht greifen. Die Einordnung ist einzelfallabhängig.
Barrierefreiheit hat einen Ruf, teuer zu sein. In Wirklichkeit ist der Aufwand stark von drei Faktoren abhängig: Wie gross ist die Website oder App? Wie viele Fehler gibt es? Sind die Fehler in leicht behebbaren Bereichen (CSS, Alt-Texte) oder in komplexerer Logik (Custom-JavaScript-Komponenten, native App-Widgets)?
Typische Kosten-Orientierung für österreichische KMU: Ein Audit für eine Standard-Website (20–50 Seiten, Kontaktformular, kein E-Commerce) kostet 2.000–5.000 Euro und dauert 2–4 Tage. Ein E-Commerce-Audit (Shopify oder WooCommerce, bis 200 Seiten) kostet 4.000–8.000 Euro. Eine native mobile App (iOS + Android) kostet 6.000–15.000 Euro. Die Code-Fixes kosten typischerweise 50–100 % der Audit-Kosten, je nach Fehlerdichte. Die Barrierefreiheits-Erklärung und der Beschwerdemechanismus kosten 500–1.500 Euro.
Der ROI der Barrierefreiheit geht weit über die Vermeidung von Bußgeldern hinaus. Ca. 15–20 % der Bevölkerung leben mit einer Behinderung, die digitale Barrierefreiheit relevant macht — Sehbehinderungen, Hörbehinderungen, motorische Einschränkungen, Dyslexie. Eine barrierefreie Website ist für diese Nutzergruppen überhaupt erst zugänglich. Das ist ein direkt messbarer Einfluss auf Conversion-Rate und Kundenzufriedenheit.
Zudem: Suchmaschinen bevorzugen semantisch korrektes HTML. Alt-Texte für Bilder werden von Google gecrawlt. Logische Überschriften-Hierarchien verbessern das Ranking. Viele WCAG-Massnahmen sind gleichzeitig SEO-Massnahmen. Barrierefreiheit ist kein Kostenfaktor — sie ist ein Qualitätsmerkmal, das sich auf mehreren Ebenen auszahlt.
Eine praktische Roadmap für ein KMU: Monat 1 — Audit durchführen, Priorisierungsliste erstellen; Monat 2 — Priorität-1-Fehler (Bußgeld-Risiko) beheben, Barrierefreiheits-Erklärung schreiben; Monat 3 — Priorität-2-Fehler beheben; danach — laufende Betreuung bei neuen Inhalten und Funktionen. Für Barrierefreiheits-Audit, Code-Fixes und Erklärung: Barrierefreiheits-Quick-Check als Einstieg, dann Erstgespräch.
Geltungsbereich, Kleinstunternehmen-Ausnahme, aktuelle Fehlerquellen, Pflichtdokumente — der Quick-Check zeigt Ihnen in 15 Fragen, wo Sie stehen und welche Schritte Priorität haben.
Kostenlos. Kein Verkauf. Das PDF ist die Grundlage für jedes Barrierefreiheits-Gespräch bei tablegray.
BaFG und BFSG verweisen auf WCAG 2.1 Level AA — nicht auf WCAG 2.2, das im Oktober 2023 veröffentlicht wurde. WCAG 2.2 ist eine Erweiterung (nicht Ersatz) von WCAG 2.1, mit neun neuen Erfolgskriterien, darunter minimale Touch-Zielgrössen und verbesserte Fokus-Anforderungen. Wer WCAG 2.2 AA erfüllt, erfüllt auch WCAG 2.1 AA. Für die gesetzliche Compliance genügt WCAG 2.1 AA — wir empfehlen trotzdem, WCAG 2.2 zu kennen und die zusätzlichen Kriterien anzustreben.
Technisch können die Inhalte überwiegend identisch sein; aber formal brauchen Sie in der Regel zwei getrennte Dokumente, die auf die jeweiligen nationalen Gesetze und Durchsetzungsbehörden verweisen. BaFG verweist auf das österreichische Sozialministeriumservice, BFSG auf die deutschen Landesbehörden. tablegray erstellt beide Versionen im Rahmen eines Mandats.
Wer auf eine Beschwerde über den Beschwerdemechanismus nicht oder nicht angemessen reagiert, riskiert, dass die Person eine Beschwerde bei der Marktüberwachungsbehörde einreicht. Diese prüft dann reaktiv. Ohne dokumentierten Beschwerdemechanismus und ohne Reaktion ist die Ausgangsposition bei einer Behörden-Prüfung deutlich schlechter als mit einem nachweislich aktiven Prozess.
Nicht automatisch. Accessibility-Plugins (wie WP Accessibility Helper oder ähnliche) können einige häufige Fehler beheben, aber sie sind keine Compliance-Garantie. Erstens decken sie, wie alle automatisierten Tools, nur einen Teil der WCAG-Kriterien ab. Zweitens betreffen viele Probleme das zugrundeliegende Theme oder Custom-Code, die das Plugin nicht ändert. Ein Plugin ist ein Hilfsmittel, kein Audit-Ersatz.
Grundsätzlich keine Konflikte. Beide Regelwerke dienen dem Schutz von Personen, auf unterschiedlichen Ebenen. Ein theoretischer Spannungspunkt: die Barrierefreiheits-Erklärung enthält einen Kontakt-Link. Diese Kontaktmöglichkeit muss datenschutzkonform ausgestaltet sein (Datenschutzerklärung, AVV falls relevant). tablegray prüft beides im Rahmen eines integrierten Mandats.
Das ist keine gute Idee. Die Barrierefreiheits-Erklärung muss die spezifischen Mängel Ihrer Website beschreiben — nicht irgendeine andere. Eine kopierte Erklärung mit falschen Informationen ist schlimmer als keine Erklärung. Im Behördenfall zeigt sie, dass Sie die eigene Compliance nicht kennen. Lassen Sie die Erklärung auf Basis eines echten Audits schreiben.
Mindestens jährlich, oder wenn sich der Erfüllungsgrad ändert — also nach jedem grösseren Release oder nach Behebung wesentlicher Mängel. Wenn Ihre Erklärung sagt „bekannter Mangel: kein Alt-Text für Produktbilder" und Sie beheben das in einem Sprint, muss die Erklärung aktualisiert werden. Eine veraltete Erklärung kann ein Compliance-Problem sein, wenn sie bekannte Mängel nennt, die längst behoben sind (Problem: Übertreibung), oder aktuelle Mängel nicht nennt (Problem: Täuschung).
Audit in 2–4 Tagen, Code-Fix per Pull-Request, Barrierefreiheits-Erklärung fertig — das ist der tablegray-Ansatz. Kein Word-Dokument, sondern deploybare Lösungen. Buchen Sie das Erstgespräch unter /erstgespraech.html.