Das brauchst du
Zugriff auf ein globales Layout oder ein Feld für eigene Scripts. Die öffentliche Website muss JavaScript zulassen. Lege in Accessonaut zuerst ein Projekt mit deiner tatsächlichen Website-Domain an und öffne im Projekt die Einbauseite.
Schritt für Schritt
- Öffne das gemeinsame Footer- oder Seiten-Template deines CMS und sichere den bisherigen Stand.
- Kopiere den vollständigen Einbaucode aus deinem Accessonaut-Projekt.
- Füge ihn einmal vor dem schließenden body-Tag ein und veröffentliche die Änderung.
- Leere Caches und öffne mehrere öffentliche Unterseiten in einem privaten Fenster. Prüfe auch eine schmale mobile Ansicht.
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
Lege eigene Änderungen in einem Child-Theme oder einer vorgesehenen Erweiterung ab, damit Updates sie erhalten. Ein Content-Security-Policy-Header kann externe Scripts und Verbindungen blockieren; erlaube gezielt deine Service-Origin.
Häufige Fragen zu HTML / eigenes CMS
Gehört das Script in den head oder vor das schließende body-Tag?
Beides funktioniert. Mit defer führt der Browser das Script erst nach dem Einlesen der Seite aus, vor dem Ereignis DOMContentLoaded. Übernimm den Einbaucode deshalb unverändert mit defer.
Was gilt bei mehreren Domains oder Subdomains?
Das Widget lädt deine Projektkonfiguration nur auf der Domain, die im Projekt steht. Das Präfix www spielt keine Rolle, shop.example.com zählt aber als eigene Domain. Lege dafür ein eigenes Projekt an. Leseeinstellungen speichert der Browser pro Domain; sie wandern nicht zwischen Domains mit.
Was muss meine Content Security Policy erlauben?
Deine Service-Adresse in script-src für widget.js und in connect-src für den Konfigurationsabruf. Das Widget fügt außerdem style-Elemente ein und unterstützt dafür keine Nonce. style-src muss deshalb 'unsafe-inline' erlauben. Teste Änderungen zuerst mit dem Header Content-Security-Policy-Report-Only.
Kann ich auf einer Staging-Umgebung testen?
Ja, das Widget erscheint dort. Ohne passende Domain zeigt es aber das Standarddesign und den Accessonaut-Hinweis. Auch die Einbauerkennung im Dashboard reagiert nur auf die Domain im Projekt.
Wenn etwas nicht klappt
Es erscheint kein Button.
Ursache: Das Script lädt nicht: falsche Adresse, ein Tippfehler im Code, eine CSP-Regel oder ein Blocker.
Lösung: Öffne die Browser-Konsole und den Netzwerk-Tab. Prüfe, ob widget.js mit Status 200 lädt, und lies Fehlermeldungen zur CSP.
Der Button erscheint, aber mit Standarddesign und Accessonaut-Hinweis trotz bezahltem Tarif.
Ursache: Die Konfiguration wurde nicht geladen. Meist stimmt die Domain nicht mit dem Projekt überein oder die Projekt-ID ist falsch.
Lösung: Vergleiche Domain und data-project-id mit deinem Projekt. Im Netzwerk-Tab muss die Anfrage an /api/widget/config erfolgreich sein.
Du willst das Widget entfernen.
Ursache: Das Script steht im gemeinsamen Template.
Lösung: Lösche den Einbaucode, veröffentliche und leere die Caches. Gespeicherte Leseeinstellungen bleiben im Browser deiner Besuchenden, wirken ohne Widget aber nicht mehr.
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.