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.

   Überschreitet ein Text die eingestellte Zeichengrenze, fragt nt-ai automatisch einmal mit schärferer Vorgabe (in der Ausgabesprache) nach; nur wenn auch das nicht reicht, wird gekürzt — dann mit Auslassungszeichen (…) statt eines Punktes, damit ein unvollständiger Text als solcher erkennbar bleibt.

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.

Text der Datei oder eigener Text an der Bildverwendung (seit 1.32.0)

Ein Bild in einem Inhaltselement übernimmt Alt-Text und Beschreibung aus den Metadaten der Datei. Über den Schalter „Standardwert überschreiben“ bekommt diese eine Verwendung einen eigenen Text; ohne Schalter bleibt der Text der Datei gültig, auch wenn er dort später geändert wird. Ein leerer eigener Text bedeutet „bewusst ohne Text“ (Schmuckbild, alt="").

Der KI-Knopf schaltet den Schalter selbst ein, denn ein erzeugter Text ist für genau diese Verwendung gedacht.

Bis einschließlich 1.31.0 fehlte der Schalter. Jedes Speichern eines Inhaltselements mit aufgeklapptem Bild schrieb einen leeren Text und verdeckte damit den Text der Datei, obwohl er grau weiter zu sehen war. Nach dem Update aufräumen:

# Nur zählen und anzeigen
vendor/bin/typo3 nt_ai:reference-text-repair --list
# Leere Texte auf "Text der Datei verwenden" zurücksetzen, wo die Datei einen hat
vendor/bin/typo3 nt_ai:reference-text-repair --apply
vendor/bin/typo3 cache:flush

Zurückgesetzt werden nur Verwendungen, deren Datei selbst einen Text hat: Dort verdeckt der leere Text sichtbar etwas. Ein leerer Text bei einer Datei ohne Text kann Absicht sein; --include-without-file-text setzt auch diese zurück.

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. Seit 1.24.0 fragt sie vorher nach: Titel und bis zu 8.000 Zeichen Dokumenttext gehen an den eingestellten KI-Anbieter (bei Ollama bleibt der Text lokal, dann entfällt die Frage). Ob das überhaupt erlaubt ist, steuert pdf.altTextDataPolicy.
• 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.

Nach Website filtern (Mehr-Site-Installationen)

Sind in einer Instanz mehrere Sites konfiguriert (z. B. viele Schul-Websites), blendet das Modul über den Reitern eine Website-Auswahl ein. Sie begrenzt die Site-Übersicht und den Lighthouse-Reiter auf die Seiten der gewählten Site — Seiten-Tabelle, „Häufigste Probleme", Summenzeile und die Lighthouse-Tabelle. „Alle Websites" zeigt wie bisher die seitenübergreifende Gesamtansicht.

Die Auswahl wird pro Backend-Nutzer gemerkt und beim Reiterwechsel mitgeführt; beim ersten Aufruf ist die Site der im Seitenbaum gewählten Seite vorbelegt. Ist nur eine Site konfiguriert, erscheint die Auswahl nicht. Die Reiter „Seitendetail" und „Erklärung" beziehen sich ohnehin auf eine einzelne Seite und sind nicht betroffen.

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.

Der Reiter erscheint nur, wenn Sie ihn nutzen dürfen — für Administratoren, oder für Redakteure, wenn die Extension-Einstellung declaration.editorsMayPublish gesetzt ist. Weil die Erklärung die ganze Website beschreibt, brauchen Redakteure seit 1.18.0 Zugriff auf alle geprüften Seiten, alle Sprachen mit Prüfergebnissen und alle gezählten Dokumente dieser Website; fehlt etwas davon, zeigt der Reiter einen entsprechenden Hinweis statt der Kennzahlen. Wählen Sie zuerst im Seitenbaum eine Seite der gewünschten Website aus: Die Erklärung wird für deren Site erzeugt und veröffentlicht (Zielseite, Feedback-Kontakt und Statistik richten sich danach), und die Reiter behalten diese Auswahl beim Wechsel bei.

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.

Seit 1.17.0 gilt ein Vorschau-Token nur für genau die Seite, für die es erzeugt wurde (Seite, Sprache, Site und URL-Pfad). Auf jeder anderen Adresse bleibt die normale, öffentliche Sicht; löst der Pfad eine andere Seite auf, antwortet TYPO3 mit 403, bevor etwas gerendert wird. Vorschau-Antworten landen nicht im Seitencache und tragen Cache-Control: private, no-store.

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.

