Aufgefallen beim Review von #893 — dort bewusst nicht mitbehoben, weil es einen Zustand betrifft, den #893 gar nicht anfasst.
Befund
Die Bildbeschreibung von 251-support-create-ticket-page-filled in docs/handbook/de/index.html
(um Zeile 7532) sagt:
Das ausgefüllte Formular mit ausgewähltem Anliegen-Typ und eingegebener Nachricht: Die
Schaltfläche Senden ist nun aktiv.
Der Screenshot zeigt aber keinen eingegebenen Text, sondern den grauen Platzhalter
Nachricht eingeben.
Warum das so ist
Der Screenshot wird von scripts/assemble-handbook-screenshots.sh aus der Golden-Baseline
test/goldens/screens/support/goldens/macos/support_create_ticket_page_filled.png gebaut. Der
erzeugende Test hält den Grund selbst fest
(test/goldens/screens/support/support_create_ticket_golden_test.dart):
The message TextField renders empty because the field is not bound to state (it drives the cubit
via onChanged only); the enabled button is what proves the filled state.
Der Cubit-State trägt die Nachricht also, das Feld rendert sie nicht — die Baseline ist korrekt,
nur die Beschreibung behauptet etwas, das im Bild nicht steht.
Warum es zählt
Für Nutzer mit Screenreader ist die Beschreibung das Bild. Sie zählt hier ein Formularfeld auf,
das sichtbar leer ist — genau die Klasse von Abweichung, wegen der in #893 die Beschreibungen der
Blöcke 250/251/252/258/259 nachgezogen wurden. Dieser eine Widerspruch ist dabei stehengeblieben.
Mögliche Wege
- Nur den Text korrigieren — die Beschreibung sagt, was das Bild zeigt: Typ gewählt, Feld noch
leer, Senden trotzdem aktiv. Billig, aber der Screenshot bleibt ein Zustand, den ein Nutzer real
nie sieht (aktiver Senden-Button ohne Text im Feld).
- Das Golden echt befüllen — im Golden-Test einen
TextEditingController mit Text setzen bzw.
den Text via enterText eingeben, Baseline über golden-regenerate.yaml neu erzeugen, danach
passt die bestehende Beschreibung ohne Änderung. Trifft nur diese eine Baseline; deckt sich
ausserdem mit dem, was die Seite in Produktion zeigt.
Tendenz zu 2, weil sonst der irreführende Zustand im Handbuch bleibt — Entscheid gehört aber zu
dem, der es umsetzt.
Nicht betroffen
250 (leeres Formular) und 252 (Absenden) — am Golden geprüft, Beschreibungen stimmen.
258/259 (Chat) — stimmen.
Aufgefallen beim Review von #893 — dort bewusst nicht mitbehoben, weil es einen Zustand betrifft, den #893 gar nicht anfasst.
Befund
Die Bildbeschreibung von
251-support-create-ticket-page-filledindocs/handbook/de/index.html(um Zeile 7532) sagt:
Der Screenshot zeigt aber keinen eingegebenen Text, sondern den grauen Platzhalter
Nachricht eingeben.
Warum das so ist
Der Screenshot wird von
scripts/assemble-handbook-screenshots.shaus der Golden-Baselinetest/goldens/screens/support/goldens/macos/support_create_ticket_page_filled.pnggebaut. Dererzeugende Test hält den Grund selbst fest
(
test/goldens/screens/support/support_create_ticket_golden_test.dart):Der Cubit-State trägt die Nachricht also, das Feld rendert sie nicht — die Baseline ist korrekt,
nur die Beschreibung behauptet etwas, das im Bild nicht steht.
Warum es zählt
Für Nutzer mit Screenreader ist die Beschreibung das Bild. Sie zählt hier ein Formularfeld auf,
das sichtbar leer ist — genau die Klasse von Abweichung, wegen der in #893 die Beschreibungen der
Blöcke 250/251/252/258/259 nachgezogen wurden. Dieser eine Widerspruch ist dabei stehengeblieben.
Mögliche Wege
leer, Senden trotzdem aktiv. Billig, aber der Screenshot bleibt ein Zustand, den ein Nutzer real
nie sieht (aktiver Senden-Button ohne Text im Feld).
TextEditingControllermit Text setzen bzw.den Text via
enterTexteingeben, Baseline übergolden-regenerate.yamlneu erzeugen, danachpasst die bestehende Beschreibung ohne Änderung. Trifft nur diese eine Baseline; deckt sich
ausserdem mit dem, was die Seite in Produktion zeigt.
Tendenz zu 2, weil sonst der irreführende Zustand im Handbuch bleibt — Entscheid gehört aber zu
dem, der es umsetzt.
Nicht betroffen
250(leeres Formular) und252(Absenden) — am Golden geprüft, Beschreibungen stimmen.258/259(Chat) — stimmen.