Die deutsche Synchronsprecherin Vivien Faber hat auf der Social-Media-Plattform Threads einen Beitrag veröffentlicht, wonach sich deutsche Synchronsprecher und -sprecherinnen seit Anfang Januar weigern, für Netflix zu arbeiten. Auslöser des Streits soll eine neue KI-Trainingsklausel für kommende Projekte des Videostreamingdienstes sein.

Laut Faber habe dies zur Folge, dass demnächst Filme und Serien auf Netflix ohne deutsche Synchronisation erscheinen. Konkret dreht es sich dabei um Eigenproduktionen (Originals) und Exklusivtitel, bei denen die Synchronisation in der Hand des Dienstes liegt. Zugekaufte Inhalte werden oftmals bereits mit deutscher Synchronfassung angeliefert.

Sprecherverband: Netflix verweigert Gespräche

Der Verband Deutscher Sprecher:innen (VDS) führt in einer aktuellen Mitteilung weiter aus, dass Netflix’ neue Klauseln unter anderem eine Rechteabtretung beinhalten, nach der der Dienst künftige Synchronaufnahmen für KI-Trainingszwecken nutzen dürfte, eine Vergütung dafür aber nicht regelt.

Auf Nachfrage teilte eine Sprecherin heise online zudem mit, dass man Netflix mehrfach signalisiert habe, für Verhandlungen bereitzustehen, um eine Lösung zu finden. Diese Kontaktaufnahmen seien bislang vom Dienst ignoriert worden. Die Forderung des VDS sei sehr klar: „Einwilligung zur Verarbeitung persönlicher Daten zu KI-Trainingszwecken muss freiwillig erfolgen und darf keine Voraussetzung für eine Beschäftigung sein“. Daher prüfe der VDS die Rechteabtretung unter allen juristischen Gesichtspunkten und unterstützen die Sprecher und Sprecherinnen in ihren Forderungen.

c’t hatte bereits Mitte vergangenen Jahres mit der Synchronsprecherin Ranja Bonalana ein Interview geführt, warum der Sprecherverband eine umfassende Regulierung für KI-Stimmen fordert. Dieser Beitrag ist nun frei abrufbar.

Bonala hatte darin davon berichtet, dass Netflix beim Start auf dem deutschen Markt erst gar nicht synchronisieren wollte. Der Dienst habe gedacht, einfach alles im O-Ton veröffentlichen zu können und die Leute würden es trotzdem konsumieren. Damit sei er dann krachend gescheitert.

Der Verband hatte im April vergangenen Jahres die Petition „Schützt die Kunst vor KI“, für die mittlerweile über 90.000 Unterschriften zusammengekommen sind.

(nij)

Das US-Verkehrsministerium will Regeln für die Verkehrssicherheit künftig von KI-Technik vorfertigen lassen, Beamten und Beamtinnen sollen diese dann nur noch korrekturlesen. Eine erste Regel der Flugaufsicht wurde sogar schon KI-gestützt verfasst, ist aber noch unveröffentlicht. Das berichtet das US-Magazin ProPublica unter Berufung auf mehrere Quellen, die bei internen Vorstellungen der Pläne anwesend waren. Der Justiziar des Ministeriums habe dabei deutlich gemacht, dass damit vor allem der Prozess der Erarbeitung von Vorgaben beschleunigt werden soll. „Wir brauchen nicht die perfekte Regel für XYZ, wir brauchen nicht einmal eine sehr gute Regel für XYZ“, zitiert ProPublica aus der Mitschrift der Aussagen von Gregory Zerzan: „Wir wollen gut genug.“ Weiterhin habe er erklärt: „Wir überschwemmen den Bereich.“

Geschwindigkeit als oberstes Gebot

Die Ankündigung habe im Ministerium Besorgnis ausgelöst, schreibt ProPublica. Immerhin sei das Haus für Regeln zuständig, die so gut wie jeden Bereich der Transport- und Verkehrssicherheit betreffen. Dabei gehe es um die Sicherheit von Flugzeugen, Pipelines oder des Güterverkehrs. Gegenwärtig dauere es Monate oder gar Jahre, die komplexen Vorgaben zu verfassen, die in den gesamten Vereinigten Staaten gelten sollen. Mit einer eigenen Version von Googles Gemini, die dafür zum Einsatz kommen soll, würden nur noch Minuten oder gar Sekunden benötigt. Erklärtes Ziel ist es dem Bericht zufolge, die Erstellung von Verkehrsregeln drastisch zu verkürzen. Von der Idee bis zur Vorlage beim Office of Information and Regulatory Affairs, das diese dann prüfen muss, sollen maximal 30 Tage vergehen.

