/* IZ - Bedienelemente: Mindestgroessen fuer Eingabefelder und Kaufknoepfe. * * Angelegt 2026-08-23, Todo K-19 und K-20, Auftrag bilder-bedienbarkeit-20260823. * * WOFUER: * Zwei gemessene Verstoesse gegen 10_IZ_Gestaltungskatalog.md, die beide erst * am Telefon wehtun und deshalb am Schreibtisch lange unbemerkt blieben. * * K-19 - Eingabefelder unter 16px. iOS-Safari zoomt beim Antippen eines * Feldes automatisch in die Seite hinein, sobald dessen Schrift kleiner als * 16px ist. Der Leser landet dann in einer vergroesserten Seite, die er von * Hand zurueckziehen muss. Am 23.08.2026 im Browser bei 1440px gemessen: * .search-field (Kopfzeile, jede Seite) 15px * input.qty (Produktseite, Mengenfeld) 15px * Ursache ist das Eltern-Theme, das * input[type="text"], ..., select, textarea { font-size: 15px } * mit der Spezifitaet (0,1,1) setzt. Die Regeln hier tragen durch das * vorangestellte :root die Spezifitaet (0,2,1) und schlagen sie - ohne * !important, genau wie css/kauf/01-feld.css es fuer die Kasse vormacht. * * K-20 - Kaufknoepfe unter 44x44px. Am 23.08.2026 gemessen: * button.single_add_to_cart_button (Produktseite) 148x40px * a.button.add_to_cart_button (Shop, Widgets) 148x40px * Der Katalog Abschnitt 6 verlangt mindestens 44x44px Trefflaeche. * * WARUM 18px UND 48px UND KEINE ANDEREN WERTE: * Die Schriftskala des Katalogs (Abschnitt 2) kennt oberhalb von 16px nur * --fs-base = 1rem. Die rem-Basis ist 18px (Katalog, berichtigt 2026-08-09), * also 18px. Die naechstkleinere Stufe --fs-sm waere 0.875rem = 15,75px und * damit weiterhin unter der Schwelle - sie kaeme dem Ziel nahe und wuerde den * Fehler trotzdem nicht beheben. Einen Zwischenwert einzufuehren verbietet * derselbe Abschnitt ausdruecklich. --sp-12 = 48px ist die naechste Stufe der * Abstandsskala (Abschnitt 3) ueber den geforderten 44px; dieselbe Wahl und * dieselbe Begruendung stehen seit dem 2026-08-09 in css/kauf/01-feld.css. * * KEIN HEX-LITERAL, KEINE PX-SCHRIFTGROESSE, KEIN RADIUS AUSSER 4px/3px/50%. * Diese Datei setzt bewusst weder Farben noch Rahmen noch Radien - sie * veraendert ausschliesslich Groessen. Alles Uebrige bleibt, wie es ist * (Arbeitsregel 16: Umbau ist kein Neuentwurf). * * WAS SIE AUSDRUECKLICH NICHT ANFASST: * - Die Kasse und das Kundenkonto. Deren Felder stehen ueber * css/kauf/01-feld.css bereits auf --fs-base und --sp-12; die Regeln hier * treffen dieselben Werte und koennen dort nichts verschieben. * - Die Adminleiste. Deren eigene Regeln beginnen saemtlich mit #wpadminbar * und tragen damit eine ID - Spezifitaet (1,x,y). Sie schlagen die (0,2,1) * hier in jedem Fall. Fuer Besucher ist die Leiste ohnehin nicht da. * - Das Newsletter-Formular der Randspalte. Dessen Groessen stehen als * style-Attribut im Formularinhalt und sind nur mit !important zu * schlagen; das geschieht dort, wo dieses Widget ohnehin geregelt wird * (inc/layout-fixes.php), und nicht hier. * * @package iz-2025-child * @since 2026-08-23 */ /* ---- K-19: Eingabefelder ---- */ :root input[type="text"], :root input[type="email"], :root input[type="url"], :root input[type="password"], :root input[type="search"], :root input[type="number"], :root input[type="tel"], :root input[type="date"], :root input[type="month"], :root input[type="week"], :root input[type="time"], :root input[type="datetime-local"], :root select, :root textarea { font-size: var(--fs-base); min-height: var(--sp-12); box-sizing: border-box; } /* Der Suchknopf steht neben dem Suchfeld und war 40px hoch. Nur die Hoehe - * seine Beschriftung ist Text auf einem Knopf und loest keinen iOS-Zoom aus, * die Schriftgroesse bleibt deshalb unberuehrt. */ :root input[type="submit"].search-submit { min-height: var(--sp-12); } /* ---- K-20: Kaufknoepfe ---- * inline-flex, weil eine Mindesthoehe den Beschriftungstext sonst oben * stehen liesse statt ihn zu zentrieren. Die Breite bleibt, wie sie ist - * gemessen 148px, also weit ueber den geforderten 44px; min-width ist nur * die Absicherung fuer kurze Beschriftungen. */ :root button.single_add_to_cart_button, :root a.button.add_to_cart_button, :root .woocommerce a.button.add_to_cart_button { display: inline-flex; align-items: center; justify-content: center; min-height: var(--sp-12); min-width: var(--sp-12); } /* Das Mengenfeld der Produktseite braucht eine eigene Zeile - nicht aus * Vorliebe, sondern weil es gemessen wurde: Nach dem ersten Ausrollen stand es * weiter auf 15px. Am 23.08.2026 im Browser ueber die CSSOM abgefragt, welche * Regeln auf input.qty passen und font-size setzen. Vier Treffer, gewonnen hat * .single-product .product .cart input[type="number"] { font-size: 15px } * mit der Spezifitaet (0,4,1) - die Regel oben hat (0,2,1) und verliert. Eine * Gegenprobe ueber das gesamte ausgelieferte CSS-Buendel ergab: das ist die * EINZIGE Regel der Seite, die eine Schriftgroesse unter 16px auf einem * Eingabefeld mit hoeherer Spezifitaet setzt. Deshalb genau eine Ausnahme und * keine pauschale Verschaerfung mit !important. */ :root .single-product .product .cart input[type="number"] { font-size: var(--fs-base); } /* ==================================================================== * K-21: Trefflaechen unter 44 x 44px - vergroessert OHNE sichtbare * Aenderung. * * Ergaenzt 2026-08-25, Todo K-21, Auftrag K21-T32-20260825 (Los 1). * * WOFUER: * Katalog Abschnitt 6 verlangt "Touch-Ziele mindestens 44 x 44px". Nach * K-19 und K-20 (oben, 23.08.) blieben die Bedienelemente ausserhalb der * Kaufstrecke uebrig. Am 2026-08-25 bei 1440px im Browser neu gemessen - * die Werte vom 23.08. waren zwei Tage alt und stimmen nicht mehr ganz: * * a.iz-btn-subscribe 130,3 x 28 Kopfzeile "Abonniere die IZ" * a.iz-pageheader__adslink 88,5 x 28 Kopfzeile "Startseite" (neu) * a.iz-header-icon--account 32 x 32 Kopfzeile Konto (neu) * a.iz-header-icon--cart 32 x 32 Kopfzeile Warenkorb (neu) * .iz-search-icon 24 x 24 Kopfzeile Suche * a.social-btn--* (4 Stueck) 40 x 40 Fussbereich * a.iz-abo-btn 230 x 35,5 Artikelseite (neu) * a.iz-btn--primary 750 x 40 Artikelseite (IZ+) * * WARUM EIN UNSICHTBARES FELD UND KEIN GROESSERER INNENABSTAND: * Innenabstand oder Mindesthoehe waeren sichtbar: die Kopfzeile wuerde * hoeher, die runden Sozialsymbole groesser. Regel 16 (Umbau ist kein * Neuentwurf) verlangt fuer jede sichtbare Abweichung einen benannten * Anlass; hier gibt es keinen, denn die Trefflaeche laesst sich ohne * Aussehensaenderung herstellen. Ein absolut positioniertes ::after * nimmt am Layout nicht teil, faengt aber Zeigereingaben ab, die durch * das Elternelement ausgeloest werden. Am 2026-08-25 vor dem Ausrollen * im Browser gegengeprueft: die sichtbaren Abmessungen bleiben in allen * acht Faellen unveraendert (auf 0,1px genau, auch die Seitenhoehe), die * abgetastete Trefflaeche steigt auf 44 x 44. * * EINE AUSNAHME, GEMESSEN UND BEWUSST SO BELASSEN - das Suchsymbol: * Es erreicht 34 x 33, nicht 44 x 44 - auf Startseite wie Artikelseite * gleichermassen, nach dem Ausrollen an der gelieferten Seite gemessen. * Grund: links schliesst das Hauptmenue (ul.iz-menu--main) und unten das * eingeklappte Suchformular (.toggle-content) unmittelbar an. * Beide stehen im DOM spaeter und liegen deshalb UEBER dem Feld - sie * verdecken es, nicht umgekehrt. Ein z-index wuerde das umkehren und * damit Hauptmenue und Such-Absendeknopf unbedienbar machen; das waere * schlechter als der Restmangel. 34 x 33 statt vorher 24 x 24 ist der * Gewinn, der ohne Schaden zu haben ist. Die vollen 44 x 44 waeren dort * nur durch sichtbares Vergroessern des Symbols zu erreichen. * * WARUM 44px UND NICHT --sp-12 (48px): * Die Regeln fuer K-19/K-20 oben verwenden --sp-12, weil 48px die * naechste Stufe der Abstandsskala ueber 44 ist. Hier waere das ein * Fehler, und zwar ein gemessener: Konto- und Warenkorbsymbol stehen * 32px breit mit 12px Abstand nebeneinander, ihre Mittelpunkte also * 44px auseinander. Zwei 48px breite Felder ueberlappten sich um 4px - * ein Klick in diesen Streifen oeffnete den Warenkorb statt des Kontos. * Bei 44px stossen die Felder bündig aneinander, gemessen 22px nach * links und 21px nach rechts ab Mitte. Eine Mindest-Trefflaeche ist * ausserdem kein Abstand: 44px ist der Wert, den Katalog Abschnitt 6 * woertlich nennt. * * WAS SIE AUSDRUECKLICH NICHT ANFASST: * - .iz-search-icon bekommt KEIN position:relative. Es steht bereits auf * position:absolute (top 29px, left -24px) und ist damit selbst * Bezugspunkt fuer sein ::after. Es auf relative zu setzen wuerde das * Symbol aus der Kopfzeile schieben. * - .iz-btn pauschal. Nur die gemessene Variante .iz-btn--primary. Die * Klasse kommt auch in der Kaufstrecke vor, wo Knoepfe gestapelt * stehen; eine pauschale Regel waere eine Ausweitung ohne Messung. * - Fliesstext- und Ueberschriftenlinks (h3.iz-newslist__title a und * die Listen der Randspalte, 18-31,5px hoch). Sie sind Text, kein * Bedienelement; WCAG 2.5.8 nimmt Links im Textfluss ausdruecklich * aus. Sie zu vergroessern hiesse die Startseite neu zu setzen. * - Das Newsletter-Kaestchen #iz-nl-agree (13 x 13). Am 2026-08-25 * gemessen: ein ::after auf input[type=checkbox] wird zwar berechnet * (width 44px), aber nicht gerendert und faengt keine Eingabe ab - * die abgetastete Trefflaeche blieb 13 x 13. Ein unsichtbarer Weg * existiert dort also nicht; das Kaestchen liegt Christian als * sichtbare Aenderung zur Freigabe vor. * * KEIN HEX-LITERAL, KEINE SCHRIFTGROESSE, KEIN RADIUS. Diese Regeln * setzen ausschliesslich Groesse und Position eines unsichtbaren Feldes. * * @since 2026-08-25 */ /* Bezugspunkt fuer das Feld - nur bei Elementen, die auf static stehen. * account, cart und .iz-btn--primary stehen bereits auf relative, * .iz-search-icon auf absolute (siehe Kommentar oben). */ :root a.iz-btn-subscribe, :root a.iz-pageheader__adslink, :root a.iz-abo-btn, :root .iz-socmed .iz-menu--icons li a { position: relative; } /* Breite Knoepfe: nur die Hoehe fehlt, die Breite liegt ueber 44px. */ :root a.iz-btn-subscribe::after, :root a.iz-pageheader__adslink::after, :root a.iz-abo-btn::after, :root a.iz-btn.iz-btn--primary::after { content: ""; position: absolute; left: 0; right: 0; top: 50%; height: 44px; transform: translateY(-50%); } /* Quadratische Symbole: Breite und Hoehe fehlen beide. */ :root a.iz-header-icon::after, :root .iz-search .iz-search-icon::after, :root .iz-socmed .iz-menu--icons li a::after { content: ""; position: absolute; left: 50%; top: 50%; width: 44px; height: 44px; transform: translate(-50%, -50%); } /* ---- K-21a: Einwilligungskaestchen des Newsletter-Formulars ---- * * Freigegeben von Abdelkabir am 2026-08-25 ("ja, beides freigegeben"), * nachdem K-21 am selben Tag ergeben hatte: Hier ist der unsichtbare Weg * NICHT gangbar. Ein ::after auf input[type=checkbox] wird zwar berechnet, * aber nicht gerendert und faengt keine Eingabe ab - die abgetastete * Trefflaeche blieb exakt 13 x 13. Das Kaestchen muss also sichtbar * wachsen; das ist der Grund, warum diese Regel eine Einzelfreigabe * gebraucht hat und die uebrigen in dieser Datei nicht. * * GEMESSEN AM 2026-08-25 AN DER GELIEFERTEN STARTSEITE, 1440px: * input#iz-nl-agree 13 x 13 px (Browservorgabe, kein inline-Wert) * umgebende td 20 x 20 px (inline style="width:20px") * Tabelle 1240 x 20 px (table-layout:fixed) * Textzelle daneben 1220 px, Innenabstand links 4px * * WARUM 24px UND NICHT 44px: * 44px sind der Katalogwert (Abschnitt 6) und werden von den Regeln * darueber auch erreicht - aber nur, weil sie ein unsichtbares Feld * aufziehen. Hier waechst das Kaestchen selbst. Ein 44px hohes Kaestchen * verdreifachte die Zeilenhoehe von 20 auf 46px und schoebe den * Einwilligungstext aus seiner Zeile. 24px ist der Wert, den WCAG 2.1 AA * (2.5.8, "Target Size (Minimum)") verlangt, und er entspricht der * Abstandsstufe --sp-6 = 24px, also der Skala aus Katalog Abschnitt 3. * Damit ist die Stufe dieselbe, die die Randspalten-Fassung desselben * Formulars seit dem 2026-08-23 traegt (inc/layout-fixes.php). * * WARUM #primary UND NICHT PAUSCHAL: * Dasselbe mc4wp-Formular 83980 erscheint zweimal: hier im Hauptbereich * der Startseite (#primary) und in der Randspalte der Artikelseiten * (#secondary). Die Randspalten-Fassung ist bereits geregelt - in * inc/layout-fixes.php, in einem Block, der ausdruecklich nur bei * iz_child_is_sidebar_view() ausgegeben wird und die Startseite deshalb * nie erreicht (am 2026-08-25 im Quelltext nachgelesen, nicht vermutet). * Die Einschraenkung auf #primary sorgt dafuer, dass die beiden Fassungen * sich nicht ueberlagern - eine zweite Regel fuer dasselbe Element waere * genau der Flicken auf dem Flicken, den Arbeitsregel 1 verbietet. * * WARUM DIE ZELLE MITWACHSEN MUSS - UND WARUM DORT !important STEHT: * Die Tabelle steht auf table-layout:fixed, die Spaltenbreite kommt also * aus der ersten Zeile. Bliebe die Zelle bei 20px, ragte das 24px breite * Kaestchen 4px darueber hinaus. Die 20px stehen als style-Attribut im * Formularinhalt, der in der Datenbank liegt (mc4wp-Formular 83980) und * nicht uns gehoert; ein inline-Wert ist ausschliesslich mit !important * zu schlagen. Es ist das einzige !important in dieser Datei, und es * steht hier statt einer Aenderung am Formularinhalt, damit der Rueckweg * aus einer einzigen Zeile besteht. * * Faellt :has() aus (Browser vor Safari 15.4 / Chrome 105), bleibt die * Zelle bei 20px und das Kaestchen ragt in den 4px-Innenabstand der * Textzelle - der Text selbst verschiebt sich auch dann nicht. * * KEIN HEX-LITERAL, KEINE SCHRIFTGROESSE, KEIN RADIUS. * * @since 2026-08-25 */ :root #primary .mc4wp-form input[type="checkbox"] { width: var(--sp-6); height: var(--sp-6); } :root #primary .mc4wp-form table td:has(> input[type="checkbox"]) { width: var(--sp-6) !important; }