Knapp elf Monate. So lange ist das Barrierefreiheits­stärkungs­gesetz — kurz BFSG, in der Branche zunehmend EBSG genannt, weil das vorangestellte „E” für „elektronisch” den Geltungsbereich klarer markiert — am 31. Mai 2026 in Kraft. Inkrafttreten war der 28. Juni 2025. Was sich seitdem in der deutschen Privatwirtschaft tatsächlich verändert hat, lässt sich heute zum ersten Mal ohne Glaskugel beurteilen. Die ersten Marktüberwachungs­bescheide sind versandt, die ersten Bußgeld­verfahren laufen, die ersten Großunternehmen haben ihre Konformitäts­erklärungen aktualisiert. Bilanz, soweit das nach elf Monaten geht.

Was das Gesetz fordert — die kurze Version

Das EBSG setzt die europäische Richtlinie 2019/882 (European Accessibility Act, EAA) in deutsches Recht um. Der Geltungs­bereich ist enger gefasst, als viele Frontend-Teams im ersten Reflex annehmen, und genau diese Schwelle hat im letzten Jahr für viel Verwirrung gesorgt. Anwendbar ist das Gesetz auf:

• B2C-Web-Anwendungen mit elektronischem Vertragsabschluss
• E-Commerce-Shops mit Bestell- und Bezahlfunktion
• E-Banking und Online-Zahlungsdienste
• Personenbeförderungs-Buchung (Bahn, Bus, Flug, ÖPNV-Apps)
• E-Book-Reader und E-Book-Software
• Ticketing-Plattformen (Veranstaltungen, Verkehr)

Ausgenommen sind reine B2B-Dienste, klassische Informations­websites ohne Transaktion und — wichtige Schwelle für die Mittelstands­debatte — Kleinst­unternehmen mit weniger als zehn Mitarbeitenden UND weniger als 2 Millionen Euro Jahresumsatz. Die Konjunktion ist hier wesentlich: Wer eines der beiden Kriterien überschreitet, ist im Anwendungs­bereich. Eine kleine Agentur mit acht Personen, aber 2,3 Millionen Euro Jahres­umsatz, fällt unter das Gesetz. Eine Bäckerei mit zwölf Angestellten und einem Online-Shop für Gutscheine ebenso.

Der technische Bring-Standard ist WCAG 2.1 AA, abgebildet in der europäischen Norm EN 301 549 (V3.2.1 in Bezug, V4.x in Vorbereitung). Wer EN 301 549 konform ist, gilt vermutet als gesetzeskonform. Wer WCAG 2.1 AA-konform ist, deckt den größten Teil von EN 301 549 ab, aber nicht alles — die Norm enthält zusätzliche Anforderungen für Mobile, Hardware, Echtzeit­kommunikation. Für reine Web-Anwendungen ist WCAG 2.1 AA in 95 % der Fälle ausreichend.

Großunternehmen: weitgehend, aber nicht durchgehend

Wer im Mai 2026 die großen B2C-Plattformen mit Tastatur und Screenreader durchklickt, stellt fest: Es hat sich etwas getan. Amazon.de hat im Oktober 2025 eine umfassende Konformitäts­erklärung publiziert; der Bestell- und Checkout-Prozess ist mit NVDA und JAWS sauber bedienbar, die Produktdetail­seiten haben echte Heading-Hierarchien statt visueller Pseudo-Header. Zalando hat in zwei Sprints die alten React-Komponenten der Filter-Sidebar gegen Radix-basierte Primitives ersetzt — ein Update, das nebenbei den ganzen Bundle um etwa 18 KB schlanker gemacht hat. OTTO ist seit 2024 Vorreiter und musste am wenigsten nachziehen.

Die Deutsche Bahn hat die DB-Navigator-Webanwendung im Februar 2026 in einer Version 5.0 ausgerollt, die — zum ersten Mal seit Jahren — VoiceOver-tauglich ist. Der vorherige Stand war so notorisch fragmentiert, dass Aktivisten ihn als Negativ­beispiel in Schulungen verwendeten. Der Druck hat gewirkt.

Aber das Bild ist nicht durchgängig. Zwei Beobachtungen, die im DACH-Frontend-Diskurs der letzten Monate immer wiederkehren:

