Barrierefreiheits-Overlays und Quellcode-Korrekturen

Ein Barrierefreiheits-Overlay ist ein Skript, das die Seiten eines Shops im Browser der Besucherinnen und Besucher verändert, nachdem sie geladen wurden. Eine Quellcode-Korrektur ändert die Templates, Styles oder Skripte des Shops, sodass der Server die korrigierte Seite an jeden Browser und jedes Tool sendet.

Zuletzt aktualisiert:

Worin unterscheiden sich ein Overlay und eine Quellcode-Korrektur?

Der Unterschied zwischen einem Barrierefreiheits-Overlay und einer Quellcode-Korrektur liegt darin, wo die Änderung erfolgt. Ein Overlay ändert die Seite im Browser jeder Besucherin und jedes Besuchers; eine Quellcode-Korrektur ändert die Dateien, aus denen die Seite aufgebaut wird.

Barrierefreiheits-Overlay
Ein Skript, das den Seiten eines Shops hinzugefügt wird und jede Seite im Browser der Besucherinnen und Besucher verändert, nachdem sie geladen wurde. Das Skript kann Attribute, Texte und Styles hinzufügen oder ändern und eigene Bedienelemente einfügen. Bis auf den Verweis, der das Skript lädt, bleibt der eigene Code des Shops, wie er war.
Quellcode-Korrektur
Eine Änderung an den eigenen Templates, Stylesheets oder Skripten des Shops: den Dateien, aus denen der Server jede Seite aufbaut. Sobald die Änderung live ist, sendet der Server die korrigierte Seite.

Was ändert ein Overlay?

Ein Barrierefreiheits-Overlay ändert die Seite im Browser der Besucherinnen und Besucher, und nur dort. Sein Skript wird mit der Seite geladen, liest, was der Browser aus dem HTML des Shops aufgebaut hat, und verändert es, bei jedem Seitenaufruf neu, in jedem Browser, der das Skript lädt und ausführt.

Details: Korrekturen, die Wissen voraussetzen, das die Seite nicht enthält

Manche Korrekturen setzen Wissen voraus, das die Seite nicht enthält, etwa was ein Produktfoto Kundinnen und Kunden vermitteln soll. Das Skript kann dieses Wissen nicht aus der Seite lesen. Es muss es erschließen oder einen Text einfügen, den jemand beim Anbieter hinterlegt hat. In beiden Fällen gibt es das Ergebnis nur in Browsern, die das Skript ausführen.

Was behebt ein Barrierefreiheits-Overlay nicht?

Ein Barrierefreiheits-Overlay korrigiert nicht den Code, der einen Fehler verursacht. Die Dateien des Themes und das HTML, das der Server sendet, bleiben, wie sie waren, bis auf den Verweis, der das Overlay lädt, und ein Browser oder Tool, das das Skript nicht ausführt, erhält die Seite mit ihren ursprünglichen Fehlern.

Was ein Overlay unverändert lässt

  • Die Dateien des Themes.

  • Das HTML, das der Server sendet.

  • Was ein Browser oder Tool ohne das Skript erhält.

  • Die Seite, bevor das Skript gelaufen ist.

  • Die Seite, nachdem das Skript entfernt wurde.

  • Alles, wo das Skript nicht läuft.

Details: was ein Overlay unverändert lässt, Punkt für Punkt

