Third Party

Skripte, die von extern eingebunden werden (etwa Cookie-Management, Social-Media-Einbindungen, Video-Player-Einbettungen, Analyse-Dienste und vieles mehr) 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 überwiegend mit einer Third Party wie beispielsweise PayPal geregelt – und die oben genannten Dienste finden natürlich 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 auch vermuten, Online-Shop-Betreibende sind besonders an Analytik-Diensten interessiert. Etwa, ob ein bestimmter Anteil an Besuchenden irgendwo den Kaufvorgang abbrechen. Oder ob eine Werbefläche für ein bestimmtes Produkt auf der Startseite besonders gut funktioniert. Um das herauszufinden, sind gerne Webanalyse-Software Dritter im Einsatz.

Relevant für die Web-Barrierefreiheit sind allerdings Third-Party-Skripts die eigenes HTML mitbringen, mit denen ein Nutzender konfrontiert ist. Beispiele dafür sind Cookie-Banner-Skript, der oben erwähnte Videoplayer oder Einbettungen aus Social-Media-Kanälen. Eine reale oder formale Barriere hier kann dazu führen, dass gleich mehrere Seiten des einbindenden Webauftritts als „nicht-konform“ im Sinne der WCAG gelten – und zwar unabhängig davon, wie gut und barrierefrei der Webauftritt ohne den - beispielhaft – 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 Sicht der Web Content Accessibility Guidelines (WCAG) auf Skripte und Inhalte dritter Parteien ist ziemlich eindeutig: Website-Betreibende sind für die eingebundenen Inhalte verantwortlich. Auch wenn die Inhalte außerhalb 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 „konform genug“. Es bestätigt nur, dass der Webauftritt letztendlich nicht konform zur WCAG ist, allein da er nicht (direkt) beeinflussbare Inhalte Dritter einbindet.

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

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 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?

In dieser Phase stellt man sich die Frage: Welche Drittparteien, die ihr eigenes HTML einsetzen und eventuell auch ihre eigenen Barrieren mitbringen, setzen wir überhaupt ein? Typische Beispiele oder Orte für Ihre Suche wären:

Am Ende der Inventur haben Sie nun eine Liste und Übersicht an Drittparteien in Ihrem Webauftritt erstellt. Ein letzter Teil der Bestandsaufnahme ist nun, die Zugänglichkeit oder WCAG-Konformität der einzelnen Dienste zu beurteilen. Eventuell haben Sie schon einen Audit nach z. B. EN 301 549 durchführen lassen. Wenn in diesem ausführlichem Test nicht ausgerechnet die Seiten, auf denen die betreffenden Third-Party-Skripte im Einsatz sind, außen vor gelassen wurden, haben Sie nun mindestens eine Ahnung, welche Dienste barrierebehaftet sein könnten. Ansonsten kann es Sinn ergeben, eine Web-Barrierefreiheits-Fachkraft dezidiert über diese Dienste schauen zu lassen.

Wenn Sie z. B. festgestellt haben, dass Sie a) einen z. B. Cookiebanner einsetzen, aber b) dort Barrieren durch einen zu geringen Farbkontrast entstehen, stellt sich die Frage nach Ihrem Einfluss auf die betroffene Komponente. Einige Diensteanbieter bieten dann doch gewisse Einflussmöglichkeiten auf das erzeugte HTML oder CSS, z. B. in Form von Farbanpassungen.

Abstrakter formuliert: Stellen Sie sich in diesem Schritt die Frage: Liegt das Abstellen der gefundenen Barrieren in meinem Einflussbereich? Stellt der Diensteanbieter passende Einstellungsmöglichkeiten zur Verfügung?

In der Inventurphase haben sie analysiert, welche Dienste im Einsatz sind und an welchen Stellen möglicherweise Barrieren auftreten können. Im Schritt danach haben Sie Ihren Einfluss darauf überprüft, ob Sie die Barrieren im Third-Party-Dienst abstellen können. Gelingt das nicht oder nicht vollständig ist es im nächsten Schritt an der Zeit, sich die Frage zu stellen: Gibt es zugänglichere Alternativen zur jeweiligen Drittpartei-Präsentation, -Datenquelle 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 daten-tabellarische oder Listen-Übersicht aller Filialen mit Adressen als ausreichender Ersatz dienen können.

Bei Cookiebanner oder Cookiedialogen kann es zu einigen typischen Fehlern kommen. Ich habe hier einige typische Fehlerszenarien und Barrieren zusammengefasst: The potentially dangerous non-accessibility of cookie notices (englisch, hier eine automatisch übersetzte deutschsprachige Fassung). Falls das Cookiemanagement durch ein Third-Party-Skript verwaltet wird und dieses barrierebehaftetes HTML ausspuckt, kann eine denkbare Alternative sein, das z. B. Cookiebanner und den Cookiedialog selbst zu bauen.

Hier eine kleine Liste an Aspekten, die bei einem selbstgebauten Cookiebanner zu beachten sind:

Im Medienmodul wird deutlich, dass die Europäische Norm (EN) 301 549 spezielle Anforderungen an insbesondere Videoplayer stellt. Allein aus diesen genannten Gründen ist eine Verwendung von YouTube, Vimeo, ablePlayer oder dem nativen <video>-Element (wenn man die Videoinhalte selbst hosten möchte) sinnvoll. Alle genannten Player, auch die beiden einbettbaren, werden als konform angesehen. Sofern das Embedding über einen iframe stattfindet, sollte man nicht vergessen, dem Frame per title-Attribut einen zugänglichen Namen zu geben.

Eine Formularinfrastruktur ist vermutlich in Ihrem Webshop durch den Verkauf Ihrer Wahren oder Dienstleistungen bereits vorhanden. Vorausgesetzt, diese Infrastruktur ist technisch konform und zugänglich, kann man sich die Frage stellen: Kann man Funktionen wie Formulare und Umfragen eventuell auch in „Ihrer“ Shop-Infrastruktur umsetzen, auf diese Art mehr Kontrolle und Handlungsmacht gewinnen, aber Abhängigkeiten zu Drittparteien zu verlieren?

Schlussendlich gibt es noch eine weitere Form der „Alternative“: Nämlich die eines alternativen Anbieters. Eventuell gibt es Dienste, die die gleichen Funktionen und Informationen liefern können wie die barrierebehaftete „Original“. Auch wenn diese Form der Suche mit Arbeit verbunden ist (z. B. das Klären der Fragen: Was wären Alternativen? Wie kann man feststellen lassen, ob die Alternative zugänglicher ist?), kann sie sich im Einzelfall lohnen, wenn früher genannte Strategien sich als nicht gangbar erwiesen haben. Dafür ist die in der BFSG-Verordnung und in der WCAG formulierte, wichtige Rolle für die gesamte Zugänglichkeit eines Web-Auftrittes zu wichtig.

Sind alle bisher genannten Punkte nicht machbar oder realistisch, bleibt nur die Kontaktaufnahme zum Dienstleister und ein gewisses politisches Einwirken an dieser Stelle. Je nach Konstellation kann man argumentieren:

Wie in „Maßnahmen“ formuliert, sollte man im Rahmen einer Klärung des „Ist“-Zustands der eigenen Zugänglichkeit auch eine Bestandsaufnahme der verwendeten Dritt-Parteien-Dienste vornehmen. Die Anweisung ist nun, dies im eigenen Shop-Projekt zu tun. Zur Erinnerung noch einmal mögliche Drittparteien-Dienste: