Webová přístupnost podle WCAG: standardy a implementace inkluzivních webů

Proč je webová přístupnost (WCAG) strategická, nikoli jen „hezká věc“

Webová přístupnost zajišťuje, aby digitální produkty mohli využívat všichni lidé bez ohledu na jejich schopnosti, používaná zařízení či kontext. Z podnikatelského hlediska přináší přístupnost lepší SEO, vyšší konverze, snížené náklady na podporu, právní jistotu a pozitivní vnímání značky. Z inženýrského pohledu vede k čistšímu kódu, konzistentnějšímu designu a lepší testovatelnosti. Standardem, podle kterého se řídí praxe i regulace, jsou WCAG (Web Content Accessibility Guidelines).

Stručný přehled WCAG: verze, úrovně a rozsah

Verze – aktuální rodina norem je řada 2.x. WCAG 2.2 rozšiřuje 2.1 (např. o kritéria pro drag&drop, ověřování a konzistentní nápovědu). WCAG 3 je ve stadiu návrhu.
Úrovně shody – A (minimum), AA (doporučená pro většinu webů a často požadovaná regulací), AAA (rozšířená přístupnost, ne vždy prakticky dosažitelná všude).
Rozsah – týká se obsahu (HTML, PDF, multimédia), komponent (UI prvky, widgety), interakcí (průběh formulářů, ovládání klávesnicí) i stavů (focus, chyby).

Čtyři principy WCAG (POUR): východiska pro design a vývoj

Vnímatelné (Perceivable) – informace musí být prezentovány způsobem, který uživatel vnímá (textové alternativy, kontrast, titulky).
Ovládatelné (Operable) – uživatelské rozhraní musí být ovladatelné různými způsoby (klávesnice, bez časového stresu, předvídatelná navigace).
Srozumitelné (Understandable) – obsah i ovládání musí být jednoznačné, konzistentní a odpouštět chyby.
Robustní (Robust) – kód musí být kompatibilní s asistivními technologiemi (AT) dnes i v budoucnu (validní značkování, ARIA).

Klíčová kritéria WCAG 2.2, která ovlivňují UX a kód

1.1.1 Textová alternativa (A) – smysluplný alt atribut u netextových prvků; dekorativní obrázky s alt="".
1.3.1 Informace a vztahy (A) – použijte strukturální značky (<h1–h6>, seznamy, tabulky), ne pouze vizuálně simulované titulky.
1.4.3 Kontrast (AA) – text vůči pozadí minimálně 4,5:1 (běžný text), 3:1 (velký text); 1.4.11 kontrast UI prvků.
2.1.1 Klávesnice (A) – vše ovladatelné bez myši; žádné „keyboard traps“.
2.4.3 Pořadí focusu (A) – logické pořadí tabulace odpovídající vizuálnímu toku; 2.4.7 Viditelný focus (AA) – focus nesmí mizet.
2.5.7 Tažení gesty (AA) – úkoly musí být řešitelné i bez drag&drop (alternativní tlačítka „Posunout nahoru/dolů“).
3.2.6 Konzistentní nápověda (A) – stejné vzory nápovědy na obdobných stránkách.
3.3.1 Identifikace chyby (A) a 3.3.3 Nápověda při chybách (AA) – konkrétní popis chyby, propojení s příslušným polem, doporučení nápravy.
3.3.7 Redundance zadávání (A) – nevyžadovat opakované zadávání dat; nabídnout předvyplnění, historii vstupů.
3.3.8 Přístupné ověřování (AA) – autentizace nesmí vyžadovat pouze kognitivní úkoly (např. rozpoznávání obrázků bez alternativního textu).
4.1.2 Název, role, hodnota (A) – komponenty musí mít sémantický název, roli a stav čitelné pro asistivní technologie; 4.1.3 Stavové zprávy (AA) – programově oznamované změny.

Semantika, role a ARIA: jak „mluvit“ s asistivními technologiemi

Preferujte nativní HTML – tlačítka, odkazy, nadpisy, seznamy. ARIA je doplněk, nikoli náhrada za špatnou semantiku.
Podpora rolí a stavů – u widgetů (accordion, dialog, záložky) užívejte správné role a atributy aria-expanded, aria-controls, aria-selected.
Živé oblasti (ARIA live) – oznamování asynchronních změn (aria-live="polite") například u výsledků vyhledávání nebo košíku.
Popisky (Labeling) – každé ovladatelné pole musí mít programově čitelný popisek (<label for="">, aria-label, aria-labelledby).

Klávesnice a fokus: ovladatelnost bez myši

Pořadí TAB – odpovídá vizuální hierarchii, neobsahuje skryté pasti; u složitých komponent používejte Tab pro vstup a výstup a šipky pro vnitřní navigaci.
Viditelný focus – neodstraňujte outline; při úpravách dbejte na dostatečný kontrast a tloušťku.
Skip odkazy – „Přeskočit na hlavní obsah“ na začátku stránky, viditelný po získání focusu.
Správné zachycení a vrácení focusu – modální dialog vrací focus na vyvolávající prvek po zavření.

Barvy, kontrast a nescrollujte očima

Nespoléhejte pouze na barvu – chybová hláška by měla být doplněná ikonou nebo textem; stav tlačítek musí být doplněn vzorem či popisem.
Kontrast interaktivních prvků – hranice, text na tlačítkách, ikonky; zvažte kontrast focus ringů vůči pozadí.
Tmavý režim – kontrolujte kontrast i v dark mode; některé barvy nemusí splňovat požadovaný poměr.