Ein Barrierefreiheits-Overlay korrigiert nicht den Code, der einen Fehler verursacht. Alles, woraus die Seite aufgebaut wird, bleibt, wie es war, und ebenso jede Kopie der Seite, die das Skript nicht erreicht:

  • Die Dateien des Themes. Die Templates, Stylesheets und Skripte des Shops bleiben, wie sie waren, bis auf den Verweis, der das Overlay lädt.
  • Das HTML, das der Server sendet. Es ist dasselbe wie vorher, bis auf diesen Verweis.
  • Was ein Browser oder Tool ohne das Skript erhält. Ein Browser mit ausgeschaltetem JavaScript, ein Browser, in dem das Skript blockiert wird oder nicht geladen werden kann, und ein Tool, das das HTML liest, ohne Skripte auszuführen, erhalten alle die Seite mit ihren ursprünglichen Fehlern.
  • Die Seite, bevor das Skript gelaufen ist. Bis das Skript geladen ist und seine Änderungen vorgenommen hat, ist die Seite so, wie der Code des Shops sie liefert.
  • Die Seite, nachdem das Skript entfernt wurde. Wird das Overlay ausgeschaltet oder entfernt, sind die Seiten wieder so, wie sie waren, bevor es hinzugefügt wurde.
  • Alles, wo das Skript nicht läuft. Ein PDF, eine E-Mail des Shops oder eine Seite auf einer anderen Domain, die das Skript nicht lädt, etwa eine extern gehostete Zahlungsseite.

Wie lässt sich das bei jedem Shop prüfen?

Mit einem gewöhnlichen Desktop-Browser, ohne Zugriff auf den Code des Shops, können Sie sehen, wo eine Änderung vorgenommen wurde: Vergleichen Sie Quelltext und dargestellte Seite, blockieren Sie das Skript des Overlays und laden Sie die Seite neu, oder lassen Sie sich die Änderung im Code zeigen.

Drei Prüfungen
  1. Quelltext und dargestellte Seite vergleichen. „Seitenquelltext anzeigen“ im Browser zeigt das HTML, das der Server gesendet hat. Der Elementinspektor in den Entwicklertools des Browsers zeigt die Seite, nachdem ihre Skripte gelaufen sind. Ein Attribut oder ein Text, der nur im Inspektor erscheint, wurde von einem Skript hinzugefügt, nachdem die Seite geladen war.
  2. Das Skript des Overlays blockieren. Blockieren Sie die Adresse, von der das Skript geladen wird, zum Beispiel über das Blockieren von Anfragen in den Entwicklertools des Browsers, und laden Sie die Seite neu. Was übrig bleibt, ist der Shop, wie sein eigener Code ihn liefert.
  3. Sich die Änderung im Code zeigen lassen. Eine Quellcode-Korrektur ist eine Änderung an einer Datei des Themes, die Ihnen eine Entwicklerin oder ein Entwickler samt Datum zeigen kann. Eine Änderung durch ein Overlay steht nicht in den Dateien des Themes.

Was sagen Behörden und Klagezahlen zu Overlays?

Im April 2025 hat die US-Handelsbehörde FTC eine endgültige Anordnung genehmigt: Sie verbietet einem Unternehmen, das ein automatisiertes Barrierefreiheits-Plug-in verkauft, zu behaupten, seine Produkte könnten jede Website WCAG-konform machen, solange es dafür keine Belege hat. Die deutschen Überwachungsstellen für Behördenwebsites halten fest, dass Overlay-Tools derzeit eine Website mit Barrieren nicht vollständig barrierefrei machen können.

  • US-Handelsbehörde FTC, 22. April 2025

    Eine endgültige Anordnung gegen ein Unternehmen, das ein automatisiertes Barrierefreiheits-Plug-in verkauft

    Sie verbietet dem Unternehmen, zu behaupten, seine automatisierten Produkte könnten jede Website WCAG-konform machen oder dauerhaft so halten, solange es dafür keine Belege hat.

  • Deutsche Überwachungsstellen, gemeinsame Einschätzung, überarbeitet im März 2025

    Overlay-Tools können eine Website mit Barrieren derzeit nicht vollständig barrierefrei machen

    Ihr Einsatz kann zusätzliche Barrieren schaffen. Die Einschätzung betrifft die Websites öffentlicher Stellen, für die die Richtlinie (EU) 2016/2102 gilt.

  • UsableNet, USA, 2024

    Klagen gegen 1.023 Unternehmen, auf deren Website ein Barrierefreiheits-Widget aktiv war

    Eine Klage macht einen Anspruch geltend und ist kein Urteil. Die Zahl sagt deshalb nichts darüber aus, wie die Verfahren ausgingen.

