Das BFSG und Dritt-Parteien-Inhalte

Skripte, die von extern eingebunden werden (Cookie-Banner-Dienste, Social-Media-Einbindungen, Video-Player-Einbettungen, Analyse-Dienste u. v. m.) sind aus dem modernen Web nicht mehr wegzudenken. Und auch Online-Shops haben ein meist spezielles Set an Diensten, die man „Dritt-Parteien-Dienste“ oder „Third Party Services“ nennt: So wird die Bezahlung einer Ware oder Dienstleistung meist mit einer Third Party wie beispielsweise PayPal geregelt – und die bereits genannten Dienste finden auch im E-Commerce Einzug. Wenn ein Produkt beispielsweise in Videoform präsentiert werden soll, so geschieht das häufig per YouTube-Kanal und der Einbettung eines zugehörigen Players auf der Produktseite. Ich würde vermuten, Online-Shop-Betreibende sind besonders an Analytik-Diensten interessiert. Etwa, ob ein bestimmter Anteil an Besuchenden irgendwo den Kaufvorgang abbrechen. Um das herauszufinden, sind gerne Webanalyse-Software Dritter im Einsatz.

Relevant für die Web-Barrierefreiheit sind allerdings Third-Party-Skripte, die eigenes HTML mitbringen, mit denen ein Nutzender konfroniert ist, z. B. bei einem Cookie-Banner-Skript. Eine reale oder formale Barriere hier kann dazu führen, dass gleich mehrere Seiten des einbindenden Webauftritts als "nicht-konform" im Sinne der WCAG (Web Content Accessibility Guidelines) gelten – und zwar unabhängig davon, wie gut und barrierefrei der Webauftritt ohne den Cookie-Banner ist.

Weil also die Einbindung einer Third Party eine große Verantwortung ist, bei der kleine Dinge wie die Einbindung einer Zeile JavaScript große (negative) Wirkungen haben können, soll dieser Artikel Eine kleine Übersicht über Anforderungen und mögliche Lösungsstrategien geben.

Die WCAG und Third Parties

Die Sicht der WCAG auf Skripte und Inhalte dritter Parteien ist ziemlich eindeutig: Website-Betreibende sind für die eingebundenen Inhalte verantwortlich. Auch wenn die Inhalte ausserhalb des Einflussbereichs des bzw. der Betreibenden liegt, so muss das Gesamtkunstwerk - also first party in Kombination mit third party allen WCAG-Erfolgskriterien genügen.

Wer dieses Thema schon mal anrecherchiert hat, ist womöglich über das Prinzip der "Teilkonformität" (partial conformance) gestolpert. Wichtig: diese Art der Konformität sagt mitnichten aus, dass der Webauftritt größtenteils konform angesehen wird, im Sinne von „er ist konform genug“. Es bestätigt nur, dass der Webauftritt letztendlich nicht konform zur WCAG ist, allein da er nicht (direkt) beeinflussbare Inhalte Dritter einbindet.

Das BFSG und Drittparteien-Systeme

Für das Barrierefreiheitsstärkungsgesetz gelten zwei Dinge in Bezug auf Drittparteien-Systeme:

