Barrierefreiheit bei Drittanbieter-Tools
Warum externe Komponenten Teil Ihrer Website bleiben
in Webdesign
Eine neue Unternehmenswebsite wurde sorgfältig aufgebaut. Die Navigation funktioniert mit der Tastatur, Kontraste wurden geprüft und Formulare haben verständliche Beschriftungen. Kurz vor dem Start kommen noch der Cookie-Banner, eine eingebettete Karte und ein externer Terminplaner hinzu. Danach bleibt der Tastaturfokus im Banner hängen, der Kalender lässt sich mit einem Screenreader kaum bedienen und die Karte verdeckt bei starker Vergrößerung den Kontaktlink.
Solche Situationen begegnen uns regelmäßig. Das eigene Frontend ist zugänglich, doch ein fremdes Skript verändert die Nutzerreise. Für Besucher spielt die technische Zuständigkeit keine Rolle. Sie wollen einen Termin buchen, eine Zahlung abschließen oder eine Filiale finden. Wenn dieser Schritt nicht funktioniert, ist die Website für sie an der entscheidenden Stelle nicht nutzbar.
Drittanbieter-Komponenten sind keine dekorativen Anhänge außerhalb der Qualitätsprüfung. Sie gehören zur Seite und oft zu einem vollständigen Prozess. Ihre Barrierefreiheit muss schon bei der Auswahl berücksichtigt, während der Integration getestet und nach Aktualisierungen erneut kontrolliert werden. Das erfordert eine andere Haltung in Webprojekten. Ein Dienst wird nicht allein nach Funktionsumfang, Preis und Datenschutz ausgewählt. Bedienbarkeit, technische Anpassbarkeit, Support und zugängliche Alternativen gehören ebenso in die Entscheidung. Je geschäftskritischer die Komponente ist, desto weniger darf sich ein Unternehmen auf eine allgemeine Aussage des Herstellers verlassen.
Aus Nutzersicht gibt es keine Grenze zwischen intern und extern
Projektteams unterscheiden sauber zwischen eigenem Code, CMS-Erweiterung, eingebettetem iFrame und extern geladenem JavaScript. Nutzer sehen diese Architektur nicht. Für sie gehört alles, was nach dem Aufruf einer Seite erscheint und zur Aufgabe benötigt wird, zu demselben Angebot.
Ein Online-Termin endet nicht am Button „Jetzt buchen“. Der Kalender, die Auswahl des Zeitfensters, persönliche Angaben und die Bestätigung bilden einen zusammenhängenden Weg. Scheitert die Tastaturbedienung bei der Uhrzeitauswahl, hilft die barrierefreie Gestaltung der vorherigen Seite nicht weiter.
Die WCAG betrachtet Konformität für vollständige Webseiten. Zusammengehörige Prozesse müssen in allen notwendigen Schritten die Anforderungen erfüllen. Ein Unternehmen kann einen problematischen Bezahlvorgang daher nicht sinnvoll mit dem Hinweis ausklammern, dass er von einem spezialisierten Anbieter stammt. Diese Sichtweise ist auch unabhängig von formalen Anforderungen vernünftig. Ein nicht erreichbarer Abschluss kostet Anfragen und Umsatz. Supportmitarbeiter müssen Aufgaben übernehmen, die digital selbstständig möglich sein sollten. Betroffene Menschen erleben eine vermeidbare Abhängigkeit.
Typische Drittanbieter sitzen an wichtigen Stellen
Externe Komponenten werden gern dort eingesetzt, wo eine Eigenentwicklung teuer oder unnötig wäre. Dazu zählen Consent-Management-Plattformen, Karten, Terminbuchungen, Chatbots, Bewerbungsportale, Newsletterformulare, Videoplayer, Bewertungswidgets, Captchas und Zahlungsdienste.
Viele dieser Werkzeuge übernehmen zentrale Funktionen. Ohne Einwilligungsdialog lässt sich die Seite möglicherweise nicht bedienen. Ohne externes Bewerbungsformular kann keine Bewerbung eingereicht werden. Ohne Zahlungsoberfläche bleibt eine Bestellung unvollständig. Die technische Abhängigkeit wird damit zu einer Abhängigkeit der Nutzer.
Auch scheinbar kleine Widgets können stören. Ein dauerhaft eingeblendeter Chatbutton überdeckt bei 400 Prozent Zoom einen wichtigen Steuereintrag. Ein Bewertungssiegel erhält Tastaturfokus, besitzt aber keinen verständlichen Namen. Ein Social-Media-Feed erzeugt eine lange Reihe schlecht beschrifteter Links. Wir erstellen früh ein Inventar der externen Bestandteile. Erfasst werden Anbieter, Funktion, Einbindungsart, betroffene Seiten und Bedeutung für den Nutzerweg. Erst diese Übersicht zeigt, welche Komponenten besonders gründlich geprüft werden müssen.
Der Cookie-Banner ist häufig die erste Barriere
Ein Consent-Banner erscheint vor dem eigentlichen Inhalt und bestimmt den ersten Eindruck. Trotzdem wird er in vielen Projekten erst am Ende konfiguriert. Das Design stammt aus einem Standardtemplate, Texte werden unter Zeitdruck ergänzt und die Tastaturbedienung bleibt ungeprüft.
Problematisch sind unsichtbare Fokuspositionen, eine unlogische Reihenfolge und Dialoge, aus denen der Fokus nicht zurückkehrt. Manchmal liegt der Tastaturfokus hinter dem sichtbaren Banner. Screenreader lesen dann Seitenelemente vor, die visuell blockiert sind. In anderen Fällen lässt sich der Dialog nicht mit Escape schließen oder die Schaltfläche zum Ablehnen ist sprachlich unklar.
Ein modaler Dialog muss seinen Zweck und seinen Namen vermitteln. Beim Öffnen gehört der Fokus an eine sinnvolle Position innerhalb des Dialogs. Tab und Umschalt-Taste plus Tab bewegen sich durch dessen bedienbare Elemente, ohne unbemerkt in die blockierte Seite zu springen. Nach dem Schließen kehrt der Fokus an eine nachvollziehbare Stelle zurück. Das lässt sich nicht zuverlässig durch optische Kontrolle beurteilen. Wir bedienen den Banner vollständig ohne Maus, testen verschiedene Zoomstufen und prüfen die Ausgabe mit Screenreader. Auch Sonderfälle gehören dazu: erneutes Öffnen der Einstellungen, Widerruf einer Einwilligung und Verhalten nach einer Sprachumschaltung.
Die Auswahl beginnt vor dem Vertragsabschluss
Auf Produktseiten stehen oft Formulierungen wie „WCAG-ready“, „ADA compliant“ oder „barrierefrei gestaltet“. Solche Aussagen können ein erster Hinweis sein, ersetzen aber keine Prüfung. Oft bleibt offen, welche Version, welches Konformitätsniveau und welche konkrete Produktoberfläche gemeint sind.
Hilfreicher sind nachvollziehbare Unterlagen. Dazu gehören ein aktueller Accessibility Conformance Report, idealerweise auf Basis einer VPAT-Struktur, dokumentierte bekannte Einschränkungen, getestete Kombinationen aus Browsern und Hilfsmitteln sowie ein erreichbarer Support für Barrieren.
Auch diese Dokumente werden kritisch gelesen. Zu klären ist, ob nur eine Marketingseite oder der gesamte Buchungsprozess geprüft wurde und ob der Bericht zur tatsächlich eingesetzten Version gehört. Zahlreiche als „nicht anwendbar“ markierte Kriterien verdienen eine genaue Kontrolle, wenn die Oberfläche entsprechende Elemente enthält. Aus unserer Erfahrung reagieren gute Anbieter konkret. Sie können bekannte Probleme benennen, einen Zeitplan für Korrekturen erläutern und Testzugänge bereitstellen. Vage Antworten und der Verweis auf ein allgemeines Zertifikat sind bei einer zentralen Komponente ein Beschaffungsrisiko.
Wenn ein Dienst bereits gekauft und technisch integriert wurde, ist der Handlungsspielraum kleiner. Die Anforderungen sollten vor der Auswahl feststehen. Neben Funktionen und Datenschutz stehen darin Tastaturbedienung, Screenreader-Kompatibilität, Vergrößerung, verständliche Fehlermeldungen und ausreichende Kontraste.
Die Liste muss zum Einsatz passen. Ein Videoplayer benötigt zugängliche Bedienelemente, Untertitel und gegebenenfalls Audiodeskription. Ein Terminplaner braucht verständliche Datums- und Zeitauswahl. Ein Zahlungsdienst muss Eingabefehler benennen und den Abschluss ohne Zeitzwang ermöglichen, soweit dieser nicht sachlich erforderlich ist. Wir prüfen ebenso, wie weit sich die Oberfläche konfigurieren lässt. Manche Komponenten sind in der Standardansicht problematisch, lassen sich aber mit einer anderen Darstellungsform, deaktivierten Animationen oder eigenen Beschriftungen verbessern. Andere kapseln ihre gesamte Oberfläche in einem fremden iFrame und erlauben kaum Einfluss.
Die Entscheidung sollte diese Unterschiede sichtbar machen. Eine kleine Bewertungsmatrix mit Muss-Kriterien, bekannten Einschränkungen und Testbefunden ist hilfreicher als ein allgemeines Bauchgefühl. Bei gleichwertigen Funktionen erhält der besser zugängliche und besser wartbare Dienst den Vorzug.
Screenshots und Verkaufsvorführungen zeigen meist den idealen Ablauf mit Maus und Standardschriftgröße. Für eine belastbare Auswahl brauchen wir Zugriff auf die echte Oberfläche. Ein kostenloser Testaccount oder eine abgegrenzte Integrationsumgebung sollte vor Vertragsabschluss verfügbar sein. Der Test beginnt bei der Startansicht, endet dort aber nicht. Fehlermeldungen, leere Ergebnisse, Zeitüberschreitungen, Bestätigungsdialoge und mobile Varianten offenbaren oft die größeren Barrieren. Gerade dynamische Zustände werden in Produktbeschreibungen selten gezeigt.
Ein kurzer Praxistest kann bereits viele Risiken aufdecken. Wir durchlaufen den zentralen Prozess mit Tastatur, starker Vergrößerung und einem gängigen Screenreader. Automatisierte Prüfungen ergänzen diesen Ablauf und finden beispielsweise fehlende Namen oder problematische ARIA-Zustände.
Für geschäftskritische Prozesse sollten Menschen mit unterschiedlichen Behinderungen einbezogen werden. Ein technischer Test erkennt nicht jede Hürde in Verständnis und Bedienung. Die Rückmeldung echter Nutzer zeigt mitunter Probleme, die in einer Checkliste korrekt aussehen und trotzdem unnötig anstrengend sind.
iFrames begrenzen den technischen Einfluss
Viele Karten, Kalender und Zahlungsdienste werden über iFrames eingebunden. Das trennt die fremde Anwendung technisch von der eigenen Seite. Stylesheets und Skripte des Websitebetreibers können den Inhalt in der Regel nicht einfach verändern. Die Einbettung selbst braucht einen aussagekräftigen Titel. Nutzer von Screenreadern sollen erkennen, ob der Frame einen Lageplan, eine Buchungsanwendung oder einen Zahlungsprozess enthält. Ein generischer Titel wie „Widget“ reicht dafür nicht.
Die Bedienbarkeit innerhalb des Frames bleibt Aufgabe des Anbieters. Fokusreihenfolge, Beschriftungen, Kontraste und Statusmeldungen lassen sich von außen kaum reparieren. Der Versuch, einzelne Fehler mit überlagerten Skripten zu korrigieren, ist meist fragil und kann nach jedem Update brechen.
Bei der Auswahl ist diese Grenze wesentlich. Je weniger Kontrolle die Integration bietet, desto stärker müssen Produktqualität, Support und vertragliche Zusagen wiegen. Für einen kritischen Prozess benötigen Unternehmen einen Ersatzweg, den sie selbst beeinflussen können. Ein Accessibility-Overlay kann die Struktur eines unzugänglichen Buchungskalenders nicht zuverlässig verstehen und reparieren. Bei fremden iFrames erreicht das Skript den eigentlichen Inhalt oft gar nicht. Auch Fokuslogik, Fehlermeldungen und komplexe Tastaturinteraktionen lassen sich nicht mit einer allgemeinen Zusatzschicht nachrüsten.
Wir sehen gelegentlich mehrere Systeme übereinander: ein Consent-Banner, ein Chatwidget und zusätzlich ein Accessibility-Menü. Jedes erzeugt eigene schwebende Schaltflächen und Dialoge. Bei Vergrößerung konkurrieren sie um denselben knappen Platz und verdecken Teile der Seite.
Der bessere Weg beginnt beim zugänglichen Produkt und einer kontrollierten Integration. Fehler werden am Ursprung behoben oder an den Anbieter gemeldet. Ist das nicht möglich, braucht es eine Alternative oder einen Anbieterwechsel. Die zusätzliche Oberfläche eines Overlays muss selbst geprüft werden. Ein Versprechen, damit automatisch alle Drittanbieter abzudecken, sollte kein Auswahlkriterium sein.
Karten und Terminbuchungen brauchen einen zweiten Weg
Interaktive Karten sind visuell hilfreich, aber für manche Nutzer schwierig zu bedienen. Viele Marker, komplexe Gesten und Informationen, die nur über Position oder Farbe vermittelt werden, erschweren Orientierung. Ein eingebetteter Kartendienst kann dabei Tastaturfokus aufnehmen, ohne einen verständlichen Ausstieg anzubieten.
Eine Adresse sollte immer als Text verfügbar sein. Öffnungszeiten, Anfahrt, Haltestellen, Parkmöglichkeiten und barrierefreie Zugänge gehören außerhalb der Karte in die Seite. Diese Informationen helfen auch Menschen mit langsamer Verbindung oder deaktivierten Drittanbieter-Inhalten.
Für mehrere Standorte ist eine zugängliche Liste oder Suchfunktion sinnvoll. Ergebnisse brauchen klare Namen und Kontaktdaten. Eine Karte kann diese Darstellung ergänzen, darf aber nicht die einzige Möglichkeit sein, einen Standort zu finden. Bei der Einbindung prüfen wir Zoomverhalten, Fokus, verständliche Beschriftung des Frames und die Darstellung auf kleinen Bildschirmen. Ein einfacher Link zum Kartendienst kann in manchen Fällen besser funktionieren als ein schwer kontrollierbares Embed.
Ein Kalender wirkt mit der Maus oft unkompliziert: Monat auswählen, Tag anklicken, Uhrzeit bestätigen. Mit der Tastatur kann dieselbe Oberfläche aus Dutzenden unbeschrifteten Feldern bestehen. Screenreader benötigen Informationen über Datum, Verfügbarkeit, Auswahlzustand und Navigation zwischen Monaten.
Wir testen eine Buchung vom Einstieg bis zur Bestätigung. Dazu gehören Zeitzone, Pflichtfelder, Datenschutzangaben, Fehlermeldungen und der Link zum Stornieren. Nach einer Eingabe darf der Fokus nicht unerwartet an den Seitenanfang springen. Ein alternatives Kontaktformular oder eine Telefonnummer kann helfen, sofern der Weg gleichwertig und zumutbar ist. „Rufen Sie uns an“ ist keine gute pauschale Lösung, wenn Onlinebuchungen rund um die Uhr möglich sind, am Telefon aber nur ein kurzes Zeitfenster angeboten wird.
Bei wiederkehrenden Terminen oder komplexen Ressourcen lohnt sich manchmal eine eigene zugängliche Oberfläche vor der Anbieter-API. Das erhöht Entwicklungsaufwand, gibt dem Unternehmen aber Kontrolle über die Nutzererfahrung. Ob dieser Weg wirtschaftlich ist, hängt von Bedeutung und Zahl der Buchungen ab.
Chats, Zahlungen und Captchas im Praxistest
Chatwidgets erscheinen oft als schwebender Button in einer Ecke. Auf dem Desktop wirkt das unauffällig. Bei 200 oder 400 Prozent Vergrößerung kann der Button Navigation, Cookie-Einstellungen oder Formulare verdecken. Auf kleinen Geräten nimmt das geöffnete Fenster manchmal fast den gesamten Bildschirm ein.
Der Auslöser braucht einen verständlichen Namen und einen sichtbaren Fokus. Das Chatfenster verhält sich je nach Umsetzung wie ein Dialog und benötigt eine nachvollziehbare Fokusführung. Neue Nachrichten sollten angekündigt werden, ohne Screenreader-Nutzer mit jeder Statusänderung zu unterbrechen. Auch die Inhalte zählen. Ein Bot, der nur vorgegebene Schaltflächen mit unklaren Bezeichnungen anbietet, kann einfache Fragen unnötig erschweren. Fehlende Möglichkeit zum Kontakt mit einem Menschen ist besonders problematisch, wenn der Bot den regulären Support ersetzen soll.
Wir prüfen, ob sich das Widget deaktivieren oder bewusst erst nach Nutzeraktion laden lässt. Eine zurückhaltende Einbindung ist oft angenehmer für alle Besucher und reduziert Konflikte mit anderen schwebenden Komponenten.
Beim Bezahlen sind Nutzer konzentriert und oft unter Zeitdruck. Wenn ein Feld nur rot umrandet wird, erfahren blinde Menschen den Fehler möglicherweise nicht. Springt die Seite nach dem Absenden an eine unbekannte Stelle, wird die Korrektur zum Suchspiel. Ein zugänglicher Prozess benennt fehlerhafte Felder, beschreibt die notwendige Korrektur und führt den Fokus sinnvoll. Informationen zu Betrag, Zahlungsart und Abschluss müssen programmatisch erkennbar sein. Sicherheitsverfahren wie zusätzliche Bestätigungen gehören ebenfalls in den Test.
Der Wechsel zu einer externen Domain oder App sollte verständlich angekündigt werden. Nach Rückkehr in den Shop muss der Status stimmen. Abgebrochene und fehlgeschlagene Zahlungen dürfen nicht dieselbe Bestätigung erzeugen.
Bei der Beschaffung wiegen Support und Reaktionszeiten schwer. Ein Fehler im Zahlungsprozess betrifft unmittelbar den Umsatz. Ein Anbieter, der Barrieren nur in einem allgemeinen Backlog führt, passt nicht zu einem geschäftskritischen Einsatz. Captchas sollen Missbrauch verhindern, schließen aber immer wieder reale Nutzer aus. Bilderrätsel verlangen visuelle Erkennung, Audioaufgaben sind schwer verständlich und interaktive Prüfungen können bei motorischen Einschränkungen scheitern. Manche Verfahren funktionieren zudem schlecht mit Datenschutz- oder Scriptblockern.
Eine Audioalternative macht ein Captcha nicht automatisch zugänglich. Tonqualität, Sprache, Zeitlimit und Bedienbarkeit müssen geprüft werden. Nutzer mit mehreren Einschränkungen benötigen möglicherweise einen anderen Weg.
Technisch gibt es oft bessere Schutzmaßnahmen: Rate Limits, serverseitige Plausibilitätsprüfung, Honeypots, risikobasierte Erkennung und Bestätigungsschritte. Keine einzelne Maßnahme verhindert jeden Angriff. Eine Kombination kann jedoch weniger Barrieren erzeugen als ein obligatorisches Rätsel. Falls ein externer Captcha-Dienst unvermeidbar ist, sollte er erst bei auffälligem Verhalten erscheinen und eine erreichbare Alternative bieten. Der Schutz des Formulars darf nicht dazu führen, dass reguläre Anfragen unmöglich werden.
Eigene Anpassungen bleiben Wartungsarbeit
Einbettungen lassen sich auf der eigenen Seite positionieren, beschriften und in ein responsives Layout setzen. Diese Arbeiten ändern nichts an der internen Qualität des fremden Widgets. Ein schöner Rahmen repariert keine unbedienbare Datumsauswahl.
Bei Skriptkomponenten ist der Einfluss manchmal größer. Anbieter stellen Themes, CSS-Variablen, Sprachdateien oder Callbacks bereit. Damit können Kontraste, Beschriftungen und Fokus nach bestimmten Ereignissen verbessert werden. Solche Anpassungen müssen dokumentiert und nach Updates kontrolliert werden.
Wir vermeiden CSS-Regeln, die tief auf wechselnde interne Klassen des Anbieters zielen. Sie brechen leicht und werden selten in dessen Versionshinweisen berücksichtigt. Offizielle Konfigurationsmöglichkeiten oder stabile Schnittstellen sind belastbarer. Wo eigene Ergänzungen nötig sind, gehören sie in den regulären Entwicklungsprozess. Quellcode, Tests, Verantwortlichkeit und Rückbauplan müssen vorhanden sein. Ein unbekanntes Snippet aus einem alten Ticket ist keine dauerhafte Lösung.
Die Alternative muss wirklich gleichwertig sein
Wenn ein Drittanbieter kurzfristig nicht zugänglich gemacht werden kann, ist eine alternative Durchführung oft der pragmatische Weg. Sie muss dieselbe Aufgabe ermöglichen und leicht auffindbar sein. Ein versteckter Hinweis im Impressum hilft niemandem, der im Buchungsprozess feststeckt.
Gleichwertigkeit betrifft mehr als das Ergebnis. Erreichbarkeit, Öffnungszeiten, Kosten und Bearbeitungsdauer spielen ebenfalls eine Rolle. Ein Formular rund um die Uhr durch eine Hotline von Montag bis Freitag zu ersetzen, verschlechtert die Leistung deutlich.
Die Alternative sollte direkt vor oder bei der problematischen Komponente angeboten werden. Ihre Formulierung benennt die mögliche Hürde sachlich und erklärt den nächsten Schritt. Nutzer müssen keine Behinderung offenlegen, um Unterstützung zu erhalten. Aus unserer Erfahrung funktionieren einfache, gut gepflegte Ersatzwege besser als komplexe Sonderlösungen. Eine zugängliche Liste neben der Karte oder ein normales Kontaktformular neben dem Kalender hilft ganz unterschiedlichen Nutzern.
Verträge und Updates zusammen denken
Eine einmalige Produktprüfung schützt nicht vor späteren Änderungen. Externe Dienste werden ohne Zutun des Websitebetreibers aktualisiert. Neue Designs, zusätzliche Felder oder geänderte Skripte können eine funktionierende Integration innerhalb eines Tages verändern.
Beschaffungsverträge sollten Zuständigkeiten für Barrieren, Reaktionszeiten und Informationen über relevante Änderungen festhalten. Ein benannter Ansprechpartner ist wertvoller als ein allgemeines Supportformular. Bei kritischen Problemen braucht der Betreiber eine Eskalationsmöglichkeit.
Auch ein Sonderkündigungsrecht oder ein exportierbarer Datenbestand kann den späteren Wechsel ermöglichen. Wenn ein Anbieter grundlegende Barrieren über Monate nicht behebt, muss ein Wechsel praktisch möglich bleiben. Technische und vertragliche Abhängigkeit gehören zusammen betrachtet. Kleine Standarddienste bieten selten individuell verhandelte Klauseln. Dann entscheidet die Risikobewertung, ob der Dienst für eine zentrale Funktion geeignet ist. Ein günstiges Widget kann teuer werden, wenn später ein Ersatz unter Zeitdruck entwickelt werden muss.
Bei eigenem Code entscheidet das Team über Veröffentlichungen. Ein fremdes Skript kann sich dagegen jederzeit ändern. Zentrale Drittanbieter gehören in die laufende Qualitätskontrolle.
Automatisierte Tests können prüfen, ob der Auslöser einen zugänglichen Namen besitzt, ein Dialog erscheint oder zentrale Elemente erreichbar bleiben. Sie erkennen jedoch nicht zuverlässig, ob ein kompletter Buchungskalender mit Screenreader verständlich ist. Ergänzend braucht es wiederkehrende manuelle Tests der zentralen Wege. Das Intervall richtet sich nach Änderungsrate und Risiko. Ein Zahlungsprozess verdient engere Kontrolle als ein optionaler Social-Media-Feed.
Supportmeldungen von Nutzern sind ebenfalls ein Signal. Sie müssen den zuständigen Produkt- oder Websiteverantwortlichen erreichen und dürfen nicht als individuelles Bedienproblem abgetan werden. Wiederkehrende Schwierigkeiten gehören in das Fehler- und Anbietermanagement.
Ein Komponentenregister klärt die Zuständigkeit
Bei gewachsenen Websites weiß oft niemand vollständig, welche externen Dienste geladen werden. Marketing ergänzt ein Trackingtool, Recruiting bindet ein Bewerbungsportal ein und der Vertrieb installiert einen Chat. Die Komponenten erscheinen auf unterschiedlichen Unterseiten und werden von verschiedenen Dienstleistern betreut.
Ein Register hält Name, Zweck, Anbieter, Einbindungsart, betroffene Seiten, Verantwortliche und letzten Prüftermin fest. Hinzu kommen bekannte Barrieren, Konfigurationen, Vertragslaufzeit und vorhandene Alternativen. Das muss kein schweres Governance-System sein; für kleinere Auftritte reicht eine gepflegte Tabelle. Technische Scans helfen beim Auffinden externer Domains und Skripte. Sie zeigen aber nicht immer, welche Geschäftsfunktion dahintersteht. Die Inventur verbindet technische Erkennung mit dem Wissen der Fachabteilungen.
Beim Relaunch oder Anbieterwechsel wird das Register zur Arbeitsgrundlage. Alte Komponenten werden nicht unbemerkt übernommen. Neue Dienste durchlaufen denselben Auswahl- und Prüfprozess.
Ein Anbieter entwickelt das Widget, der Websitebetreiber entscheidet über seinen Einsatz. Diese geteilte Situation führt leicht zu gegenseitigen Verweisen. Für betroffene Nutzer bleibt währenddessen die Barriere bestehen. W3C empfiehlt Organisationen, beschaffte und syndizierte Drittinhalte in ihrer Accessibility-Policy zu berücksichtigen. Gerade bei wesentlichen Funktionen sollen Anbieter nach ihrer Zugänglichkeit ausgewählt und Alternativen vorgesehen werden.
Die WCAG kennt unter engen Bedingungen Aussagen zur teilweisen Konformität bei nicht kontrollierbaren Drittinhalten. Das ist kein Freibrief für bewusst eingekaufte, dauerhaft unzugängliche Kernprozesse. Eine Konformitätsaussage sollte genau beschreiben, welche Seiten und Prozesse tatsächlich geprüft wurden.
Praktisch braucht es eine interne Person, die Entscheidungen treffen kann. Sie koordiniert Fachbereich, Einkauf, Entwicklung und Anbieter. Ohne diese Rolle bleiben Befunde zwischen Tickets und Vertragsfragen liegen.
So prüfen wir eine externe Komponente
Am Anfang steht der konkrete Nutzerweg. Wir beschreiben, welche Aufgabe mit der Komponente erledigt wird und welche Zustände auftreten. Erst danach betrachten wir einzelne WCAG-Kriterien und technische Details. Der Test umfasst Tastaturbedienung, sichtbaren Fokus, Screenreader-Ausgabe, Zoom und mobile Darstellung. Formulare werden mit korrekten und fehlerhaften Eingaben durchlaufen. Dynamische Meldungen, Dialoge und Rücksprünge erhalten besondere Aufmerksamkeit.
Gefundene Barrieren werden nach Auswirkung priorisiert. Ein nicht erreichbarer Absende-Button blockiert den Prozess. Eine unklare Zusatzbeschreibung erschwert ihn. Diese Unterscheidung hilft bei Auswahl und Eskalation.
Eine reine Fehlerliste reicht als Ergebnis nicht aus. Wir dokumentieren mögliche Konfigurationen, eigene Anpassungen, Aussagen des Anbieters und einen Ersatzweg. So kann das Projektteam eine belastbare Entscheidung treffen. Zuerst werden alle externen Komponenten gesammelt. Browser-Entwicklungswerkzeuge, Consent-Konfiguration und Gespräche mit Fachabteilungen liefern gemeinsam ein vollständigeres Bild als eine einzelne Quelle.
Danach ordnet das Team die Komponenten nach Bedeutung. Alles, was Anmeldung, Kauf, Buchung, Bewerbung, Kontakt oder Einwilligung ermöglicht, erhält hohe Priorität. Rein ergänzende Inhalte folgen später.
Für jede zentrale Komponente wird mindestens ein vollständiger Ablauf ohne Maus geprüft. Starke Vergrößerung und ein Screenreader-Test ergänzen die Bewertung. Bekannte Fehler erhalten Verantwortliche und Termine. Wo eine schnelle Korrektur nicht möglich ist, wird eine zugängliche Alternative sichtbar angeboten. Parallel beginnt die Klärung mit dem Anbieter. Ergebnisse und erneute Prüfungen landen im Komponentenregister.
Was wir Unternehmen konkret empfehlen
Wenn wir eine bestehende Website prüfen, beginnen wir nicht mit jedem Social-Media-Feed. Zuerst kommen die Stellen an die Reihe, an denen Nutzer etwas erledigen müssen: Einwilligung, Kontakt, Buchung, Bewerbung und Zahlung. Dort führt eine Barriere unmittelbar zum Abbruch.
Für neue Dienste verlangen wir einen Testzugang, bevor die technische Entscheidung gefallen ist. Der wichtigste Ablauf wird ohne Maus, mit Vergrößerung und mit Screenreader durchgespielt. Bleiben wesentliche Fehler offen und bietet der Hersteller weder belastbare Abhilfe noch einen Zeitplan, suchen wir weiter. Ein später Anbieterwechsel kostet fast immer mehr als diese Prüfung.
Bei bereits eingebauten Werkzeugen ist der erste sinnvolle Schritt ein Komponentenregister mit Verantwortlichen. Danach braucht jeder blockierte Prozess entweder eine Korrektur oder einen auffindbaren, gleichwertigen Ersatzweg. An dieser Stelle zeigt sich die Qualität einer Integration sehr viel deutlicher als in einem Zertifikat oder einer Herstellerpräsentation.