Benutzerhandbuch

Dieses Kapitel richtet sich an Redakteure, die das TYPO3-Backend nutzen.

KI-Schaltflächen im Bearbeitungsformular

Die KI-Dienste stehen direkt in den Bearbeitungsformularen zur Verfügung — es muss kein separates Modul geöffnet werden. Überall, wo die Schaltfläche „✨ KI" erscheint, kann die KI durch einen Klick das benachbarte Feld befüllen. Das Ergebnis lässt sich vor dem Speichern prüfen und bearbeiten.

Seiten-Teaser

In den Seiteneigenschaften verfügt das Teaser-Feld (abstract) über eine „✨ KI"-Schaltfläche, die einen kurzen Teaser aus dem gerenderten Seiteninhalt erzeugt.

Meta-Description

Im Seitenlayout-Modul bietet das SEO-Panel „✨ Meta-Description mit KI erzeugen". Die Seite wird dabei zu einer Meta-Description mit maximal 155 Zeichen zusammengefasst, eine Vorschau zur Bearbeitung angezeigt und der Text bei „Übernehmen" auf der Seite gespeichert.

Alt-Texte generieren

Es gibt drei Möglichkeiten, Alt-Texte zu erstellen:

1. Einzeln über das Datei-Metadaten-Formular. Beim Bearbeiten der Metadaten eines Bildes ruft die Schaltfläche „Alt-Text generieren" die KI für die aktuell gewählte Sprache auf.

2. Massenweise per CLI. Für Websites mit vielen fehlenden Alt-Texten:

   # Testlauf — zeigt, was generiert würde, ohne DB-Schreibzugriffe.
   vendor/bin/typo3 nt_ai:generate-alt-texts --dry-run --limit=20
   
   # Echter Lauf, 100 Dateien, deutsche Ausgabe.
   vendor/bin/typo3 nt_ai:generate-alt-texts --limit=100 --language=de
   
   # Bestimmten Anbieter erzwingen.
   vendor/bin/typo3 nt_ai:generate-alt-texts --provider=openai
   
   # Vorhandene Alt-Texte ebenfalls überschreiben.
   vendor/bin/typo3 nt_ai:generate-alt-texts --overwrite
   
   # PDF-Dokumente ebenfalls berücksichtigen (Alt-Text aus dem PDF-Text).
   vendor/bin/typo3 nt_ai:generate-alt-texts --include-pdf
   

   Diesen Befehl über den Standard-Scheduler-Task „Konsolenbefehle ausführen" planen, damit neu hochgeladene Bilder automatisch abgedeckt werden.

3. Eigene Integration. Entwickler können die Methode AiService::generateAltText() direkt aufrufen — siehe Entwicklerhandbuch.

Alt-Texte für PDF-Dokumente

Auch PDF-Dokumente können einen KI-Alt-Text erhalten — relevant, wenn ein PDF als Vorschaubild mit Link zum vollständigen Dokument eingebunden ist. Da ein PDF nicht an die Bild-KI (Vision) gesendet werden kann, wird stattdessen sein Textinhalt extrahiert und zu einem prägnanten Alt-Text zusammengefasst (Art und Thema des Dokuments).

• Einzeln: dieselbe Schaltfläche „Alt-Text generieren" im Datei-Metadaten-Formular eines PDFs.
• Massenweise: nt_ai:generate-alt-texts --include-pdf (bezieht PDFs zusätzlich zu Bildern ein; ohne die Option bleibt es bei Bildern, damit bestehende Cron-Läufe unverändert bleiben).

Bei gescannten PDFs ohne Textebene ist keine Extraktion möglich — hier meldet das Werkzeug, dass kein Text gefunden wurde.

Die Alt-Texte werden durch die Alt-Text-Einstellungen geprägt — Stil, Länge, Tonalität, Markenkontext, benutzerdefinierte Regeln. Einmal angepasst, verwenden alle nachfolgenden Generierungen die neuen Einstellungen.

Barrierefreiheits-Audit durchführen

Web → Barrierefreiheits-Audit öffnen und eine Seite im Seitenbaum auswählen.

Wurde die Seite noch nie geprüft, erscheint ein Hinweisbanner. Klick auf „Audit jetzt starten". Die Extension lädt die gerenderte Seite per HTTP, parst sie, führt alle konfigurierten Regeln aus und speichert den Bericht.

Die Ergebnisseite zeigt:

• Score (0–100). Berechnungsformel: siehe Wie der Score berechnet wird.
• Anzahl je Schweregrad — Fehler, Warnungen, Hinweise.
• Befunde-Tabelle. Jede Zeile enthält:
  • Schweregrad-Badge
  • Regel-ID (verwendbar in TSconfig zum Deaktivieren einzelner Regeln)
  • Meldung — was falsch ist
  • Vorschlag — wie es behoben werden kann (oft KI-generiert)
  • WCAG-Referenz — das zugehörige Erfolgskriterium
  • Ort — ein CSS-Selektor, der auf das Element verweist
  • HTML-Ausschnitt — das betroffene Markup
• Frühere Berichte. Die letzten 10 Berichte werden zum Vergleich aufbewahrt, um zu erkennen, ob Änderungen den Score verbessern oder verschlechtern.

Klick auf „Aktuellsten Bericht als CSV exportieren", um den Bericht zur Weitergabe oder Archivierung herunterzuladen.

BFSG-Bericht (druckbar / PDF)

