Das brauchst du
Zugriff auf den Quellcode und den gemeinsamen Layout- oder HTML-Einstieg deiner Anwendung. Lege in Accessonaut zuerst ein Projekt mit deiner tatsächlichen Website-Domain an und öffne im Projekt die Einbauseite.
Schritt für Schritt
- Öffne im Next.js App Router das gemeinsame Root-Layout. Importiere
Scriptausnext/script. - Verwende
next/scriptmit der öffentlichen widget.js-Adresse,data-project-idundstrategy="afterInteractive". Die Datenattribute entsprechen deinem Einbaucode. - Platziere die Einbindung einmal im gemeinsamen Layout. Bei React ohne Next.js kannst du den normalen Einbaucode in das HTML-Dokument übernehmen.
- Baue und veröffentliche die Anwendung. Prüfe harte Seitenaufrufe und clientseitige Navigation auf doppelte Buttons oder verlorene Einstellungen.
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.
import Script from 'next/script';
<Script
src="https://accessonaut.com/widget.js"
data-project-id="DEINE_PROJEKT_ID"
data-language="de"
strategy="afterInteractive"
/>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
Nutze als Script-Quelle die öffentliche Accessonaut-Service-Domain. Gib keine API-Schlüssel und keine Umgebungsvariablen mit Geheimnissen an den Browser weiter. CSP-Regeln müssen Script und Konfigurationsabruf erlauben.
Häufige Fragen zu Next.js / React
Wird das Widget bei clientseitiger Navigation neu geladen?
Nein. Ein <Script> im Root-Layout lädt laut Next.js nur einmal, auch wenn Besuchende zwischen Routen wechseln. Das Widget bleibt im body stehen, und aktive Lesehilfen gelten weiter. Die Sprache legt das Widget beim Start fest. Besuchende können sie im Panel wechseln.
Wo baue ich es im Pages Router ein?
In pages/_app.js oder pages/_app.tsx. Next.js empfiehlt dort next/script für Scripts, die auf allen Routen laden sollen. Auch dort lädt das Script nur einmal.
Was muss meine Content Security Policy erlauben?
Deine Service-Adresse in script-src und connect-src, denn das Widget ruft seine Konfiguration per fetch ab. Nutzt du Nonces wie im CSP-Leitfaden von Next.js, gib dem <Script> die Nonce als nonce-Prop. Das Widget fügt seine Styles als style-Elemente ein und unterstützt dafür keine Nonce. style-src muss deshalb 'unsafe-inline' erlauben. Steht dort eine Nonce, ignoriert der Browser 'unsafe-inline'.
Und bei React ohne Next.js, etwa mit Vite?
Bei Vite ist die index.html im Projektordner der Einstieg der Anwendung. Füge den normalen Einbaucode dort einmal vor dem schließenden body-Tag ein. Baue ihn nicht zusätzlich in eine Komponente ein.
Wenn etwas nicht klappt
Im Entwicklungsserver zeigt das Widget das Standarddesign mit Accessonaut-Hinweis.
Ursache: Auf localhost oder einer Vorschau-Domain lädt das Widget deine Projektkonfiguration nicht. Sie gilt nur für die Domain im Projekt.
Lösung: Prüfe Design und Tarifmerkmale auf der Produktionsdomain.
Die Browser-Konsole meldet einen CSP-Verstoß.
Ursache: Die Richtlinie blockiert Script, Konfigurationsabruf oder Styles des Widgets.
Lösung: Lies die gemeldete Direktive ab und ergänze die Service-Adresse in script-src oder connect-src. Bei style-src siehe die Antwort oben.
Du willst das Widget entfernen.
Ursache: Das Script steckt im gemeinsamen Layout.
Lösung: Lösche das <Script> aus dem Layout, baue neu und veröffentliche. Entferne auch CSP-Freigaben, die du nur für das Widget angelegt hast.
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.