Quelle: US Federal Trade Commission, Pressemitteilung vom 22. April 2025 (auf Englisch); BFIT-Bund, gemeinsame Einschätzung der Überwachungsstellen; UsableNet, 2024 Year-End ADA Web Lawsuit Report (auf Englisch)

Die US-Handelsbehörde FTC, endgültige Anordnung vom 22. April 2025

Am 22. April 2025 hat die US-Handelsbehörde Federal Trade Commission (FTC) eine endgültige einvernehmliche Anordnung (final consent order) gegen ein Unternehmen genehmigt, das ein automatisiertes Barrierefreiheits-Plug-in für Websites verkauft. Die im Januar 2025 vorgelegte Beschwerde der FTC warf dem Unternehmen vor, das Plug-in habe, anders als das Unternehmen behauptete, nicht alle Websites, die es einsetzten, WCAG-konform gemacht.

Die Anordnung verbietet dem Unternehmen, zu behaupten, seine automatisierten Produkte könnten jede Website WCAG-konform machen oder dauerhaft so halten, solange es dafür keine Belege hat. Außerdem verbietet sie ihm, Bewertungen, Blogbeiträge oder Artikel über seine Produkte als unabhängige Meinungen darzustellen, wenn sie es nicht sind, und verpflichtet es zur Zahlung von 1 Million US-Dollar. Quelle: die Pressemitteilung der FTC vom 22. April 2025, auf Englisch.

Die deutschen Überwachungsstellen für die Barrierefreiheit von Informationstechnik, März 2025

Die Überwachungsstellen des Bundes und der Länder für die Barrierefreiheit von Informationstechnik halten in einer gemeinsamen Einschätzung fest, dass Overlay-Tools derzeit nicht in der Lage sind, eine Website mit Barrieren vollständig barrierefrei zu machen, und dass ihr Einsatz zusätzliche Barrieren schaffen kann. Die Einschätzung wurde im März 2025 überarbeitet. Veröffentlicht wird sie von der BFIT-Bund, der Überwachungsstelle des Bundes. Ihr Kernsatz im Wortlaut: „Aktuell sind Overlay-Tools nicht in der Lage, einen Webauftritt, der Barrieren aufweist, vollständig barrierefrei darzustellen“.

Die Einschätzung hält außerdem fest, dass Overlay-Tools und assistive Technologien, die gleichzeitig eingesetzt werden, einander stören können, was dazu führen kann, dass Menschen mit Behinderungen die Website nur schwer oder gar nicht nutzen können. Sie betrifft die Websites öffentlicher Stellen, für die die Richtlinie (EU) 2016/2102 über den barrierefreien Zugang zu Websites und mobilen Anwendungen gilt: Eine solche Website ist nur dann barrierefrei, wenn sie die Anforderungen auch ohne Overlay-Tool erfüllt. Quelle: die gemeinsame Einschätzung auf bfit-bund.de.

Klagen in den USA gegen Unternehmen mit einem Widget (UsableNet, 2024)

Diese Zahlen stammen aus den USA. UsableNet, das Berichte über Klagen zur digitalen Barrierefreiheit in den USA veröffentlicht, gibt an, dass 2024 Klagen gegen 1.023 Unternehmen erhoben wurden, auf deren Website ein Barrierefreiheits-Widget aktiv war. Eine Klage macht einen Anspruch geltend und ist kein Urteil. Die Zahl sagt deshalb nichts darüber aus, wie die Verfahren ausgingen. Quelle: der Jahresbericht 2024 von UsableNet über Klagen zur Barrierefreiheit von Websites in den USA, auf Englisch.

Was ist die Alternative zu einem Barrierefreiheits-Overlay?

Die Alternative zu einem Barrierefreiheits-Overlay ist eine Quellcode-Korrektur: eine Korrektur in der Datei, die den Fehler verursacht, etwa in einem Template, einem Stylesheet oder einem Skript. Sobald die Änderung live ist, gehören das korrigierte Markup und die korrigierten Styles zu dem, was der Server sendet, und erreichen so alle Besucherinnen und Besucher, jeden Browser und jedes Tool.