Bei einer internen Vorstellung der Pläne wurde demnach erklärt, dass Gemini 80 bis 90 Prozent der Erstellung von Regularien übernehmen soll. Um die Leistungsfähigkeit vorzuführen, habe die KI-Technik während der Präsentation eine typische Ankündigung für eine geplante Regel erstellen sollen. Diese werden vorab veröffentlicht, damit die Öffentlichkeit dazu Stellung nehmen kann. Im konkreten Fall habe in der KI-generierten Version aber offenbar genau jener Text gefehlt, der die Regel ausführt. Trotzdem hätten sich die Verantwortlichen nicht besorgt gezeigt, dass die sogenannten Halluzinationen von KI-Textgeneratoren für Probleme sorgen könnten. Und selbst wenn, wäre es dann an den Beamten und Beamtinnen des Ministeriums, solche Fehler zu finden und zu entfernen.

Von den Verantwortlichen hat ProPublica keine Stellungnahme zu dem Bericht erhalten, wohl aber von den anonymen Quellen aus dem Ministerium. Diese hätten darauf hingewiesen, dass die Ausarbeitung von Vorschriften eine komplexe Aufgabe sei, die viel Fachwissen erfordere. Beachtet werden müssten bestehende Gesetze und andere Vorschriften, aber auch Rechtsprechung durch Gerichte. Fehler oder Versäumnisse bei der Formulierung könnten zu Rechtsstreitigkeiten oder sogar Verletzungen und Todesfällen führen. Sogar der ehemalige KI-Chef des Ministeriums hat die Pläne demnach kritisiert. Mike Hortin hat das Amt Ende August aufgegeben, als es die Pläne noch nicht gegeben hatte. Für ihn klinge das, als würde man „einen Highschool-Praktikanten die Vorschriften ausarbeiten lassen“.

(mho)

Mit dem European Accessibility Act (EAA) und seiner nationalen Umsetzung durch das Barrierefreiheitsstärkungsgesetz (BFSG) gelten seit Juni 2025 in Deutschland verbindliche Anforderungen für zahlreiche digitale Produkte und Dienstleistungen. Parallel dazu wurden die organisatorischen Voraussetzungen geschaffen: Die zuständige Marktüberwachungsbehörde ist eingerichtet und nimmt schrittweise ihre Arbeit auf. Damit rückt Barrierefreiheit für viele Unternehmen erstmals in den konkreten Fokus von Compliance, Risikoabwägung und Produktverantwortung.

Und es wächst der Wunsch nach effizienten, skalierbaren Lösungen. Viele Organisationen hoffen auf automatisierte Accessibility-Checks als schnellen und möglichst vollständigen Weg zur Konformität. Entsprechend populär sind Linter, Browser-Extensions, CI/CD-Integrationen und KI-gestützte Prüfwerkzeuge. Automatisierung ist dabei ein wichtiges und sinnvolles Werkzeug – doch sie hat klare technische Grenzen.

Denn zahlreiche Barrieren lassen sich nicht maschinell erkennen. Sie entstehen durch fehlenden Kontext, unklare Bedeutung, komplexe Interaktionen oder mangelnde Verständlichkeit – Aspekte, die menschliches Urteilsvermögen erfordern. Dieser Artikel zeigt, welche Arten von Accessibility-Tools es gibt, welche Aufgaben sie sinnvoll übernehmen können und warum ein erheblicher Teil der Barrieren auch mit modernster Automatisierung unsichtbar bleibt.

Testwerkzeuge und ihre Grenzen

Um die Möglichkeiten und Grenzen automatisierter Barrierefreiheitsprüfungen zu verstehen, lohnt sich zunächst ein Blick auf die unterschiedlichen Werkzeugtypen und darauf, welche Aspekte von Accessibility sie jeweils erfassen können.

Linter sind statische Analysetools für Quellcode. Sie erkennen syntaktische oder strukturelle Fehler, etwa ob ein alt-Attribut fehlt oder ein Button kein Label besitzt. Allerdings haben sie keine Kenntnis darüber, wie sich Seiten im Browser verhalten, wie Fokusabläufe funktionieren oder ob interaktive Komponenten korrekt reagieren. Statische Tools sehen nur Code – nicht Nutzung.

Browser-Extensions analysieren hingegen das Document Object Model (DOM) im gerenderten Zustand und können so mehr erkennen als statische Analyzer. Dennoch bleiben sie „Snapshot-Tools“: Sie bewerten einen Zustand, aber nicht die Interaktion über mehrere Schritte hinweg. Komplexe Fokusänderungen, Tastaturfallen oder dynamisch aktualisierte Inhalte bleiben typischerweise unsichtbar.

Unit-Test-Plug-ins sind nützlich, um bestimmte einzelne Komponenten auf Barrieren zu prüfen. Allerdings decken Unit-Tests die Funktionalität (zum Beispiel Tastaturbedienbarkeit) nur einer Komponente ab und bilden typischerweise keine vollständigen Nutzerflows ab.

