Das brauchst du
Ein Tag-Manager-Container, der bereits auf allen Seiten deiner Website eingebunden ist, und Berechtigungen zum Bearbeiten und Veröffentlichen. Lege in Accessonaut zuerst ein Projekt mit deiner tatsächlichen Website-Domain an und öffne im Projekt die Einbauseite.
Schritt für Schritt
- Öffne deinen Container und wähle Tags → Neu. Klicke auf Tag-Konfiguration und wähle Benutzerdefiniertes HTML.
- Füge den unveränderten Einbaucode in das HTML-Feld ein und gib dem Tag einen eindeutigen Namen, etwa Accessonaut.
- Wähle einen Trigger für alle Seiten, etwa „Initialisierung – Alle Seiten“. Stimme die Einwilligungseinstellungen des Tags mit deinem Consent-Konzept ab.
- Prüfe die Auslösung über „In Vorschau ansehen“ im Tag Assistant. Veröffentliche den Container danach über Senden und Veröffentlichen.
- Teste die öffentliche Website in einem privaten Fenster. Prüfe in den Entwicklertools, dass das Script mit
data-project-idgenau einmal auf der Seite steht.
So sieht die Einbindung aus
Verwende den fertigen Code aus deinem Projekt. Das Beispiel benötigt deine echte Projekt-ID und die öffentlich erreichbare Service-Adresse.
<script src="https://accessonaut.com/widget.js"
data-project-id="DEINE_PROJEKT_ID"
data-language="de" defer></script>Das Design an deine Website anpassen
Öffne im Accessonaut-Projekt „Lesehilfen-Widget“. Fünf Vorlagen und eine Live-Vorschau helfen dir beim Gestalten: Farben, Schriften, Menübreite, Ecken, Schatten, Symbol oder beschrifteter Öffner sowie eigene Texte. Position und Randabstände lassen sich für Desktop und Smartphone abstimmen. Nach dem Speichern übernimmt dein vorhandener Einbaucode das Projektdesign automatisch; die öffentliche Konfiguration wird bis zu einer Minute zwischengespeichert.
Im WordPress-Plugin kannst du stattdessen lokale Einstellungen wählen. Diese haben Vorrang vor dem Projektdesign. Die Gestaltung ist in allen Tarifen verfügbar. Im Free-Tarif bleibt der Accessonaut-Hinweis sichtbar. Persönliche Leseeinstellungen deiner Besuchenden haben Vorrang vor Designvorgaben.
Darauf achten
Das Widget lädt nur, wenn der Tag Manager lädt und das Tag auslöst. Blocker für Werbung und Tracking oder eine fehlende Einwilligung verhindern dann auch die Lesehilfe. Ein direkter Einbau im Template ist deshalb robuster. Tag Manager verkleinert eingefügten Code; prüfe das ausgegebene Script. Entferne zusätzliche Einbauten aus Theme oder CMS.
Häufige Fragen zu Google Tag Manager
Welcher Trigger ist richtig?
„Initialisierung – Alle Seiten“ löst vor allen anderen Triggern aus, nur die Einwilligungsinitialisierung kommt früher. Ein Seitenaufruf-Trigger für alle Seiten geht auch. Nutze „Initialisierung der Einwilligung“ nicht: Google sieht sie nur für Einwilligungseinstellungen vor. Auch der Trigger für Verlaufsänderungen passt nicht, denn er löst bei jedem Seitenwechsel in Single-Page-Anwendungen erneut aus.
Welche Option zur Tag-Auslösung wähle ich?
Lass das Tag in den erweiterten Einstellungen unter den Optionen zur Tag-Auslösung einmal pro Seite auslösen. Google nennt diese Option für das Laden externer JavaScript-Bibliotheken. Das Widget legt sich zwar kein zweites Mal an, ein erneutes Auslösen lädt das Script aber unnötig.
Wie verbinde ich das Tag mit meiner Einwilligungsverwaltung?
In den Einwilligungseinstellungen des Tags kannst du unter den zusätzlichen Einwilligungsprüfungen festlegen, dass eine Einwilligung nötig ist. Dann lädt das Widget erst nach Zustimmung. Das Widget setzt keine Cookies und speichert Leseeinstellungen lokal. Entscheide nach deiner Datenschutzprüfung.
Kann ich zuerst auf einer Staging-Umgebung testen?
Ja. Mit Umgebungen veröffentlichst du in eine Staging-Umgebung, ohne Live zu ändern. Auf einer Staging-Domain zeigt das Widget aber das Standarddesign mit Accessonaut-Hinweis, weil die Projektkonfiguration nur für die Domain im Projekt gilt.
Wie entferne oder pausiere ich das Widget?
Öffne das Tag und pausiere es über das Menü mit den drei Punkten, oder lösche es. Beides wirkt erst, wenn du den Container wieder veröffentlichst.
Wenn etwas nicht klappt
In der Vorschau löst das Tag aus, auf der Live-Seite fehlt das Widget.
Ursache: Der Container ist noch nicht veröffentlicht.
Lösung: Wähle Senden und Veröffentlichen und prüfe die Website danach in einem privaten Fenster.
Die Browser-Konsole meldet einen CSP-Verstoß.
Ursache: Deine Richtlinie erlaubt das Script oder die Verbindung zur Service-Adresse nicht.
Lösung: Ergänze die Service-Adresse in script-src und connect-src. Mit einer Nonce im Container-Snippet gibt Tag Manager sie laut Google an die eingefügten Scripts weiter.
Einbau prüfen
- Öffne die öffentliche Website in einem privaten Fenster. Das Widget wird genau einmal angezeigt.
- Erreiche den Button mit der Tastatur. Öffne das Panel, ändere die Textgröße und schließe es wieder.
- Prüfe Startseite, Unterseite, Formular und mobile Ansicht. Das Widget darf keine wichtigen Bedienelemente verdecken.
- Prüfe im Netzwerk-Tab, dass widget.js und die Projektkonfiguration von deiner Service-Adresse geladen werden. Bei Fehlern kontrolliere Domain, Projekt-ID und CSP.
- Bei Free-Projekten bleibt der sichtbare Accessonaut-Hinweis Bestandteil des Widgets. Berechtigungen kommen aus deinem Projekt.
Datenschutz und Grenzen
Beim Laden ruft der Besucherbrowser das Script und die Projektkonfiguration vom Accessonaut-Dienst ab. Dabei fallen IP-Adresse, Browser-Anfragedaten und Website-Hostname an. Darstellungswünsche werden lokal im Browser gespeichert. Berücksichtige die Einbindung in deinen Datenschutzhinweisen und prüfe deine konkrete Konfiguration.
Die Lesehilfen erzeugen keine Konformitätsgarantie. Prüfe Barrieren im Quellcode und vollständige Nutzerabläufe zusätzlich automatisch und manuell.