So liefert Validiscan seine Korrekturen aus

  • Als Änderung, die Sie prüfen können.

  • Nichts in Ihrem Live-Shop ändert sich, bevor Sie es entscheiden.

  • In den Dateien, die den Fehler verursachen.

  • Ohne eigenes Skript.

  • Geprüft, nachdem die Änderung live ist.

Details: was eine Quellcode-Korrektur ändert und wie Validiscan seine Korrekturen ausliefert

Die Alternative ist eine Quellcode-Korrektur: eine Korrektur in der Datei, die den Fehler verursacht, etwa in einem Template, einem Stylesheet oder einem Skript des Shop-Themes. Sobald die Änderung live ist, gehören das korrigierte Markup und die korrigierten Styles zu dem, was der Server sendet, und erreichen so alle Besucherinnen und Besucher, jeden Browser und jedes Tool, ohne von einem zusätzlichen Skript abzuhängen.

So liefert Validiscan seine Korrekturen aus:

  • Als Änderung, die Sie prüfen können. Validiscan liefert die Änderungen als Pull Request auf einem neuen Branch Ihres Repositorys mit einem Commit pro Korrektur, als unveröffentlichte Kopie Ihres Shopify-Themes oder als Patch-Paket mit einer Patch-Datei pro Korrektur.
  • Nichts in Ihrem Live-Shop ändert sich, bevor Sie es entscheiden. Sie oder Ihr Entwicklungsteam führen den Pull Request zusammen, veröffentlichen die Theme-Kopie oder spielen den Patch ein.
  • In den Dateien, die den Fehler verursachen. Eine Korrektur kann ein Template, ein Stylesheet oder eines der eigenen Skripte des Themes ändern. Eine Slideshow, die von selbst weiterläuft, erhält zum Beispiel in ihrem Template eine Pause-Schaltfläche, und ein Codeblock, der dem Hauptskript des Themes hinzugefügt wird, verbindet die Schaltfläche mit der Slideshow.
  • Ohne eigenes Skript. Nichts in einer Auslieferung von Validiscan läuft von selbst auf Ihrer Website, und Validiscan fügt nie ein Skript hinzu, das Ihre Seiten im Browser der Besucherinnen und Besucher nach dem Laden korrigiert. Code, der zu den eigenen Skripten des Themes hinzukommt, wird Teil Ihres Codes, und Ihr Entwicklungsteam prüft ihn mit dem Rest der Änderung.
  • Geprüft, nachdem die Änderung live ist. Sobald die Änderungen live sind, prüft ein Verifizierungsscan die betroffenen Seiten noch einmal, und das Remediation Evidence Package hält mit Datum fest, was geprüft, geändert und verifiziert wurde.
Der Ablauf eines Projekts, Schritt für Schritt

Wie unterscheiden sich die beiden Ansätze?

Ein Barrierefreiheits-Overlay und eine Quellcode-Korrektur unterscheiden sich darin, wo die Änderung liegt, wer sie sehen kann und was danach bleibt: Die Korrekturen eines Overlays waren nie in Ihrem Code, die Änderungen einer Quellcode-Korrektur sind Teil davon.

Barrierefreiheits-Overlay und Quellcode-Korrektur im Vergleich, nach dem Ort der Änderung
Frage Barrierefreiheits-Overlay Quellcode-Korrektur
Wo erfolgt die Änderung? Im Browser der Besucherinnen und Besucher, durch ein Skript, bei jedem Seitenaufruf In den eigenen Dateien des Themes, einmal
Was sendet der Server? Dasselbe HTML wie vorher, plus einen Verweis auf das Skript Das korrigierte HTML und die korrigierten Styles
Was erhält ein Browser oder Tool, das das Skript nicht ausführt? Die Seite mit ihren ursprünglichen Fehlern Die korrigierte Seite
Kann Ihr Entwicklungsteam die Änderung prüfen, bevor sie live geht? Nicht als Änderung am Code des Shops Ja: Zeile für Zeile in einem Pull Request oder Patch-Paket oder als Vorschau einer unveröffentlichten Theme-Kopie
Was steht in Ihrem Code, wenn Sie den Anbieter nicht mehr bezahlen? Keine der Korrekturen, weil sie nie in Ihrem Code waren Die Änderungen, weil sie Teil Ihres Codes sind
Was kann die Änderung rückgängig machen? Das Skript lädt nicht, wird blockiert oder wird entfernt Eine spätere Änderung am Theme, zum Beispiel ein Theme- oder App-Update
Was läuft im Browser der Besucherinnen und Besucher, das vorher nicht da war? Das Skript des Overlays Kein zusätzliches Skript. Braucht eine Korrektur eine Funktion, kommt Code zu den eigenen Skripten des Themes hinzu

