diff --git a/deploy/chrome/README.md b/deploy/chrome/README.md new file mode 100644 index 00000000..8bb3af2e --- /dev/null +++ b/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`. diff --git a/dms/docs/UX-10-PRUEFPROTOKOLL.md b/dms/docs/UX-10-PRUEFPROTOKOLL.md index 676237c8..3b1060a1 100644 --- a/dms/docs/UX-10-PRUEFPROTOKOLL.md +++ b/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=` 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). diff --git a/dms/docs/UX-11-PRUEFPROTOKOLL.md b/dms/docs/UX-11-PRUEFPROTOKOLL.md index 1f1e612a..f92536ea 100644 --- a/dms/docs/UX-11-PRUEFPROTOKOLL.md +++ b/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. diff --git a/docs/CHROME-BROWSER-NACHTRAG-PRUEFPROTOKOLL.md b/docs/CHROME-BROWSER-NACHTRAG-PRUEFPROTOKOLL.md new file mode 100644 index 00000000..b4eab0ee --- /dev/null +++ b/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=` 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`. diff --git a/docs/QA-15-F17-NEXTJS16-PRUEFPROTOKOLL.md b/docs/QA-15-F17-NEXTJS16-PRUEFPROTOKOLL.md index e64f1a71..3760e20c 100644 --- a/docs/QA-15-F17-NEXTJS16-PRUEFPROTOKOLL.md +++ b/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).