End-to-End-Testtools bieten eine größere Abdeckung. Sie können komplexere Interaktionen simulieren, etwa die Fokussteuerung beim Öffnen und Schließen eines Modals, also eines Dialogs, der sich über die Inhalte der Seite legt und oft eine zusätzliche Aktion beinhaltet. An solche Testszenarien müssen Entwicklerinnen und Entwickler jedoch selbst denken. Werden Accessibility-Plug-ins integriert, lassen sich einige Aspekte automatisiert prüfen. Das umfangreichste Ergebnis erhält man, indem man Testfälle für wichtige Prozesse selbst schreibt und zusätzlich verschiedene Zustände seiner Website über automatisierte Plug-ins prüfen lässt. Doch auch dann bleibt ein grundsätzliches Problem: End-to-End-Tests wissen nicht, ob ein Bedienablauf „logisch“ oder „verständlich“ ist. Sie führen Befehle aus – aber sie „erleben“ die Nutzung nicht so, wie es ein Mensch tut.

CI/CD-Scanner automatisieren Prüfungen im Build- oder Deployment-Prozess. Sie eignen sich besonders gut dafür, typische fehlerhafte Muster frühzeitig aufzudecken und Regressionen zu vermeiden. Ihre Grenzen sind jedoch die gleichen wie die der zugrunde liegenden Tools. Ob man Linter, Browsererweiterungen, Unit-Tests oder End-to-End-Tests einbindet: Sie prüfen Code, Struktur und einfache Interaktionen – aber keine komplexen Navigationsabläufe oder inhaltlichen Bedeutungen.

Alle diese Werkzeuge leisten wertvolle Beiträge im Entwicklungsprozess. Doch wie viel Testaufwand lassen sie noch übrig?

Wie viel Automatisierung wirklich leisten kann: Erkenntnisse aus Studien und Praxis

Mehrere Studien haben untersucht, wie hoch der Anteil der Barrieren ist, den automatisierte Tools tatsächlich erkennen können. Eine umfassende Analyse des Accessibility-Software-Anbieters Deque Systems ergab 2024, dass dessen automatisierte Tests etwa 57 Prozent aller Accessibility-Probleme in realen Audits identifizieren konnten. Mit KI-Unterstützung will das Unternehmen sogar gut 80 Prozent erreicht haben.

Accessibility-Praktikerinnen und -Praktiker sehen die Wirksamkeit der automatisierten Tools deutlich eingeschränkter und schätzen, dass sich nur 20 bis 40 Prozent der potenziellen Barrieren technisch erkennen lassen. Mehrere Expertinnen und Experten, darunter Adrian Roselli und Steven Faulkner, berichten aus umfangreichen Feldtests, dass automatisierte Checks sogar nur 4 bis 10 Prozent der wirklichen Probleme erkennen.

Womit lässt sich diese Diskrepanz in den Schätzungen erklären? Natürlich unterscheiden sich die Zahlen der Marketing-Abteilung und der unabhängigen Accessibility-Beratung, weil sie damit unterschiedliche Ziele verfolgen. Auch die absichtlich eingefügten Bugs, die die Testseiten enthalten, unterscheiden sich, und somit auch die Testergebnisse. WCAG-Versionen (Web Content Accessibility Guidelines), genutzte Tools – all das sorgt für eine hohe Varianz in Schätzungen.

Trotz der Unterschiede zeigen diese Zahlen eindeutig, dass die existierenden Tools noch nicht hundertprozentig beurteilen können, ob eine Website barrierefrei ist. Selbst die formelle Prüfung der WCAG-Kriterien ist noch nicht zu 100 Prozent automatisiert möglich.

Typische Limitierungen und Fallbeispiele

Auch wenn Barrierefreiheit deutlich mehr als stupide Einhaltung der WCAG-Erfolgskriterien erfordert, stellen diese Richtlinien eine fundierte Checkliste zum Einstieg dar. Die darin enthaltenen Anforderungen betreffen sowohl die technische als auch die semantische Seite der Inhalte, das heißt, wie sie programmatisch zur Verfügung gestellt werden und wie verständlich sie formuliert sind.

Automatisierte Accessibility-Tools können in erster Linie Strukturen, Muster und technische Eigenschaften prüfen. Sie erkennen fehlende Attribute, inkorrekte Rollen oder syntaktische Fehler – aber sie verstehen nicht, was Inhalte bedeuten, wie Nutzerinnen und Nutzer mit einer Anwendung interagieren oder wie logisch ein Interface aufgebaut ist.

Deswegen lohnt sich der Blick auf die WCAG-Kriterien aus folgender Perspektive: Welche Anforderungen betreffen nicht nur Strukturen und formelles Vorhandensein von bestimmten Elementen, sondern auch Aspekte wie intuitive Nutzung, Interpretation, Kontext und Relevanz? Dabei stehen die Kriterien der Konformitätsstufen A und AA (siehe Infokasten) im Fokus, da sie von sämtlichen Barrierefreiheitsgesetzen als rechtliche Anforderung genannt werden. Die WCAG-Richtlinien basieren auf den Grundprinzipien der Barrierefreiheit für Webinhalte – Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit. Rund um diese Prinzipien sind auch die Beispiele in diesem Artikel gruppiert.