Přístupnost webu: proč má myslet na každého uživatele
Přístupný web umožní člověku zjistit, co potřebuje, a dokončit úkol bez zbytečné cizí pomoci. Nestačí čitelná titulní stránka ani vysoké skóre automatického testu. Ověřte celou poptávku, rezervaci nebo nákup, včetně chyb a potvrzení. Začněte nejdůležitější cestou, opravte bariéry v jejím zdroji a stejný postup zařaďte do každé významné změny webu.
Představte si zákazníka, který vybere službu, vyplní údaje a nedokáže potvrdit objednávku, protože poslední tlačítko funguje jen myší. Pro firmu je to nedokončený obchod. Pro člověka je to překážka v samostatném používání služby. Přístupnost neřeší pouze vzhled. Týká se struktury, ovládání, jazyka, médií i způsobu, jakým web oznamuje změny.
Tento průvodce je určen majitelům firem, správcům webů a týmům, které přebírají práci dodavatele. Obsahuje návrh ruční kontroly i modelový příklad oprav. Nejde o výsledek auditu konkrétního webu. Technické a právní podklady jsme ověřili 28. října 2026; právní působnost je potřeba posoudit podle skutečně poskytované služby.
01Začněte samostatností zákazníka, ne zvláštní verzí webu
Někteří lidé používají čtečku obrazovky, jiní zvětšení, klávesnici, hlasové ovládání nebo kombinaci pomůcek. Stejný člověk může potřebovat jiné nastavení na telefonu a na počítači. Není užitečné navrhovat jednu domnělou „typickou osobu s postižením“. Popište konkrétní úkol a zjistěte, které možnosti jeho dokončení rozhraní nabízí.
Přehledné nadpisy, srozumitelné chyby a dostatečně velké ovládací prvky mohou pomoci i člověku s dočasně omezenou pohyblivostí nebo ve složitém prostředí. Tyto přínosy však nenahrazují potřeby lidí se zdravotním postižením. Návštěvník by neměl nejdřív vysvětlovat své omezení, aby se dostal k ceně, termínu nebo potvrzení.
Obchodní přínos posuzujte podle skutečných dokončených úkolů a podnětů zákazníků. Neslibujte předem určité zvýšení konverzí. Mapa zákaznické cesty pomůže určit důležité kroky; kontrola přístupnosti k nim doplní otázku, zda je člověk zvládne různými způsoby ovládání. Telefonická pomoc je užitečná podpora, ale není omluvou pro neopravovaný formulář.
02Oddělte technický standard od právní povinnosti
WCAG je technický standard s ověřitelnými kritérii a úrovněmi A, AA a AAA. Pro nový projekt má smysl výslovně sjednat například WCAG 2.2 na úrovni AA, rozsah stránek a způsob ověření. Tato projektová volba sama neurčuje, jaký právní režim na firmu dopadá. V zadání potřebujete obě odpovědi.
V Česku zákon č. 424/2023 Sb. upravuje vybrané výrobky a služby, včetně služeb elektronického obchodování poskytovaných spotřebitelům. Není to plošný příkaz pro každý firemní web. Zákon obsahuje výjimku pro služby poskytované mikropodnikem. Nezaměňujte ji za obecné osvobození všech malých firem či výrobků; nejprve ověřte zákonnou působnost a podmínky konkrétního provozovatele.
Weby povinných subjektů veřejného sektoru mají vlastní režim, který vysvětluje Digitální a informační agentura. U přeshraničního prodeje prověřte příslušnou národní úpravu. Výsledek technického testu proto označujte přesně: jakou verzi standardu, úroveň, stránky a stavy pokryl. Výrok „web splňuje zákon“ potřebuje širší podklad než zelený výsledek skeneru.
03Vyberte stránky, stavy a celé procesy
Pro první pracovní kontrolu sepište hlavní úkoly: najít vhodnou službu, zjistit podmínky, odeslat poptávku, objednat a případně upravit nebo zrušit rezervaci. U každého určete začátek a ověřitelné dokončení. Důležitý je i příchod z vyhledávače rovnou na detail, nikoli pouze procházení od úvodní stránky.
Vzorek by měl zahrnout rozdílné šablony a společné prvky: menu, vyhledávání, cookie dialog, formulář, zákaznický účet i vloženou platbu. Přidejte prázdný výsledek, chybu, načítání a potvrzení. Pět téměř totožných článků neprověří rezervační kalendář. U každého testu zaznamenejte zařízení, prohlížeč, případnou asistivní technologii a datum.
Rozlišujte rychlé hledání bariér a úplné posouzení shody. Omezený vzorek je dobrý začátek plánování, ne důkaz bezchybnosti všech stránek. Dodavateli dejte dostupné testovací účty a data bez skutečných osobních údajů. Objednávky a platby zkoušejte v určeném testovacím prostředí, aby kontrola nevytvářela skutečné závazky.
04Srozumitelná struktura pomáhá najít správné místo
W3C doporučuje smysluplnou strukturu a logicky uspořádané nadpisy. Vzhled velkého tučného písma sám nenahrazuje nadpis v HTML. Podobně seznam nemá být pouze několik řádků oddělených pomlčkami. Člověk používající čtečku může procházet nadpisy a oblasti stránky, aniž by postupně poslouchal každý opakovaný odkaz.
Nadpis „Podmínky vrácení“ pomůže více než neurčité „Další informace“. Odkaz má dávat smysl ve svém kontextu a tlačítko má popsat akci. Pokud máte několik karet se stejným „Více“, zajistěte rozlišení jejich účelu také pro asistivní technologie. Nevyplňujte přístupné názvy klíčovými slovy určenými vyhledávačům.
Pište instrukce v pořadí, v jakém je člověk potřebuje. Vysvětlete odborné výrazy, u ceny uveďte podmínky a neodkazujte výhradně na polohu či barvu: „použijte zelené tlačítko vpravo“ nemusí pomoci. Redakční kontrola má zahrnout také jazyk stránky, názvy dokumentů a to, zda důležité informace nezůstaly jen ve staženém souboru.
05Klávesnice musí projít celou cestou
Ovládání klávesnicí je základní požadavek pro běžné webové funkce. Odložte myš a zkuste otevřít menu, vybrat variantu, změnit množství a odeslat formulář. Tab a Shift+Tab obvykle přesouvají fokus, další klávesy se řídí typem prvku. Vlastní komponenta potřebuje promyšlené ovládání, ne náhodnou sadu zkratek.
Fokus je aktuální místo ovládání. Musí být rozpoznatelný a jeho pořadí má odpovídat úkolu. Kontrolujte také pevnou hlavičku a cookie lištu: kritérium Focus Not Obscured na úrovni AA vyžaduje, aby prvek s fokusem nebyl obsahem vytvořeným autorem úplně zakrytý. Prakticky je lepší udržet viditelný celý ovládací prvek.
Z vloženého kalendáře či jiné komponenty musí existovat ovladatelná cesta ven. Klávesnicová past není totéž jako správně fungující modální dialog, který fokus dočasně drží uvnitř a jde zavřít. Při opravě začněte nativními HTML prvky. Přepsaný vzhled odkazu na tlačítko ještě nemění jeho chování ani význam.
06Ověřte kontrast, zvětšení a velikost ovládání
Neposuzujte čitelnost jen na velkém monitoru v ideálním osvětlení. Zkontrolujte skutečné barvy textu a pozadí, aktivní stav i chybové hlášky. Světle šedý text, který na návrhu působí jemně, může být obtížně čitelný. Barva navíc nemá nést důležitou informaci sama; chybu označte také textem a vazbou na příslušné pole.
| Kontrola | Technický orientační bod | Co udělat na webu |
|---|---|---|
| Textový kontrast | WCAG AA: běžný text 4,5 : 1, velký text 3 : 1; existují výjimky. | Změřit konkrétní kombinace, nejen hlavní odstavec. |
| Zvětšení textu | Zvětšení na 200 % bez ztráty obsahu a funkce, s výjimkami kritéria. | Zkusit menu, pole i dlouhé chybové zprávy. |
| Přeskupení obsahu | U svisle posouvaného obsahu šířka 320 CSS px; výjimky pro nutné dvourozměrné části. | Ověřit, že běžný text nevyžaduje posouvání do stran. |
| Dotykový cíl | WCAG 2.2 AA: 24 × 24 CSS px nebo splnění příslušné výjimky. | Zkontrolovat malé ikony a odstupy mezi ovladači. |
Hodnoty jsou technická minima v daném kontextu, nikoli cíl pohodlného návrhu. Zvětšení zkoušejte i v mezikrocích. U široké datové tabulky může být posouvání do stran odůvodněné, ale okolní formulář by tím neměl přestat fungovat. Kontrola důležitých ikon a stavů navíc zahrnuje samostatná pravidla pro netextový kontrast.
07Formulář musí vysvětlit chybu a zachovat práci
Každé pole potřebuje srozumitelný název, který je s ním programově spojený. Návod W3C k popiskům vysvětluje, proč samotný placeholder nestačí. Po začátku psaní může zmizet a jeho vztah k poli nemusí být dostatečný. Povinné údaje a požadovaný formát vysvětlete před odesláním, ne teprve po neúspěchu.
Chyba „Neplatná hodnota“ nutí člověka hádat. U konkrétního pole napište, co je špatně a jak to opravit; u delšího formuláře pomůže přehled chyb s odkazy. Zpětná vazba k formuláři má být dostupná i čtečce. Zachovejte už vyplněné správné údaje a po úspěchu jednoznačně potvrďte, co se stalo a co bude následovat.
Přihlášení patří do stejné kontroly. Neblokujte bezdůvodně vložení hesla ani správce hesel. Přístupné ověřování podle WCAG 2.2 pracuje také s podporou uživatele a alternativami ke kognitivním testům. Změnu ověřte společně s bezpečnostním návrhem: zjednodušení obsluhy neznamená vypnutí kontroly identity. Zkoušejte také chybný kód a návrat k opravě.
08Obrázky, video a dokumenty nesmějí uzavřít informace
Alternativní text popisuje účel obrázku v konkrétním místě. Rozhodovací strom W3C pro alt odlišuje informativní, funkční a dekorativní obrázky. Dekorace může mít prázdný alt. Schéma potřebuje dostupné vysvětlení, ne jen „infografika“. U grafu zpřístupněte důležitý závěr a hodnoty také textem nebo tabulkou.
U videa řešte ovládání přehrávače, titulky a podle obsahu také popis důležitých vizuálních informací. Průvodce přístupnými médii pomáhá rozlišit tyto potřeby. Automaticky vytvořené titulky před zveřejněním opravte, zejména názvy, čísla a odborné pojmy. Přepis je užitečný, ale jeho existence sama neřeší každou potřebu videa.
Podmínky služby ani návod neschovávejte pouze do obrázku nebo naskenovaného PDF. Pro dokument si vyžádejte vlastní kontrolu struktury a čitelnosti. Při pravidelné tvorbě obsahu spojte tato pravidla s přípravou obrázků a médií pro web. Redaktor musí vědět, jaký podklad dodat a kde vysvětlit význam, který samotná fotografie nepředá.
09Dialogy a změny obsahu potřebují předvídatelné chování
Po otevření modálního dialogu má být jasné, kde člověk je a jak ho zavře. Vzor dialogu W3C APG popisuje práci s fokusem uvnitř okna a návrat po zavření. Zkoušejte skutečný cookie panel, přihlášení i výběr termínu. Vizuální překrytí stránky bez odpovídajícího chování může ponechat klávesnici v neviditelném pozadí.
Po přidání zboží do košíku nestačí na okamžik změnit malé číslo v rohu. Stavové zprávy mají být programově dostupné asistivním technologiím bez zbytečného přesouvání fokusu. Oznamujte důležitý výsledek přiměřeně; nepřerušujte člověka při každém napsaném znaku. Test musí zahrnout úspěch, prázdný výsledek i selhání požadavku.
U animace, automaticky se měnícího obsahu a časového omezení posuďte, zda návštěvník potřebuje možnost zastavení nebo více času. Nezavádějte pohyb, který nenese užitečnou informaci. Každá knihovna, chatbot a vložený rezervační systém rozšiřují rozsah kontroly. Logo externího dodavatele není důkazem, že jeho část funguje s vaším webem přístupně.
10Ruční kontrolu postavte na konkrétním úkolu
Automatický nástroj pomůže opakovaně hledat část chyb. W3C ale výslovně uvádí, že samotný nástroj shodu neurčí. Praktický test proto začněte například zadáním „najděte službu, zjistěte podmínky a odešlete testovací poptávku“. Poznamenejte, kde se cesta zastaví, jaké informace chybějí a jak lze závadu zopakovat.
- Projděte úkol jen klávesnicí, včetně otevření a zavření všech potřebných oken.
- Zvětšete text a stránku. Ověřte, že nezmizela tlačítka, instrukce ani potvrzení.
- S člověkem zkušeným ve čtečce ověřte orientaci, názvy prvků, hodnoty a změny stavu.
- Vyvolejte chybu, opravte ji a ověřte, že už zadané údaje zůstaly zachované.
- Zaznamenejte konkrétní kroky, očekávané chování, skutečný výsledek a prostředí.
- Po opravě zopakujte stejný scénář i související cestu se společnou komponentou.
Čtečka obrazovky není pouze předčítání celého dokumentu od začátku. Zkušený tester používá nadpisy, seznamy prvků i různé režimy ovládání. Krátký pokus začátečníka může problém objevit, ale nerozliší spolehlivě všechny chyby webu od nezkušenosti s nástrojem. Domluvte reprezentativní kombinace zařízení a asistivních technologií a zapojte skutečné uživatele.
11Opravy řaďte podle bariéry a ověřitelného výsledku
Následující příklad je modelový. Firma nabízí konzultaci přes formulář. Kontrola našla tři různé překážky a jednu opakovanou chybu. Nejde o měření klientského webu ani univerzální pořadí závad. Priorita závisí na tom, zda člověk úkol vůbec dokončí, jak rozšířená chyba je a zda existuje použitelná cesta bez ní.
| Modelová závada | Dopad na úkol | Podmínka převzetí opravy |
|---|---|---|
| Termín lze vybrat pouze myší | Člověk ovládající web klávesnicí nemůže pokračovat. | Vybere, změní a potvrdí termín klávesnicí. |
| Chyba po odeslání není oznámena | Uživatel čtečky neví, proč žádost neodešla. | Najde chybu, její pole i návod k opravě. |
| Při zvětšení zmizí potvrzovací tlačítko | Dokončení se stává nedostupné. | Tlačítko zůstane dostupné v kontrolovaných velikostech. |
| Stejný nepojmenovaný ovladač je ve více šablonách | Oprava jedné stránky by nechala ostatní bariéry. | Změna sdílené komponenty projde ověřením ve všech dotčených místech. |
Každé položce přiřaďte vlastníka, dotčené stránky a důkaz. Formulace „vylepšit accessibility“ není přebíratelný úkol. U opakovaného prvku opravte zdroj v komponentě nebo redakční šabloně. Počet odstraněných varování sledujte pomocně; důležitější je, zda dříve zablokovaný člověk může provést požadovanou akci.
12Přístupnost potřebuje vlastníka i po spuštění
Při předání vyžadujte popis ověřeného rozsahu, známých bariér, použitého standardu a provedených ručních testů. Určete, kdo schvaluje nové komponenty a kdo reaguje na hlášení uživatelů. Kontakt pro nahlášení problému musí být sám dostupný. Připomínku přijměte bez požadavku, aby člověk veřejně sděloval diagnózu nebo další nepotřebné osobní údaje.
Doplňkový panel pro změnu písma či barev může mít konkrétní funkci, ale jeho instalace sama neprokazuje přístupnost. Nevyřeší automaticky nepochopitelný proces, nevhodný popis fotografie nebo chybné chování vlastního kalendáře. Požadujte důkaz na původně nefunkčním úkolu a průběžně opravujte zdrojový obsah i implementaci, nikoli pouze viditelný příznak.
Zařaďte kontrolu do pravidelné péče o web: po změně formuláře, menu, cookie lišty nebo externí integrace znovu projděte související scénář. Redakci dejte krátké příklady správných nadpisů, odkazů a popisů médií. Přístupnost se udržuje konkrétní prací, kterou lze přidělit, ověřit a předat dalšímu člověku.
13Časté otázky
Musí být přístupný úplně každý firemní web?
Právní povinnost závisí na působnosti příslušného předpisu, druhu služby a provozovateli. Zákon č. 424/2023 Sb. není plošným pravidlem pro všechny weby. Přístupnost však můžete stanovit jako požadavek kvality i tam, kde konkrétní zákonná povinnost nevzniká.
Stačí splnit WCAG 2.2 AA?
Je to přesné technické zadání, pokud určíte rozsah a způsob ověření. Samotná shoda ale neodpoví na všechny právní otázky a standard nepokrývá každou individuální potřebu. Kombinujte ověřování kritérií s testováním důležitých úkolů a zpětnou vazbou skutečných uživatelů.
Znamená skóre 100 v automatickém testu bezbariérový web?
Ne. Nástroj vyhodnocuje jen to, co umí zkontrolovat. Nemusí poznat smysluplnost textu, vhodnost alternativního popisu nebo to, zda člověk dokončí složitý proces. Výsledek používejte jako dílčí podklad vedle ruční kontroly, nikoli jako certifikát celého webu.
Vyřeší přístupnost doplněk s ikonou v rohu?
Samotná instalace neprokazuje výsledek. Ověřte konkrétní funkce a jejich soužití s asistivními technologiemi. Neovladatelný formulář nebo chybějící význam obsahu potřebuje opravu v návrhu, kódu či redakci. Za výsledek odpovídá proces správy webu, ne vzhled ikony.
Můžeme vše zkontrolovat sami bez čtečky obrazovky?
Zvládnete užitečný první průchod klávesnicí, zvětšením a kontrolou obsahu. Ten však nepokrývá práci s asistivními technologiemi ani úplnou shodu. Pro složitější web přizvěte zkušeného testera a uživatele s relevantními potřebami; přesně uveďte, co vaše vlastní kontrola ověřila.
Musí mít každý obrázek vyplněný dlouhý alt?
Ne. Dekorativní obrázek může mít prázdný alt, funkční obrázek potřebuje pojmenovat účel a informační obrázek sdělit podstatný význam. Složitý graf často vyžaduje také dostupné podrobnosti vedle něj. Délku volte podle potřebného sdělení, ne podle povinné kvóty slov.
Jak často máme přístupnost znovu kontrolovat?
Určete pravidelný režim podle velikosti a změn webu, ale důležité scénáře kontrolujte také po zásahu do jejich součástí. Nový kalendář nebo platební modul nemusí čekat na výroční audit. Každá oprava má mít opakovaný test a známé bariéry jasného vlastníka.
14Zdroje a hranice tohoto průvodce
Technická doporučení vycházejí z WCAG 2.2 a navázaných návodů W3C WAI. Pro první orientaci poslouží Easy Checks, pro organizaci testu také zapojení uživatelů do projektu. Odkazy u jednotlivých tvrzení rozlišují normativní kritéria, vysvětlující dokumentaci a právní zdroje.
Popsaný kontrolní postup, rozdělení odpovědnosti a modelová tabulka oprav jsou redakční doporučení. Článek neobsahuje vlastní statistiku bariér, klientské výsledky ani potvrzení shody konkrétního webu. Při přebírání projektu si vyžádejte důkazy odpovídající jeho skutečnému rozsahu a cílovým uživatelům.