Was leistet eine Quellcode-Korrektur nicht?

Auch eine Quellcode-Korrektur hat Grenzen: Sie braucht Zugriff auf den Code des Shops, sie behebt nur, was sich im Code beheben lässt, sie erreicht keine eingebundenen Dienste von Drittanbietern wie Zahlungs- oder Chat-Widgets, und ein späteres Theme- oder App-Update kann einen behobenen Fehler zurückbringen.

Details: jede Grenze im Einzelnen

Auch eine Quellcode-Korrektur hat Grenzen, die Sie kennen sollten, bevor Sie sich entscheiden:

  • Sie braucht Zugriff auf den Code. Validiscan arbeitet mit einem Klon Ihres Repositorys, einer Kopie Ihres Shopify-Themes oder einem Export Ihres Themes, den Ihr Entwicklungsteam hochlädt. Sie oder Ihr Entwicklungsteam prüfen die Änderung, bevor sie live geht.
  • Sie behebt, was sich im Code beheben lässt. Manche Fehler erfordern eine Inhalts- oder Designentscheidung, die nur Sie treffen können, zum Beispiel Untertitel für Ihre Produktvideos. Dafür gibt Validiscan eine Anleitung (Korrekturstufe MANUAL), statt Ihren Code zu ändern.
  • Sie erreicht nicht, was nicht zu Ihrem Theme gehört. Eingebundene Dienste von Drittanbietern wie Zahlungs- oder Chat-Widgets bringen ihren eigenen Code mit, den eine Änderung an Ihrem Theme nicht verändert. Sie gehören nicht zu einem Projekt von Validiscan, PDFs ebenso wenig.
  • Sie kann wieder verloren gehen. Ein späteres Theme- oder App-Update kann einen behobenen Fehler zurückbringen. Der Regressionsschutz scannt den Shop nach einem Zeitplan erneut und meldet einen Fehler, der behoben war und wieder aufgetreten ist.

Was sollten Sie jeden Anbieter für Barrierefreiheit fragen?

Fragen Sie jeden Anbieter für Barrierefreiheit, auch Validiscan, wo die Änderung liegt, ob Ihr Entwicklungsteam jede Änderung sehen kann, bevor sie live geht, und was in Ihrem Shop bleibt, wenn Sie nicht mehr bezahlen. Verspricht ein Anbieter, dass Ihr Shop die gesetzlichen Vorgaben erfüllt oder vor rechtlichen Ansprüchen geschützt ist, fragen Sie, worauf dieses Versprechen beruht.