1. Der für das Gesetz relevante Standard ist die Europäische Norm (EN) 301 549. Dies ist eine „harmonisierte“ Norm, die sich in großen Teilen auf die WCAG bezieht (konkret: aktuell WCAG Version 2.1 Level AA in ihrem Kapitel 9 referenziert). Entsprechend übernimmt die EN 301 549 Konformitätsregelungen aus der WCAG.
2. In Paragraph 19 der BFSG-Verordnung ¹ wird - unter anderem - die Anforderung definiert, dass Identifizierung-, Authentifizierungs- und Zahlungsfunktionen zugänglich angeboten werden. Die Formulierung in der Verordnung ist: "[muss] wahrnehmbar, bedienbar, verständlich und robust gestaltet werden", was man als deutliche Referenz auf die WCAG und ihre vier Grundprinzipien (Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit, Robustheit) verstehen sollte. Wenn man sich gerade Zahlungsdienste im E-Commerce in der gelebten Praxis anschaut, so sind das Drittanbieter-Dienste wie Klarna, Stripe oder Paypal – also meist externe Services. Das Barrierefreiheitsstärkungsgesetz gibt damit, meiner Lesart nach, einen doppelten Auftrag zur Zugänglichkeit gerade von Third-Party-Diensten. Einerseits durch direkten Verweis auf die WCAG, die in Sachen vollständiger Konformität die Barrierefreiheit bzw. Konformität aller Bedienelemente, gleich aus welcher Quelle, voraussetzt. Zweitens ist den Autorinnen und Autoren des BFSG (besser: der zur Grunde liegenden EU-Richtlinie 2019/882) wohl bewusst, dass nicht zugängliche z. B. Bezahlsysteme einen Flaschenhals in einem Kaufprozess darstellen können – entsprechen wird die Barrierefreiheit dieser Systeme ausdrücklich eingefordert.

Maßnahmen

Soweit also ein Grobüberblick der Anforderungen. Benutzenden ist die genaue Herkunft oder politische Geschichte eines barrierebehafteten Codes egal, für sie ist nur relevant, ob eine Web-Oberfläche benutzbar ist oder nicht. Aber welche Maßnahmen zur Analyse und Behebung von Barrieren in Third Party Skripten sollten Web-Shop-Betreibende veranlassen?

Schritt 1: Inventur

In dieser Phase stellt man sich die Frage: Welche Drittparteien setzen wir überhaupt ein? Typische Beispiele oder Orte für Ihre Suche wären:

• Cookie Banner
• Karteneinbindungen
• Videoplayer
• Zahlungsanbieter

Schritt 2: Alternativen

Wenn Sie im ersten Schritt festgestellt haben, dass Sie erstens Third Party Skripte einsetzen und diese zweitens neue Barrieren auf ihren Webauftritt bringen, stellen Sie sich die Frage: Gibt es zugänglichere Alternativen zur jeweiligen Drittpartei oder können Sie gleichwertige Alternativfassungen schaffen? Für eine per Definition nicht vollständig barrierefrei zu bekommende Karte (über z. B. Google Maps) könnte man sich überlegen, was genau der Zweck der Einbindung war und wie man die dargestellten Informationen alternativ darstellen kann. Ist es beispielsweise eine Visualisierung einer einzelnen Adresse oder die Übersicht von z. B. Filialen in einem bestimmten Gebiet? In diesem Fällen würde ein HTML-Text der Adresse oder eine datentabellarische Übersicht aller Filialen mit Adressen als ausreichender Ersatz dienen können.

Schritt 3: Auf den Hersteller einwirken

Ist eine Alternativfassung der Daten oder Funktionen, die die Drittpartei bietet nicht möglich, bleibt entweder der Ausbau der Funktion oder ein „politisches“ Einwirken auf den Dienste-Erbringer. Zu dem Thema habe ich mit den konkreten Beispiel eines Cookie-Banners schon mal auf Smashing Magazine etwas ausführlicher geschrieben (allerdings auf englisch, hier eine automatisch übersetzte deutschsprachige Fassung). Die Theorie ist, dass sich Anbietende möglicherweise in Richtung Zugänglichkeit bewegen, wenn genug Ihrer Kunden diese einfordern.

Ausblick

Wie auch bei vielen anderen Aspekten des BFSG darf man gespannt sein, wie Jurist*innen und Marktüberwachungsbehörden in der Praxis ab 2025 handeln werden. Davon unabhängig ist es immer eine gute Idee, sein eigenes E-Commerce-Projekt und seine Drittdienste auf Barrieren abzuklopfen. Dieser Artikel ist nur ein kleiner Auszug des Moduls zum Thema, dass ich in Kürze auf e-commerce-barrierefrei.de anbieten werde. Wie immer gilt: per unten stehender Mailingliste kann man über den Start des Projektes auf dem Laufenden bleiben: