Chrome auf 204 installiert, Browser-/a11y-Nachtrag UX-10/OPS-11 (68/68 bestanden)

Google Chrome stable 154.0.8037.57 + pa11y 10.0.0 auf Entwicklungshost 204
installiert (Prüfsumme/GPG-Signatur verifiziert, deploy/chrome/README.md).
web/a11y-audit/run.sh lief damit erstmals real dort: 68/68 Prüfschritte
bestanden, keine axe-Verstöße, pdf-viewer vollständig (vorher 1/5).

Echter Fund behoben: keyboard-flow.js rief die API ohne Identität auf,
folderapi.handleDocuments verlangt aber immer 'caller'/X-User-Id.

UX-11 (vier neue Seiten) und ein Token-Modus-Lauf bleiben offen, weil sie
eine eigenständige Erweiterung der Testfixture brauchen, kein Nachtrag.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

deploy/chrome/README.md

@@ -0,0 +1,46 @@
+# Chrome auf Entwicklungshost 204 (nur für Browser-/a11y-Testläufe)
+
+Installiert 2026-09-22, freigegeben vom Nutzer nach dem KoSIT/veraPDF-Muster.
+
+## Was wurde installiert
+
+- **Google Chrome stable** `154.0.8037.57` via offizielles `.deb`
+  (`https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb`).
+  Verifiziert: SHA256 des Downloads gegen den Eintrag in der GPG-signierten
+  `Packages`-Datei des offiziellen apt-Repos abgeglichen (Release-Signatur mit
+  Googles veröffentlichtem Schlüssel `EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796`
+  geprüft, `gpg --verify` -> "Good signature").
+- **pa11y** `10.0.0` global via npm (`npm install -g pa11y`,
+  `PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true` — nutzt das bereits installierte,
+  verifizierte System-Chrome statt einen zweiten Chromium-Download).
+  Bringt `puppeteer-core` mit, das `web/a11y-audit/*.js` erwartet.
+
+## Pfad-Besonderheit ggü. Host 131
+
+Auf 131 liegt der globale npm-Root unter `/usr/local/lib/node_modules`
+(ältere npm-Version). Auf 204 (npm 11) ist der globale Root
+`/usr/lib/node_modules`. Die Audit-Skripte haben einen festen Default-Pfad
+(`/usr/local/lib/node_modules/pa11y/node_modules`), der hier NICHT stimmt.
+
+**Immer mit explizitem Override aufrufen:**
+
+```sh
+export A11Y_NODE_MODULES=/usr/lib/node_modules/pa11y/node_modules
+export A11Y_CHROME=/usr/bin/google-chrome
+```
+
+(`run.sh` ermittelt `A11Y_CHROME` bereits automatisch über `command -v
+google-chrome`, falls nicht gesetzt — nur `A11Y_NODE_MODULES` muss man selbst
+setzen.)
+
+## Rückbau
+
+```sh
+npm uninstall -g pa11y
+apt-get purge -y google-chrome-stable
+rm -rf /opt/nexarch-chrome /root/.cache/google-chrome /root/.config/google-chrome
+apt-get autoremove -y
+```
+
+Footprint: Chrome ~265 MB unter `/opt/google/chrome`, pa11y+puppeteer-core
+node_modules unter `/usr/lib/node_modules/pa11y`.

dms/docs/UX-10-PRUEFPROTOKOLL.md

@@ -53,3 +53,39 @@ Zahlen der Endprüfung (Commit `a6708f8`, Host 204): `@nexarch/shl` 60/60 (7 Dat
 - **Weitere Web-Apps** (`audit-log`, `mail-search`, `notifications`, `account` u. a.) sind nicht Teil der Kachel; `web/audit-log` sendet weiter `caller`.
 - **Token-Widerruf** bleibt Core (IAM-12): ein ausgestelltes Token gilt bis TTL plus 30 s.
 - **Große Downloads** laufen über den Speicher des Browsers (Entscheidung 3).
+
+## Nachtrag 2026-09-22: echter Browser-/a11y-Lauf auf 204 (mit installiertem Chrome)
+
+Auf Entwicklungshost 204 wurde Google Chrome 154.0.8037.57 installiert (siehe
+`deploy/chrome/README.md`), damit ist `web/a11y-audit/run.sh` erstmals dort
+lauffähig. Ergebnis (Übergangsmodus, `NEXT_PUBLIC_AUTH_MODE=caller` — der
+Audit-Fixture-Server hat keinen Core-Kontodienst, siehe unten):
+
+- **68/68 Prüfschritte bestanden, Exit 0** (vorher: `pdf-viewer` nur 1/5,
+  Tastatur-/a11y-Audit im Token-Modus ungeprüft).
+- 11 Seiten × hell/dunkel je axe: keine Verstöße. `pdf-viewer` läuft jetzt
+  vollständig (Startseite + Viewer, hell und dunkel).
+- Reflow (320×256), Textabstände (WCAG 1.4.12), Upload per Tastatur: alle ok.
+- Tastaturabläufe (Papierkorb wiederherstellen, Ordnerbaum, Metadaten
+  speichern): alle 3 bestanden, 0 Mausereignisse.
+- Englische Oberfläche: 100 % der Seiten mit `lang="en"`, keine Verstöße.
+
+**Echter Fehler gefunden und behoben** (Commit `42724d6`,
+`web/a11y-audit/keyboard-flow.js`): `getJSON()` rief `/folders/{id}/documents`
+und `/documents/{id}/metadata` ohne Identität auf. `folderapi.handleDocuments`
+verlangt aber immer eine Identität (`authz.Identity`, `caller`-Parameter oder
+`X-User-Id`-Header) — ohne sie kam ein Fehlerobjekt statt eines Arrays
+zurück, `docs.some is not a function`. War latent, weil dieser Testpfad vor
+diesem Lauf nie gegen einen echten Browser mit echtem Chrome auf 204 lief.
+Fix: `caller=<ids.user_id>` wird jetzt an jeden `getJSON`-Aufruf angehängt.
+Nach dem Fix: 10/10 Wiederholungen stabil, kein erneuter Fehlschlag.
+
+**Token-Modus-Lauf weiterhin offen:** `web/a11y-audit/run.sh` nutzt
+`dms/cmd/a11y-fixture` als Backend — dieser Fixture-Server hat keinen Core-
+Kontodienst/JWKS, daher zwingend `NEXT_PUBLIC_AUTH_MODE=caller`. Ein echter
+Token-Modus-Lauf bräuchte die Kombination aus `scripts/gesamt-token-smoke.sh`
+(echter Kontodienst + Policy-Dienst + `dms-app`) mit den Browser-/a11y-
+Skripten aus `web/a11y-audit/` — zwei bisher getrennte Testkabelbäume
+zusammenführen. Das ist ein eigenständiges Vorhaben, keine schnelle Ergänzung,
+und wird hier bewusst nicht begonnen. Vorschlag: eigenes Ticket
+"a11y-Audit im Token-Modus" (DMS-Board).

dms/docs/UX-11-PRUEFPROTOKOLL.md

@@ -57,3 +57,24 @@ Insgesamt 8 Iterationen, alle inhaltlich (Bugs bzw. falsche Annahmen über beste
 - **Ende-zu-Ende „Upload → Regel greift“:** Nicht erneut geprüft (INT-03/INT-04 decken den Importpfad bereits ab); diese Kachel deckt nur die Verwaltungsoberfläche.
 - **Ordner-/Typ-/Tag-Auswahl im Klärungskorb und bei Postfächern** ist aktuell ein reines ID-Eingabefeld, kein Baum-/Auswahl-Widget (es gibt noch keinen `documentTypeApi`-Client und `fetchChildren` liefert nur eine Ebene je Aufruf). Funktional korrekt, aber keine komfortable Auswahl — ein eigenes UX-Ticket für Picker-Komponenten wäre sinnvoll, war aber nicht Teil dieses Tickets („Nicht Bestandteil“: kein neuer Regel-Simulator, keine neue Abruflogik).
 - **`dms.mail.rule.write` deckt sowohl Regeln als auch Anhangfilter ab** (ein Recht statt zwei), da beide dieselbe fachliche Handlung sind (Mail-Verarbeitung konfigurieren); im Katalog dokumentiert.
+
+## Nachtrag 2026-09-22: Tastatur/axe/Reflow — weiterhin offen
+
+Chrome wurde auf Host 204 installiert (siehe `deploy/chrome/README.md`) und
+`web/a11y-audit/run.sh` läuft dort jetzt real (siehe Nachtrag in
+`dms/docs/UX-10-PRUEFPROTOKOLL.md`, 68/68 bestanden für die dort bereits
+verdrahteten Seiten). Für die vier NEUEN UX-11-Oberflächen
+(`/mail-accounts`, `/mail-rules`, `/clarification`,
+`/documents/{id}/einvoice`) fehlt das noch, weil:
+
+- `dms/cmd/a11y-fixture` seedet keine Postfächer/Mail-Regeln/Klärungskorb-
+  Einträge/E-Rechnung-Ergebnisse.
+- `web/a11y-audit/run.sh` setzt keine `NEXT_PUBLIC_MAIL_*`/`NEXT_PUBLIC_
+  EINVOICE_*`-API-URLs (nur die zehn bereits vorhandenen Variablen).
+
+Beides ist eine eigenständige Erweiterung der Testfixture (neue Seed-Daten,
+neue Env-Variablen, neue Einträge in `pages.txt`), keine Ergänzung, die sich
+in einem Nachtrag miterledigen lässt. Bleibt offen; siehe auch den Vorschlag
+im UX-10-Nachtrag für ein Token-Modus-Ticket — beides ließe sich sinnvoll in
+einem gemeinsamen Folgeticket "a11y-Fixture für Mail/E-Rechnung + Token-Modus"
+bündeln.

docs/CHROME-BROWSER-NACHTRAG-PRUEFPROTOKOLL.md

@@ -0,0 +1,60 @@
+# Chrome auf Host 204 — Browser-/a11y-Nachtrag (2026-09-22)
+
+Freigegeben vom Nutzer (gleiches Muster wie KoSIT/veraPDF): Google Chrome
+stable auf dem Entwicklungshost 192.168.1.204 installieren, um die als offen
+dokumentierten Browser-/Barrierefreiheitsprüfungen nachzuholen.
+
+## Installiert
+
+- **Google Chrome stable 154.0.8037.57** — offizielles `.deb`, SHA256 gegen
+  den Eintrag in der GPG-signierten `Packages`-Datei des offiziellen
+  apt-Repos verifiziert (Release-Signatur mit Googles Schlüssel
+  `EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796` geprüft — "Good signature").
+- **pa11y 10.0.0** global via npm (`PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true`,
+  nutzt das bereits verifizierte System-Chrome statt eines zweiten
+  Chromium-Downloads). Liefert das `puppeteer-core`, das
+  `web/a11y-audit/*.js` erwartet.
+- Pfad-Besonderheit ggü. Host 131 (dort `/usr/local/lib/node_modules`, hier
+  npm 11 mit `/usr/lib/node_modules`): Aufrufe brauchen
+  `A11Y_NODE_MODULES=/usr/lib/node_modules/pa11y/node_modules`.
+- Rückbau: siehe `deploy/chrome/README.md`.
+
+## Nachgeholte Prüfungen
+
+| Ticket | Status vorher | Status jetzt |
+|---|---|---|
+| UX-10 | `pdf-viewer` 1/5, Tastatur/a11y ungeprüft | 68/68 bestanden, Exit 0 (siehe Nachtrag in `dms/docs/UX-10-PRUEFPROTOKOLL.md`) |
+| UX-11 | Tastatur/axe/Reflow für 4 neue Seiten ungeprüft | weiterhin offen — `a11y-fixture` seedet keine Mail-/E-Rechnung-Daten (siehe Nachtrag in `dms/docs/UX-11-PRUEFPROTOKOLL.md`) |
+| OPS-11 (Next.js 16) | Browser-/a11y-Regression ungeprüft | 68/68 bestanden, keine Regression (siehe Nachtrag in `docs/QA-15-F17-NEXTJS16-PRUEFPROTOKOLL.md`) |
+| Token-Modus generell | ungeprüft (Fixture ohne Kontodienst) | weiterhin offen — braucht Zusammenführung von `a11y-fixture` und `gesamt-token-smoke.sh` |
+
+## Echter Fund und Fix
+
+`web/a11y-audit/keyboard-flow.js`: `getJSON()` rief die Backend-API ohne
+Identität auf. `folderapi.handleDocuments` verlangt aber immer eine
+Identität (`caller`/`X-User-Id`) — ohne sie kam ein Fehlerobjekt statt eines
+Arrays zurück (`docs.some is not a function`). Latent, weil dieser Pfad vor
+diesem Lauf nie gegen einen echten Browser mit echtem Chrome auf 204 lief.
+Fix in Commit `42724d6`: `caller=<user_id>` an jeden `getJSON`-Aufruf. Danach
+10/10 Wiederholungen stabil.
+
+## Offen, mit Ticketvorschlag
+
+1. **UX-11-Seiten in `a11y-fixture` verdrahten** (Postfach-/Regel-/
+   Klärungskorb-/E-Rechnung-Seed-Daten, neue `NEXT_PUBLIC_*_API_URL`s,
+   `pages.txt` erweitern).
+2. **a11y-Audit im Token-Modus**: `a11y-fixture` und
+   `scripts/gesamt-token-smoke.sh` (echter Kontodienst + Policy-Dienst +
+   `dms-app`) zusammenführen — zwei bisher getrennte Testkabelbäume, kein
+   Nachtrag.
+
+Beides eignet sich für ein gemeinsames Folgeticket "a11y-Fixture für
+Mail/E-Rechnung + Token-Modus" (DMS-Board).
+
+## Rückbau/Zustand auf 204
+
+Alle Testläufe liefen in einem temporären Klon (`/root/nexarch-a11y-run`,
+entfernt) gegen den Wegwerf-Cluster `dms_dev`; die Next.js-Prozesse und
+Ports (4110–4112, 8299) wurden nach jedem Lauf durch `run.sh`s eigenen
+`trap` beendet. Chrome und pa11y selbst bleiben auf 204 installiert (für
+künftige Läufe), Rückbau bei Bedarf laut `deploy/chrome/README.md`.

docs/QA-15-F17-NEXTJS16-PRUEFPROTOKOLL.md

@@ -65,3 +65,23 @@ Summe: 304 bestehende Tests, 7 übersprungen (unverändert, alle E2E gegen echte
 - Commit-Nachricht: `OPS-11: next.js-migration auf 16.x`
 - Branch: `feature/qa-15-f17-nextjs-16-upgrade`
 - Kein Merge, kein Deploy.
+
+## Nachtrag 2026-09-22: Browser-/a11y-Regressionslauf nach dem Next.js-16-Upgrade
+
+Chrome 154.0.8037.57 wurde auf Host 204 installiert, `web/a11y-audit/run.sh`
+lief damit erstmals real dort (siehe Nachtrag in
+`dms/docs/UX-10-PRUEFPROTOKOLL.md`): **68/68 Prüfschritte bestanden, Exit 0**,
+axe meldet über alle 11 Seiten × hell/dunkel keine Verstöße. Damit ist
+bestätigt, dass das Next.js-16-Upgrade (PR #117) keine sichtbare
+Barrierefreiheits- oder Rendering-Regression in den drei geprüften Apps
+(`dms-browser`, `dms-upload`, `pdf-viewer`) verursacht hat.
+
+Ein dabei gefundener Fehler (`getJSON` ohne Identität in
+`keyboard-flow.js`) war ein latenter Testfehler, unabhängig vom Next.js-
+Upgrade — siehe Nachtrag in `dms/docs/UX-10-PRUEFPROTOKOLL.md` für Details
+und Fix (Commit `42724d6`).
+
+Nicht Teil dieses Laufs: `kennzahlen-dashboard`, `mail-search`,
+`retention-admin` und `shl` haben keine eigenen Browser-/a11y-Skripte in
+`web/a11y-audit/` — nur `tsc`/`vitest`/`next build` (bereits in PR #117
+bestätigt).