/* Bauteil 05 - Hinweis- und Rechtstexte. * * Angelegt 2026-08-09 nach IZ-Kompass/3_Architekturplan_Kaufstrecke.md, * Abschnitt 2, Block 05. Dort steht der Auftrag: "Ein Bauteil fuer alle * Pflichttexte und Checkboxen: einheitlicher Abstand, einheitliche * Trefflaeche, aria-describedby, Fehlermeldung mit aria-live." Jede Zeile * hier ist aus einer MESSUNG am gelieferten HTML abgeleitet, nicht aus einer * Annahme (Regel 5). * * ================================================================ * WAS DIESES BAUTEIL NICHT IST * ================================================================ * Es aendert KEINEN Rechtstext. Die Beschriftung des Bestellknopfes (L-1) * und der Inhalt der Widerrufsbelehrung (L-2/F-3) sind Einstellungs- und * Inhaltsfragen und liegen bei Christian. Dieses Bauteil gestaltet den * Kasten, nicht den Satz darin. Es fuehrt auch KEINEN eigenen Textspeicher * ein - ein zweiter Ort fuer dieselben Rechtstexte waere bei einer Abmahnung * der schlechteste denkbare Zustand (Bauplan, Block 05). * * ================================================================ * WAS GEMESSEN WURDE - Live, /daten/, 1440px, 2026-08-09 * ================================================================ * Zehn Germanized-Checkboxen sind aktiv (gemessen ueber * WC_GZD_Legal_Checkbox_Manager, nicht aus der Einstellungstabelle gelesen). * Neun davon stehen an der Kasse, "privacy" an der Registrierung. Ihre * Wrapper tragen ausnahmslos die Klassen * legal form-row checkbox- [validate-required] * einzige Ausnahme: "photovoltaic_systems" traegt statt "legal" den eigenen * Namen. Deshalb greifen die Regeln unten auf genau diese zwei Klassen. * * ELFTES ELEMENT, IM BAUPLAN NICHT VERZEICHNET: Germanized PRO rendert im * SCHRITT 1 zusaetzlich eine eigene Datenschutz-Zeile * p.form-row.legal.data-privacy.validate-required (input #gzdp-privacy-policy) * Sie ist keine der zehn Checkbox-Einstellungen und faellt trotzdem unter * dieses Bauteil, weil sie dieselbe Klasse "legal" traegt. Das ist gewollt: * sie IST eine Pflicht-Checkbox und soll nicht anders aussehen. * * Gemessene Ist-Werte an dieser Zeile (getComputedStyle): * Wrapper

EBGaramond12-Regular 18px, Farbe rgb(0,0,0), margin 0 * Label OpenSans 15px, Farbe rgb(91,93,92) = #5b5d5c, inline-block * Kaestchen 20x20px, accent-color: auto (Browserblau) * Pflichtzeichen rgb(91,93,92) = #5b5d5c * Verweis rgb(184,39,56) = #b82738, text-decoration: none * Abstaende margin 0 bei zwei Kaesten, "20px 0 0" beim dritten * * ================================================================ * WARUM SICH WAS AENDERT - je Zeile ein benannter Anlass (Regel 16) * ================================================================ * #b82738 am Verweis falsches Markenrot, Katalog 1 und 8 Schritt 3 - * dieselbe Stelle, die dort seit 2026-08-07 offen * gefuehrt wird (Abweichung A-20) * text-decoration: none ein Verweis mitten im Fliesstext, der sich nur * durch seine Farbe abhebt, traegt seine Bedeutung * allein ueber Farbe - Katalog 6, WCAG 1.4.1 * #5b5d5c an Text/Stern steht in keiner Palettentabelle des Katalogs. * KEIN Kontrastmangel: gemessen 6,63:1 auf Weiss. * Der Anlass ist die Palette, nicht die Lesbarkeit * rgb(0,0,0) am Wrapper ebenfalls nicht in der Palette (Katalog 1 kennt * nur --iz-text und --iz-text-muted) * 18px / 15px zwei Schriftgroessen in einem Bedienelement, beide * in px - Katalog 2 verlangt ausschliesslich rem * accent-color: auto das Kaestchen wird beim Anhaken browserblau. Der * Katalog kennt kein Blau * inline-block am Label die zweite Textzeile laeuft unter das Kaestchen * statt in einer Flucht mit der ersten. Bauteil 01 * legt fuer Auswahlkaestchen bereits * display:flex / align-items:flex-start / gap fest - * dieselbe Bedienelementart darf nicht zweierlei * aussehen (Systematik, Regel 16) * uneinheitliche margins 0 / 0 / 20px an drei gleichartigen Kaesten * Fokus Katalog 6: "Ein Fokusring, der nur die * Browservorgabe ist, reicht nicht" * * ================================================================ * ZUR FOKUSLAGE - eine Berichtigung, gemessen * ================================================================ * 11_IZ_Umschaltliste.md Regel 3b sagt: "Auf /daten/ hat heute kein * einziges Feld einen sichtbaren Fokus." Die Messung am 2026-08-09 ist * genauer: Das Parent-Theme (iz-2025/style.min.css) setzt "outline: none" * im Fokus fuer input[type=text], input[type=email], input[type=tel], * select und textarea - fuer input[type=checkbox] und input[type=radio] * jedoch NICHT. Kaestchen und Auswahlknoepfe behalten also den Ring des * Browsers. Das Bauteil setzt trotzdem einen eigenen, weil der Katalog die * Browservorgabe ausdruecklich nicht genuegen laesst. * * ================================================================ * ZUR SPEZIFITAET - gemessen, nicht geschaetzt, und ohne !important * ================================================================ * Fuer das Label gewinnt im Bestand * .woocommerce-checkout .form-row.data-privacy label (0,0,3,1) * aus woocommerce.min.css. Der hiesige Selektor * p.form-row.legal > label.woocommerce-form__label (0,0,3,2) * traegt gleich viele Klassen und ein Element mehr - die kleinstmoegliche * Erhoehung, die sicher schlaegt. Bewusst OHNE ".woocommerce-checkout" davor, * damit dieselbe Regel auch auf der Registrierungsseite greift, wo diese * Body-Klasse fehlt. * * ================================================================ * WARUM OHNE EIGENE CONTAINER-KLASSE * ================================================================ * Anders als Bauteil 01/02 (.iz-kauf-formular) haengt dieses Bauteil an den * Germanized-Klassen selbst. Grund: die Checkboxen werden vom Plugin an * "woocommerce_review_order_after_payment" gerendert, es gibt dort kein * eigenes Markup, in das sich ein Container setzen liesse, ohne eine * PHP-Datei einzufuehren - der Bauplan sagt fuer Block 05 ausdruecklich * "keine PHP-Datei noetig". Die Eingrenzung leistet stattdessen der * Ladeschalter aus Block 00: Diese Datei wird ueberhaupt nur auf den * Ausgabeorten der Kaufstrecke eingebunden (waehrend der Bauphase allein * auf den Alternativ-Adressen). * * NICHT GELOEST, WEIL IN CSS NICHT LOESBAR: aria-live="polite" an der * Fehlermeldung. Die Checkout-Fehler erscheinen in der von WooCommerce per * JavaScript befuellten .woocommerce-NoticeGroup-checkout, nicht je Checkbox. * Das gehoert dorthin, wo dieser Bereich gebaut wird (Block 23/24), und ist * im Bericht als Luecke benannt statt hier vorgetaeuscht. * * KEIN HEX-LITERAL, KEINE PX-SCHRIFTGROESSE, KEIN RADIUS AUSSER 4px/3px/50%, * KEIN !important. */ /* ---- Der Kasten einer Rechts-Checkbox ---- * Ein einziger Aussenabstand nach oben statt drei verschiedener im Bestand. * margin statt gap, weil diese

keine gemeinsame Flex-Eltern haben - sie * werden vom Plugin einzeln in den Bestellbereich gerendert. */ p.form-row.legal, p.form-row.photovoltaic_systems { margin: var(--sp-4) 0 0; padding: 0; color: var(--iz-text); font-family: "OpenSans", "Verdana", sans-serif; font-size: var(--fs-sm); line-height: 1.5; } /* Der erste Kasten einer Folge braucht keinen Abstand nach oben - der kommt * vom Element davor. */ p.form-row.legal:first-child, p.form-row.photovoltaic_systems:first-child { margin-top: 0; } /* ---- Kaestchen und Text in einer Flucht ---- * Gleiche Form wie .iz-kauf-feld--kasten in Bauteil 01: das Kaestchen bleibt * oben stehen, der Text bildet einen eigenen Block daneben. Ohne das laeuft * die zweite Zeile unter das Kaestchen (im Bestand gemessen). */ p.form-row.legal > label.woocommerce-form__label, p.form-row.photovoltaic_systems > label.woocommerce-form__label { display: flex; align-items: flex-start; gap: var(--sp-2); /* Der Katalog verlangt mindestens 44px Trefflaeche; --sp-12 ist 48px, * die naechste Stufe der Abstandsskala darueber. Die ganze Zeile ist * die Trefflaeche, nicht nur das 20px grosse Kaestchen. */ min-height: var(--sp-12); margin: 0; padding: var(--sp-1) 0; color: var(--iz-text); font-family: "OpenSans", "Verdana", sans-serif; font-size: var(--fs-sm); line-height: 1.5; cursor: pointer; } /* ---- Das Kaestchen selbst ---- * OHNE width/height, und das ist gemessen, nicht vergessen: WooCommerce setzt * je Checkbox-Zeile eine eigene Regel * .woocommerce-checkout .form-row.checkbox- input[type="checkbox"] * { width: 1.11111rem !important } * Sie greift bei ALLEN zehn Kaesten und ergibt einheitlich 20px (gemessen auf * /daten-neu/, 1440px). Eine eigene Groessenangabe hier waere in jedem * einzelnen Fall wirkungslos - sie liesse sich nur mit einem zweiten * !important durchsetzen, und das verbietet Regel 1. Zwanzig Pixel sind kein * gemessener Mangel: die Trefflaeche ist die ganze 48px hohe Zeile, nicht das * Kaestchen. */ p.form-row.legal input[type="checkbox"], p.form-row.photovoltaic_systems input[type="checkbox"] { flex: 0 0 auto; /* Ein Viertel Zeilenhoehe Versatz, damit das Kaestchen optisch auf der * ersten Textzeile sitzt und nicht an deren Oberkante klebt. */ margin: var(--sp-1) 0 0; accent-color: var(--iz-rot); } /* ---- Fokus ---- * Katalog 6. Gemessen: --iz-rot (#8b1a1a) auf Weiss ergibt 9,29:1 und liegt * damit deutlich ueber den 3:1, die WCAG 1.4.11 fuer den Umriss eines * Bedienelements verlangt. */ p.form-row.legal input[type="checkbox"]:focus-visible, p.form-row.photovoltaic_systems input[type="checkbox"]:focus-visible { outline: 2px solid var(--iz-rot); outline-offset: 2px; } /* ---- Pflichtkennzeichnung ---- * Nicht allein ueber Farbe: Germanized liefert zum Sternchen bereits einen * Text fuer Vorlesewerkzeuge mit (screen-reader-text bzw. abbr[title]). * Das Sternchen wird deshalb nur eingefaerbt, nicht mit Bedeutung beladen. * Die gepunktete Unterstreichung, die der Browser jedem abbr[title] gibt, * entfaellt - sie sieht wie ein Verweis aus und ist keiner. */ p.form-row.legal .required, p.form-row.legal abbr.required, p.form-row.photovoltaic_systems .required, p.form-row.photovoltaic_systems abbr.required { color: var(--iz-rot); text-decoration: none; border-bottom: 0; cursor: inherit; } /* ---- Verweise in den Rechtstexten ---- * AGB, Widerrufsbestimmungen, Datenschutz, SEPA-Mandat. Unterstrichen, weil * ein Verweis mitten im Fliesstext sich nicht allein durch Farbe abheben * darf (Katalog 6, WCAG 1.4.1). */ p.form-row.legal a, p.form-row.photovoltaic_systems a { color: var(--iz-rot); text-decoration: underline; text-underline-offset: 2px; } p.form-row.legal a:hover, p.form-row.legal a:focus-visible, p.form-row.photovoltaic_systems a:hover, p.form-row.photovoltaic_systems a:focus-visible { color: var(--iz-rot-hover); } p.form-row.legal a:focus-visible, p.form-row.photovoltaic_systems a:focus-visible { outline: 2px solid var(--iz-rot); outline-offset: 2px; } /* ---- Fehlerzustand ---- * Drei Signale gleichzeitig, nie nur Farbe (Katalog 6): roter Rahmen um das * Kaestchen, Fehlertext, aria-invalid im Markup. WooCommerce setzt * "woocommerce-invalid" auf die Zeile, sobald die Pflichtpruefung anschlaegt. */ p.form-row.legal.woocommerce-invalid input[type="checkbox"], p.form-row.photovoltaic_systems.woocommerce-invalid input[type="checkbox"] { outline: 2px solid var(--iz-rot); outline-offset: 2px; } p.form-row.legal .iz-kauf-hinweis__fehler, p.form-row.photovoltaic_systems .iz-kauf-hinweis__fehler { display: block; margin-top: var(--sp-1); color: var(--iz-rot); font-size: var(--fs-sm); font-weight: 700; } /* ---- Reiner Hinweistext ohne Kaestchen ---- * Germanized kann eine Checkbox mit "hide_input" als blossen Pflichthinweis * ausgeben. Heute ist das bei keiner der zehn der Fall (gemessen: alle * hide_input = no); die Regel steht, damit der Fall nicht ungestaltet * auftaucht, sobald jemand die Einstellung umlegt. */ p.form-row.legal > label.woocommerce-form__label:not(.checkbox) { display: block; min-height: 0; cursor: default; } /* ---- Bewegung ---- * Das Bauteil bewegt nichts. Die Regel steht trotzdem, damit ein spaeterer * Zusatz sie nicht vergisst (Katalog, Regel 12 Punkt 5). */ @media (prefers-reduced-motion: reduce) { p.form-row.legal *, p.form-row.photovoltaic_systems * { transition: none; animation: none; } }