Nicht erreichbare Seiten blockieren den geplanten Audit nicht. Eine Seite, die dauerhaft mit HTTP 404/410 antwortet (z. B. eine news-/events-Detail-URL ohne Datensatz), zählt nicht als technischer Fehler — sie löst die Regel „alle Seiten fehlgeschlagen" nicht aus — und wird eine Woche lang aus der Warteschlange genommen. Echte technische Fehlversuche werden mit steigender Sperrfrist (6 h → 24 h → 3 d → 7 d) zurückgestellt, statt jeden Lauf erneut zuerst gezogen zu werden. Aus dem Suchindex genommene Seiten (no_index, EXT:seo) werden nicht geprüft.

Der geplante Task rotiert über den Seitenbaum (am längsten nicht geprüfte Seiten zuerst). **Seiten ohne Site** (gemeinsame Datensatz-Behälter für Formulare, Fußzeile oder Menü) werden übersprungen, und fehlgeschlagene Seiten für einige Stunden zurückgestellt — so bleibt die Warteschlange nicht an nicht prüfbaren Seiten hängen.

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.

Befunde ignorieren, vergleichen und Regeln verwalten

Seit 1.21.0.

Befunde ignorieren. Jede Befundkarte im Seitendetail hat die Schaltfläche Ignorieren (bei gruppierten Befunden Alle ignorieren). Sie verlangt eine Begründung und eine Frist: 7, 30 oder 90 Tage, 1 Jahr oder unbefristet. Ein ignorierter Befund zählt nicht mehr in Score und Bericht; der Score der Seite wird sofort neu berechnet. Unter Ignorierte Befunde stehen Begründung, Benutzer und Ablaufdatum, dort lässt sich der Befund wieder aufnehmen. Nach Ablauf der Frist erscheint er mit dem nächsten Audit von selbst wieder. Ignorieren darf, wer den Inhalt der Seite bearbeiten darf.

Wiedererkannt wird ein Befund an Regel, Inhaltselement und Gegenstand (Bild, Überschrift, Linkziel), nicht am Wortlaut der Meldung – ein ignoriertes Bild bleibt also ignoriert, auch wenn die KI die Meldung beim nächsten Lauf anders formuliert.

Vergleich mit dem vorigen Audit. Über den Empfehlungen steht, was sich seit dem letzten Audit geändert hat: neu, behoben, unverändert. Neue Befunde tragen in der Liste die Marke „neu", die behobenen lassen sich aufklappen. Ignorierte Befunde gelten nicht als behoben.

Regeln je Website. Administratoren schalten im Reiter Regeln einzelne Regeln für eine Website ab – zusätzlich zur bisherigen Einstellung mod.tx_ntai.audit.disabledRules im Page-TSconfig. Die Änderung wirkt ab dem nächsten Audit.

Spalte „Wer". Die Tabelle Empfehlungen nennt je Zeile, wer das Problem üblicherweise behebt: Redaktion, Entwicklung oder Design.

Farbvorschlag bei zu geringem Kontrast. Der Befund nennt die nächstliegende Textfarbe, die das geforderte Verhältnis erreicht, z. B. „Textfarbe #767676 statt #999999 verwenden: Das ergibt 4.5:1 auf #ffffff (gefordert 4.5:1)".

Neue Regeln.

Regel	Prüft	Stufe
link.new.window	Links mit target="_blank" ohne Hinweis auf das neue Fenster	Hinweis
svg.name	SVG mit role="img" ohne <title> oder aria-label	Warnung
landmark.name	mehrere <nav> oder <aside> ohne eigene Namen	Hinweis
table.header.empty	leere Kopfzellen (außer der Ecke links oben)	Warnung

Seiten hinter Passwortschutz. Liegt die Website hinter HTTP-Basic-Auth (Staging), tragen Sie in den Extension-Einstellungen unter Audit Benutzername und Passwort ein (audit.httpAuthUser, audit.httpAuthPassword, auch als %env(NAME)%). Die Zugangsdaten gehen nur an die eigene Website.