Über die Schaltfläche „Bericht (BFSG)" in der Seitendetail-Ansicht öffnet sich ein eigenständiger, druckbarer HTML-Bericht (WCAG 2.2 · BFSG · EN 301 549). Er ist self-contained (eingebettetes CSS, Screenshot als Data-URI) und lässt sich über „Drucken / als PDF speichern" direkt als PDF ablegen oder archivieren.

Der Bericht enthält:

• ein Konformitäts-Verdict (Nicht konform / Teilweise konform / Automatisiert konform),
• Kennzahlen (Score, Fehler, Warnungen, Hinweise) sowie — falls vorhanden — den Lighthouse-Accessibility-Score und einen gerenderten Screenshot der Seite,
• die Befunde nach WCAG-Kriterium gruppiert mit Schweregrad, Meldung, Empfehlung und Code-Ausschnitt,
• einen Disclaimer, dass es sich um eine automatisierte, teils KI-gestützte Prüfung handelt — keine rechtsverbindliche Barrierefreiheitserklärung.

Tip

Im Druckdialog „Hintergrundgrafiken" aktiviert lassen, damit die farbigen Schweregrad-Badges auch im PDF sichtbar sind.

Gesamtbericht (seitenübergreifend)

In der Site-Übersicht (Modul ohne ausgewählte Seite bzw. Reiter „Site-Übersicht") erzeugt die Schaltfläche „Gesamtbericht (BFSG)" einen druckbaren Bericht über alle auditierten Seiten (jeweils der letzte Audit pro Seite):

• aggregiertes Konformitäts-Verdict (z. B. „Nicht konform – 23 von 58 Seiten mit kritischen Fehlern"),
• Kennzahlen inkl. Durchschnitts-Score und Aufteilung konform / mit Warnungen / mit kritischen Fehlern,
• Seitenübersicht (schlechteste zuerst) mit Score und Status je Seite,
• häufigste WCAG-Barrieren seitenübergreifend mit Vorkommen und Anzahl betroffener Seiten.

Dies ist das geeignete Nachweisdokument für die BFSG-Dokumentation. Es werden nur Seiten berücksichtigt, auf die der/die angemeldete Redakteur/in Zugriff hat.

Barrierefreiheitserklärung erstellen

Der Reiter „Erklärung" im Audit-Modul erzeugt aus den vorhandenen Audit-Daten den Entwurf einer Erklärung zur Barrierefreiheit (nach dem BITV-Mustertext / BFSG § 14, EU 2016/2102) und veröffentlicht ihn nach redaktioneller Freigabe auf der Barrierefreiheits-Seite.

So funktioniert es:

1. Fakten — der Reiter zeigt oben, was nt-ai bereits gemessen hat: Stand der Vereinbarkeit, Seiten ohne kritische Befunde, konforme PDF-Dokumente, das Datum der letzten Prüfung, die übernommenen WCAG-Barrieren sowie die umgesetzten Maßnahmen. Diese Fakten fließen unverändert in den Entwurf — die Erklärung kann so nicht vom Gesamtbericht abweichen.
2. Entwurf erzeugen — pro Sprache (Deutsch, und Englisch falls die Zielseite eine Übersetzung hat) erzeugt die KI einen strukturierten Entwurf. Fehlende Pflichtangaben werden als „[bitte ergänzen]" markiert statt geraten.
3. Prüfen & anpassen — der Entwurf erscheint editierbar im Textfeld. Die rechtliche und inhaltliche Freigabe bleibt beim Betreiber; automatisierte Prüfungen decken nur einen Teil der WCAG-Kriterien ab.
4. Übernehmen — veröffentlicht den freigegebenen Text auf die Zielseite. Beim ersten Mal wird das vorhandene Erklärungs-Element auf der Seite aktualisiert (kein Duplikat); danach immer dasselbe Element (versioniert, mit Zugriffsprüfung über den DataHandler).

Zielseite: standardmäßig die Seite mit dem Slug /barrierefreiheit, alternativ per Seiten-UID in den Extension-Einstellungen. Die Angaben zu Feedback-Kontakt, Durchsetzungs-/Schlichtungsstelle und den Maßnahmen werden ebenfalls dort gepflegt (Reiter „Barrierefreiheitserklärung"). Installierte Schwester-Erweiterungen (nt-lingua) und das nt-ai-Audit werden automatisch als Maßnahmen ergänzt.

Das Werkzeug erstellt einen fundierten, datengestützten Entwurf — keine Rechtsberatung. Verantwortung und Freigabe liegen beim Betreiber.

Vorschau-Audit für unveröffentlichte Seiten

Der Audit prüft die gerenderte Frontend-Seite. Seiten mit einem Startdatum in der Zukunft, versteckte oder zugriffsbeschränkte Seiten wären im normalen Frontend nicht erreichbar. Damit auch solche Seiten vor der Veröffentlichung geprüft werden können, ruft der Audit die Seite über einen kurzlebigen, signierten Vorschau-Token ab (simuliert Zeit und Sichtbarkeit wie die Backend-Vorschau). Der manuelle Audit und nt_ai:audit --preview nutzen diesen Modus automatisch — es ist keine Konfiguration nötig.

Audit-Auslöser

Der Audit kann auf drei Arten gestartet werden:

• Manuell — Schaltfläche „Audit jetzt starten" im Backend-Modul.
• Beim Speichern — audit.autoOnSave aktivieren; jedes Seitenspeichern löst einen Audit aus (durch audit.autoCooldown ratenbegrenzt).

• Geplant / CLI — vendor/bin/typo3 nt_ai:audit per Cron oder Scheduler ausführen:

  # Eine einzelne Seite prüfen.
  vendor/bin/typo3 nt_ai:audit --page=42 --save
  
  # Bis zu 100 Seiten prüfen, Fehler wenn Score unter 80.
  vendor/bin/typo3 nt_ai:audit --limit=100 --save --min-score=80
  
  # Nur Seiten mit Befunden anzeigen.
  vendor/bin/typo3 nt_ai:audit --limit=100 --quiet-pass
  

  Mit --min-score gibt der Befehl einen Rückgabewert ungleich null zurück, wenn eine Seite den Schwellenwert unterschreitet — nützlich für CI-Pipelines. Mit --fail-on=error (oder warning) richtet sich der Rückgabewert nach den Befund-Schweregraden statt nach dem Score.

Publishing Quality Gate (Freigabe-Prüfung)

Der Quality Gate verhindert (oder warnt), dass Seiten mit ungelösten kritischen Barrierefreiheits-Befunden veröffentlicht werden. Er greift, wenn eine Seite im Backend gespeichert bzw. sichtbar geschaltet wird, und wertet den zuletzt gespeicherten Audit-Bericht der Seite aus.

Modi (Extension-Einstellung audit.qualityGate):

• off — deaktiviert (Standard).
• warn — Speichern ist erlaubt, es erscheint aber eine Flash-Message mit der Anzahl kritischer Befunde.
• block — die Veröffentlichung wird verhindert: Die Seite bleibt versteckt, bis die Befunde behoben (und der Audit erneut ausgeführt) wurde.

Weitere Einstellungen:

• audit.qualityGateSeverity — ab welchem Schweregrad geblockt wird: error (nur Fehler) oder warning (Fehler und Warnungen).
• audit.qualityGateScope — onPublish (nur beim Sichtbar-Schalten einer versteckten Seite) oder onSave (bei jedem Speichern einer sichtbaren Seite).
• audit.qualityGateAdminBypass — wenn aktiv, dürfen Administratoren den Gate trotz Befunden überschreiben.

Note

Der Gate bewertet den letzten Audit. Nach dem Beheben von Befunden die Seite erneut auditieren, sonst blockiert der veraltete Bericht weiterhin. Liegt für eine Seite noch gar kein Audit vor, greift der Gate nicht.

Wie der Score berechnet wird

Der Audit-Score ist ein ganzzahliger Wert von 0–100, der aus den Befunden eines einzelnen Audit-Laufs abgeleitet wird. Er beginnt bei 100 und zieht Punkte basierend auf dem Schweregrad jedes Befunds ab:

Schweregrad	Abzug je Befund	Bedeutung
Fehler	−10 Punkte	Eindeutiger WCAG-Verstoß (fehlender Alt-Text, unterbrochene Überschriftenhierarchie, fehlendes Formular-Label, …)
Warnung	−3 Punkte	Wahrscheinliches Problem oder dringende Best-Practice-Empfehlung (generischer Linktext, geringer Kontrast, langer Satz, …)
Hinweis	−1 Punkt	Stilhinweis oder geringes Qualitätssignal (Absatzlänge, Verteilung von Zwischenüberschriften, …)

Der Score fällt nie unter 0. Eine Seite mit zehn Fehlern erhält 100 − 10 × 10 = 0.

Farbliche Schwellenwerte:

• Grün (90–100) — hervorragend; nur geringfügige Probleme.
• Gelb (70–89) — Handlungsbedarf; einige Warnungen oder Hinweise.
• Rot (0–69) — kritisch; enthält Fehler oder viele Warnungen.

Note

Der Score ist ein schneller redaktioneller Indikator, kein WCAG-Konformitätszertifikat. Ein Score von 100 bedeutet, dass von den konfigurierten Regeln kein Befund erkannt wurde — nicht, dass die Seite vollständig barrierefrei ist. Manuelle Tests mit assistiver Technologie sind für vollständige Konformität stets erforderlich.

Befunde verstehen

Schweregrade:

Fehler

Ein eindeutiger WCAG-Verstoß. Vor der Veröffentlichung beheben.

Warnung

Ein wahrscheinliches Problem oder eine WCAG-AA-Empfehlung. Sollte behoben werden.

Hinweis

Stilhinweis oder Best Practice. Prüfenswert.

Häufige Befunde und Lösungshinweise:

Bild hat kein alt-Attribut

Die Schaltfläche „Alt-Text generieren" in den Datei-Metadaten verwenden oder den Massen-CLI-Befehl ausführen.

Generischer Linktext „hier klicken" beschreibt das Ziel nicht

Den Link so umformulieren, dass das Ziel klar wird, z. B. „Jahresbericht 2025 herunterladen" statt „hier klicken".

Überschriftenebene springt von h2 auf h4

Keine Ebenen überspringen. Stattdessen h3 verwenden oder die umgebenden Überschriften neu strukturieren.

Das <html>-Element hat kein lang-Attribut

Die Sprache in der TYPO3-Site-Konfiguration festlegen. Das Frontend gibt dann automatisch <html lang="..."> aus.

Kontrastverhältnis 3,2:1 liegt unter WCAG AA

Die Inline-Farbe im RTE anpassen oder im CSS des Sitepackages korrigieren.

PDF-Barrierefreiheit

Das Modul Medien → PDF Accessibility prüft alle im System indexierten PDFs auf maschinell erkennbare Barrierefreiheits-Merkmale (BFSG betrifft auch Dokumente):

Prüfung	Referenz	Schwere
Getaggtes PDF (Struktur-Baum)	PDF/UA-1 · WCAG 1.3.1	Fehler
Gescannte Seiten ohne Textebene	WCAG 1.1.1 / 1.4.5	Fehler
Dokumentsprache (/Lang)	WCAG 3.1.1	Fehler
Alternativtexte für Abbildungen (Figure ohne /Alt)	WCAG 1.1.1	Fehler
Verschlüsselung / Zugriffsschutz	PDF/UA-1	Fehler
Dokumenttitel + Titel-Anzeige	WCAG 2.4.2	Warnung
Schrifteinbettung	PDF/UA-1	Warnung
Lesezeichen bei langen Dokumenten (≥ 20 Seiten)	Best Practice	Hinweis
PDF/UA-Kennzeichnung (XMP)	Matterhorn 06-002	Hinweis

Jede Datei erhält einen Score (0–100) mit Ampel-Status; die Befundliste enthält je Problem eine konkrete Handlungsempfehlung (z. B. „mit Tags neu exportieren", „OCR durchführen"). Geprüft wird rein in PHP — es sind keine Systemwerkzeuge nötig. Bereits geprüfte, unveränderte Dateien (gleicher SHA1) werden übersprungen.

CLI/Scheduler: nt_ai:pdf-audit [--limit N] [--force] [--fail-on=error|warning] — Exit-Code 1 bei Befunden der angegebenen Schwere (CI-tauglich).

Zusätzlich verfügbar:

• Dashboard-Widget „PDF-Barrierefreiheit": Anteil der PDFs ohne Fehler als Ring, Zählkacheln (ohne Fehler / mit Fehlern / ungeprüft).
• BFSG-Gesamtbericht: Der druckbare Gesamtbericht (Site-Übersicht → „Gesamtbericht (BFSG)") enthält einen Abschnitt „Dokumente (PDFs)" mit Status je Datei — BFSG betrifft ausdrücklich auch Dokumente.
• Berichte gelöschter Dateien werden automatisch entfernt; Statistiken zählen nur tatsächlich vorhandene PDFs.

Upload-Gate

In der Erweiterungskonfiguration (Tab PDF) lässt sich ein Gate für Backend-Uploads aktivieren:

Einstellung	Wirkung
pdf.uploadGate	off (Standard) · warn = Datei wird gespeichert, Redakteur erhält eine Warnung mit den Befunden · block = Upload nicht barrierefreier PDFs wird mit einer Meldung inkl. Befunden abgelehnt
pdf.uploadGateSeverity	Ab welchem Schweregrad das Gate greift: error oder auch warning (Standard)
pdf.uploadGateAdminBypass	Administratoren dürfen trotz Befunden hochladen (erhalten nur die Warnung)

Bei jedem Backend-PDF-Upload wird zusätzlich automatisch ein Bericht gespeichert — das Modul bleibt so ohne manuelle Läufe aktuell. Frontend-Formular-Uploads sind vom Gate ausgenommen (Besucher können das Dokument nicht korrigieren).

Grenzen der automatischen Prüfung

Lesereihenfolge, Kontraste im Layout und die inhaltliche Qualität von Alternativtexten sind nicht maschinell prüfbar. Ein befund­freies PDF ist ein starkes Signal, aber kein PDF/UA-Zertifikat — dafür sind Acrobat/veraPDF und eine manuelle Prüfung nötig.

KI-Inhaltsqualitäts-Score (Seiten-Score)

Der Seiten-Score analysiert den gerenderten Seiteninhalt mit einem LLM und bewertet ihn in fünf Kategorien auf einer Skala von 0–100:

Kategorie	Was bewertet wird
GEO/SEO	Qualität der Meta-Description, Titeloptimierung, strukturierte Inhalte für KI-Suchmaschinen, Themenautorität und Entitätsklarheit.
Performance	Seitenstruktur: Überschriftenhierarchie, Bild-Alt-Attribute, semantisches HTML, minimale Inline-Stile.
Semantics	HTML5-Landmark-Elemente (<article>, <main>, <aside>), ARIA-Labels, Strukturdaten-Signale.
Keywords	Vorhandensein des Fokus-Keywords in Titel, erstem Absatz und Überschriften; natürliche Keyword-Dichte.
Barrierefreiheit	WCAG-Signale: Alt-Texte, Formular-Labels, Linktext-Qualität, Kontrasthinweise.

Score-Schwellenwerte:

• ≥ 75 — gut (grüner Ring)
• 50 – 74 — ausreichend (bernsteinfarbener Ring)
• < 50 — kritisch (roter Ring)

Note

Der Score ist eine LLM-Schätzung, keine deterministische Messung. Als schnellen redaktionellen Kompass verwenden, nicht als Konformitätszertifikat. Für verbindliche WCAG-Prüfungen den Barrierefreiheits-Audit nutzen.

Fundorte:

Seitenlayout-Modul — Inline-Panel

Eine Seite in der Seitenlayout-Ansicht öffnen. Die dritte Spalte des KI-Assistent-Panels („Seiten-Score") zeigt fünf Messringe. Beim ersten Öffnen einer Seite auf „Analyse starten" klicken. Nach Abschluss der Analyse füllen sich die Ringe mit Farbe und eine Liste konkreter Verbesserungsvorschläge erscheint. Nach inhaltlichen Änderungen auf „Neu analysieren" klicken.

Note

Die Verbesserungsvorschläge werden in der Sprache des Backends erzeugt (nicht in der Sprache der geprüften Seite). Ein deutsches Backend liefert also auch bei englischen Seiten deutsche Tipps.

Dashboard-Widgets

Unter Backend → Dashboard → Widgets hinzufügen → KI beliebige Widgets hinzufügen:

• Score-Übersicht — ein Widget mit allen fünf Kategoriedurchschnittswerten als Mini-Ringe und der Anzahl analysierter Seiten.
• Score: GEO/SEO, Score: Performance, …, Score: Barrierefreiheit — einzelne Messringe je Kategorie, die den Durchschnitt über alle analysierten Seiten zeigen.

Score-Verlauf

Bei jeder Score-Analyse — manuell oder durch den Scheduler — werden die Ergebnisse angehängt; alte Scores werden nie gelöscht. Das Inline-Panel zeigt unterhalb der Ringe eine Reihe farbiger Punkte, sobald mindestens zwei historische Läufe vorliegen. Jeder Punkt steht für einen Analyselauf:

• Grüner Punkt — Durchschnitt aller fünf Scores war ≥ 75 (gut)
• Bernsteinfarbener Punkt — Durchschnitt war 50–74 (Handlungsbedarf)
• Roter Punkt — Durchschnitt war < 50 (kritisch)

Über einem Punkt hovern, um Datum und genauen Durchschnitt zu sehen. Der rechteste Punkt ist stets der aktuellste Lauf (volle Deckkraft; ältere Läufe sind abgedunkelt).

Fokus-Keyword festlegen

Das Keyword-Feld unter Seiteneigenschaften → SEO (Fokus-Keyphrase) wird sowohl vom Keyword-Score als auch von der SeoKeyphraseRule im Barrierefreiheits-Audit genutzt. Es sollte auf den Hauptsuchbegriff gesetzt werden, für den die Seite ranken soll. Die KI-Schaltfläche neben dem Feld generiert einen Keyword-Vorschlag aus dem Seiteninhalt.

Massenanalyse ausführen

# Alle Seiten aller Sites.
vendor/bin/typo3 nt_ai:analyze-pages

# Seite 42 und vollständiger Teilbaum.
vendor/bin/typo3 nt_ai:analyze-pages 42 99

# Nur direkte Unterseiten von Seite 1.
vendor/bin/typo3 nt_ai:analyze-pages 1 1

Jede Seite wird in allen konfigurierten Site-Sprachen in einem Lauf analysiert. Diesen Befehl über den TYPO3-Scheduler planen, damit Scores nach Inhaltsänderungen aktuell bleiben.

Note

Der Befehl ist token-intensiv — jede Seite verursacht einen LLM-Aufruf. Kosten über das Dashboard-Widget Token-Verbrauch im Blick behalten.

SEO-Feld-Assistent

Das SEO-Panel im Seitenlayout-Modul bietet Ein-Klick-Generierung für drei SEO-Felder:

SEO-Titel

„Generieren" → Vorschau eines Seitentitels mit maximal 60 Zeichen, optimiert für Suchergebnisse. „Übernehmen" speichert ihn direkt in pages.seo_title.

Meta-Description

„Generieren" → Vorschau einer Meta-Description mit maximal 155 Zeichen. Speichert in pages.description.

Fokus-Keyphrase

„Generieren" → schlägt ein Fokus-Keyword aus dem Seiteninhalt vor. Speichert in pages.tx_ntai_focus_keyphrase.

Dieselben drei Felder haben auch in den Seiteneigenschaften „✨ KI"-Schaltflächen für Redakteure, die dort lieber arbeiten.

Lighthouse-Monitoring

Öffentlich erreichbare URLs erforderlich

PSI analysiert Seiten durch Abruf ihrer öffentlichen URLs von Google-Servern. Für lokale Entwicklungsumgebungen (DDEV, localhost) funktioniert dies nicht, da Google diese nicht erreichen kann. Lighthouse-Prüfungen nur auf dem Produktivserver oder einem öffentlich erreichbaren Staging-Server ausführen.

Was gemessen wird

Score	Was gemessen wird
Performance	Ladegeschwindigkeit der Seite, Ressourceneffizienz, render-blockierende Assets.
Accessibility	Lighthouse-automatische Barrierefreiheitsprüfungen (ergänzt den nt-ai-WCAG-Audit, der das gerenderte DOM tiefer analysiert).
Best Practices	HTTPS-Nutzung, Konsolenfehler, veraltete APIs, Bildformate.
SEO	Meta-Tags, robots.txt, mobilfreundliches Rendering.

Core Web Vitals werden ebenfalls erfasst:

• LCP (Largest Contentful Paint) — Ladeleistung
• CLS (Cumulative Layout Shift) — visuelle Stabilität
• INP (Interaction to Next Paint) — Reaktionsfähigkeit

Dashboard-Widget

Das Widget Lighthouse-Scores unter Backend → Dashboard → Widgets hinzufügen → KI hinzufügen. Es zeigt die durchschnittlichen Scores über alle analysierten Seiten als vier Messringe, gruppiert nach der konfigurierten Strategie (Mobil/Desktop).

Anzeige im Seitenlayout-Modul

Zusätzlich zur Modul-Übersicht zeigt das KI-Assistent-Panel im Seitenlayout-Modul eine eigene Spalte „Lighthouse" mit den vier Messringen (Performance, Barrierefreiheit, Best Practices, SEO) der zuletzt gespeicherten Messung dieser Seite, samt Strategie und Zeitpunkt. Von dort führt ein Link direkt ins Lighthouse-Modul.

Die Anzeige ist read-only: Lighthouse wird ausschließlich über den Scheduler/CLI gemessen (öffentliche URL erforderlich). Liegt für die Seite noch keine Messung vor, erscheint ein entsprechender Hinweis mit Link ins Modul.

Lighthouse-Prüfungen ausführen

# Alle Seiten mit konfigurierter Strategie (standardmäßig mobil).
vendor/bin/typo3 nt_ai:lighthouse

# Seite 42 und vollständiger Teilbaum, Desktop-Strategie.
vendor/bin/typo3 nt_ai:lighthouse 42 99 --strategy=desktop

# Beide Strategien in einem Lauf (verdoppelt API-Aufrufe).
vendor/bin/typo3 nt_ai:lighthouse 42 99 --strategy=both

nt_ai:lighthouse als Scheduler-Task „Konsolenbefehle ausführen" einplanen. Empfehlung: nächtlich nach nt_ai:analyze-pages ausführen, damit beim Alarm-Check alle Daten aktuell sind.

Score-Schwellenwert-Alarme

Der Befehl nt_ai:alert-check vergleicht die aktuellsten KI-Inhalts-Scores und Lighthouse-Scores mit den je Kategorie konfigurierten Schwellenwerten unter Admin Tools → Settings → Extension Configuration → nt_ai → Alerting.

Wenn eine Seite einen Schwellenwert unterschreitet, wird eine einzige HTML-Zusammenfassungs-E-Mail mit allen Verstößen versandt — eine E-Mail pro Lauf, kein seitenweiser Spam.

Alarme konfigurieren

1. alerting.enabled auf 1 setzen.
2. alerting.recipient auf die zu benachrichtigende(n) E-Mail-Adresse(n) setzen.
3. Schwellenwerte für jede zu überwachende Kategorie eingeben (0 deaktiviert den Alarm für diese Kategorie).

Empfohlene Schwellenwerte:

• KI-Inhalts-Scores: 50 (kritischer Schwellenwert — roter Bereich)
• Lighthouse Performance: 70
• Lighthouse Accessibility: 80 (automatische Lighthouse-Prüfung, nicht WCAG)

Planung

Einen Scheduler-Task „Konsolenbefehle ausführen" für nt_ai:alert-check anlegen und nach den Analyse-Läufen einplanen:

03:00  nt_ai:analyze-pages    (KI-Inhalts-Scores)
03:30  nt_ai:lighthouse       (Lighthouse-PSI-Scores)
04:00  nt_ai:alert-check      (vergleichen + E-Mail senden falls nötig)

Token-Verbrauch und Kostenschätzung

Wenn das Token-Tracking aktiviert ist (tokenTracking.enabled = 1 in der Erweiterungskonfiguration), wird jeder KI-Aufruf protokolliert. Die Dashboard-Widgets unter Web → Dashboard zeigen den Verbrauch:

• Token-Verbrauch — Gesamt-Tokens und geschätzte Kosten für den aktuellen Monat, aufgeschlüsselt nach Anbieter und Kontext. Das Feld „ca. Kosten" erscheint blau, wenn das Modell in der integrierten Preistabelle gelistet ist.
• Verbrauch nach Benutzer — Token-Anzahl und geschätzte Kosten je Redakteur für den aktuellen Monat.
• Token-Verlauf — ein Balkendiagramm des täglichen Token-Verbrauchs über die Zeit.

Kosten sind ausschließlich Schätzungen, berechnet aus den protokollierten Token-Anzahlen anhand der integrierten Preistabelle (Configuration/ModelPricing.php). Für nicht gelistete Modelle wird eine Warnung angezeigt. Wechselkurs und benutzerdefinierte Modellpreise lassen sich bei Bedarf in der Erweiterungskonfiguration anpassen.

Barrierefreiheits-Widget (Frontend)

Zusätzlich zu den Backend-Werkzeugen liefert nt-ai ein optionales Frontend-Widget, mit dem Besucher die Darstellung an ihre Bedürfnisse anpassen können. Es erscheint als runde Schaltfläche unten links („Barrierefreiheit"); ein Klick öffnet ein Einstellungsfeld.

Funktionen

Funktion	Wirkung
Textgröße	Vergrößert/verkleinert den Inhalt (Seiten-Zoom, 100–175 %).
Textabstand vergrößern	Zeilen-, Wort- und Buchstabenabstand nach WCAG 1.4.12.
Kontrast erhöhen	Verstärkt den Kontrast; Stärke per Regler.
Farbsättigung / Graustufen	Reduziert die Farbsättigung bis zu Graustufen (Regler).
Blaulichtfilter	Warmer Filter gegen Blaulicht; Stärke per Regler.
Dunkelmodus	Schaltet das native dunkle Theme der Website (Markenorange bleibt Akzent).
Farbschwäche	Farbanpassung für Rot-, Grün- oder Blausehschwäche (Durchschalten).
Animationen reduzieren	Deaktiviert Bewegungen/Übergänge.
Links hervorheben	Unterstreicht und markiert alle Links.
Fokus hervorheben	Deutliche Umrandung des per Tastatur fokussierten Elements.
Leichter lesbare Schrift	Wechselt auf eine gut lesbare Schriftfamilie.
Größerer Mauszeiger	Vergrößert den Mauszeiger.
Lesehilfe (Lineal)	Ein Leseband folgt dem Mauszeiger.
Bilder ausblenden	Blendet Inhaltsbilder aus (Logo, Navigation, Hero, Footer bleiben).
Ton stummschalten	Schaltet den Ton aller Audio-/Videoelemente stumm.
Webseite vorlesen	Vorlesefunktion — siehe Vorlesefunktion.

Bei Hover/Fokus über einen Menüpunkt erscheint eine Kurzbeschreibung seitlich am Panel. Das Widget ist vollständig tastaturbedienbar (echte Buttons/Regler, Alt + 1 öffnet/schließt, Esc schließt). Die Einstellungen werden lokal im Browser gespeichert (localStorage) — keine Server-Speicherung, kein Tracking. „Alles zurücksetzen" (unten oder als ↺ oben) stellt den Ausgangszustand her.

Konfiguration im Backend

Das Widget wird über die Site-Einstellungen gesteuert (Site-Verwaltung → Einstellungen → Barrierefreiheit):

Einstellung	Wirkung	Standard
Barrierefreiheits-Widget anzeigen	Blendet das Widget ein/aus.	ein
Position des Widgets	Ecke: bottom-right, bottom-left, top-right, top-left.	bottom-right
Beschriftung anzeigen	Aus = nur Symbol (dezent), Ein = Symbol mit Text „Barrierefreiheit".	aus
Symbol	Launcher-Symbol (8 Varianten: Person im Doppelkreis, im Kreis, mit Armen, auf Linie, im gefüllten Kreis, Rollstuhl, aktiver Rollstuhl, Hand mit Person).	classic
Symbolgröße (px)	Größe des Symbols.	26
Abstand zum Seitenrand (px)	Horizontaler Abstand zum linken/rechten Rand.	16
Abstand oben/unten (px)	Vertikaler Abstand zum oberen/unteren Rand.	16
Ziel für Textgröße & Farbfilter	CSS-Selektor des Elements, auf das Schriftvergrößerung (Zoom) und Farbfilter (Kontrast, Sättigung, Farbschwäche) wirken. Muss den Inhalt umschließen, aber keine fixierten Elemente (Sticky-Header, Zurück-nach-oben) enthalten.	#maincontent

Standardmäßig erscheint nur das dezente Symbol unten rechts (damit es z. B. den Cookie-Consent-Button nicht überdeckt).

Dunkelmodus = echtes Theme

Der Dunkelmodus des Widgets schaltet ein natives dunkles Theme der Website (nt-dark-theme.css im Sitepackage, aktiviert über html[data-nt-theme="dark"]) — kein CSS-Invert-Filter mehr. Die Markenfarbe (Orange) bleibt als Akzent erhalten.

Systemeinstellungen haben Vorrang

Betriebssystem und Browser bieten viele dieser Optionen bereits systemweit. nt-ai respektiert diese automatisch: prefers-reduced-motion, prefers-contrast und prefers-color-scheme werden berücksichtigt; zusätzlich ist ein seitenweiter prefers-reduced-motion-Schutz für die Scroll-Animationen des Themes (.animate-box) enthalten, sowie Fokus-Sichtbarkeit im Windows-Kontrastmodus (forced-colors). Außerdem liefert das Set zwei Tastatur-Guards: Skip-Links (.visually-hidden-focusable) werden bei Tastaturfokus sichtbar eingeblendet, und ein :focus-visible-Sicherheitsnetz sorgt für eine sichtbare Fokus-Umrandung, auch wenn das Theme outline unterdrückt.

Warum ein Widget — und ausdrücklich kein Overlay

Kommerzielle „Accessibility-Overlays" (z. B. Werkzeuge, die per JavaScript ARIA nachrüsten oder die Seite „automatisch barrierefrei machen") stehen in der Fachwelt stark in der Kritik. nt-ai vermeidet bewusst diesen Ansatz:

• Overlays beheben keine echten Fehler. Sie überlagern das Problem, statt es in der Quelle zu lösen. Rechtlich (BFSG / EN 301 549) zählt die barrierefreie Quelle — kein Widget schützt vor Klagen oder Beanstandungen.
• Overlays sind oft selbst eine Barriere. Sie kollidieren mit Screenreadern und Tastaturbedienung, verändern ungefragt den DOM und können assistive Technik stören.
• Sie duplizieren, was das System schon kann. Nutzer mit Behinderung haben ihre Hilfsmittel bereits konfiguriert; ein Widget, das dagegen ankämpft, verschlechtert die Lage.

Das nt-ai-Widget ist deshalb bewusst als Komfort-/Personalisierungs-Layer ausgelegt, nicht als „Barrierefrei-Macher":

• Kein DOM- oder ARIA-Rewriting. Es setzt ausschließlich data-*-Attribute auf <html>; reines CSS erledigt die Darstellung. Der Seiteninhalt bleibt unberührt.
• Systemeinstellungen werden respektiert, nicht überschrieben (siehe Hinweis oben).
• Das Widget selbst ist vollständig barrierefrei: echte Schaltflächen, aria-expanded/aria-pressed, Tastaturbedienung, Esc schließt und gibt den Fokus zurück, keine Fokusfalle.
• Datenschutzfreundlich: rein lokal, keine externen Requests.

Der Konformitäts-Pfad bleibt der Audit

Das Widget ersetzt nicht die Barrierefreiheit der Website. Echte Konformität entsteht durch das Beheben der Ursachen — dafür sind das Barrierefreiheits-Audit, die BFSG-Berichte und der Alt-Text-Generator von nt-ai gedacht. Das Widget ist Komfort obendrauf.

Geplant (Stufe 2)

Eine Vorlese-Funktion (Text-to-Speech) ist als spätere Erweiterung vorgemerkt. Sie wurde bewusst zurückgestellt, weil sie Screenreader-Funktionalität dupliziert und nur für Nutzer ohne assistive Technik sinnvoll ist — sie muss sauber davon getrennt und klar gekennzeichnet werden.

Vorlesefunktion (Text-to-Speech)

nt-ai bringt eine selbstgehostete Vorlesefunktion mit, die Dienste wie ReadSpeaker vollständig ersetzt. Sie liest den Inhaltsbereich (#maincontent) Block für Block vor und hebt den gerade gesprochenen Absatz hervor. Die Steuerleiste bietet Zurück/Vor (Absatz), Pause/Stopp sowie Regler für Lautstärke und Tempo. Zusätzlich gibt es im Widget den Modus „Klicken und vorlesen": einschalten und einen beliebigen Absatz anklicken, um ab dort vorlesen zu lassen.

Zwei Wege zur Nutzung

1. Im Barrierefreiheits-Widget: der Punkt „Webseite vorlesen".

2. Frei im Template platzierbar (z. B. neben dem Klickpfad): ein sichtbarer „Vorlesen"-Button. Entweder das mitgelieferte Fluid-Partial oder blankes HTML — beide werden automatisch verdrahtet:

   <!-- Fluid-Partial (Sitepackage) -->
   <f:render partial="ReadAloud" arguments="{_all}"/>
   
   <!-- oder direkt im Template/HTML -->
   <button type="button" class="nt-tts-btn" data-nt-tts>Vorlesen</button>
   

   Optional lässt sich der vorzulesende Bereich pro Button überschreiben: data-nt-tts="#mein-bereich".

Engine — hybrid, vom Admin umschaltbar

Die Sprachausgabe-Engine wird in den Site-Einstellungen gewählt (Site-Verwaltung → Einstellungen → Vorlesen (TTS)):

Einstellung	Wirkung	Standard
Vorlesefunktion aktivieren	Schaltet Vorlesen (Widget + Buttons) an/aus.	ein
Sprachausgabe-Engine	Web Speech (Browser-Stimmen, kostenlos, lokal) oder Cloud (Premium-Stimmen).	Web Speech
Sprechgeschwindigkeit (%)	Relative Geschwindigkeit (100 = normal).	100
Vorlese-Bereich	CSS-Selektor des vorzulesenden Bereichs.	#maincontent

• Web Speech nutzt die im Browser/Betriebssystem vorhandenen Stimmen — kostenlos, keine Datenübertragung. Qualität je nach Gerät gut bis solide.
• Cloud erzeugt Premium-Stimmen serverseitig über nt-ai. Der Anbieter/Key wird in der nt-ai-Erweiterungskonfiguration (Tab Vorlesen (TTS)) gesetzt: tts.cloudProvider (z. B. OpenAI), tts.voice, tts.model; der API-Key ist der des jeweiligen Providers. Erzeugte Audios werden serverseitig gecacht (tts.cloudProvider|voice|model|Sprache|Tempo|Text), sodass wiederholtes Vorlesen desselben Textes keine weiteren Kosten verursacht. Der API-Key verlässt den Server nicht.

Aussprache korrigieren

Akronyme/Markennamen wie TYPO3 werden von Stimmen oft buchstabiert („T-Y-P-O-3"). Über die Site-Einstellung „Aussprache-Ersetzungen" lässt sich das einfangen: Begriffe im Format Begriff=Aussprache, mehrere durch | getrennt — z. B. TYPO3=Typo drei|CMS=C-M-S. Die Ersetzung wirkt vor beiden Engines (nur die Sprachausgabe wird geändert, der sichtbare Seitentext bleibt), berücksichtigt Groß-/Kleinschreibung und ganze Wörter. Keine Anführungszeichen verwenden.

Datenschutz

Bei Web Speech bleibt alles im Browser. Bei Cloud wird der vorzulesende Text an den konfigurierten Anbieter gesendet (AVV beachten). Fällt der Cloud-Dienst aus, schaltet der Client automatisch auf die Browser-Stimme zurück.

Die Steuerung ist vollständig tastaturbedienbar; die Vorlesefunktion ist kein Ersatz für einen Screenreader, sondern ein Zusatzangebot für Nutzer ohne assistive Technik.

Schutz vor Bots & Massennutzung, Kosten

Der Cloud-Endpunkt (/nt-ai/tts) löst kostenpflichtige API-Aufrufe aus und ist deshalb mehrfach geschützt:

• Nur bei Engine „Cloud" aktiv — läuft die Site auf Web Speech, antwortet der Endpunkt nicht (HTTP 403).
• Cross-Site-Anfragen werden abgewiesen (HTTP 403; das Audio wird nur von der eigenen Seite geladen).
• Rate-Limit pro IP — Erweiterungskonfiguration tts.rateLimit (Standard 30/Minute/IP, 0 = unbegrenzt). Weitere Anfragen erhalten HTTP 429 mit Retry-After.
• Server-Cache: bereits vertonte Textpassagen kosten nichts und zählen nicht zum Limit; die Textlänge ist gedeckelt; der Endpunkt ist als noindex markiert.

Kosten im Blick: Jede echte Cloud-Generierung (Cache-Miss) wird bei aktivem Token-Tracking erfasst und erscheint im Dashboard-Widget „Token-Verbrauch" unter „Vorlesen (TTS, Zeichen)" mit geschätzten Kosten (TTS wird pro Zeichen abgerechnet, Preise in Configuration/ModelPricing.php). Web Speech verursacht keine Kosten und kein Tracking.