Formuláře: validace, chyby a prevence frustrace

Jednoznačné popisky – label blízko polí, uvádějte příklady formátů (např. „+420 123 456 789“), nepoužívejte placeholder jako náhradu popisku.
Chybové hlášení u pole i souhrn – popis chyby u pole a shrnutí chyb nahoře stránky; programové označení atributy aria-invalid="true", aria-describedby.
Validace při ztrátě focusu – včasná a nepříliš agresivní; možnost opravy bez nutnosti resetovat formulář.
Ukládání stavu – automatické ukládání, varování před ztrátou dat při odchodu ze stránky.

Obrázky, multimédia a čas

Alt text – sděluje účel obrázku, ne zbytečné detaily; komplikované grafy mají dlouhý popis v textu nebo skrytém bloku.
Video – titulky (minimálně u mluveného slova), audiopopis pro klíčové vizuální informace, ovládání klávesnicí, možnost zastavení animací.
Animace a blikání – musí být vypínatelné, bez blikání rychlejšího než 3× za sekundu; respektujte systémové preference (prefers-reduced-motion).
Časové limity – možnost prodloužení nebo vypnutí; relogin bez ztráty stavu.

Tabulky, grafy a složitý obsah

Tabulky pro data – hlavičky sloupců či řádků označeny pomocí <th> s atributy scope či headers; nezneužívat tabulky pro layout.
Grafy – poskytnout datovou tabulku nebo alespoň textové shrnutí hlavního sdělení.
Interaktivní vizualizace – klávesová navigace, popisy a upozornění o změnách; používejte aria-live.

Single Page Applications (SPA) a dynamika rozhraní

Aktualizace role „document“ – po změně „stránky“ posuňte focus na hlavní nadpis a oznamte změnu názvu.
Správa regionů – landmarky (<main>, <nav>, <aside>, <header>, <footer>), aby asistivní technologie mohly rychle přeskakovat.
Stavy a oznámení – načítání, dokončení, chyby: musí být programově čitelné (aria-busy, role="status").

Mobilní a dotyková přístupnost

Velikost cíle – minimální aktivní plocha cca 44×44 CSS pixelů; dostatečné rozestupy, aby se prsty „nepřekrývaly“.
Gesta – alternativy k tahům a dlouhým stiskům (kritéria 2.5.7 a 2.5.8 – bez přesnosti a složitých gest).
Orientace – uživatelské rozhraní funguje v portrétu i landscape, pokud není objektivní důvod k odlišnému řešení.

Nástroje a proces testování přístupnosti

Automatizované skenery – zachytí přibližně 30–40 % problémů (např. linty, axe, Lighthouse). Není možné se na ně zcela spolehnout místo manuálního testování.
Manuální test klávesnicí – projděte klíčové scénáře s Tab, Shift+Tab, šipkami, Space/Enter a Esc.
Čtečky obrazovky – NVDA/JAWS (Windows), VoiceOver (macOS/iOS), TalkBack (Android). Ověřte pořadí, role a popisky.
Kontrastní měřiče – ověřte poměry přímo na reálném UI, nikoli pouze v designovém systému; věnujte pozornost barevným stavům.
Uživatelské testy – zapojte osoby s různými typy postižení a asistivními technologiemi; získejte kvalitativní vhled do bariér.

Design systémy a governance přístupnosti

Komponenty se zárukou – knihovna s dokumentovanými atributy „Name, Role, Value“, příklady ARIA, testy focusu a interakce.
Checklisty v CI/CD – automatické kontroly a11y lint, povinné checklisty pro pull requesty, kontrastní testy v pipeline.
Role a odpovědnosti – definujte vlastníka přístupnosti, postup pro hlášení bariér a roadmapu zlepšení.

PDF a další dokumenty

Tagované PDF – struktura, čitelné pořadí, alternativy pro obrázky, záložky, jazyk dokumentu.
Alternativní formát – pro klíčový obsah nabídněte HTML verzi nebo prostý text; PDF není jediná možná cesta.

Legislativní kontext a standardy v praxi

EN 301 549 – evropská norma pro přístupnost ICT, často odkazuje na WCAG 2.1/2.2 AA pro webové stránky a aplikace.
Veřejná správa – obvykle povinnost splnit úroveň AA; smluvní požadavky se promítají i na dodavatele.
Byznys – rostoucí očekávání trhu (RFP, ESG, brand); přístupnost snižuje právní rizika a rozšiřuje cílovou skupinu.

Typické antipatterny a jak se jim vyhnout

Div button – vizuálně vypadá jako tlačítko, ale nemá správnou roli ani ovladatelnost klávesnicí. Použijte element <button>.
Placeholder ≠ label – placeholder mizí při psaní a je méně vhodný pro paměť i asistivní technologie. Vždy používejte explicitní <label>.
Neviditelný focus – „čistý“ design nesmí skrýt orientaci uživatele.
„Vše v ARIA“ – ARIA nepřekrývá špatný HTML; raději použijte nativní elementy a jednoduché vzory.
Kontrast jen ve statickém stavu – i stavy jako hover, active a disabled musí mít dostatečný kontrast.

Praktické kroky implementace pro produktový tým

Discovery – stanovte cíle, uživatelské segmenty a regulační požadavky; vyberte metriky a rizikové scénáře.
Design – používejte designový systém s guidelines pro přístupnost; validujte kontrasty a stavy v designových nástrojích.
Vývoj – semantické HTML, „progressive enhancement“, testování na klávesnici jako první