Fehlerseiten. Antwortet eine Seite mit einer Fehlerausgabe statt ihres Inhalts („Oops, an error occurred!"), wird sie nicht geprüft, sondern wie eine nicht erreichbare Seite zurückgestellt. Bisher entstand daraus ein Bericht über die Fehlerseite.

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; unbrauchbare Titel (Dateiname, Programmvorgabe; seit 1.23.0)	WCAG 2.4.2	Warnung
Qualität der Tags (seit 1.25.0): leerer Strukturbaum	PDF/UA-1 · WCAG 1.3.1	Fehler
Qualität der Tags: Marked fehlt, Suspects, sehr wenige Elemente, keine Überschriften, übersprungene Überschriftenebenen, Tabellen ohne Kopfzellen, Links ohne Link-Tag	PDF/UA-1 · WCAG 1.3.1	Warnung
Formularfelder ohne Beschreibung (/TU; seit 1.24.0)	WCAG 1.3.1 / 4.1.2	Fehler
Tab-Reihenfolge auf Formularseiten (/Tabs /S; seit 1.24.0)	WCAG 2.4.3	Warnung
Schrifteinbettung	PDF/UA-1	Warnung
Lesezeichen bei langen Dokumenten (≥ 20 Seiten)	Best Practice	Hinweis
PDF/UA-Kennzeichnung (XMP)	Matterhorn 06-002	Hinweis

Wo ist eine PDF verlinkt? (seit 1.24.0)

Die Spalte Verwendungen zeigt je PDF „öffentlich / insgesamt": Dateiverweise und Links in Textfeldern (auch t3://file?uid=… und fileadmin-Pfade im Fließtext). Über Nur öffentlich verlinkte und Nach Verwendungen arbeitet die Redaktion zuerst an den Dokumenten, die Besucher wirklich erreichen. In der Befundansicht einer Datei steht die Liste der Verwendungen mit Seite, Datensatz und einer Schaltfläche zum Bearbeiten.

Die Angaben kommen aus dem Referenzindex von TYPO3 und sind so aktuell wie dieser (Planer-Aufgabe „Referenzindex aktualisieren"). „Öffentlich" heißt seit 1.29.0: für einen nicht angemeldeten Besucher jetzt erreichbar – Datensatz und Seite sind nicht gelöscht, nicht versteckt, innerhalb ihrer Start- und Stoppzeit und keiner Benutzergruppe vorbehalten; Elternseiten zählen, wenn sie das an Unterseiten vererben. Gefunden werden nur Felder, die der Referenzindex kennt; eigene Felder brauchen in der TCA einen Softreference-Parser.

PDFs, die sich nicht öffnen ließen (verschlüsselt mit erlaubtem Zugriff für Hilfsmittel, Zeit- oder Größenlimit, defekt), erscheinen seit 1.29.0 grau als „nicht prüfbar" und zählen nicht zu den Dateien mit Fehlern. Große Kartenwerke mit vielen Vektorpfaden plant man am besten ordnerweise mit nt_ai:pdf-audit --folder=….

Arbeitsliste: Priorität und Maßnahme (seit 1.33.0)

Bei einem gewachsenen Bestand ist Reparieren selten der erste Schritt. Viele Dokumente werden gelöscht, als Webseite neu angelegt oder aus der Word- oder InDesign-Quelle sauber neu exportiert. Das Modul hilft, diese Entscheidung je PDF festzuhalten und die Liste abzuarbeiten.

• Priorität (berechnet, nicht gespeichert): hoch = Fehler und öffentlich verlinkt; mittel = Fehler ohne öffentliche Verlinkung, oder Warnungen bzw. „nicht prüfbar" bei öffentlicher Verlinkung; niedrig = übrige Befunde. PDFs ohne Befunde haben keine Priorität. Die Stufe folgt jeder neuen Prüfung und jeder geänderten Verlinkung.
• Maßnahme (in der Befundansicht unter „Maßnahme"): offen · löschen/archivieren · als Webseite · aus Quelle neu exportieren · nachbearbeiten · Ausnahme · erledigt, dazu eine Notiz. Die Entscheidung bleibt bei neuen Prüfungen erhalten, auch wenn die Datei ersetzt wird; beim Löschen der Datei wird sie entfernt.
• Filter und Sortierung: nach Priorität und Maßnahme filtern, „Nach Priorität" sortieren (innerhalb einer Stufe die meistverlinkten zuerst). Die Kachel „Ohne Maßnahme" zählt PDFs mit Befunden, für die noch nichts entschieden ist. Der Hinweis „nirgends verlinkt – löschen?" steht an Dateien ohne jede Verwendung im Referenzindex.
• CSV-Export enthält Priorität, Maßnahme und Notiz, etwa zur Weitergabe an einen Dienstleister.
• Ausnahme und Barrierefreiheitserklärung: PDFs mit der Maßnahme „Ausnahme" erscheinen im Entwurf der Erklärung unter „Nicht barrierefreie Inhalte" mit der Notiz als Begründung. Tragen Sie dort Grund und Alternative ein (z. B. „Archivfassung von 2015, auf Anfrage in zugänglicher Form"). Dateien aus nicht-öffentlichen Speichern (z. B. geschützte Kundendokumente) werden dort nicht genannt, weil die Erklärung öffentlich ist.

Schnellkorrektur: Titel, Sprache, Titelanzeige (seit 1.33.0)

Drei Mängel lassen sich nachträglich sicher beheben, ohne das Dokument neu zu erzeugen: fehlender oder nichtssagender Dokumenttitel, fehlende Dokumentsprache und die Anzeige des Titels im Fenster statt des Dateinamens. In der Befundansicht steht dafür der Bereich „Schnellkorrektur", sobald einer dieser Befunde vorliegt.

1. Korrektur vorbereiten liest das PDF und schlägt einen Titel vor (vorhandener Titel, sonst die erste aussagekräftige Textzeile, sonst der Dateiname) sowie die Sprache (vorhanden, sonst eine Schätzung Deutsch/Englisch). Titel per KI vorschlagen schickt dazu den Dokumentanfang an den KI-Anbieter; es gilt dieselbe Einstellung wie beim PDF-Alt-Text (pdf.altTextDataPolicy).
2. Titel und Sprache prüfen oder ändern und Korrigieren wählen. Ohne diese Bestätigung wird nichts geschrieben.
3. Die Erweiterung hängt die neuen Angaben als inkrementelles Update an die Datei an: Die ursprünglichen Bytes bleiben unverändert, Inhalt, Tags, Formulare und Schriften werden nicht neu geschrieben. Der Titel wird in den Dokumenteigenschaften und, falls vorhanden, in den XMP-Metadaten gesetzt, damit beide übereinstimmen.
4. Vor dem Ersetzen wird die korrigierte Fassung neu eingelesen: Die neuen Werte müssen ankommen, Seitenzahl, Tags, Abbildungen, Formularfelder und Schriften müssen gleich bleiben. Optional prüft zusätzlich ein externes Programm (pdf.verifyCommand, etwa qpdf). Erst dann wird die Datei ersetzt; Verwendungen und Verlinkungen bleiben erhalten, die Datei wird sofort neu geprüft.
5. Das Original liegt unter var/nt_ai/pdf-original/ (außerhalb des Webverzeichnisses). Korrektur rückgängig machen stellt es wieder her, solange die Datei seitdem nicht anders geändert wurde.

Nicht korrigiert werden verschlüsselte und digital signierte PDFs (die Signatur würde als „verändert" angezeigt) sowie Dateien, die sich nicht lesen lassen. Eine PDF/UA-Kennung setzt die Schnellkorrektur nie – sie würde eine Konformität behaupten, die drei Metadaten allein nicht herstellen. Für Tags, Lesereihenfolge, Alternativtexte und Tabellen bleibt der Weg über die Quelldatei oder Acrobat.

Sammelkorrektur: Über der Liste setzt „Sammelkorrektur ausführen" bei PDFs mit brauchbarem Titel die gewählte Sprache, wo sie fehlt, und schaltet die Titelanzeige ein – je Durchgang bis zu zehn Dateien, jede mit Sicherung. Ein Titel wird immer einzeln vergeben.

Zusätzliche Strukturprüfung mit Python (Beispiel Mittwald): pikepdf bringt qpdf mit und lässt sich ohne Systemrechte installieren: python3 -m pip install --target var/python pikepdf. Dann in den Extension-Einstellungen unter „PDF" pdf.verifyCommand setzen, z. B. PYTHONHOME=/usr/local/python/usr/local PYTHONPATH=/html/typo3-composer/var/python /usr/local/python/bin/python3 /html/typo3-composer/vendor/netthinks/nt-ai/Resources/Private/Scripts/pdf-check.py. Ist qpdf als Programm installiert, genügt qpdf --check.

Export, Bericht per E-Mail und Ampel an der Datei (seit 1.26.0)

• CSV-Export: „Als CSV exportieren" liefert die Liste so, wie sie angezeigt wird (Filter und Sortierung), mit Status, Score, Zahlen, Verwendungen und den Befundtexten. Semikolon-getrennt mit Kennung für Excel. Ein XLSX-Export ist nicht enthalten.
• Bericht per E-Mail: Der Befehl nt_ai:pdf-report --to=redaktion@example.org (als Planer-Aufgabe) schickt eine Zusammenfassung: Summen, häufigste Befunde und die öffentlich verlinkten PDFs mit Fehlern, die meistverlinkten zuerst. Für einen Bericht je Redaktion eine Aufgabe je Ordner anlegen: --folder="1:/user_upload/bauamt/". Weitere Optionen: --only-linked, --since-days=7, --dry-run (nur Zahlen, kein Versand). Der Befehl liest gespeicherte Berichte, er prüft nicht selbst – davor läuft nt_ai:pdf-audit.
• Ampel in der Dateiliste: In der Listenansicht des Moduls Dateiliste trägt jedes geprüfte PDF ein Symbol (grün, gelb, rot) mit Score und Zahlen; ein Klick führt zu den Befunden. In der Kachelansicht gibt es das Symbol nicht, weil TYPO3 dort keine Aktionen darstellt. Nur TYPO3 14.
• Hinweis im Metadaten-Formular: Beim Bearbeiten der Metadaten eines geprüften PDFs steht das Ergebnis über dem Titelfeld, mit Link zu den Befunden.

Viele PDFs auf einmal prüfen (seit 1.27.0)

„Neue & geänderte PDFs jetzt prüfen" prüft bis zu zehn Dateien sofort. Sind es mehr, werden sie als Aufträge vorgemerkt und von der Planer-Aufgabe nt_ai:process-queue abgearbeitet (je Lauf eine begrenzte Zahl, Option --limit). Das Modul zeigt, wie viele PDFs noch warten. Ohne eingerichtete Aufgabe bleiben die Aufträge liegen. Für die Erstprüfung großer Bestände ist weiterhin nt_ai:pdf-audit der direkte Weg, bei Bedarf ordnerweise mit --folder und --limit.

Verschlüsselte PDFs (seit 1.27.0)

Verschlüsselte PDFs kann die Prüfung nicht öffnen. Sie wertet aber die Berechtigungen aus: Ist der Textzugriff für Bildschirmlesehilfen gesperrt, ist das ein Fehler. Ist er erlaubt (typisch bei reinem Kopier- oder Änderungsschutz), gibt es eine Warnung mit dem Hinweis, dass alle übrigen Merkmale ungeprüft sind; der Score einer nicht geöffneten Datei liegt höchstens bei 49. Ob zum Öffnen ein Kennwort nötig ist, wird nicht festgestellt.

Wer sieht das Modul?

Das Modul ist für Redakteure freigegeben, sobald es in der Backend-Gruppe unter Module angehakt ist (Medien → PDF-Barrierefreiheit). Jeder sieht nur die PDFs seiner Dateifreigaben; Summen und Aktionen beziehen sich auf diese Auswahl.

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 — es sei denn, die Prüfung selbst wurde seitdem verbessert: Jeder Bericht merkt sich, mit welcher Fassung des Analyzers er entstand, und ältere Berichte werden beim nächsten Lauf automatisch neu erstellt. Im Modul tragen sie bis dahin die Markierung „veraltet“.

CLI/Scheduler: nt_ai:pdf-audit [--limit N] [--force] [--fail-on=error|warning] [--folder="1:/Ordner/"] [--max-size-mb N] [--time-limit N] — Exit-Code 1 bei Befunden der angegebenen Schwere (CI-tauglich). Mit --folder (kombinierter Ordner-Identifier, z. B. 1:/GaD/) lässt sich die Prüfung auf einen Ordner eingrenzen und so je Ordner als eigene, zeitlich gestaffelte Planer-Aufgabe einrichten, statt alle PDFs in einem Lauf zu prüfen.

Sehr große PDFs und Speicher. smalot/pdfparser kann bei mehrseitigen, grafiklastigen PDF deutlich mehr als 256 MB benötigen (bei vielen Hostern der Vorgabewert für das CLI-memory_limit). Ein einzelner solcher Abbruch stoppt den Lauf nicht mehr dauerhaft: Die betroffene Datei wird als „nicht prüfbar" vermerkt (Score 0), sodass der nächste Lauf sie überspringt statt an ihr hängenzubleiben. Vorbeugend lassen sich mit --max-size-mb N PDFs über N MB überspringen (ebenfalls mit Vermerk), statt sie zu parsen. Für den vollständigen Bestand empfiehlt sich ein CLI-memory_limit von 512 MB. Nähert sich ein Lauf dem memory_limit (über 80 %), beendet er sich seit 1.19.0 vor der nächsten Datei sauber (Exit-Code 1); die übrigen PDFs folgen beim nächsten Lauf.

Sehr komplexe PDFs und Zeitlimit (seit 1.19.0). Karten und Pläne mit sehr vielen Vektorpfaden kann smalot/pdfparser minutenlang beschäftigen. Jede Datei hat deshalb ein Zeitlimit (Einstellung pdf.auditTimeLimit, Standard 60 s, --time-limit N je Lauf, 0 = aus). Eine Datei darüber wird als „nicht prüfbar" vermerkt, der Lauf macht mit der nächsten weiter (mit PHP-Erweiterung pcntl; ohne sie endet der Lauf dort und setzt beim nächsten Mal dahinter fort) und meldet Exit-Code 1 mit der Anzahl in der Zusammenfassung. Seiten ohne Rasterbild werden nicht mehr nach Text durchsucht — der Text entscheidet nur, ob eine Bildseite ein Scan ist —, was gerade solche Pläne um ein Vielfaches schneller macht.

Jede Datei wird je Inhalt (SHA1) und Fassung der Prüfung genau einmal versucht: Der Vermerk „nicht prüfbar" wird schon vor dem Parsen geschrieben, sodass auch ein abgebrochener oder hängengebliebener Lauf die Datei beim nächsten Mal überspringt. Neu geprüft wird erst nach einer Änderung der Datei, einer neuen Fassung der Prüfung oder mit --force. Verliert der Lauf zwischendurch die Datenbankverbindung (MySQL „server has gone away"), wird sie vor dem Speichern einmal neu aufgebaut.

Zusätzlich verfügbar:

• Dashboard-Widget „PDF-Barrierefreiheit": Anteil der PDFs ohne Fehler als Ring, Zählkacheln (ohne Fehler / mit Fehlern / ungeprüft). Eine Einstellung „Ordner" (Zahnrad am Widget) grenzt die Zahlen auf einen obersten Dateiordner ein (Standard „Alle Ordner"); der gewählte Ordner wird als Kennzeichnung angezeigt. Passend für Installationen, in denen die oberste Ordnerebene je einer Redaktion/Schule entspricht.
• 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.

Mehrere Websites? Die Widgets Audit-Score, Seiten-Score und Lighthouse haben eine Einstellung „Website" (Zahnrad am Widget). Standard ist „Alle Websites"; wählen Sie eine Site aus, zeigt das Widget nur deren Seiten. Die aktuell gewählte Website wird im Widget als Kennzeichnung angezeigt, damit die Zahlen nie aus dem Zusammenhang gerissen werden. So ist der Durchschnitt in einer Installation mit vielen Sites für jede Redaktion aussagekräftig.

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

# Nur geänderte Seiten neu bewerten, höchstens 150 pro Lauf.
vendor/bin/typo3 nt_ai:analyze-pages --changed-only --limit=150

Jede Seite wird in allen konfigurierten Site-Sprachen in einem Lauf analysiert.

Option	Kürzel	Wirkung
--changed-only	-c	Überspringt eine Seite/Sprache, wenn ihr jüngstes Score neuer ist als die letzte Änderung an der Seite oder ihren Inhaltselementen (pages.tstamp und MAX(tt_content.tstamp)). Ohne Schemaänderung.
--limit=N	-l	Höchstzahl tatsächlich analysierter Seiten je Lauf (0 = ohne Grenze). Übersprungene, unveränderte Seiten zählen nicht mit.

Empfehlung für den Zeitplan. Ein vollständiger Lauf bewertet bei jedem Aufruf alle Seiten neu und sendet ihren Text an den KI-Anbieter — bei großen Beständen teuer und, wenn nur wenige Seiten sich ändern, überwiegend unnötig. Für einen getakteten Betrieb --changed-only verwenden: An ruhigen Tagen entstehen keine Kosten, Änderungen werden zeitnah erfasst. --limit begrenzt zusätzlich einen Nachlauf nach einer großen redaktionellen Aktion, damit er nicht in einem Stück durchläuft. Ein erster Bestandslauf (ohne --changed-only) legt die Ausgangs-Scores an; danach genügt der getaktete Änderungslauf.

Der Exit-Code bildet die Lage ab: Der Befehl endet nur bei echten technischen Fehlern (Zeitüberschreitung, Anbieterfehler, Schreibfehler) mit Code 1 und färbt die Scheduler-Aufgabe rot. Seiten ohne Site (zentrale Datensatz-Ordner für Formulare, Fußzeile, Navigation — doktype = 1, aber über keine Site erreichbar) und Seiten mit einem sauberen 404/410 (news-/events-Detail-URL ohne Datensatz) sind ein Ergebnis, kein Ausfall: Sie werden als „unreachable" gezählt, nicht als „error", und belegen keinen --limit-Platz. Eine gesunde Instanz bleibt damit grün.

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.

SEO-Titel und Meta-Beschreibungen im Massenlauf

Der SEO-Feld-Assistent füllt die Felder einer einzelnen Seite. Für eine ganze Website gibt es seit 1.20.0 den Massenlauf: Er sucht Seiten, deren SEO-Titel oder Meta-Beschreibung leer ist, erzeugt die Texte aus dem Seiteninhalt und speichert sie wie eine normale Bearbeitung (sichtbar im Verlauf des Datensatzes).

# Vorschläge ansehen, nichts speichern
vendor/bin/typo3 nt_ai:generate-seo-meta 1 --dry-run --limit=10

# Seite 1 und alles darunter füllen, höchstens 25 Seiten je Lauf
vendor/bin/typo3 nt_ai:generate-seo-meta 1

# Englische Sprachversion (sys_language_uid 1), nur die Meta-Beschreibung
vendor/bin/typo3 nt_ai:generate-seo-meta 1 --language=1 --description-only

Option	Bedeutung
page (Argument)	Startseite: diese Seite und alle darunter. Leer oder 0 = alle Seiten.
--language	sys_language_uid der Datensätze, die gefüllt werden. Die Texte entstehen in dieser Sprache.
--limit	Höchstzahl Seiten je Lauf (Standard 25).
--title-only / --description-only	Nur eines der beiden Felder.
--force	Auch bereits gefüllte Felder neu schreiben.
--dry-run	Vorschläge ausgeben, nichts speichern.
--queue	Nicht sofort erzeugen, sondern je Seite einen Auftrag in die Warteschlange legen.

Übersprungen werden Verweise, Ordner und ähnliche Seitentypen, versteckte Seiten und Seiten, die von Suchmaschinen ausgeschlossen sind (no_index). Vorhandene Werte bleiben ohne --force unangetastet.

Jede erzeugte Angabe kostet Tokens beim KI-Anbieter. Prüfen Sie die Texte nach dem ersten Lauf stichprobenartig – eine Meta-Beschreibung ist ein Werbetext, kein Pflichtfeld.

Warteschlange und Verlauf

Warteschlange. Mit --queue legt der Massenlauf nur Aufträge an. Abgearbeitet werden sie von nt_ai:process-queue, das als Planer-Aufgabe alle paar Minuten laufen sollte:

vendor/bin/typo3 nt_ai:process-queue --limit=10

Jeder Lauf nimmt höchstens --limit Aufträge (Standard 10) und hört nach --time-limit Sekunden (Standard 240) auf, neue anzunehmen. Ein fehlgeschlagener Auftrag wird nach fünf Minuten erneut versucht, insgesamt bis zu drei Mal. Bricht ein Lauf mittendrin ab, wird sein Auftrag nach 30 Minuten wieder freigegeben. Derselbe Auftrag (Seite, Sprache) steht nie doppelt in der Warteschlange. Erledigte Aufträge und Verlaufseinträge werden nach --keep-days Tagen (Standard 180) gelöscht.

Verlauf. Der Reiter Verlauf im Audit-Modul zeigt, welche Werte die KI geschrieben hat: Zeitpunkt, Seite, Feld, alter und neuer Wert, Auslöser (Backend, Kommandozeile oder Warteschlange), Benutzer und Modell. Dazu die letzten Aufträge mit ihrem Stand. Redakteure sehen nur Einträge von Seiten, auf die sie Zugriff haben; die Gesamtzahlen der Warteschlange sehen nur Administratoren. Protokolliert werden der Massenlauf und das Übernehmen eines Vorschlags im SEO-Panel.

Empfehlungen (Arbeitsliste)

Über der Befundliste im Reiter Seitendetail steht seit 1.20.0 die Tabelle Empfehlungen. Sie fasst gleiche Befunde zu einer Zeile zusammen und ordnet sie nach Dringlichkeit:

Spalte	Inhalt
Priorität	Hoch (Fehler), Mittel (Warnung), Niedrig (Hinweis), mit Anzahl der Fundstellen
Wo	Inhaltselement, Bild oder Stelle im Dokument; bis zu fünf Fundstellen, der Rest als Zahl
Was	das Problem
Wie	der Weg zur Behebung
Warum	wen das Problem betrifft, und das WCAG-Kriterium

Die Befundliste darunter bleibt unverändert und enthält jede einzelne Fundstelle mit ihren Schaltflächen.

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

# Nur geänderte Seiten neu messen, höchstens 200 pro Lauf.
vendor/bin/typo3 nt_ai:lighthouse --changed-only --limit=200

Option	Kürzel	Wirkung
--strategy=…	—	mobile, desktop oder both (Standard aus den Einstellungen).
--changed-only	-c	Überspringt eine Seite/Sprache/Strategie, wenn ihre jüngste Messung neuer ist als die letzte Änderung an der Seite oder ihren Inhaltselementen (pages.tstamp und MAX(tt_content.tstamp)). Die Prüfung ist strategiebezogen — ein both-Lauf überspringt nicht mobile, nur weil desktop kürzlich lief.
--limit=N	-l	Höchstzahl tatsächlich gemessener Seiten je Lauf (0 = ohne Grenze). Übersprungene, unveränderte Seiten zählen nicht mit.

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.

Laufzeit begrenzen. Ein Volllauf misst bei jedem Aufruf alle Seiten; die Laufzeit wächst also mit dem Seitenbestand. Für einen getakteten Betrieb --changed-only verwenden — dann wird nur gemessen, was sich seit der letzten Messung geändert hat. Anders als bei analyze-pages fallen dabei keine personenbezogenen Daten an (Google ruft die öffentliche Seite selbst ab). Zu beachten: Lighthouse-Werte schwanken auch ohne Inhaltsänderung (Server, Assets, Dritte) — daher regelmäßig zusätzlich einen Volllauf (ohne --changed-only) ansetzen, z. B. monatlich.

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).
• Server-Cache: bereits vertonte Textpassagen werden sofort ausgeliefert, kosten nichts und zählen nicht zu den Limits; die Textlänge ist gedeckelt; der Endpunkt ist als noindex markiert.
• Rate-Limit pro IP — Erweiterungskonfiguration tts.rateLimit (Standard 30/Minute/IP, 0 = unbegrenzt). Weitere Anfragen erhalten HTTP 429 mit Retry-After.
• Nur Text der Seite (seit 1.17.0, tts.requirePageText) — das Widget schickt Seite und Sprache mit; vorgelesen wird nur, was auf der öffentlichen Fassung dieser Seite steht. Fremder Text, Text anderer Sites und Text versteckter oder geschützter Seiten wird abgewiesen (HTTP 403).
• Gleichzeitige Erzeugungen (seit 1.18.0, tts.maxConcurrent, Standard 4) — mehr neue Passagen laufen nicht gleichzeitig beim Anbieter; weitere Anfragen erhalten sofort HTTP 503 mit Retry-After: 5. Ein abgebrochener Aufruf gibt seinen Platz spätestens nach Anfrage-Timeout plus 30 Sekunden frei.
• Tagesbudget für alle Besucher zusammen (seit 1.17.0) — tts.dailyCharacterBudget (Standard 200 000 Zeichen) und tts.dailyRequestBudget (Standard 2 000 Aufrufe) pro Kalendertag (UTC). Wechselnde IP-Adressen helfen dagegen nicht. Ist ein Budget erschöpft, antwortet der Endpunkt mit HTTP 503, bevor der Anbieter gefragt wird.

In allen Fällen liest das Widget mit der kostenlosen Browserstimme weiter. Das betrifft auch Text, der erst im Browser entsteht: per JavaScript nachgeladene Inhalte, die Übersetzungen von nt-lingua im Browser, Einfache Sprache per Cookie, Inhalte hinter einem Frontend-Login und Plugin-Ansichten, die von URL-Parametern abhängen (z. B. eine News-Detailansicht). Wer dafür Cloud-Stimmen braucht, schaltet tts.requirePageText ab — die Budgets gelten weiter.

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.