Erstens, die Konformität endet am Cookie-Banner. Die meisten großen Plattformen haben ihre Erstanbieter-Komponenten in Ordnung gebracht, aber Drittanbieter-Widgets — Consent Management Platforms wie OneTrust, Usercentrics, Cookiebot — sind nach wie vor das schwächste Glied. Tastaturfokus, der unsichtbar wird, Modal-Dialoge ohne aria-modal, Buttons mit <div> als Tag. Eine Site, die in der eigenen Code­base WCAG 2.1 AA erreicht, fällt am eingebundenen Banner durch.

Zweitens, Live-Komponenten bleiben Risiko. Live-Chat-Widgets (Intercom, Zendesk, Crisp) haben sich gebessert, aber langsam. Video-Streams ohne Live-Untertitelung — bei Webinar-Plattformen, bei Live-Shopping-Streams — sind noch immer der Regelfall, obwohl Live-Captioning durch Whisper-basierte Pipelines technisch trivial geworden ist. Hier ist die Lücke zwischen „rechtlich gefordert” und „faktisch geliefert” am größten.

Mittelstand: ein gespaltenes Bild

Im Mittelstand wird es heterogen. Die Unternehmen, die bereits vor dem 28. Juni 2025 ein internes Accessibility-Programm hatten — typischerweise solche, die im öffentlichen Sektor liefern und schon unter BITV 2.0 standen — haben den Übergang ohne Drama bewältigt. Die anderen klemmen.

Was wir aus den ersten Marktüberwachungs­berichten der Bundesnetzagentur, die seit Februar 2026 in Auszügen publiziert werden, ablesen können:

• Etwa 38 % der untersuchten Online-Shops von mittleren Unternehmen sind „nicht-konform” oder „nur teilweise konform”.
• Die häufigsten Mängel: fehlende Alt-Texte (62 % der nicht-konformen Sites), unzureichende Tastatur­bedienbarkeit (54 %), fehlende oder fehlerhafte Form-Labels (47 %), unzureichender Farb­kontrast (41 %), fehlende Skip-Links und Heading-Strukturen (38 %).
• Auffallend: Die meisten dieser Probleme sind bekannte Klassen, für die seit Jahren Automatisierte Test­tools existieren. Axe, Lighthouse, WAVE — sie hätten 80 % dieser Mängel im CI-Build detektieren können.

Das deutet auf das eigentliche Problem hin. Es ist nicht primär ein Wissens­problem. Es ist ein Priorisierungs­problem. Solange die Markt­überwachung als entfernt und die Bußgeld­wahrscheinlichkeit als niedrig empfunden wird, fließt das Sprint-Budget in andere Tickets.

Markt­überwachung und Bußgelder: das Druckwerkzeug

Die Markt­überwachung läuft beim Bundes­amt für Soziale Sicherung (BAS) als gesetzlicher Markt­überwachungs­behörde, mit operativer Unterstützung durch die Bundesnetzagentur und die Länder­behörden. Das Beschwerde­verfahren ist niedrig­schwellig: Eine Verbraucherin, die eine Online-Buchung wegen Barriere nicht abschließen kann, kann per Formular melden. Die Behörde fordert das Unternehmen zur Stellungnahme auf, setzt eine Mängelbehebungsfrist (typisch 30 Tage) und kann bei Nicht­behebung ein Bußgeld bis zu 100.000 Euro pro Verstoß verhängen.

Die Statistik nach elf Monaten:

• über 4.200 eingegangene Beschwerden, davon ca. 60 % E-Commerce-bezogen
• ca. 1.100 förmliche Aufforderungen zur Stellungnahme
• bisher 38 verhängte Bußgelder, davon der höchste bekannt gewordene Fall bei 67.000 Euro (ein Reise­buchungs­portal, das nach zweimaliger Aufforderung den Zahlungs­schritt nicht zugänglich gemacht hat)

Das EBSG arbeitet nicht primär durch Strafen, sondern durch die Möglichkeit von Strafen. Es reicht, dass die Behörde anschreibt — die Mehrheit reagiert dann.

Das ist, nüchtern betrachtet, ein funktionierender Vollzugs­mechanismus. Nicht durchschlagend, aber wirksam. Wer die Frist verstreichen lässt, zahlt; wer reagiert, kommt ohne Bußgeld davon. Genau das war der gesetz­geberische Plan.

Was 2026 in Pull-Requests gehört

Aus der Mängel­statistik der Markt­überwachung ergibt sich eine pragmatische Pflicht­liste für jeden Frontend-Pull-Request:

