Stav k 2. 11. 2026 · Travel 0.21.2 · Úraz 0.14.1
Syntéza zachovává teze, rozdílné důrazy a nejistoty tří samostatných posudků nad travel 0.21.2 a úrazem 0.14.1. Doplňuje jejich plné znění; oddělený rozhodovací report řeší volbu dalšího postupu. Nejde o průměr doporučení ani o tři lidská autorizovaná odborná stanoviska.
Nezávislé posudky vytvořily modely GPT-6 Sol, GPT-6.1 Sol a GPT-6.1 Terra s úsilím xhigh. GPT-5.6 se na výslovnou volbu uživatele neúčastnil.
Všechny tři pohledy podporují společné komponentové a obsahové role. Úrazové částky, frekvence a osoby se nemají mechanicky přepsat na cestovní varianty, aktivity a cenu celé cesty. Jednotný univerzální průchod nyní nemá doloženou potřebu.
Posudky: gpt-6-sol, gpt-6.1-sol, gpt-6.1-terra
Červené kickery #F42534, bílé písmo zelených akcí, šedá stránka, bílé formuláře, patička #003B71 a čtyři fáze tvoří přijaté zadání. Následné sjednocení má zabránit dalšímu driftu; přístupnostní rozpor není oprávněním preference potichu změnit.
Posudky: gpt-6-sol, gpt-6.1-sol, gpt-6.1-terra
Všichni požadují úplný místní průchod bez AI/API a bez skutečných vedlejších účinků. Travelové „Pojištění je sjednáno“ je viditelný obsahový rozpor s modelovým režimem, nikoli důkaz, že se smlouva skutečně uzavřela. Označení simulace potřebují oba produkty.
Posudky: gpt-6-sol, gpt-6.1-sol, gpt-6.1-terra
Společný katalog má evidovat význam, stavy, schválení, produktové výjimky a důkazy. Změna patří do nového reprodukovatelného vydání. Historická vydání ani původní kořenový úraz se tímto auditem nemění; hotová integrace Ferdy z podkladů nevyplývá.
Posudky: gpt-6-sol, gpt-6.1-sol, gpt-6.1-terra
Rozdílné načasování je fakt; správná společná politika zatím není jednomyslně určená.
K rozhodnutí: Vlastník produktu má zvolit účel a načasování. Hypotézu pozdějšího kontaktu ověřit; nevydávat ji za prokázané zvýšení konverze.
Shoda na čtyřech fázích neznamená shodu na každém popisku.
K rozhodnutí: Zachovat přijatý fázový model. Změnu názvu a podobu podkroku projednat zvlášť; není již schválenou implementací.
Zde nejde o spor auditorů, ale o rozpor artefaktu se záměrem a o další přístupnostní omezení.
K rozhodnutí: Potvrdit roli navy ceny i v rekapitulaci. Zvlášť rozhodnout řešení kontrastu při zachování požadovaných akcentů; neslibovat shodu WCAG.
Posudky se doplňují, nepředkládají totožný implementační plán.
K rozhodnutí: Oddělit opravy současných modelových obrazovek od budoucí integrace. Integrace není podmínkou sjednocení vzhledu ani nyní schváleným výsledkem.
| Priorita | Úkol | Význam | Odpovědnost | Ověření |
|---|---|---|---|---|
| P1 | Pravdivé kritické stavy | Sjednotit modelové platby, dokumenty, e-maily a dokončení. Výchozí travel karty už říkají „Vybrat“; detail má „Sjednat tuto variantu“. Zachované neaktivní renderery nelze vydávat za aktuální obrazovku. | Produkt a UX writing | Snímky kritických stavů a oba úplné offline starty; správný účinek každé aktivní akce. |
| P1 | Výslovná indexační politika | Specializované zjištění GPT-6.1 Sol: veřejný úraz nemá v ověřeném HTML noindex ani odpovědní X-Robots-Tag; travel má noindex v HTML. To není důkaz indexace. Noindex také nenahrazuje ochranu přístupu. | Správa webu a SEO | evidence/public-http.json, původní HTML a následná kontrola zvoleného pravidla; skutečný index samostatně. |
| P1 | Kontrast a klávesnicové interakce | Předložit barevné rozpory k rozhodnutí. Ověřit přesun fokusu při Jiné zemi, dialogy, chyby a návraty. Výběrový test s BODY jako activeElement sám nedokazuje únik do podkladu. | UI a přístupnost | keyboard.json, ustálené computed stavy a cílené ověření čtečkou i dalšími prohlížeči. |
| P1 | Podmínka před skutečným adaptérem | Ověření současné smlouvy dat, validace a odpovědností Ferdy je vstupní podmínkou případné integrační práce, nikoli úkolem odloženým za vizuální refaktoring. Terra ji ve svém integračním kontextu označuje P0. Nynější audit skutečný adaptér nevytváří. | Integrační tým a vlastníci Ferdy | Aktuální potvrzené schéma, prostředí a chybové stavy; historický draft nestačí. |
| P2 | Společný kontrakt komponent | Začít hlavičkou, navigací, akcemi a poli; poté nabídky, rekapitulace a dialogy. Field 16 px a radius 8 px jsou navrhovaný základ, nikoli současná všeobecná shoda nebo univerzální požadavek WCAG. | Architektura a design systém | Verzovaný katalog, zdůvodněné výjimky a regresní scénáře obou produktů. |
| P3 | Ověření s lidmi a obchodní správnost | Otestovat porozumění ceně, kontaktu a dokončení. Obchodní rozsah 22/11 platí pro lokální dataset. Analytické výsledky zatím nejsou k dispozici; změnu obchodní úspěšnosti je potřeba ověřit samostatně. | Výzkum a produkt | Výzkumný protokol a ověřená obchodní data; měření před tvrzením o přínosu. |
Rozsah: Hierarchie, hustota formulářů, navigace, nabídky a volba rozsahu sjednocení.
Role: nezávislý produktový a UX/UI posudek pro rozhodnutí o další iteraci. Rozsah: aktuální místní site/versions/travel-0.21.2/ a releases/uraz/ferda-0.14.1/. Nejde o návrh změny výpočtů, text pojistných podmínek ani posouzení reálného sjednání. Starý stylopis z 28. 10. používám jen jako vzor práce s konkrétním důkazem a rozlišením měřeného stavu od návrhu; jeho tehdejší popis úrazu 0.11.1 a travelu V19 není popisem dnešních verzí.
V tabulce níže jsou cesty assets/... relativní k site/versions/travel-0.21.2/; úrazové soubory ferda-flow.js, desktop.js, experience.js, uraz-unified.css, wordpress-theme.css a shared/... jsou relativní k releases/uraz/ferda-0.14.1/. index.html se vždy vztahuje k produktu v příslušném sloupci. Tím zůstávají lokální zdroje dohledatelné i bez jejich publikace v reportu.
evidence/020–093 pro nynější verze a šířky 375/1440 px. Snímek ukazuje jeden stav, nikoli všechny interakce. Evidence evidence/measurements.json uvádí osm průchodů, 124 obrazovek a žádné zaznamenané chyby; její funkční výsledek nepovažuji za uživatelský výzkum.Lokální kontrola nově zachytila tytéž dvě verze z portálových cest při 375 px. Následující dvojice jsou konkrétní vizuální důkaz, nikoli popis starých V19/0.11.1:
| Krok | Travel 0.21.2 | Úraz 0.14.1 | Vizuální rozdíl |
|---|---|---|---|
| Vstup | 020-travel-entry | 025-uraz-entry | Travel v prvním kroku ukazuje delší produktové zadání, úraz shromažďuje kontaktní údaje dříve. |
| Výběr a nastavení | 021-travel-results | 027-uraz-customize | Travel řadí mnoho nabídek, úraz detailně dolaďuje jednu zvolenou nabídku; nejde o totožný krok. |
| Osobní údaje | 022-travel-people | 028-uraz-people | Opakovaní cestující oproti jednomu pojištěnému a volitelnému jinému pojistníkovi. |
| Rekapitulace | 375 px, 1440 px | 375 px, 1440 px | Travel má jednu bílou kartu s vnitřními šedými skupinami a červenými linkami přes obsah; úraz sérii bílých panelů s krátkou červenou linkou pod nadpisem. Obě řešení ukazují podstatné údaje, ale mají jinou vizuální gramatiku. |
| Dokončení | 024-travel-done | 031-uraz-done | Travel tvrdí „Pojištění je sjednáno“ a odeslání potvrzení; úraz říká „Vše je připravené“. Obě stránky potřebují výslovnou pravdivou modelovou značku. |
| Dialog | 375 px: aktivity, 1440 px | 375 px: riziko, 1440 px | Travelový editor aktivit zůstává středovým dialogem i na mobilu; úrazový editor rizika přechází na spodní panel. Produktový obsah je jiný, chování zavření a fokusu má být stejné. |
Další konkrétní rozpor: na čerstvé travelové rekapitulaci je hlavní cena 489 Kč červeně, zatímco README/PROJECT aktuální iterace říká, že velké nadpisy a ceny zůstávají modré, a na úrazové rekapitulaci je cena modrá. V izolovaném Chrome/file průchodu je .recap-product > strong[data-selected-price] rgb(244, 37, 52), 28 px/700; předchozí travelové .offer-tile__price a .selected-summary__price jsou rgb(0, 46, 95). Úrazová rekapitulace .price-summary > strong je rgb(0, 46, 95), 30 px/600. Přesné měření a reprodukční skript. To není chybějící červený kicker; je to jiná role ceny. Před případnou změnou je třeba rozhodnout, zda modrá cena platí opravdu pro všechny fáze včetně travelové rekapitulace.
Měřená formulářová odchylka: společné hero má v obou produktech 48 px desktop/34 px mobil a pracovní h1 přibližně 32/26 px, tedy velikost titulů už není hlavní rozdíl. V 124 kontextech mají na 375 px travelová data #trip-date-from, #trip-date-to text 12 px a roh 7 px; pole pojistníka 14 px/7 px. Úrazové #profile-age, #profile-profession, #person-first, #person-last mají 16 px/8 px. Společná specifikace pole má určit čitelnost a stav, ale nemusí slepě sjednotit každou šířku nebo délku hodnoty.
Kontrast rozhodnutého CTA: kombinace aktuální zelené #00b53b a bílé má vypočtený kontrast přibližně 2,74 : 1 (standardní převod sRGB na relativní jas). Uživatelovo pravidlo bílého textu zachovat; odstín zelené a velikost/tloušťku písma je potřeba projednat jako výslovné přístupnostní rozhodnutí, nikoli text potichu ztmavit.
Ponechat červené malé sekční nadpisy #F42534 v obou produktech, bílé písmo zelených hlavních tlačítek, šedou stránku s bílými formuláři, patičku #003B71, travelovou kontaktní hlavičku, čtyři fáze navigace, žádný verzový pruh v travelu a kompletní místní modelové průchody bez AI/API. Původní kořenový /cmp_uraz/ a starší vydání jsou mimo úpravy. Současná vrstva section-accents.css prosazuje červenou pro .eyebrow, .step-kicker a příbuzné role; nové sjednocení ji musí zachovat. Tato rozhodnutí nejsou znovu otevřenými variantami.
| Oblast | Travel 0.21.2 | Úraz 0.14.1 | Rozhodnutí / typ |
|---|---|---|---|
| Úvod a hero | Dvousloupcový .hero-grid, produktový titulek a v kartě dvě cesty: .entry-tabs „Klasický formulář / Popíšu cestu“. Na 375 px se pozvánka Alexe ukazuje před dlouhým formulářem; levá důvěryhodnostní odrážka se skrývá. snímek, assets/iteration.css .hero-grid, .story-invitation, assets/travel-refinement.css .hero-copy h1. | Obdobný .uraz-hero, ale úvodní karta se soustředí na věk, zaměstnání a kontakt; na mobilu odrážky zůstávají vidět. snímek, uraz-unified.css .uraz-hero, .uraz-trust-list. | Sdílet konstrukci hero: šířky, typografické role, pořadí na mobilu a pravidlo pro skrývání ilustrace/odrážek. Obsah a dvě travelové vstupní cesty zůstanou produktové. Návrh. |
| Hustota prvního kroku | #calculator-form má destinaci, termíny, čtyři věkové kategorie, zvířata a volitelnou dopravu/storno; 375px snímek je dlouhý před hlavním CTA. index.html ř. 65–119, assets/iteration.css .destination-grid, .people-grid, .pets-picker. | První karta .uraz-calculator-card má věk, zaměstnání a kontakt; další krytí následuje ve fázi Konfigurace. uraz-unified.css .uraz-calculator-card; snímek. | Sjednotit pravidla formuláře, nikoli počet polí. Pro travel zvážit průběžné shrnutí a přístup k CTA po blokách; případné rozdělení kroku testovat, protože mění orientaci. Pro úraz držet vyhledávání zaměstnání a kontaktní údaje podle jeho výpočtové potřeby. Inference + návrh. |
| Navigace | assets/travel-navigation.js mapuje 16 obrazovek do 4 fází; výsledky, mapa, aktivity, simulátor i porovnání jsou Konfigurace. Mobil ukazuje název fáze a „1 / 4“. | ferda-flow.js definuje 4 stejné fáze; více úrazových podkroků (např. pojištěný, pojistník, obmyšlené osoby) se skládá do Údajů. Mobil zobrazuje podkrok typu „Základní údaje“/„Úprava nabídky“, nikoli jen jméno fáze. index.html .step-nav, shared/app.js ř. 42–43. | Sdílet fázový model a vzor zpět, ale jasně rozlišit fázi od podkroku na obou mobilech. Současné „1 / 4“ v travelu neříká, kolik interních obrazovek následuje; neslibovat čtyři obrazovky. Zdrojově doloženo + návrh. |
| Nabídky a srovnání | #results-grid / .offer-tile ukazuje na desktopu 3 sloupce a na mobilu 22 variant v dlouhém seznamu; každá má cenu za cestu, shodu, jeden důležitý limit, detail, výběr a porovnání. desktop, mobil, index.html ř. 140–154, assets/app.js ř. 543. | Úraz používá volbu rizik, porovnávací tabulku nabídek a následnou úpravu vybraného produktu s frekvencí placení. konfigurace, desktop.js cards(), experience.js render...customize, shared/comparison.js. | Sdílet kostru nabídkové karty/řádku: logo, název, časová jednotka ceny, klíčové krytí, důkaz/podklady, detail a výběr. Matice rizik, shoda DNA, délka cesty, frekvence placení a dostupnost připojištění jsou produktové. V travelu rozhodnout, zda všech 22 položek ukázat najednou nebo přidat progresivní zveřejnění; žádné položky nesmějí zmizet. Návrh. |
| Osobní údaje | Jedna .form-card pro pojistníka a opakované fieldsety cestujících; .selected-summary vpravo drží vybranou nabídku. snímek, index.html ř. 177–184, assets/app.css .selected-summary. | Úraz dělí pojištěného, adresu a pojistníka do samostatných bílých panelů; další údaje mohou být podkroky. snímek, ferda-flow.js people(), desktop.js people, shared/app.js data routes. | Sdílet design polí, validací, shrnutí nabídky a editace, ponechat počet osob a vztah pojistník/pojištěný podle produktu. Srovnat časování kontaktu: úraz chce e-mail už v kalkulaci, travel až po výběru. To je obsahové rozhodnutí, ne CSS. Návrh. |
| Rekapitulace a konec | .recap-card skládá cestu, krytí, kontakt a osoby. Následuje modelový e-mail, platba a obrazovka „Pojištění je sjednáno / poslali jsme“ se syntetickým číslem smlouvy. index.html ř. 186–198; snímek konce. | Rekapitulace skládá krytí, pojištěného, pojistníka, cenu a podklady; dokončení ukazuje návrh a výsledné krytí. Modelovost je přímo v textu platebního kroku (desktop.js payment) a dokončení (desktop.js done), přesto mobilní konec sám nese „Vše je připravené“. snímek. | Společná obsahová norma pro mock režim je priorita P1: na každém kritickém kroku a potvrzení jasně označit simulaci, nikdy netvrdit, že byl skutečně odeslán e-mail, uzavřena smlouva nebo přijata platba. Ponechat produktová fakta v rekapitulaci. Zdrojově doloženo + návrh; nejde o tvrzení, že se skutečně něco odesílá. |
| Dialogy | Několik .modal[role=dialog][aria-modal=true] pro detail, připojištění, důkaz, editaci cesty i asistenci; assets/app.js ř. 1235–1250 explicitně řeší fokus a Tab smyčku. Konkrétní #activity-editor-modal má podle assets/innovation.css .activity-editor-modal šířku do 720 px a na 375 px i 1440 px zůstává středový; jiné travelové modaly .offer-detail-modal a .option-modal přecházejí podle assets/app.css v mobilu na spodní panel. | Nativní <dialog id="detail-dialog"> a <dialog id="ferda-dialog">; shared/base.css mění mobilní dialog na spodní panel. Konkrétní rizikový editor je na 375 px dole, na 1440 px uprostřed. | Sdílet vzor chování, ne nutně DOM implementaci v první iteraci: název, Escape, fokus, návrat k vyvolávacímu ovladači, scroll, bezpečné zavření a mobilní plocha. Pro mobil určit, které editory mají být spodní panel a proč; nativní dialog může být cílový společný základ až po regresi všech travelových případů. Zdrojově doloženo + návrh. |
| CTA a detaily | Postupové .button--primary a původní .button--navy mají po assets/travel-refinement.css zelenou s bílou; sekundární obrys navy. Vedle výběru jsou četná AI vysvětlení, důkazy, detail i úprava. | .button pro hlavní postup je zelená/bílá, sekundární akce obrysová; na konfiguraci je jedno velké „Pokračovat na osobní údaje“. uraz-unified.css / wordpress-theme.css. | Sdílet akční role primární postup/výběr, sekundární detail/úprava, textový návrat. AI nesmí být jediné vysvětlení; travel má současně text a detail, jejich smysl má být jednoznačný. Focus a disabled důvod kontrolovat odděleně od barvy. Návrh. |
Pozorování mimo tabulku: obě současné verze už mají záměrně podobnou hlavičku, hlavní barvy, typografický základ, červené kickery a patičku. Největší zbylé rozhodnutí není další přebarvení. Je to sjednocení chování fází a komponent při zachování významu různých produktových dat. Plošné sjednocení velikosti sekcí by travelový mobilní formulář dále prodloužilo a úrazovou porovnávací tabulku mohlo znehodnotit. To je inference ze snímků, nikoli naměřený dopad na uživatele.
| Směr | Obsah | Přínos | Cena / riziko | Můj závěr |
|---|---|---|---|---|
| A. Cílené opravy | Společné pojmenování modelového režimu, navigační popisky, CTA role a drobné rozdíly v hero/formulářích v samostatných CSS/JS vrstvách. | Rychlé, malé riziko pro současné průchody. | Duplikace a kaskáda porostou; každou opravu bude nutné dělat dvakrát. | Vhodné jako první bezpečný krok pro P1 obsah a přístupnost, nestačí jako dlouhodobé pravidlo. |
| B. Sdílené komponenty a tokeny | Jeden kontrakt pro hlavičku, fázový ukazatel, hero, pole/validace, karty nabídky, CTA, rekapitulační fakta, dialog a patičku; obě aplikace předávají vlastní text, data a výpočet. | Sníží vizuální drift a dovolí společné kontroly bez slučování produktových cest. | Vyžaduje mapu vlastnictví, API komponent a postupné připojení obou rendererů; regresní riziko v interakcích. | Doporučuji po cílené opravě P1. Pilot: hlavička, navigace, CTA/pole; teprve potom složitější nabídky a dialogy. |
| C. Jeden univerzální průchod | Sloučit router, datový model i obsah kroků do jedné konfigurovatelné aplikace. | Jeden runtime a potenciálně méně duplicit. | Travelové DNA/mapa/22 výsledků a úrazová rizika, placení a osoby mají jiné rozhodovací okamžiky. Konfigurace by mohla zakrýt produktové výjimky, výrazně rozšířit testovací matici a ohrozit historická vydání. | Nyní nedoporučuji; odložit, dokud nebude prokázaná potřeba společné logiky, ne pouze podobný vzhled. |
canvas, bílý surface, navy titulek/cenu, červený kicker, zelený postup s bílým textem, sekundární navy akci, chybu, fokus a vybraný stav. Při refaktoringu zachovat .eyebrow/.step-kicker #F42534 v úvodu, kartách, detailech a dynamických krocích. Výchozí společný komponent nesmí přepisovat produktové limity, cenu ani rozhodovací logiku.site/. Starší ZIP a kořenový úraz zachovat byte shodně. Před předáním zkontrolovat demo/prázdný start, mobil/desktop, všechny volby, odkazy, podmíněné formuláře, validace, cestu do nabídky, změnu výběru, rekapitulaci, modelové dokončení, dialogy a kontrolní součty. Změna společné komponenty musí projít oběma produkty.| Kontrola | Očekávaný důkaz |
|---|---|
| 375/1440 px, demo i prázdný start u obou produktů | Screenshoty stejných rolí a průchod bez horizontálního přetečení; červené kickery, bílé zelené akce, modré titulky/ceny, bílá pole, šedá stránka, navy patička. |
| Navigace zpět a úprava nabídky | Všech 4 fází lze dosáhnout podle pravidel aplikace; po návratu z porovnání/údajů zůstane výběr a smysluplný fokus. |
| Formulář a validace | Prázdný start skutečně vyvolá chyby na požadovaných místech; podmíněná země, zaměstnání, různé role osob a jejich návrat fungují bez služby. |
| Nabídky | Travel zpřístupní všech 22 modelových variant, úraz všechny své modelové nabídky a volby krytí; jednotka ceny a zahrnuté krytí jsou srozumitelně pojmenované. |
| Dialog a mobilní klávesnice | Otevření, Escape/zavření, návrat fokusu, scroll, spodní panel a tlačítko v bezpečné oblasti na 375 px; žádný dialog nepřekryje jedinou možnost dokončení. |
| Modelové dokončení | Na platebním kroku i potvrzení je simulace čitelná; žádný text netvrdí uskutečněné odeslání/platbu/smlouvu; při síťovém bloku zůstává průchod kompletní. |
#00b53b zůstat přesná ve všech hlavních tlačítkách, nebo lze zvolit tmavší zelený odstín při zachování bílého textu? Aktuální dvojice má výpočtový kontrast 2,74 : 1. Rozhodnutí patří k přístupnosti, ne k obecné změně palety.Meze: posudek vychází z lokálních zdrojů a dostupných Chrome snímků. Není to fyzický telefon, Safari, uživatelský test, odborná kontrola pojistných produktů ani ověření skutečné integrace. Staré měření WordPressu není použité jako dnešní autorita pro hodnoty stylu.
Rozsah: Pojmy, účinky akcí, kontakty, modelové přísliby a oddělení veřejného obsahu od soukromého průchodu.
Datum: 2. 11. 2026. Odborná role: seniorní marketingový a obsahový analytik. Zadaný model / úsilí: GPT-6.1 Sol / xhigh. Rozsah: travel 0.21.2 a úraz 0.14.1; návrh rozhodnutí a průběžně udržovatelných pravidel. Bez změn kalkulaček, nasazení, měření skutečných konverzí nebo právního posouzení.
Sjednotit způsob, jakým oba produkty vysvětlují zadání, výběr nabídky, vyplnění osob a dokončení. Zachovat vlastní produktové údaje a rozdílný obsah krytí. Nejbližší obsahovou prioritou je pravdivost modelového režimu, přesné názvy akcí a společná politika získávání kontaktů. Zvětšení podobnosti obrazovek samo o sobě nedokazuje vyšší konverzi ani lepší SEO.
Obě hero už mají dobrou společnou obsahovou kostru: červený název produktu, krátký příslib, vysvětlení, dvě výhody a formulář s konkrétní otázkou. Úrazové „Do života s jistotou“ a cestovní „Na dovolenou s klidem“ mohou zůstat rozdílné. Obsahový systém má sjednotit jejich role, délkové rozmezí a návaznost na formulář, nikoli přepsat oba produkty na jednu větu.
Za uzavřené zadání považuji červené malé nadpisy #F42534, bílé písmo zelených hlavních akcí, šedý základ stránky s bílými formuláři, patičku #003B71, společnou produktovou hlavičku a čtyři fáze. Nevkládat prezentační pruh ani návrat do galerie. Úplný místní průchod a ruční alternativy musí zůstat dostupné bez AI a API.
Přečteny AGENTS.md, README.md, PROJECT.md a aktuální HTML/JS obou vydání. Původní posudek cmp_uraz/reports/stylopis-wordpress-2026-10-28/gpt-6.1-sol.md sloužil k návaznosti metody: oddělovat fakta, návrhy a adaptace. Dřívější WordPress audit není novým měřením aktuálních kalkulaček ani autoritou pro jejich vzájemné textové sjednocení.
Vlastní reprodukovatelná inventura zdrojových textů a metadat obsahuje SHA-256 čtených souborů, řádky výskytu a počet lokálních nabídek. Vzniká skriptem source-copy-audit.py. Zdrojový text dokládá existenci řetězce nebo pravidla; sám nepotvrzuje jeho viditelnost v konkrétním stavu prohlížeče. Neověřuje živé sazby, obchodní oprávnění, platnost dokumentů, skutečné indexování Googlu ani doručování zpráv.
Doplněna nová společná evidence ze současného Chromu: 124 kontextů a osm úspěšných modelových dokončení, oba produkty × 375/1440 px × demo/prázdný start, bez zaznamenané chyby v tomto běhu. Jde o měření hlavního auditora; osobně jsem prohlédl nové snímky travel vstupu, výsledků, osob, rekapitulace, dokončení, úrazového vstupu, rekapitulace a dokončení. Úspěch automatického průchodu neověřuje porozumění textům ani pravdivost obchodních tvrzení. Mobil je viewport Chromu, nikoli test fyzického telefonu nebo Safari.
Aktuální SEO doporučení byla ověřena 2. 11. 2026 výhradně v primárních zdrojích Google Search Central. Právní správnost účelů kontaktování, souhlasů, zdravotních otázek, obmyšlených osob, slev a okamžiku vzniku pojištění musí ověřit příslušný vlastník a odborník. Níže jsou pouze jejich dopady na obsah a technické rozhraní.
V tabulce F znamená zdrojový fakt, N návrh a R rozhodnutí, které ještě není schválenou změnou UI. P1 řeší srozumitelnost závazku a dokončení; P2 systémovou konzistenci; P3 následné ověření.
| Priorita / stav | Důkaz v aktuálním vydání | Výklad a návrh |
|---|---|---|
| P1 · F/N | Úraz experience.js:12, .contact-profile; shared/ui.js:25–26 má povinný e-mail a nepovinný telefon. shared/core.js:138 blokuje první pokračování bez e-mailu. Travel index.html:177–180, #client-form, získává kontakty až po výběru nabídky a telefon je povinný. | Kontakty mají odlišné načasování i povinnost. Doporučuji pro oba nejprve cenu a volbu nabídky, potom údaje pro pokračování. Důvodem je srozumitelný vztah mezi požadovaným údajem a užitkem; z těchto podkladů nelze vyčíslit změnu odchodů. |
| P1 · F/N | Oba vstupy obsahují „Bez telefonního spamu“. Úraz .uraz-no-spam-note říká „Samotné porovnání…“, travel .no-spam-note „Samotná kalkulace…“. Travel .contact-purpose slibuje použití telefonu „pouze k důležitým informacím k této smlouvě a cestě“. | Negativní a obtížně ověřitelný slib nahradit přesným účelem a povinností údaje. Produkční formulaci lze potvrdit až podle skutečného procesu. Modelové testování potřebuje rovnou sdělit, že nic neodešle. |
| P1 · F/N | Viditelný výchozí travel seznam už správně používá „Vybrat“ (assets/app.js:543, renderTiles, potvrzuje snímek 083), stejně jako úraz (experience.js:22). Aktivní detail nabídky však generuje „Sjednat tuto variantu“ (app.js:578, [data-select-offer]), přesto po výběru následují osoby a rekapitulace. Zachované renderery řádků/matice mají také „Sjednat“, ale renderResults nyní volá jen dlaždice; jejich řetězce nejsou důkazem viditelného hlavního seznamu. | Sjednotit aktivní výběrové akce na „Vybrat nabídku“, případně krátké „Vybrat“ v jednoznačné kartě. Sloveso „sjednat“ vyhradit kroku s ověřeným skutečným účinkem. Při případném návratu jiných rendererů ověřit i jejich texty. |
| P1 · F/N | Travel index.html:188–196, [data-screen="email-navrh"], [data-screen="platba"], [data-screen="gopay"], [data-screen="potvrzeni"]: „Návrh jsme poslali“, GoPay, „Zaplatit“, „Pojištění je sjednáno“. site/preview-guard.js vypíná fetch a skutečné formulářové odeslání; app.js:1146–1151 dokončí simulaci časovačem. Úraz ferda-flow.js:97 končí „Vše je připravené“ a číslem návrhu. | Travel obsah v těchto stavech vzbuzuje očekávání skutečného úkonu. Označit místní platbu, e-maily a dokumenty v samotném stavu i akcích jako ukázkové. U obou produktů má konec výslovně sdělit, že smlouva nevznikla a zpráva nebyla odeslána. Použití značky brány ani modelová částka neprokazují integraci. |
| P1 · F/N | Travel index.html:43,144 uvádí „22 variant od 11 pojišťoven“. Vložený katalog skutečně má 22 variant a 11 skupin; viz vlastní inventura. app.js:562–564 mění počet výsledků podle zobrazených nabídek. | Počet je podložen pro lokální dataset, nikoli pro současnou nabídku trhu. V náhledu „Ukázkové srovnání 22 variant od 11 pojišťoven“. Ve výsledcích počet odvozovat z dostupných a filtrovaných dat. Do produkce nepřenášet číslo bez zdroje, definice rozsahu a vlastníka aktualizace. |
| P1 · F/N | Travel index.html:44–62,175,218–220 nabízí Alexe, popis cesty a vysvětlení rozdílů. innovation.js:203–229 vrací upravitelnou modelovou mapu bez analýzy; výsledek v index.html:127 už správně říká, že nejde o vyhodnocení popisu. index.html:124 přesto obsahuje „Analyzovaný plán cesty“. | Stejnou pravdivost promítnout i do pozvánek, názvů a stavů. Přímá cesta k mapě je správný vzor. Ke každé prezentované možnosti patří lokální ukázka nebo ruční alternativa, ne pouze vysvětlení chyby služby. Nenazývat předvyplněnou ukázku osobní analýzou. |
| P2 · F/N | Oba mají Kalkulace → Konfigurace → Údaje → Rekapitulace; úraz ferda-flow.js:8–9, travel travel-navigation.js:5–7. V travelu se stejné výsledky nazývají také „Výsledky“, „Porovnání“, „Nabídky“. | Čtyři společné fáze zachovat. Uvnitř používat „Nabídky“ pro seznam a „Porovnání nabídek“ pro srovnání vybraných variant. Případné přejmenování „Konfigurace“ na „Nabídky a krytí“ je samostatné R, protože obecný technický výraz popisuje úkol méně konkrétně. |
| P2 · F/N | Úraz hero „pro sebe i své blízké“, ale shared/core.js:138 validuje věk pojištěného 18–75; aktuální průchod má jednoho pojištěného. Travel má kategorie více cestujících a zvířata odděleně. | Hero může vyjádřit ochranu rodiny, nesmí bez vysvětlení slibovat právě nedostupný rodinný nebo dětský průchod. U úrazového formuláře stručně označit aktuálně podporovaný rozsah. Nesjednocovat počty a věkové kategorie mezi produkty mechanicky. |
| P2 · F/N | Travel index.html:196,208 uvádí 5% slevu za další sjednání a použití údajů z předchozí smlouvy. Úraz experience.js:36–38 odvozuje „Slevu“ z místního porovnání ročních nákladů a frekvence. | Nejde o jeden společný typ slevy. V ukázce výslovně označit modelové cenové zvýhodnění. Produkční promo potřebuje ověřené podmínky, platnost a rozsah; frekvenci zobrazovat spolu s celkovou roční cenou. „Měsíčně“ a „za celou cestu“ musí zůstat produktově odlišné jednotky. |
| P2 · F/N | shared/ui.js:5 úrazu má cleanText, který z textu odstraňuje výskyty slova „modelový“. | Potřebnou transparentnost nelze spolehlivě zajistit nahodilou větou, když obecný textový filtr odstraňuje označení režimu. Režim, příslib, účinek akce a zdroj ceny mají být explicitní obsahové položky, které takový filtr nepřepisuje. |
| Obrazovka / role | Společná kostra a hlavní akce | Produktová odlišnost, která má zůstat |
|---|---|---|
| Hero / zadání | Název produktu → užitek → vysvětlení → dvě ověřitelné výhody → otázka formuláře → hlavní další akce. | Úraz potřebuje věk a povolání; travel destinaci, termín, cestující a aktivity. Úraz „Vybrat krytí“, travel „Porovnat nabídky“ odpovídají různému nejbližšímu kroku a nemusí být totožné. |
| Nabídky a krytí | Kontext zadání → počet či rozsah výsledků → cena s jednotkou → rozhodující krytí a omezení → „Detail nabídky“, „Porovnat“, „Vybrat nabídku“. | Úraz skládá rizika a částky; travel vybírá varianty a cestovní připojištění. Vysvětlení ceny nesmí zamlčet doplněné nebo nedostupné krytí. |
| Údaje osob | Účel kroku → jasně rozlišený pojistník a pojištěný → formuláře → kontaktní účel → „Pokračovat na rekapitulaci“ nebo název dalšího podkroku. | Travel cestující, zvířata; úraz jiný pojistník, případné obmyšlené osoby a doplňující otázky. Pojistníka jednotně vysvětlit jako osobu, která pojištění sjednává. |
| Rekapitulace | Nabídka a celková cena → krytí → osoby → počátek/termín → dokumenty → jasná možnost úprav → popis následujícího účinku. | Úraz frekvence a první splátka; travel cena celé cesty, přesný termín a destinace. Není vhodné sjednotit obě ceny do neurčitého „Cena“. |
| Dokončení | Jednoznačný stav → co se stalo → co se nestalo v modelovém režimu → dokument/souhrn → další smysluplná akce. | Pořadí plateb a potvrzení musí v budoucí produkci vycházet ze skutečného ověřeného procesu. Současné oba modelové průchody mají přiznat stejný typ simulace. |
V každém kroku postačí jeden hlavní úkol. Produktový kicker je stále červený, ale nepřebírá roli hlavního nadpisu. Detailové modaly mají konkrétní název objektu a akci „Uložit změny“, pokud se změna ukládá; „Zavřít detail“, pokud se jen zavírá. „Hotovo“ lze ponechat u jednoduché volby, pouze když bezprostřední okolí jednoznačně vysvětluje účinek.
Jde o návrhy pro příští vydání, nikoli schválené produkční texty. Prototyp má působit jako hotový produkt, současně jasně pojmenovat místní simulaci u rozhodných úkonů. K tomu není potřeba verzovací nebo prezentační pruh.
| Situace | Úraz — navržená formulace | Travel — navržená formulace |
|---|---|---|
| Vstupní vysvětlení | „Zadejte věk a povolání. Potom si vyberete krytí a porovnáte nabídky.“ | „Vyberte destinaci, termín a cestující. Potom porovnáte nabídky pro svou cestu.“ |
| Modelová cena | „Ukázkové ceny pro zvolené krytí.“ | „Ukázkové ceny za celou cestu.“ |
| Výběr konkrétní varianty | „Vybrat nabídku“; pod výsledky „Údaje osob doplníte v dalším kroku.“ | Stejná akce i informace. |
| Ukázkový kontakt | „Pro test použijte ukázkové kontakty. Žádný e-mail ani zprávu neodešleme.“ | Stejná formulace u #client-form. |
| Budoucí produkční kontakt — pouze po ověření procesu | „E-mail pro dokumenty k pojištění.“ Telefon případně „Telefon (nepovinné)“ + přesný ověřený účel. | Stejné označení a stejná zásada účelu; případná odlišná povinnost musí mít potvrzený důvod. |
| Ruční alternativa | „Vyplnit údaje ručně“ / „Použít ukázkové údaje“. | „Vyplnit cestu ve formuláři“ / „Otevřít ukázkovou mapu rizik“. |
| Vysvětlení bez AI | „Prohlédnout vysvětlení krytí“. | „Prohlédnout ukázku vysvětlení rozdílů“ a dostupné „Porovnat vedle sebe“. |
| Rekapitulace | „Zkontrolujte krytí, osoby a první splátku.“ Hlavní akce „Vyzkoušet platbu“. | „Zkontrolujte cestu, osoby a cenu za celou cestu.“ Hlavní akce „Vyzkoušet platbu“. |
| Platební simulace | „Dokončit ukázkovou platbu“; „Žádné peníze se nepřevádějí.“ | Stejně; případná maketa brány „Ukázka platební brány“. |
| Konec | „Ukázka je dokončená. Smlouva nevznikla a žádný e-mail jsme neodeslali.“ „Zobrazit ukázkový návrh“. | Stejný stav; „Zobrazit ukázkovou smlouvu“, „Prohlédnout ukázku e-mailu“, „Otevřít Moje cesta“. |
Zvažoval bych také nahradit metaforu „DNA cesty“ vysvětlujícím názvem „Plán a aktivity cesty“. Metaforu lze ponechat jako doprovodné označení po vysvětlení. Nemá být jediným názvem vstupu, který musí člověk pochopit bez znalosti návrhu.
A — doporučená společná varianta: zadání a porovnání bez kontaktů; e-mail a případný telefon ve fázi Údaje. Výhodou je přímá vazba na následující úkon. Nevýhodou je pozdější možnost kontaktovat člověka, který nedokončil výběr; tento obchodní důsledek je potřeba posoudit podle skutečných pravidel služby. V modelovém režimu zůstávají validační stavy kontaktů testovatelné a nic se neodesílá.
B — zachovaný dřívější kontakt u úrazu: použít jen s potvrzeným obchodním důvodem. Vysvětlit konkrétní účel, povinnost a možnost pokračování. Samostatnou volitelnou akci typu „Poslat přehled nabídek“ v náhledu nahradit „Prohlédnout ukázku e-mailu“. Nesmí vzniknout skryté očekávání zpětného hovoru pod obecným slibem „bez spamu“.
Rozhodnutí A/B se má posuzovat jako obsahová a produktová politika napříč oběma produkty. Bez výzkumu nelze tvrdit, že A zlepší konverzi nebo že B přinese kvalitnější kontakty. Před produkční změnou je nutné ověřit účely, texty a technické zacházení s údaji; tento report nepřisuzuje žádné variantě právní soulad.
Současný doložený stav: travel HTML má noindex,nofollow (index.html:9); úraz HTML tento tag nemá a jeho description slibuje online sjednání (index.html:6). V obou čtených HTML není canonical. Čerstvá veřejná HTTP kontrola potvrdila pro oba aktuální vstupy HTTP 200 a byte shodu s místními soubory; ani jedna odpověď neobsahovala X-Robots-Tag. Kořenový https://devel.kingux.cz/robots.txt vrátil 404. V těchto ověřených odpovědích tedy chybí společný indexační zákaz pro úraz, zatímco travel jej má v HTML. To nedokazuje aktuální indexaci úrazu; Search Console a skutečný stav indexu nebyly prověřeny. Chybějící robots.txt není sám o sobě technická chyba webu. Absence marketingové description u úmyslně neindexovaného travel náhledu není prioritní SEO závada.
Pro veřejné prototypy doporučuji jednotnou explicitní politiku neindexování v HTML nebo HTTP hlavičce, také pro publikované modelové dokumenty podle typu souboru. Google musí pravidlo noindex obdržet: samotné blokování URL v robots.txt mu jeho přečtení může znemožnit. Google podporuje X-Robots-Tag také pro PDF. Nejde o požadavek změnit současný server během tohoto auditu. Google Search Central: blokování indexování.
Pro budoucí produkci doporučuji následující rozdělení:
| Vrstva | Obsah a cíl | Navržená politika |
|---|---|---|
| Veřejná produktová vstupní stránka | Komu pojištění slouží, podstatné krytí a omezení, jak porovnání funguje, ověřitelný provozovatel a odborně revidovaný obsah. Jedna jasná cesta do kalkulace. | Kandidát pro indexaci; vlastní produktový title, odpovídající hlavní nadpis a věcná description. Nevkládat osobní nebo individuální údaje do metadat. |
| Zadání a individuální nabídky | Pomáhají člověku provést úkol. Jejich hlavním cílem je průchod a srozumitelné rozhodnutí. | Politiku indexace zvolit explicitně. Pro individuální dynamické výsledky doporučuji noindex, nepřidávat SEO text mezi pole jen kvůli délce. |
| Osoby, rekapitulace, platby, osobní dokumenty | Soukromé údaje a konkrétní stav rozpracování. | Nepovažovat za veřejné SEO vstupy. U produkce ověřit řízení přístupu k datům a dokumentům; noindex je doplňková indexační politika. |
| Místní a devel ukázky | Ověření vzhledu a chování na modelových datech. | Stejná politika noindex pro oba produkty; nepřenášet ji omylem na indexovatelný produkční marketingový obsah. |
Toto rozdělení je návrh architektury, nikoli tvrzení o nezbytném konkrétním routování Ferdy. Ochrana soukromého obsahu vyžaduje řízení přístupu; noindex nebrání přímému otevření URL. Google výslovně rozlišuje heslem chráněný soukromý obsah a veřejně navštívitelný neindexovaný obsah. Google Search Central: řízení sdíleného obsahu.
Produkční veřejné vstupy mohou mít například title „Úrazové pojištění – porovnání krytí | České pojištění“ a „Cestovní pojištění – porovnání nabídek | České pojištění“, pokud přesně odpovídají skutečné službě. Krokové titulky prohlížeče mohou být „Údaje pojištěného | Úrazové pojištění“ a „Rekapitulace | Cestovní pojištění“. Jde o orientaci v kartách a historii i u neindexovaných kroků. Google doporučuje popisné, stručné titulky a jasný hlavní titul; negarantuje zobrazení přesného textu v hledání. Google Search Central: titulky výsledků.
Description má věcně shrnout veřejný produktový vstup a neslibovat neověřenou nejnižší cenu, úplný trh ani vyřízené sjednání. Google může použít jiný výňatek a délku upravuje podle zařízení; nepředepisuji univerzální limit znaků jako podmínku SEO. Google Search Central: výňatky a descriptions.
Současné hashové obrazovky jsou přijatelné pro neindexovaný prototyp; není důvod přestavovat jejich routování jen kvůli SEO. Pokud mají být někdy samostatné veřejné obsahové stránky dohledatelné, Google pro různé obsahy doporučuje skutečné URL s History API a procházené odkazy, nikoli závislost na fragmentu. Počáteční noindex nelze pro veřejnou SEO landing spolehlivě „vypnout až JavaScriptem“, protože Google může vykreslení přeskočit. Google Search Central: JavaScript SEO.
Důvěryhodnost obsahu pojištění má stát na ověřených zdrojích, skutečném rozsahu porovnání, identitě provozovatele, datu odborné revize a pravdivých cenových podmínkách. Nejde o mechanické přidání odznaků ani číselného „E-E-A-T skóre“. Google doporučuje užitečný, spolehlivý obsah a doložitelnou odbornost; neudává preferovaný počet slov. Google Search Central: obsah pro lidi.
Úrazový ferda-flow.js:47–63 už obsahuje explicitně modelový adaptér toFerdaDraft, requiresCodebookMapping:true, illustrativeQuestionnaire a seznam neprovedených integrací: číselníky a adresy, mapování rizik, zdravotní otázky, serverová validace, Offer/dokumenty a platba. To je důkaz vědomé přípravy datového rozhraní, nikoli hotové kompatibility se současnou produkční Ferdou. Travel má lokální stav a vypnuté služby. Aktuální produkční schéma ani dohoda o integraci se tímto auditem nepotvrzují.
Doporučuji připravit slovník obsahových klíčů podle účinku: offer.select, people.continue, review.continue, payment.simulate, completion.demo, doplněný režimem demo/production a produktovou variantou. Konkrétní technický formát může zvolit implementátor. Text konečného stavu musí odpovídat potvrzenému výsledku služby; stav „odesláno“, „zaplaceno“ nebo „sjednáno“ nesmí vznikat pouze přechodem na další obrazovku. Chyba posouzení, změna ceny či nedostupná integrace mají svůj text i možnost návratu. Modelová varianta zůstane plně průchozí pro vizuální a validační testy.
| ID | Pravidlo | Akceptační kontrola |
|---|---|---|
| COPY-01 | Stejná role akce používá stejný pojem v obou produktech; její text předpovídá nejbližší účinek. | Ve všech pohledech nabídek „Vybrat nabídku“ vede na další krok; „Porovnat“ pouze na srovnání; finální akce odpovídá výsledku. |
| COPY-02 | Kicker pojmenovává produkt nebo sekci; hlavní nadpis úkol; podnadpis potřebné vysvětlení. | V každém viditelném kroku je rozpoznatelný hlavní úkol. Malé nadpisy mají #F42534 i v detailu, chybě a mobilu. |
| COPY-03 | Cena vždy obsahuje jednotku, období a srozumitelný součet. | Úraz první splátka + frekvence + roční součet; travel cena celé cesty + rozsah osob a připojištění. |
| COPY-04 | Modelový režim nepředstírá skutečné doručení, úhradu, smlouvu nebo individuální AI posouzení. | V dokončení, e-mailu, platbě, mapě i dokumentu je lokální ukázka jasná; obecné textové filtry označení neodstraní. |
| COPY-05 | Kontakt se žádá s vysvětleným účelem a zřetelnou povinností. | Oba prázdné starty ověří zvolenou politiku A/B; nepovinný telefon lze přeskočit; povinné pole má potvrzený důvod. |
| COPY-06 | Každé obchodní číslo a příslib má vlastníka, rozsah, zdroj a datum platnosti. | Počet nabídek souhlasí s datasetem/filtry; modelové slevy jsou označené; žádný nepodložený slib o celém trhu nebo cenové výhodnosti. |
| COPY-07 | AI a jiné služby jsou volitelné rozšíření místní ukázky. | Každou prezentovanou možnost lze prohlédnout bez sítě nebo ručně dokončit; chybová zpráva nevede do slepé větve. |
| SEO-01 | Prostředí a role stránky určují indexaci předem. | V každém novém vydání zkontrolovat původní HTML a HTTP X-Robots-Tag; u PDF ověřit příslušné hlavičky; u produkční landing nesmí zůstat demo noindex. Aktuální travel má zákaz v HTML, úraz v ověřeném HTML ani hlavičce nikoli. |
| SEO-02 | Soukromé údaje a dokumenty se chrání přístupem, nikoli názvem URL nebo noindex. | V budoucím propojení ověřit cizí relaci, odhlášení, přímou URL a dokument; výsledek evidovat technicky. Právní posouzení samostatně. |
| SEO-03 | Veřejný obsah má vlastní stručný title, skutečný účel a ověřené podklady. | Metadata a hlavní obsah odpovídají; žádná jména osob, čísla smluv či soukromé údaje v title/description. |
U každého pravidla vést produkt, aktuální stav (návrh/schváleno/zavedeno/ověřeno), vlastníka, zdroj rozhodnutí, cílové vydání a odkaz na konkrétní důkaz. Zjištění v jednom snímku není potvrzením všech větví. Pravidla se mají měnit podle rozhodnutí a skutečných průchodů, nikoli podle neověřených odhadů konverzí.
V příští obsahové iteraci ověřit na obou produktech desktop a mobil, ukázkový i prázdný start, seznam/detail/porovnání, návrat k editaci, chyby kontaktů a dat, modelovou platbu a dokončení. Zachovat test skutečných formulářových polí; předvyplnění není důkaz validace.
S lidmi ověřit zejména tyto otázky: Co se stane po „Vybrat nabídku“? Kdy je potřeba kontakt a proč? Poznáte cenu za celé období? Co právě vzniklo po dokončení? Považujete mapu za analýzu svého textu, nebo za ukázku? Použít stejná zadání pro úraz a travel a sledovat správnost porozumění, samostatné dokončení a důvody návratů; konkrétní velikost vzorku zvolit podle účelu výzkumu.
V případné budoucí produkční analytice oddělit začátek, platné zadání, zobrazení ceny, výběr nabídky, dokončení údajů, zahájení platby a serverem potvrzený výsledek. Do událostí neposílat texty zdravotních otázek, volný popis cesty ani osobní údaje; konkrétní nastavení sběru a souhlasů je nutné ověřit. A/B porovnání kontaktů má předem definovat hlavní metriku, potřebný vzorek a kontrolní ukazatele kvality. Tento audit žádný konverzní nárůst, SEO skóre ani předpověď výkonu neprokazuje.
Rozsah: Sémantické tokeny, kontrakty komponent, klávesnice, kontrast a hranice budoucího adaptéru Ferdy.
Datum: 2. 11. 2026. Rozsah: statické zdroje travel site/versions/travel-0.21.2 a úraz releases/uraz/ferda-0.14.1, s historickým integračním podkladem D:/devel/_prototypes/cmp_uraz/site/ferda/IMPLEMENTACE.md z 21. 10. Metodika staršího WordPress reportu je pouze historickým východiskem. Nejde o implementaci UI ani audit aktuální produkční Ferdy, úplný test přístupnosti nebo důkaz shody WCAG. Kde není uvedeno živé měření, jde o čtení kódu, výpočet z deklarovaných barev a doporučení k ověření.
Sdílet významové role, rozměry a kontrakty formulářů a interakcí; produktové otázky, kalkulaci, karty rizik, varianty dokumentů a kroky ponechat jako samostatné konfigurace. Zachovat schválené #F42534 malé nadpisy, bílé písmo na zelených hlavních akcích, šedou stránku s bílými formuláři, patičku #003B71, cestovní produktovou hlavičku a čtyři fáze, bez prezentačního pruhu a odkazu na rozcestník. Zajistit celou místní průchodnost bez AI/API a bez skutečného odeslání, platby a sjednání. Červený a zelený kontrast má otevřený rozpor s požadavky čitelnosti; tichá změna preference není schválená.
| Role / metrika | Výchozí společná specifikace | Stav a produktová volnost |
|---|---|---|
accent.section | #F42534, malé sekční nadpisy | Stabilní zákaz modrého přebarvení; kontrast dle následující tabulky vyžaduje rozhodnutí. Nezaměňovat s chybou. |
action.primary, action.onPrimary | zelená #00B53B, bílá; hover #009B33 | Podle travel-refinement.css; prověřit také počítané stavy úrazu. Zachovat barvy jako zadání, neprohlašovat za kontrastně vyhovující. |
surface.page, surface.form | #F2F4F7, #FFFFFF | Ověřit dědičnost průhledných vnořených ploch i vybrané/neaktivní stavy; pod formulářem nesmí zmizet vyznačení stavu. |
text.primary, heading, heading.card | #231F20, #003B71, #002E5F | Rozdělit role, nikoli přepsat všechny modré jedním hexem; #03407C pro sekční nadpis je stávající samostatná role. |
footer.surface, footer.text | #003B71, bílá | Potvrzená preferovaná role. Odkaz a fokus potřebují i jiné rozlišení než barvu. |
| Typografie | Montserrat; tělo 16 px desktop; nadpis kroku 32/26 px, hero 48/34 px | Navrhovaný výchozí základ podle travel; produkt může mít odůvodněnou odchylku. Mobilní tělo travelu je nyní 14 px, nikoli 16 px. Testovat zvětšení textu a délky překladů. |
| Rozměry | jednotná škála 4/8/12/16/24/32 px, radius prvku 8 px, karty 15 px | Návrh pro nové komponenty; existující pozorované hodnoty nejsou důkazem jednotného systému. Cíl dotyku 44 × 44 CSS px; WCAG 2.2 AA uvádí minimum 24 × 24 s výjimkami, neplošnou povinnost 44 px. |
| Fokus, výběr, chyba, disabled | samostatné role kontrastu a obrysu, textový význam, žádná závislost jen na barvě | Hodnoty nejsou ještě schválené. Měřit proti skutečnému sousednímu pozadí v každém stavu, včetně sticky prvků a high-contrast režimu. |
Výpočet dle WCAG 2.2, relativní luminance a kontrast: normalizovaná složka c = sRGB/255, lineární c/12,92 pro c ≤ 0,04045, jinak ((c+0,055)/1,055)^2,4; luminance L = 0,2126R + 0,7152G + 0,0722B; poměr (Lsvětlejší+0,05)/(Ltmavší+0,05). Následující výsledek je pro jednolité deklarované barvy, nikoli automatický verdikt všech vykreslení.
| Text | Podklad | Poměr | Posouzení vůči SC 1.4.3 |
|---|---|---|---|
#F42534 | #FFFFFF | 4,069:1 | Běžný informativní text pod 4,5:1; velký text nad 3:1. |
#F42534 | #F2F4F7 | 3,693:1 | Stejný závěr, nižší rezerva. |
#FFFFFF | #00B53B | 2,737:1 | Pod 4,5:1 i 3:1. |
#FFFFFF | #009B33 | 3,661:1 | Pod 4,5:1; velký text nad 3:1. |
#FFFFFF | #003B71 | 11,266:1 | Nad 4,5:1. |
WCAG 2.2 SC 1.4.3 požaduje pro běžný text 4,5:1 a pro velký text 3:1; existují výjimky například pro čistě dekorativní a neaktivní obsah. Kicker nesmí být automaticky prohlášen za dekorativní, pokud nese význam. Na rozhodnutí předložit varianty: zachovat přesný vzhled s výslovně evidovaným rozporem, nebo hledat způsob splnění při zachování schválených barevných hodnot a významu; konkrétní změnu posoudit s uživatelem. Netvrdit úplnou shodu WCAG ani ji neodvozovat z jediné dvojice barev. Netextový kontrast má samostatná pravidla 3:1 pro potřebné hranice a stavy.
| Oblast | Travel 0.21.2 | Úraz 0.14.1 | Doporučená smlouva / ověření |
|---|---|---|---|
| Kaskáda | index.html:6,13–15: navigation → app → innovation → iteration → refinement → countries → accents. travel-refinement.css nastavuje .eyebrow,.step-kicker na modrou. | index.html:9–11 načítá základ, řadu produktových a prezentačních vrstev, WordPress, header, unified, accents; uraz-unified.css nastavuje hero eyebrow na modrou. | section-accents.css je finální vrstva a používá široký !important pro více názvů, např. .selected-summary__label a .results-toolbar__label. V nové verzi nejdříve katalogizovat role podle skutečného významu, prověřit počítaný styl pro všechny stavy; poté definovat vlastníka a prioritu každé vrstvy. Není bezpečné prostě změnit --blue: přímé barvy a specifičnost mohou zůstat vítězi. |
| Plochy | travel-refinement.css: white cards a page #F2F4F7. | uraz-unified.css: bílé mnohé plochy i všechna input,select,textarea. | Prověřit, zda široký selector nepotlačuje výběr, disabled a validaci; vždy porovnat výsledné styly, ne pouze hodnoty tokenů. |
| Výběr destinace | index.html:66–79 používá fieldset/legend, nativní radio a podmíněný <select>; travel-countries.js:16–38 přepíná hidden/disabled/required a při volbě jiné země přesune fokus do selectu. | Volby frekvence v experience.js a dotazníku v ferda-flow.js také používají nativní fieldset/radio. | Jiná země: při průchodu radii šipkami může fokus okamžitě opustit skupinu; ručně ověřit klávesnicí a se čtečkou. aria-expanded na radiu přezkoumat proti WAI-ARIA roli radio; není vhodné předpokládat její podporu. Po návratu zachovat hodnotu i označení, skryté pole nedělat povinným. |
| Chyby | app.js:916–925 kontroluje required, přidá is-invalid, zaměří první neplatné; country select má aria-describedby pouze na hint, viz index.html:78. | shared/ui.js:16 a shared/refinement.js:23 tvoří aria-invalid a vazbu na text chyby. | Dodat stabilní ID a napojení viditelné chyby i u country selectu, test validace, opravy a opakovaného submitu; nerozšiřovat to tvrzením o všech polích bez testu. Povinné a podmíněné pole musí mít čitelný štítek, pomoc a stejnou informaci pro AT. |
| Dialog a návrat | app.js obsahuje vlastní vrstvy; jejich úplný focus management není tímto statickým čtením ověřen. | shared/app.js:53–65 pamatuje kontext, otevírá nativní dialog, releasePriceContext() obnovuje jméno; ferda-flow.js:102–107,147 otevírá dialog osoby, zaostří vstup a obnovuje fokus dle datového atributu. | Název, počáteční fokus, Tab/Shift+Tab, Escape, Zrušit beze změn, Uložit, návrat na existující spouštěč a fallback po překreslení nebo odstranění jsou nutné testovací případy. Nativní dialog je dobrý základ, sám nedokazuje správný workflow. W3C APG dialog. |
| Záložky a kroky | index.html:54–64 tablist/tab/tabpanel; iteration.js:21–33 doplňuje šipky, Home a End. | ferda-flow.js:64–67 generuje fáze a aria-current=step. | Testovat selected, focus, vazby a skrytý obsah při změně; APG tabs. Produkty mohou mít vlastní podkroky, společná je sémantika průběhu a návratu. |
| Mobil a čitelnost | travel-refinement.css má mobilní body 14 px a 34px hero; země travel-countries.css:2 min. výška 56 px. | uraz-unified.css má 34px hero a mobilní jednosloupcové formuláře; experience.css obsahuje i popisky 10–12 px. | Nevyvozovat splnění celé stránky z min-height jednotlivých prvků. Prověřit 320/375/768 px, 200% zvětšení, orientaci, překryv sticky ovládání a skutečné cíle na dotyk včetně rozestupů. Malé pomocné texty posoudit na reálném zařízení. WCAG cíl 24 px a výjimky. |
id, label, hodnota, povinnost, nápověda, podmínka zobrazení a chyba; výstupem sémanticky spojené label, aria-describedby, aria-invalid pouze při chybě; oprava chybu odstraní, podmíněný skrytý obsah není validován. Složená otázka používá fieldset/legend, nativní radio nebo checkbox a dostupný textový výběr. Serverová a klientská validace zůstávají oddělené a musí se při skutečné integraci sladit.aria-current, povolené návraty a explicitně řízený návrat na rekapitulaci. Při přechodu fokus na smysluplný nadpis/kontext a oznámení změny; neztratit neuloženou práci. Popis cesty a mapa rizik mají přímou offline alternativu.Historický podklad IMPLEMENTACE.md výslovně popisuje pouze samostatnou statickou ukázku a čtecí audit z 21. 10. 2026. Ověřené v tomto podkladu jsou historické identity 130/132/142, čtyři desktopové fáze u zkoumané varianty a samostatné události Calc/Buy/Order; 132 a 142 nejsou totožné produkty. Prototypové CMPFerda.toFerdaDraft je vzor hranice UI, ne ověřený request ani záruka současného schématu. Historický dokument uvádí nutnost mapování číselníků, rizik, skutečných produktových atributů a serverové validace; dokumenty a platba tehdy integrovány nebyly.
P0 před návrhem skutečného adaptéru: znovu ověřit aktuální vlastníky, existující formulářové definice a životní cyklus stavu přímo u odpovědných zdrojů; doplnit smlouvu dat a chyb, dostupné integrační prostředí a odpovědnost za validaci. P1: mapování konkrétních produktů, verzování vstupů, invalidace odvozených výsledků, návaznost dokumentů a zabezpečená správa stavu. P2: sjednotit prezentační vrstvu a automatizované kontraktní testy bez nahrazování produktové logiky. Neznáme aktuální endpointy, auth, právní či provozní pravidla ani současné produkční brány; nic z toho tento report nedokazuje. Modelový průchod zůstává oddělený a funkční i při nedostupnosti budoucí integrace.
Založit společný verzovaný katalog: primitives → semantic roles → shared components → product adapters → explicit exceptions; u každé role evidovat vlastníka, příklady použití, zakázaná použití, stavy, kontrast, zdroj a datum rozhodnutí. Stanovit review změny tokenu napříč produkty a zpětnou kompatibilitu; odchylka má jméno produktu, důvod, trvání a ověřovací případ. Každá nová kalkulačka přidá příklady validního/nevalidního/dlouhého textu a offline větve, ne novou kopii stejné komponenty. Vydané adresáře a ZIPy zůstanou neměnné; změna se skládá reprodukovatelně jako nová verze.
Přejímka každé změny: obě verze startu, všechny fáze a větve, volby, nabídky, úprava/rekapitulace, offline bez AI/API; chybové a opravené formuláře; klávesnice, viditelný fokus, pořadí, dialog včetně návratu a kontrola čtečkou; mobil a zoom; kontrast skutečných barev ve stavech; porovnání vypočtených stylů a screenshotů na reprezentativních obrazovkách; ověřit modelová potvrzení bez skutečných vedlejších účinků. WCAG 2.2 je soubor více kritérií a vyžaduje samostatný úplný audit, nikoli pouze tyto kontroly.
Doplněna vlastní izolovaná kontrola v lokálním headless Chrome nad file:// kopií portal/site, na šířkách 375 a 1440 CSS px, s blokací síťových požadavků; místní HTTP bylo v tomto sandboxu nepřístupné. Porovnané index.html a hlavní app.js obou produktů jsou byte shodné s posuzovanými vydáními; nebyl takto porovnán každý soubor portálu. Důkazy a opakovatelný skript: `keyboard.json`, `keyboard.cjs`, snímky country-arrow-*, travel-dialog-* a uraz-dialog-* v téže složce. Jde o výběrovou kontrolu, ne test se čtečkou ani na fyzickém telefonu.
document.activeElement hlášen BODY, nikoliv konkrétní ovládací prvek stránky; samotné toto měření nedokazuje, že se aktivoval podklad. Ověřit fyzicky oběma směry a ve více prohlížečích, včetně interakce se čtečkou.#009B33, úrazové bílou na #00B53B. Na 375 px emulovaný hover travelu vykázal rgb(0,180,59), tedy nemá smysl přisuzovat mobilnímu dotyku desktopový hover. Fokus travelu měl 3px solid rgba(244,36,52,.35), úraz 3px solid #002E5F; hodnoty je nutné porovnat s konkrétním sousedním pozadím a nesměšovat s výsledkem kontrastu textu. Volání hover a focus probíhala postupně na stejném prvku, takže kombinované stavy závisejí i na kurzoru.Nezávisle na výše popsaném selektivním klávesnicovém testu proběhlo čerstvé měření lokálně v Chrome přes HTTP: `measurements.json` obsahuje 124 zachycených kontextů, výsledky osmi modelových průchodů (oba produkty × dva starty × 375/1440 px) a 22 snímků. Jde o evidence pro tyto scénáře a rozměry, nikoli o úplné pokrytí kombinací nebo produkční Ferdu. Položka primary v měřicím skriptu zahrnuje také některé navigační či druhotné prvky, takže její count nelze interpretovat jako počet hlavních CTA. Barvy zaznamenané během CSS animace neslouží jako ustálené tokeny.
| Konkrétní prvek | Travel | Úraz | Rozhodovací dopad |
|---|---|---|---|
| Hero H1 při 1440 / 375 px | 48 / 34 px, váha 600 | 48 / 34 px, váha 600 | Hodnota je už sjednocená; line-height a letter-spacing nejsou úplně totožné. |
| Pracovní H1 na obrazovce údajů při 1440 / 375 px | 32 / 26 px, váha 600 | 32 / 26 px, váha 600 | Zachovat jako společný výchozí pár, pokud projde schválením specifikace. |
| Datum na vstupu na 375 px | #trip-date-from, #trip-date-to: text 12 px, radius 7 px, výška 48 px | #profile-age: 16 px, radius 8 px, výška 48 px; nejde o shodný typ vstupu | Nesjednocovat pouze vnější výšku: cestovní datum má podstatně menší text. Ověřit fyzickou čitelnost a případné chování nativního date inputu na jednotlivých platformách. |
| Jméno v údajích na 375 px | #client-form [name=firstName]: 14 px, radius 7 px, výška 48 px | #person-first: 16 px, radius 8 px, výška 48 px | Doporučení k rozhodnutí: jednotných 16 px a radius 8 px pro nový společný Field; není to dosavadní shoda ani již schválená změna. |
| Datum a jméno travel při 1440 px | Změřené příklady 16 px, radius 7 px | Změřené úrazové příklady 16 px, radius 8 px | Nesjednocený mobilní obsah a rozdílný radius přetrvávají i přes podobný desktop. |
MUST – návrh závazného minima: sémantické role tokenů a jejich vlastník; schválené uživatelské preference barev a layoutu včetně zdokumentovaného kontrastního rozporu; plné offline větve a zákaz skutečného odesílání, plateb a sjednání v modelu; označení polí, vazby chyb a náprava; nativní sémantika skupin a dostupná klávesnice; viditelný fokus, přístupná jména a návrat z dialogu; stavově oddělené koncepty návrh/potvrzení; reprodukovatelné nové vydání a zachování starších. Platnost konkrétních barevných preferencí a offline hranic již plyne ze zadání; formalizace ostatních položek jako společné katalogové smlouvy je návrh.
SHOULD – doporučení ke schválení: jednotný Field 16 px / radius 8 px / minimálně 48 px výšky; doporučený cíl dotyku 44 × 44 px; škála rozestupů 4/8/12/16/24/32; stávající velikosti hero 48/34 a pracovního H1 32/26; produktové výjimky s důvodem a revizí; test klávesnice, reflow a čteček napříč prohlížeči; oddělené produktové adaptéry. Jde o produktová doporučení, nikoli univerzální tvrzení, že WCAG vyžaduje uvedené hodnoty. Výjimky mají zůstat zdokumentované a hodnocené proti konkrétním kritériím; změny současných vydání nejsou tímto posudkem provedeny.