Diese Fragen eignen sich für jeden Anbieter, auch für Validiscan. Die Antworten zeigen, wo die Arbeit landet und was Sie selbst prüfen können. Auf jede Frage folgt die Antwort von Validiscan.

  1. Wo liegt die Änderung: in den Dateien meines Themes oder in einem Skript, das Sie hosten? Validiscan: in den Dateien Ihres Themes.
  2. Kann mein Entwicklungsteam jede Änderung sehen, bevor sie live geht? Validiscan: ja. Ein Pull Request hat einen Commit pro Korrektur, und ein Patch-Paket hat eine Patch-Datei pro Korrektur. Eine unveröffentlichte Kopie Ihres Shopify-Themes lässt sich in der Vorschau ansehen und prüfen, bevor Sie sie veröffentlichen.
  3. Was bleibt in meinem Shop, wenn ich Sie nicht mehr bezahle? Validiscan: die Änderungen, weil sie Teil Ihres Codes sind. Der Regressionsschutz kann zum Ende jedes Monats gekündigt werden.
  4. Was läuft in den Browsern meiner Besucherinnen und Besucher, das vorher nicht da war? Validiscan: kein zusätzliches Skript und nichts, das von Validiscan geladen wird. Braucht eine Korrektur eine Funktion, etwa eine Pause-Schaltfläche für eine Slideshow, fügt sie den eigenen Skripten Ihres Themes Code hinzu, den Sie mit dem Rest der Änderung prüfen.
  5. Was ist nicht abgedeckt? Validiscan: Befunde, bei denen Sie selbst inhaltlich entscheiden müssen (Korrekturstufe MANUAL), eingebundene Dienste von Drittanbietern wie Zahlungs- oder Chat-Widgets und PDFs.
  6. Welcher Teil der Prüfung ist automatisiert, und was prüft ein Mensch? Validiscan: Automatisierte Scans melden Fehler, die sich am Code einer Seite nachweisen lassen, und sie finden nicht jeden Fehler. Eine manuelle Checkliste mit 35 Punkten, die ein Mensch abarbeitet, deckt jedes Kriterium von WCAG 2.2 ab, das keine Regel testet, und dazu einige, die Regeln nur zum Teil testen. Für die übrigen Kriterien, darunter 1.1.1 Non-text Content, beruht ein Ergebnis allein auf automatisierten Prüfungen. Die Methode und die Standards
  7. Wie werden die Korrekturen geprüft, nachdem sie live sind, und welchen Nachweis erhalte ich? Validiscan: ein Verifizierungsscan der betroffenen Seiten und ein datiertes Remediation Evidence Package.
  8. Was genau sagen Sie über das Ergebnis aus? Validiscan: Das Paket gibt die Konformität mit den Erfolgskriterien von WCAG 2.1 Stufe AA und WCAG 2.2 Stufe AA an, wie sie auf den aufgeführten Seiten an den angegebenen Tagen geprüft wurde. Es belegt eine Prüfung und die durchgeführten Arbeiten zur Behebung. Ein Zertifikat ist es nicht.
  9. Versprechen Sie, dass mein Shop die gesetzlichen Vorgaben erfüllt oder vor rechtlichen Ansprüchen geschützt ist? Fragen Sie, worauf ein solches Versprechen beruht. Validiscan gibt kein solches Versprechen ab: Ob ein Shop ein Gesetz erfüllt, ist eine rechtliche Bewertung, die Sie gemeinsam mit Ihrer Rechtsberatung treffen.

Quellen

3 Quellen, alle für diese Seite geprüft am 6. Oktober 2026.

USA 2
  1. FTC Approves Final Order Requiring accessiBe to pay $1 Million · US Federal Trade Commission ·  · geprüft am
  2. 2024 Year-End ADA Web Lawsuit Report · UsableNet · geprüft am
Deutschland 1

Beginnen Sie mit einem kostenlosen Check Ihres Shops.

Senden Sie die Adresse Ihres Shops. Validiscan scannt ihn und antwortet mit jedem Fehler, den der Scan nachweisen kann, jeweils mit der Seite und dem Code.

Kostenlosen Check anfordern

Oder schreiben Sie an info@validiscan.com.

Was der kostenlose Check umfasst und was nicht
Sie senden
die Adresse Ihres Shops
Gescannte Seiten
bis zu 15
Sie erhalten
jeden Fehler, den der Scan nachweisen kann, mit Seite und Code
In Ihrem Shop
nur öffentliche Seiten; keine Anmeldung, nichts gekauft, kein Formular abgeschickt
Was er nicht ist
ein vollständiges Audit

Nachricht an Validiscan

Für einen kostenlosen Check nennen Sie die Adresse Ihres Shops und seine Plattform.

Validiscan verwendet, was Sie senden, um Ihnen zu antworten. Datenschutzerklärung