Künstliche Intelligenz
Vernetzte Fernseher vor Gericht: Open Source Code muss nicht installierbar sein
Wer Open Source in Produkte einbaut, muss die Lizenzbedingungen beachten. Dazu gehört häufig die Pflicht, den auf einem Gerät genutzten Source Code mitzuliefern oder auf Anfrage herauszugeben. Doch ob der Hersteller wirklich den echten Code herausrückt, lässt sich womöglich nie prüfen. Denn auf dem Gerät installierbar sein muss der Code nicht, sagt ein kalifornisches Gericht.
Weiterlesen nach der Anzeige
Was diese Zwischenentscheidung im weiteren Gerichtsverfahren und, sofern sie rechtskräftig wird, später in der Praxis bedeutet, ist unklar. Umstritten ist sogar, was die Verfahrensparteien bei Gericht genau beantragt haben.
Worüber gestritten wird
Anlass zu dem Gerichtsverfahren hat das Unternehmen Vizio gegeben, das unter anderem vernetzte Fernseher verkauft und dann mit Werbung und Daten über die Sehgewohnheiten seiner Kunden Geld verdient. Vizio liefert seine Fernseher unter anderem mit vorinstallierter Open-Source-Software aus, darunter Linux-Kernels, die unter der GNU General Public License Version 2 (GLPv2) sowie der GNU Lesser General Public License Version 2.1 (LGLPv2.1) lizenziert sind. Diese Lizenzen verlangen, dass mit dem Produkt der Source Code oder ein Angebot zu dessen Herausgabe geliefert werden. Dem ist Vizio, das seit 2024 Walmart gehört, nicht nachgekommen.
Die gemeinnützige Software Freedom Conservancy (SFC) aus New York hat ab 2018 Vizio-Farbfernseher gekauft und dann den Source Code beantragt. In jahrelangem Hin und Her schickte Vizio mehrfach Code, der aber immer unvollständig oder nicht kompilierbar war. 2021 ging die SFC unter Berufung auf kalifornisches Vertragsrecht (und nicht Copyright) zu Gericht und erkämpfte 2023 zwei wichtige Zwischenentscheidungen über Open Source: Demnach wirken die Lizenzen als Verträge zugunsten Dritter. Nicht nur die Copyright-Inhaber können die Lizenz unter Berufung auf Copyright durchsetzen, sondern auch Käufer des Geräts unter Berufung auf Vertragsrecht.
Vizio wird zumindest etwas herausrücken müssen
Anfang Dezember 2025 teilte die zuständige Richterin des kalifornischen Superior Court im County of Orange mit, dazu zu neigen, zu entscheiden, dass Vizio der SFC tatsächlich die Source Codes für ein bestimmtes Fernseher-Modell herausgeben muss. Ob Vizio darüber hinaus den Source Code aller seiner Fernseher, die mit Software unter GPL oder LGPL laufen, allen Kunden mitliefern oder in bestimmter Form anbieten muss, soll in einem Gerichtssaalverfahren geklärt werden. Unter anderem sieht die Richterin widersprüchliche Äußerungen der Free Software Foundation, die diese Lizenzen formuliert hat.
Doch zu Festivus 2025 überraschte die Richterin mit einer Zwischenentscheidung auf Antrag Vizios: Demnach verpflichten die Lizenzen Vizio tatsächlich dazu, den Source Code so zur Verfügung zu stellen, dass er leicht erlangt und modifiziert werden kann. Das umfasst auch Scripte für Kompilation und Installation.
Weiterlesen nach der Anzeige
Das bedeute aber nicht, dass Vizio allen Nutzern die Wiederinstallation der Software, modifiziert oder nicht (!), auf seinen vernetzten Fernsehern in einer Weise ermöglichen muss, die alle Funktionen des Originalprogramms erhält und/oder sicherstellt, dass die Fernseher weiter ordentlich funktionieren. Vielmehr diene die Herausgabepflicht der Weiternutzung der Software für andere (!) Anwendungen.
Linus Torvalds schilt SFC
Das veranlasste Linus Torvalds dazu, beide Verfahrensparteien öffentlich zu schelten: Vizio, weil es den Source Code nicht verfügbar gemacht hat, und die SFC, weil sie auch die für die Installation erforderlichen Schlüssel verlangt habe. Das hat die SFC aber gar nicht verlangt.
Die SFC verteidigte sich noch am Heiligen Abend öffentlich: Natürlich habe sie nie behauptet, dass die Open-Source-Lizenzen verlangten, dass vom Nutzer modifizierte Software auf dem Gerät von Rechts wegen zu funktionieren haben. (So eine Behauptung wäre auch absurd, schließlich weiß man ja nicht, in welcher Weise der Nutzer die Software verändert, Anmerkung.) Zudem komme auch andere Software zum Einsatz, die Vizio unstrittig nicht herausgeben muss. Überhaupt stelle Vizios Antrag auf Dinge ab, über die gar nicht gestritten werde.
Allerdings bezieht sich die Zwischenentscheidung des Gerichts ausdrücklich auch auf nicht-modifizierte Software. Und in der Tat kann ein Hersteller sein Gerät kryptographisch so verrammeln, dass Nutzer überhaupt nichts darauf installieren können, auch nicht die unveränderte Originalsoftware. Auch das verbieten GPL und LGPL unstrittig nicht.
Diesen Weg geht Vizio, weil es ja sein Geld weniger mit dem Verkauf der Fernseher, sondern vielmehr mit der Verwertung der später mit dem Gerät geernteten Daten verdient. Das ist branchentypisch bei „Smart TV“. Könnten Käufer eigene Software installieren und dabei auf Überwachungsroutinen verzichten, entginge Vizio der Reibach.
Verhandlung verschoben
Und tatsächlich hat die SFC nie verlangt, dass Vizio die kryptographischen Schlüssel herausrückt. Allerdings spricht die ursprüngliche Klage von den Vorzügen der gegenständlichen Open-Source-Lizenzen und erwähnt dabei Beispiele, bei denen der Code angepasst und auf dem Gerät installiert wird. Das geht bei Vizios vernetzten Fernsehern ohne deren Schlüssel nicht.
Und damit ist die Verwirrung komplett. Praktisch stellt sich die Frage, wie Käufer eines kryptographisch blockierten Gerätes mit Open-Source-Software je herausfinden können, ob der ihnen vom Hersteller zugemittelte Softwarecode überhaupt der wirklich auf dem Gerät genutzte ist, wenn sie ihn, auch testweise, nicht darauf installieren können.
Eigentlich hätte das Verfahren vor rund zwei Wochen endlich in die Gerichtssaalphase eintreten sollen, im fünften Jahr nach Klageerhebung. Doch ein anderes Verfahren der selben Richterin, mit Geschworenen, dauert länger als geplant. Damit ist die Richterin unabkömmlich und musste den Vizio-Prozess auf unbestimmte Zeit vertagen. Am Montag hätte bei einer Verhandlung ein neuer Termin gefunden werden sollen, doch auch diese Verhandlung wurde vom Gericht kurzfristig abberaumt.
„…the Agreements require Vizio to make the source code available in such a manner that the source code can be readily obtained and modified by Plaintiff or other third parties. While source code is defined to include ‚the scripts used to control compilation and installation,‘ this does not mean that Vizio must allow users to reinstall the software, modified or otherwise, back onto its smart TVs in a manner that preserves all features of the original program and/or ensures the smart TVs continue to function properly. Rather, in the context of the Agreements, the disputed language means that Vizio must provide the source code in a manner that allows the source code to be obtained and revised by Plaintiff or others for use in other applications.
…nothing in the language of the Agreements requires Vizio to allow modified source code to be reinstalled on its devices while ensuring the devices remain operable after the source code is modified…“
Das Verfahren heißt Software Freedom Conservancy v Vizio (Az. 30-2021-01226723-CU-BC-CJC).
(ds)
Künstliche Intelligenz
„Wollen nicht perfekt, gut genug reicht“: KI soll US-Verkehrsregeln verfassen
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.“
Weiterlesen nach der Anzeige
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)
Künstliche Intelligenz
Automatisierte Accessibility-Prüfung im Web: Möglichkeiten und Grenzen
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.
Weiterlesen nach der Anzeige

