Ein Buchungskalender, ein Chat-Fenster, Bewertungssterne, ein Kartenmodul, ein Zahlungs-Iframe, eine eingebettete Stellenbörse und ganz vorn das Consent-Banner: Ausgerechnet die Bausteine, die Besucher am dichtesten an Abschluss, Termin oder Bewerbung heranführen, stammen in den seltensten Fällen aus dem eigenen Repository. Für das BFSG ändert das an der Zurechnung wenig. Die Pflicht trifft den Dienstleistungserbringer, und zwar für die Dienstleistung so, wie sie beim Nutzer ankommt (BFSG, § 14). Wie berechtigt der Blick auf fremden Code ist, zeigt die Auswertung von einer Million Startseiten aus dem Februar 2026: Auf 95,9 Prozent (WebAIM Million 2026, Utah State University) der geprüften Startseiten fanden sich automatisiert erkennbare WCAG-Verstöße, und Seiten mit einem eingebundenen CAPTCHA-Dienst trugen im Mittel 7,7 Fehler (WebAIM Million 2026) mehr als der Durchschnitt.
Das Wichtigste in Kürze
- Die Pflicht trifft den Dienstleistungserbringer für die Dienstleistung, wie sie beim Nutzer ankommt (BFSG, § 14; BFSGV, § 12 Nummer 3). Eine Ausnahme für zugelieferte Bausteine kennt das Gesetz nicht; Verträge verlagern nur das wirtschaftliche Risiko.
- Ein Link auf ein fremdes Angebot begründet keine Prüfpflicht. Sobald ein Baustein zum Schritt im eigenen Buchungs-, Bestell- oder Bewerbungspfad wird, etwa Kalender, Chat, Zahlungs-Iframe oder Consent-Banner, zählt er zur eigenen Dienstleistung.
- Typische Bruchstellen: Kalender ohne Pfeiltasten, Chat-Buttons ohne zugänglichen Namen, Zahlungs-Iframes ohne Rahmentitel. Häufigster erkannter Fehler bleiben zu geringe Textkontraste auf 83,9 Prozent der Startseiten (WebAIM Million 2026).
- Als Nachweis taugt ein Accessibility Conformance Report nach VPAT 2.5Rev vom April 2025 (Information Technology Industry Council) mit Produktversion, Prüfdatum, Prüfmethode und Normfassung; harmonisiert ist EN 301 549 V3.2.1 mit WCAG 2.1 AA.
- Der Anbieterbericht beschreibt den Auslieferungszustand, die eigene Gegenprüfung die Realität: Tastaturein- und -ausstieg, Iframe-Titel und Statusmeldungen auf den umsatzkritischen Pfaden, quartalsweise wiederholt, weil Skripte sich ohne eigenes Release ändern.
- Liefert der Anbieter nicht, helfen eine sichtbare zugängliche Alternativroute, Kapselung im eigenen Dokument oder Ablösung des Bausteins; die Belastungsklausel nach § 17 BFSG deckt ein Beschaffungsproblem nicht ab.
Die Zurechnung: fremder Code, eigene Dienstleistung
Der Ausgangspunkt ist unspektakulär und deshalb leicht zu übersehen. § 14 BFSG verpflichtet den Dienstleistungserbringer, seine Dienstleistung so zu gestalten, dass sie den Barrierefreiheitsanforderungen der Rechtsverordnung entspricht, diese Anforderungen während der gesamten Erbringung aufrechtzuerhalten, Informationen nach Anlage 3 bereitzustellen, Nichtkonformitäten der Marktüberwachung zu melden und dieser auf begründetes Verlangen Auskunft zu geben (BFSG, § 14). Adressat ist der Erbringer der Dienstleistung, nicht der Zulieferer eines einzelnen Bausteins.
Konkret wird es in der Verordnung. Damit Dienstleistungen barrierefrei erbracht werden, müssen Webseiten einschließlich der zugehörigen Online-Anwendungen und auf Mobilgeräten angebotene Dienstleistungen einschließlich mobiler Anwendungen auf konsistente und angemessene Weise wahrnehmbar, bedienbar, verständlich und robust gestaltet sein (BFSGV, § 12 Nummer 3). Eine Ausnahme für Bestandteile, die von Dritten geliefert werden, enthält die Vorschrift nicht. Ergänzend verlangt dieselbe Norm, dass die zur Erbringung der Dienstleistung eingesetzten Produkte ihrerseits die einschlägigen Anforderungen erfüllen (BFSGV, § 12 Nummer 1). Die Systematik lautet also: Was eingesetzt wird, wird zugerechnet.
Was das Gesetz nicht vorsieht
Für Onlineshops und Buchungsstrecken wird die Lage noch deutlicher. Für Dienstleistungen im elektronischen Geschäftsverkehr verlangt die Verordnung ausdrücklich, dass Identifizierungsmethoden, elektronische Signaturen sowie Sicherheits- und Zahlungsdienste wahrnehmbar, bedienbar, verständlich und robust gestaltet sind (BFSGV, § 19). Genau diese Funktionen laufen in der Praxis fast durchgehend über fremde Bausteine, meist als Iframe eines Zahlungsdienstleisters oder als eingebettetes Authentifizierungsfenster. Wie sich das im Kaufabschluss auswirkt, haben wir im Beitrag zum barrierefreien Checkout im Detail beschrieben; die Anforderungen an Shops insgesamt fasst die Seite zum barrierefreien E-Commerce zusammen.
Verlinkt oder eingebettet: wo die Zurechnung endet
Nicht jeder fremde Inhalt gehört zur eigenen Dienstleistung. Die brauchbare Trennlinie verläuft nicht zwischen eigenem und fremdem Code, sondern zwischen Verweis und Einbettung: Wird der Baustein zu einem Schritt des eigenen Bestell-, Buchungs-, Bewerbungs- oder Kontaktprozesses, oder verlässt der Nutzer die eigene Dienstleistung und tritt in ein fremdes Angebot mit eigenem Pflichtenkreis ein? Ein Link auf die Website eines anderen Unternehmens begründet keine Prüfpflicht für dessen Gestaltung. Ein Kalender, ohne den der Termin nicht zustande kommt, ist dagegen Teil der Leistung, die man selbst anbietet.
| Konstellation | Teil der eigenen Dienstleistung? | Einordnung |
|---|---|---|
| Textlink auf das Angebot eines anderen Unternehmens | nicht enthalten | Fremde Dienstleistung mit eigenem Pflichtenkreis |
| Buchungskalender als Iframe im eigenen Terminpfad | enthalten | Bedienschritt der eigenen Dienstleistung |
| Chat-Fenster als Support-Kanal | enthalten | Unterstützungsdienst (BFSGV, § 12 Nummer 4) |
| Zahlungs-Iframe im Kaufabschluss | enthalten | Zahlungsdienst (BFSGV, § 19) |
| Weiterleitung in das Portal des Zahlungsdienstleisters | Teilweise | Übergabe, Rückweg und Statusanzeige bleiben zurechenbar |
| Consent-Banner vor dem ersten Seiteninhalt | enthalten | Vorgeschalteter Bedienschritt der eigenen Seite |
| Eingebettete Stellenbörse mit Bewerbungsformular | enthalten | Formularstrecke der eigenen Dienstleistung |
| Bewertungssterne aus einem fremden Portal | enthalten | Angezeigter Inhalt der eigenen Seite |
Der Grenzfall ist die Weiterleitung. Wer den Nutzer für die Zahlung oder die Identifizierung auf eine fremde Domain schickt, gibt die Gestaltung dort aus der Hand, behält aber den Übergang: die Ankündigung des Wechsels, die Rückkehr in den eigenen Prozess und die Statusmeldung über Erfolg oder Abbruch. Eine gefestigte Rechtsprechung zur Reichweite der Zurechnung liegt bislang nicht vor. Die vorsichtige Lesart behandelt eine funktional erzwungene Weiterleitung als Bestandteil der eigenen Strecke und dokumentiert die Auswahlentscheidung für den Anbieter entsprechend.
Das Consent-Banner steht vor allem anderen
Wo die eingebetteten Bausteine brechen
Die Fehlerbilder wiederholen sich über Anbieter und Branchen hinweg, weil sie aus derselben Bauweise stammen: Ein Widget wird für die Einbettung in beliebige Seiten entwickelt, es bringt eigenes Markup, eigene Fokuslogik und eigene Farben mit, und es wird selten mit Hilfsmitteln getestet. Sechs Muster tauchen in Prüfungen besonders häufig auf (Projekterfahrung).
Buchungskalender
Das Datumsraster reagiert auf Klicks, aber nicht auf Pfeiltasten; der Fokus springt beim Monatswechsel an den Seitenanfang zurück. Betroffen sind die Bedienbarkeit per Tastatur (W3C, WCAG 2.2, 2.1.1) und häufig auch die Mindestzielgröße von 24 mal 24 CSS-Pixeln (W3C, WCAG 2.2, 2.5.8).
Chat-Fenster
Der Öffnen-Button ist ein Grafikelement ohne zugänglichen Namen, eingehende Nachrichten werden nicht angekündigt, und der Fokus wandert beim Öffnen nicht in den Dialog. Einschlägig sind Name, Rolle und Wert (W3C, WCAG 2.2, 4.1.2) sowie Statusmeldungen (W3C, WCAG 2.2, 4.1.3).
Bewertungssterne
Der Wert steckt ausschließlich in fünf Grafiken oder in einer CSS-Breitenangabe. Ohne Textalternative bleibt die Bewertung für Screenreader-Nutzer unbekannt (W3C, WCAG 2.2, 1.1.1). Interaktive Sterne zur Abgabe einer Bewertung sind zusätzlich häufig nicht mit der Tastatur erreichbar.
Kartenmodul
Die interaktive Karte fängt den Tastaturfokus im Canvas ein, Zoom-Schaltflächen tragen keinen Namen, und eine Textalternative mit Adresse und Anfahrtsbeschreibung fehlt. Aus einer Orientierungshilfe wird so eine Sackgasse mitten im Kontaktbereich.
Zahlungs-Iframe
Der Rahmen hat keinen aussagekräftigen Titel, Fehlermeldungen zur Kartennummer erscheinen nur im Iframe, und in Einzelfällen lässt sich der Fokus nicht wieder herausbewegen. Die Anforderung an Zahlungsdienste ist ausdrücklich geregelt (BFSGV, § 19).
Stellenbörse
Mehrstufige Bewerbungsformulare ohne verknüpfte Beschriftungen, Pflichtfeldfehler ohne Zuordnung und ein Datei-Upload, der ausschließlich per Ziehen und Ablegen funktioniert. Letzteres verlangt eine Alternative ohne Ziehbewegung (W3C, WCAG 2.2, 2.5.7).
Die Häufigkeitsverteilung der Fehler passt zu diesen Mustern. In der Auswertung von einer Million Startseiten entfielen die häufigsten erkannten Verstöße auf zu geringe Textkontraste mit 83,9 Prozent (WebAIM Million 2026), fehlende Alternativtexte mit 53,1 Prozent, fehlende Formularbeschriftungen mit 51 Prozent und leere Links mit 46,3 Prozent (WebAIM Million 2026, Utah State University). Leere Schaltflächen, ein typisches Widget-Muster aus Symbolgrafik ohne Beschriftung, kamen auf 30,6 Prozent (WebAIM Million 2026, Utah State University).
Das Ausbleiben erkannter Fehler bedeutet nicht, dass eine Seite zugänglich oder konform ist.
Auch der Zusammenhang zwischen zusätzlicher Technik und Fehlerzahl ist messbar. Seiten mit ARIA-Auszeichnungen wiesen im Mittel 59,1 Fehler auf, Seiten ohne ARIA 42 Fehler (WebAIM Million 2026, Utah State University); je Startseite wurden durchschnittlich 133 ARIA-Attribute gezählt, ein Zuwachs von 27 Prozent gegenüber dem Vorjahr (WebAIM Million 2026, Utah State University). Widgets bringen genau solche Auszeichnungen mit, oft in Kombination aus generischen Rollen und fehlenden Namen. Ein eingebundener CAPTCHA-Dienst fand sich auf 9,6 Prozent (WebAIM Million 2026) der Startseiten, ein eingebetteter Video-Player auf 6,2 Prozent mit im Mittel 9,4 zusätzlichen Fehlern (WebAIM Million 2026, Utah State University). Für dialogorientierte Bausteine lohnt zusätzlich der Blick auf die Anforderungen an barrierefreie Chatbots und Sprachdialoge.
Schritt 1: Das Widget-Inventar
Bevor geprüft wird, muss bekannt sein, was überhaupt eingebunden ist. In der Praxis scheitert das häufig daran, dass Bausteine über einen Tag-Container nachgeladen werden, dass Marketing und Personalabteilung eigene Einbindungen beauftragt haben und dass Kampagnenseiten Skripte tragen, die in der Hauptvorlage nicht vorkommen. Ein belastbares Inventar entsteht aus drei Quellen: dem Quelltext der wichtigsten Seitentypen, der Liste der geladenen Fremd-Domains im Netzwerkprotokoll des Browsers und den Verträgen aus dem Einkauf.
- Baustein und Zweck in einem Satz, damit die fachliche Notwendigkeit später bewertbar bleibt.
- Einbindungsart: Skript im Seitenkopf, Iframe, Web Component, Tag-Container oder serverseitige Einbindung.
- Position im Nutzerpfad: vor dem Inhalt, im Bestell- oder Buchungsprozess, im Formular, im Fußbereich.
- Interner Verantwortlicher mit Namen, nicht mit Abteilungskürzel.
- Vertragsbezug: Vertragsnummer, Laufzeit, Kündigungsfrist, Ansprechpartner beim Anbieter.
- Nachweisstand: liegt ein Accessibility Conformance Report vor, mit welchem Datum und welcher Normfassung?
- Eigener Prüfstand: Datum der letzten Tastatur- und Screenreader-Probe, gefundene Blocker, Status.
- Ersatzstrategie: zugängliche Alternativroute, Kapselung oder Ablösung, mit grober Aufwandsschätzung.
Der blinde Fleck: Tag-Container
Schritt 2: Nachweise statt Zusagen
Die Aussage "unser Widget ist barrierefrei" ist kein Nachweis. Brauchbar ist ein Accessibility Conformance Report, also ein ausgefüllter Bericht auf Basis der aktuellen VPAT-Vorlage. Die Vorlage wird vom Information Technology Industry Council gepflegt; die aktuelle Fassung VPAT 2.5Rev stammt aus dem April 2025 und erscheint in vier Editionen für Section 508, für die EU-Norm, für die WCAG und als kombinierte internationale Edition (Information Technology Industry Council). Die WCAG- und die internationale Edition beziehen WCAG 2.2 ein, die EU-Edition verweist auf die EN 301 549 (Information Technology Industry Council). Für deutsche Auftraggeber ist damit die EU- oder die internationale Edition die passende Anforderung.
- Produktname und Version des geprüften Bausteins, nicht nur der Firmenname.
- Prüfdatum und Angabe, ob manuell, automatisiert oder kombiniert geprüft wurde.
- Prüfumgebung: Browser, Betriebssystem und eingesetzte Hilfsmittel mit Versionsstand.
- Bewertung je Kriterium in den Stufen Supports, Partially Supports, Does Not Support oder Not Applicable, jeweils mit Erläuterung.
- Benannte Normfassung einschließlich Konformitätsstufe, etwa WCAG 2.2 Stufe AA.
- Ansprechpartner für Rückfragen und ein Hinweis, wann der Bericht turnusmäßig aktualisiert wird.
Auf die Normfassung achten
Drei Antworten sollten hellhörig machen. Erstens der Verweis auf ein Zugänglichkeits-Overlay statt auf einen Prüfbericht; warum das keine Erfüllung darstellt, ordnet der Beitrag zu Accessibility-Overlays ein. Zweitens ein Bericht ohne Datum oder ohne Versionsangabe, der oft Jahre älter ist als die eingesetzte Skriptfassung. Drittens die Formulierung, das Produkt sei "WCAG-konform", ohne Version und ohne Stufe. Wer schriftlich nachfragt und die Antwort ablegt, hat auch dann etwas in der Hand, wenn der Anbieter nichts liefert: den dokumentierten Versuch.
Schritt 3: Die eigene Gegenprüfung
Ein Prüfbericht des Anbieters beschreibt das Produkt im Auslieferungszustand. Auf der eigenen Seite wirkt es in einer bestimmten Konfiguration, mit einem eigenen Farbschema, in einer bestimmten Sprache, oft überschrieben von eigenem CSS und eingebettet in einen Prozess, den der Anbieter nicht kennt. Deshalb ersetzt der Bericht die eigene Prüfung nicht, sondern grenzt sie ein. Geprüft wird an der Stelle, an der der Baustein tatsächlich steht, entlang der drei bis fünf Pfade, über die Umsatz, Termine oder Bewerbungen entstehen.
- Tastaturpfad vollständig: Einstieg in den Baustein, vollständige Bedienung, geordneter Ausstieg ohne Falle (W3C, WCAG 2.2, 2.1.1 und 2.1.2).
- Fokus sichtbar und frei: Fokusanzeige erkennbar und nicht von Leisten oder Bannern verdeckt (W3C, WCAG 2.2, 2.4.7 und 2.4.11).
- Rahmen benannt: Jeder Iframe trägt einen Titel, der seinen Zweck beschreibt, nicht den Anbieternamen.
- Screenreader-Probe: Rolle, Name und Zustand jedes Bedienelements werden angesagt (W3C, WCAG 2.2, 4.1.2).
- Dynamik hörbar: Neue Nachrichten, Ladezustände und Fehler werden als Statusmeldung übermittelt (W3C, WCAG 2.2, 4.1.3).
- Zeitlimits: Sitzungs- und Zahlungsfenster lassen sich verlängern oder ankündigen (W3C, WCAG 2.2, 2.2.1).
- Kontrast im Widget-Theme: Text und Bedienelemente erreichen die geforderten Verhältnisse, auch im dunklen Modus.
- Vergrößerung: Bei 200 Prozent Zoom und 320 CSS-Pixeln Breite bleibt der Baustein bedienbar, ohne horizontales Scrollen zu erzwingen.
- Ohne Zeigegerät: Ziehbewegungen haben eine Alternative, Zielflächen sind ausreichend groß (W3C, WCAG 2.2, 2.5.7 und 2.5.8).
Der Aufwand bleibt überschaubar, wenn die Prüfung auf die kritischen Pfade begrenzt wird. Eine strukturierte Screenreader-Prüfung der Kernstrecken ist in wenigen Stunden zu leisten, ein vollständiges WCAG-Audit liefert danach die klauselbezogene Dokumentation für die Akte. Wichtig ist die Trennung im Befund: Welche Abweichung liegt im eigenen Code, welche im eingebetteten Baustein, welche entsteht erst aus dem Zusammenspiel beider? Nur die dritte Kategorie lässt sich weder allein vom Anbieter noch allein im eigenen Haus lösen.
Nicht jede Abweichung wiegt gleich
Schritt 4: Vertrag und Beschaffung
Der Hebel mit der größten Wirkung liegt vor der Einbindung. Wer Barrierefreiheit erst nach dem Rollout anspricht, verhandelt ohne Druckmittel; wer sie in die Leistungsbeschreibung schreibt, bekommt entweder ein passendes Produkt oder eine frühe Absage. Sieben Punkte gehören in Beschaffungsunterlagen und Verträge.
- Zusicherung mit Bezugspunkt: Konformität mit benannter Normfassung und Stufe, etwa EN 301 549 in der jeweils harmonisierten Fassung, hilfsweise WCAG 2.2 Stufe AA.
- Nachweispflicht: Vorlage eines Accessibility Conformance Reports bei Vertragsschluss und erneut nach jedem größeren Versionssprung.
- Nachbesserungsfristen nach Schweregrad: kurze Frist für Blocker im kritischen Pfad, längere Frist für leichte Mängel, jeweils mit Beginn ab schriftlicher Meldung.
- Ankündigungspflicht: Änderungen an Markup, Bedienlogik oder Fokusverhalten werden vorab mitgeteilt, nicht stillschweigend ausgerollt.
- Mitwirkung bei Behördenanfragen: Zulieferung der erforderlichen Angaben, damit die Auskunftspflicht gegenüber der Marktüberwachung erfüllt werden kann (BFSG, § 14 Nummer 5).
- Testzugang: Zugriff auf eine Vorabumgebung, damit neue Fassungen vor dem Livegang geprüft werden können.
- Rechtsfolgen: Minderung, Sonderkündigungsrecht oder Ersatzvornahme, wenn die Nachbesserung ausbleibt.
Beschaffung schlägt Nachbesserung
Öffentliche Auftraggeber haben hier ohnehin engere Vorgaben; die Systematik der Anforderungen in Vergabeverfahren beschreibt der Beitrag zu Barrierefreiheit in öffentlichen Ausschreibungen. Für Unternehmen lohnt der Blick dorthin trotzdem, weil die dort üblichen Formulierungen als Vorlage taugen. Wer digitale Inhalte in verschiedenen Formaten ausliefert, findet dieselbe Nachweislogik auch bei barrierefreien E-Books nach EPUB wieder: Der Vertrieb verantwortet, was er ausliefert.
Wenn der Anbieter nicht liefert
Der Regelfall ist nicht die Verweigerung, sondern die Verzögerung: Der Anbieter bestätigt den Befund, verweist auf die Roadmap und nennt kein Datum. Für diesen Fall braucht es eine Reaktion, die nicht auf Zustimmung angewiesen ist. Drei Wege stehen zur Verfügung, und sie schließen einander nicht aus.
Zugängliche Alternativroute
Dieselbe Funktion über einen zweiten, geprüften Weg anbieten: Rückrufwunsch statt Kalender-Widget, barrierefreies Kontaktformular statt Chat, Adresse mit Anfahrtsbeschreibung als Text statt Karte. Die Alternative gehört sichtbar neben den Baustein, nicht in eine Fußnote, und sie muss zum gleichen Ergebnis führen.
Kapseln
Was im eigenen Dokument liegt, lässt sich verbessern: Iframe-Titel setzen, Fokus vor und nach dem Baustein verwalten, Überschriften und Beschriftungen ergänzen, Kontraste über eigene Stilregeln korrigieren. Die Grenze ist klar: Inhalte innerhalb eines Iframes aus fremder Herkunft sind von außen nicht veränderbar.
Ersetzen
Bei Blockern im kritischen Pfad ist die Ablösung oft der kürzere Weg. Ein Terminkalender oder eine Bewertungsanzeige ist als eigene Komponente überschaubar; Aufwand und Risiko sinken, wenn Anforderungen von Beginn an in die barrierefreie Webentwicklung einfließen.
Kein Ausweg über die Belastungsklausel
Eine Alternativroute ist ein belastbarer Zwischenstand, kein Zielzustand. Sie hält den Zugang offen, während die Nachbesserung läuft, und sie gehört mit Datum und geplantem Ende in die Dokumentation. Was sie nicht leisten kann: die gleichwertige Teilhabe an derselben Oberfläche. Wer den Zwischenstand dauerhaft stellt, verlagert die Mühe auf genau die Nutzergruppe, die das Gesetz entlasten soll.
Betriebsrisiko: stille Updates
Der Unterschied zwischen eigenem und fremdem Code zeigt sich am deutlichsten im Betrieb. Eigener Code ändert sich mit einem Release, das geplant, getestet und protokolliert wird. Ein eingebundenes Skript ändert sich, wenn der Anbieter es ausliefert, also möglicherweise heute Nacht. Damit kann die Barrierefreiheit einer Buchungsstrecke zurückfallen, ohne dass im eigenen Haus eine einzige Zeile geändert wurde und ohne dass jemand davon erfährt.
Der Trend arbeitet gegen die Betreiber. Die durchschnittliche Startseite enthielt zuletzt 1.437 Elemente, ein Zuwachs von 22,5 Prozent binnen eines Jahres, und die Zahl der erkannten Fehler stieg auf 56,1 je Seite, ein Plus von 10,1 Prozent gegenüber dem Vorjahr (WebAIM Million 2026, Utah State University). Mehr eingebundene Technik bedeutet mehr Bewegung im Markup und damit mehr Gelegenheiten für Regressionen. Eine einmalige Prüfung vor dem Stichtag beschreibt deshalb einen Zustand, der schon wenige Wochen später überholt sein kann.
- Stichprobe je Quartal über alle Bausteine im kritischen Pfad, mit fester Prüfliste und dokumentiertem Ergebnis.
- Anlassprüfung nach jedem erkennbaren Anbieter-Update, nach Theme-Wechseln und nach Änderungen am Tag-Container.
- Automatisierte Regressionsprüfung der Kernstrecken als Teil der Auslieferungskette, ergänzt um eine manuelle Tastaturprobe.
- Änderungsprotokoll je Baustein: erkannte Version, Datum, Befund, Meldung an den Anbieter, gesetzte Frist.
- Eskalationsvorlage für Anbietergespräche mit Befund, Kriterienbezug, Nutzerwirkung und Fristsetzung.
- Aktualisierung der Erklärung, sobald eine bekannte Einschränkung entsteht oder entfällt.
Diese Dokumentation hat zwei Adressaten. Der erste ist die eigene Barrierefreiheitserklärung, in der bekannte Einschränkungen offen benannt werden, zusammen mit der Alternativroute und dem geplanten Zeitrahmen; wie der zugehörige Rückmeldekanal aufgebaut sein sollte, beschreibt der Beitrag zum Feedback-Mechanismus. Der zweite ist die Marktüberwachung. Für Dienstleistungen prüfen die Behörden auch ohne konkreten Anlass in angemessenem Umfang stichprobenartig (BFSG, § 28); die Länder haben dafür die Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF) mit Sitz in Magdeburg errichtet, die ihre Arbeit mit dem Geltungsbeginn am 28. Juni 2025 aufgenommen hat (Bundesfachstelle Barrierefreiheit). Bleibt eine Nichtkonformität nach Aufforderung bestehen, reicht die Skala von der erneuten Aufforderung über die Untersagung bis zu Geldbußen von bis zu 100.000 Euro, bei weiteren Verstößen bis zu 10.000 Euro (BFSG, § 37). Welche Verfahrenswege daneben bestehen, ordnet der Beitrag zu Durchsetzung und rechtlichen Risiken ein.
Was in die Akte gehört
So bringen wir Fremdkomponenten in die Nachweislage
In Projekten beginnen wir mit dem Inventar, weil sich daran die Diskussion sortiert: Häufig sind zwei oder drei Bausteine im kritischen Pfad für den überwiegenden Teil der Blocker verantwortlich, während der Rest kosmetische Befunde liefert. Danach folgen die Nachweisanforderung beim Anbieter, die eigene Gegenprüfung entlang der Kernstrecken und die Entscheidung über Kapselung, Alternativroute oder Ablösung.
- Inventar aller eingebundenen Bausteine samt Einbindungsart, Position im Nutzerpfad und Vertragsbezug.
- Nachweisanforderung an die Anbieter mit vorformuliertem Schreiben, Fristsetzung und Ablage der Antworten.
- Gegenprüfung der kritischen Pfade mit Tastatur und Screenreader, Befunde getrennt nach eigenem Code, Fremdcode und Zusammenspiel.
- Vertrags- und Beschaffungsbausteine mit Normbezug, Nachbesserungsfristen und Mitwirkungspflichten.
- Fallback-Konzept je Baustein mit Alternativroute, Kapselung oder Ersatzplanung und grober Aufwandsschätzung.
- Wiederkehrende Stichproben samt Änderungsprotokoll und Pflege der Erklärung.
Welche Bausteine dabei ineinandergreifen, zeigt die Leistungsübersicht; wo Redaktions- und Marketing-Teams selbst Einbindungen verantworten, verankern wir die Prüfroutine in einer Schulung für barrierefreie Inhalte. Und wenn die Prüfung Filter- und Suchbausteine im Shop erreicht, greift dieselbe Systematik wie bei der barrierefreien Produktsuche im Onlineshop: Zuerst der Pfad, dann das Werkzeug.
Quellen und Studien
Verwandte Artikel
Barrierefreies Redaktionssystem: ATAG für Redaktionen
ATAG 2.0 prüft das Werkzeug statt nur die Website: Teil A die Redaktionsoberfläche, Teil B die Leitplanken, die barrierefreie Inhalte wahrscheinlich machen.
Barrierefreie Lernplattformen: E-Learning nach BFSG
Kostenpflichtige Onlinekurse fallen unter das BFSG, Hochschulen unter die BITV 2.0. So wird die Lernstrecke von der Buchung bis zum Zertifikat barrierefrei.
BFSG-Marktüberwachung 2026: So läuft eine Prüfung ab
Marktüberwachung der Länder, Auskunftsverlangen, Fristen und Bußgelder bis 100.000 Euro: So läuft eine BFSG-Prüfung ab und so stellen Sie sich prüfsicher auf.