# .github/workflows/a11y.yml — minimaler Pflicht-Check
name: Accessibility
on: [pull_request]
jobs:
  axe:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx playwright install --with-deps chromium
      - run: npx @axe-core/cli http://localhost:4321 \
          --exit --tags wcag2a,wcag2aa,wcag21a,wcag21aa

Das ist die Untergrenze. Axe in CI fängt 50–60 % der automatisierbar erkennbaren Mängel. Was Axe nicht prüfen kann — und was deshalb in jedem PR mit UI-Änderung als Review-Checkliste stehen muss:

• Tastatur-Pfad: Tab durch das geänderte Component, ohne Maus. Bleibt der Fokus sichtbar? Ist die Reihenfolge logisch? Kommt man wieder raus?
• Screenreader-Probe: Mindestens eine kurze NVDA- oder VoiceOver-Session über den geänderten Bereich. Was wird vorgelesen? Was fehlt?
• Zoom 200 %: Browser-Zoom auf 200 %. Bricht das Layout? Werden Inhalte abgeschnitten? Sind interaktive Elemente noch erreichbar?
• Farb­kontrast bei Custom-Colors: Mindestens 4.5:1 für normalen Text, 3:1 für Large Text (≥ 18.66 px regular oder 14 px bold). Tailwind 4 hat hierfür inzwischen einen --contrast()-Helper in der Color-Mix-Pipeline.

Die Tool-Triade 2026 für manuelles Testing ist nach wie vor NVDA (Windows) + VoiceOver (macOS/iOS) + TalkBack (Android). ChromeVox ist faktisch tot — Google hat die Weiterentwicklung Ende 2024 eingestellt. JAWS bleibt im Enterprise-Umfeld relevant, ist aber für ein typisches Frontend-Team durch NVDA gut ersetzbar.

Was schwer bleibt

Drei Klassen von Komponenten, die auch im Mai 2026 die meisten Teams Zeit kosten:

Dynamische Komponenten­bibliotheken ohne ARIA-Test-Coverage. Eine selbst­gebaute Combobox, ein selbst­gebauter Datepicker, ein selbst­gebautes Dropdown-Menü — sie sind in 80 % der Fälle nicht-konform und in 100 % der Fälle ein Wartungs­problem. Die pragmatische Antwort 2026 heißt: nicht selbst bauen. Radix Primitives, React Aria Components, Headless UI sind in einer Reife, die eigene Implementierungen kaum rechtfertigt. Wer dennoch baut, übernimmt die Verantwortung, ARIA Authoring Practices durchzugehen — und in CI mit @axe-core/playwright end-to-end zu prüfen.

Drittanbieter-Widgets. Hier hilft Vertrags­druck. Wer einen Consent-Manager einkauft, gehört in den Vertrag eine Klausel über WCAG-2.1-AA-Konformität. Die großen Anbieter haben darauf reagiert; die kleineren noch nicht.

Live-Streams und Echtzeit­kommunikation. EN 301 549 fordert Echtzeit­untertitel für Live-Video, wo es technisch möglich ist. Whisper-basierte Live-Captioning-Pipelines (z. B. via Deepgram, AssemblyAI, oder selbst gehostet mit faster-whisper) haben 2025 eine Qualität erreicht, die produktiv tragfähig ist. Latenz typisch 300–700 ms, WER (Word Error Rate) im Deutschen bei sauberer Audio-Quelle unter 8 %. Wer Live-Streaming betreibt, hat die technische Grundlage. Die organisatorische Umsetzung — wer pflegt das Glossar, wer prüft die Captions vor Veröffentlichung — bleibt die offene Frage.

Was bleibt nach elf Monaten

Das EBSG ist kein Bruch mit der Vergangenheit. Es ist die formalisierte Version dessen, was gute Frontend-Teams seit Jahren ohnehin tun. Was es verändert hat, ist nicht die Technik. Es ist die Verbindlichkeit. Accessibility ist keine „Nice-to-have”-Spalte im Ticket­system mehr; sie ist ein gesetzlich gefordertes Lieferkriterium für eine wachsende Klasse von B2C-Anwendungen. Wer das im PR-Review weiter als „erweiterte Anforderung” behandelt, arbeitet 2026 im Risiko.

Die gute Nachricht: Die Werkzeuge sind da. Axe, Radix, React Aria, Whisper, Tailwind 4 — die Infrastruktur ist 2026 so robust wie nie. Was bleibt, ist die Disziplin, sie zu verwenden.