Maria Korneeva ist Frontend Technology Lead und Google Developer Expert mit Fokus auf Angular und Barrierefreiheit. Sie arbeitet freiberuflich an Frontend-Anwendungen, leitet Workshops und teilt ihre Erfahrungen auf Konferenzen und Meetups sowie in ihrem Buch „Barrierefreie Webentwicklung: von den Grundlagen bis zur praktischen Umsetzung“.
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.
Weiterlesen nach der Anzeige
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?
(Bild: jaboy/123rf.com)

Mehr über Accessibility im Web erfährst du auf der enterJS 2026 am 16. und 17. Juni in Mannheim. Die Konferenz dreht sich rund um die JavaScript/TypeScript-Entwicklung im Enterprise-Bereich. Vergünstigte Frühbuchertickets sind im Online-Ticketshop erhältlich.
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.
Die Web Content Accessibility Guidelines (WCAG) sind ein internationaler Standard des World Wide Web Consortium (W3C) zur barrierefreien Gestaltung von Webinhalten. Sie definieren prüfbare Erfolgskriterien, die sich an vier Grundprinzipien orientieren: wahrnehmbar, bedienbar, verständlich und robust.
Die WCAG unterscheiden drei Konformitätsstufen, die unterschiedliche Ebenen von Wirkung, Aufwand und fachlicher Komplexität der Anforderungen beschreiben:
- Stufe A
Anforderungen mit grundlegender Wirkung auf die Barrierefreiheit und vergleichsweise geringem Umsetzungsaufwand. Ohne ihre Erfüllung ist eine Nutzung für viele Menschen mit Behinderungen kaum oder gar nicht möglich (z. B. Alternativtexte für Bilder, Tastaturbedienbarkeit). - Stufe AA
Anforderungen mit hoher Wirkung für eine breite Nutzer:innengruppe, die zentrale Barrieren im Nutzungskontext abbauen, aber bereits ein höheres Maß an gestalterischem, redaktionellem und technischem Barrierefreiheits-Know-how erfordern (z. B. ausreichende Farbkontraste, verständliche Beschriftungen, konsistente Navigation).
Diese Stufe gilt in der Praxis als maßgeblicher rechtlicher Standard und wird von nahezu allen Barrierefreiheitsgesetzen gefordert. - Stufe AAA
Anforderungen mit sehr spezifischer Wirkung für einzelne Nutzergruppen, die mit hohem konzeptionellem, technischem oder organisatorischem Aufwand verbunden sind und daher nicht für alle Inhalte realistisch umsetzbar sind (z. B. Gebärdensprachversionen).
Künstliche Intelligenz
Frankreichs Parlament für Social-Media-Verbot unter 15
Die französische Nationalversammlung hat für ein Nutzungsverbot sozialer Netzwerke für Kinder und Jugendliche unter 15 Jahren gestimmt. Die Abgeordneten in Paris nahmen am Montagabend einen entsprechenden Gesetzesvorschlag an. Er sieht vor, dass „der Zugang zu einem von einer Onlineplattform bereitgestellten Onlinedienst für ein soziales Netzwerk“ für Minderjährige unter 15 Jahren verboten ist. Der Text muss noch im Senat abgestimmt werden, der anderen Parlamentskammer.
Weiterlesen nach der Anzeige
Welche sozialen Medien konkret vom Verbot betroffen wären, lässt die verabschiedete Formulierung offen. Klargestellt wird lediglich, dass „Online-Enzyklopädien“ sowie „Bildungs- oder Wissenschaftsverzeichnisse“ davon ausgenommen sein sollen. Auch private Messengerdienste sollen nicht betroffen sein.
Ursprünglicher Gesetzesvorschlag sah kein Komplettverbot vor
Der ursprünglich eingebrachte Text, über den die Abgeordneten debattierten, ging weniger weit: Er sah vor, dass bestimmte Seiten mit Erlaubnis der Eltern auch weiterhin hätten genutzt werden können. Das ist nun nicht mehr der Fall.
Der Gesetzesvorschlag wurde in der Nationalversammlung vor allem vom Lager des französischen Präsidenten Emmanuel Macron unterstützt. Nach der Abstimmung teilte Macron auf der Plattform X mit: „Das ist es, was Wissenschaftler empfehlen, und das ist es, was die Franzosen in großer Mehrheit fordern.“
Der Staatschef will, dass die Regelung bereits zum nächsten Schuljahr greift. „Ab dem 1. September werden unsere Kinder und Jugendlichen endlich geschützt sein. Dafür werde ich sorgen“, schrieb Macron.
EU-Recht führte zu Problemen bei vorherigem Gesetz
Weiterlesen nach der Anzeige
Frankreich hatte bereits vor einigen Jahren versucht, ein Mindestalter von 15 Jahren dafür einzuführen, dass Jugendliche ohne Erlaubnis ihrer Eltern ein eigenes Konto auf sozialen Netzwerken anlegen können. Das Gesetz konnte wegen der europäischen Rechtslage aber nicht angewandt werden. Ob die neuen Regeln dem aktuellen EU-Recht standhalten, muss sich noch zeigen.
Das Europäische Parlament stimmte vergangenes Jahr mit deutlicher Mehrheit für die Forderung nach einem EU-weiten Mindestalter. Der verabschiedete Bericht hat aber bislang keine bindende Wirkung.
Sollte das Gesetz in Frankreich endgültig verabschiedet werden, wäre Deutschlands Nachbar eines der ersten Länder, das derart restriktive Vorgaben für Minderjährige einführt. In Australien dürfen Kinder und Jugendliche unter 16 Jahren seit Kurzem keine eigenen Social-Media-Konten mehr auf vielen großen Plattformen haben.
In Großbritannien stimmte das Oberhaus in der vergangenen Woche ebenfalls für ein Social-Media-Verbot bis 16 Jahre, das jetzt noch durch das von der Regierungspartei Labour dominierte Unterhaus muss. In Dänemark verständigte sich die Regierung mit der Opposition darauf, eine nationale Altersgrenze von 15 Jahren für den Zugang zu bestimmten sozialen Medien einzuführen.
Und auch in Deutschland gibt es eine Debatte darüber, ob der Zugang zu sozialen Medien für Kinder eingeschränkt werden sollte.
(dahe)
-
Entwicklung & Codevor 2 MonatenKommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac
-
UX/UI & Webdesignvor 3 MonatenArndt Benedikt rebranded GreatVita › PAGE online
-
Künstliche Intelligenzvor 4 WochenSchnelles Boot statt Bus und Bahn: Was sich von London und New York lernen lässt
-
Entwicklung & Codevor 2 MonatenKommentar: Anthropic verschenkt MCP – mit fragwürdigen Hintertüren
-
Apps & Mobile Entwicklungvor 2 MonatenFast 5 GB pro mm²: Sandisk und Kioxia kommen mit höchster Bitdichte zum ISSCC
-
Apps & Mobile Entwicklungvor 2 MonatenHuawei Mate 80 Pro Max: Tandem-OLED mit 8.000 cd/m² für das Flaggschiff-Smartphone
-
Social Mediavor 1 MonatDie meistgehörten Gastfolgen 2025 im Feed & Fudder Podcast – Social Media, Recruiting und Karriere-Insights
-
Künstliche Intelligenzvor 3 MonatenWeiter billig Tanken und Heizen: Koalition will CO₂-Preis für 2027 nicht erhöhen
