Slovník pojmů
Přístupnost webu
Přístupný web není zvláštní varianta pro malou skupinu lidí. Je to rozhraní, které dává obsah a ovládání smysl i bez myši, při zvětšení textu, s asistivní technologií nebo v nestandardních podmínkách.
Stručná definice
Použitelný web předává význam a stav více než jedním způsobem.
Přístupnost neznamená jen technickou validitu ani pouze kontrast barev. Začíná sémantickým HTML: skutečný odkaz naviguje, button provádí akci, nadpisy popisují hierarchii a label pojmenovává formulářové pole. Díky tomu prohlížeč a pomocné technologie rozumějí obsahu bez toho, aby vývojář vše znovu ručně popisoval.
Dále jde o ovladatelnost. Uživatel musí dosáhnout funkcí klávesnicí, vidět focus, rozumět chybě formuláře a zjistit, že se po asynchronní akci změnil obsah. WCAG shrnuje čtyři užitečné principy: obsah má být vnímatelný, ovladatelný, srozumitelný a robustní. Konkrétní řešení ale vždy vyžaduje ověření v daném rozhraní.
Jaký problém řeší
Odstraňuje bariéry, které vznikají při běžném používání webu.
Lidé nepracují všichni stejným zrakem, sluchem, pohybem, jazykem ani technologií. Přístupnost podporuje i uživatele se dočasným omezením, pomalým připojením nebo malou obrazovkou.
- navigace, vyhledávání a čtení obsahu pomocí klávesnice nebo čtečky obrazovky
- formuláře objednávky, přihlášení a administrace se srozumitelnými popisky a chybami
- dynamické komponenty, jako jsou dialogy, našeptávače, filtry a notifikace
- obsah použitelný při zvětšení textu, vysokém kontrastu či omezeném pohybu
- e-commerce a interní systémy, kde je důležité správně dokončit akci, ne jen zobrazit stránku
Praktický příklad
Nativní tlačítko a oznámený stav namísto imitace ovládání
Nativní button lze automaticky ovládat tabulátorem, Enterem a mezerou. Po úspěšném načtení výsledků se informační oblast s role=status oznámí čtečce obrazovky; samotný text se nastavuje přes textContent, nikoli vkládáním nedůvěryhodného HTML. Pokud by šlo o dialog, bylo by navíc nutné řídit přesun i návrat focusu.
ARIA zde doplňuje informaci o měnícím se stavu. Nenahrazuje však tlačítko atributem role="button" na divu. Jestliže existuje vhodný nativní prvek, přednost má jeho skutečné chování, sémantika i kompatibilita.
HTML a JavaScript
<button type="button" id="load-orders">Načíst objednávky</button>
<p id="orders-status" role="status" aria-live="polite"></p>
<script>
document.querySelector('#load-orders').addEventListener('click', () => {
document.querySelector('#orders-status').textContent = 'Objednávky byly načteny.';
});
</script>
Jak funguje
Cesta uživatele: struktura → ovládání → zpětná vazba
Tento jednoduchý tok je textovou alternativou diagramu přístupného rozhraní. Každý krok musí fungovat bez závislosti na samotném vzhledu.
- Obsah má strukturu HTML určí hlavní obsah, navigaci, nadpisy, odkazy a formulářové prvky. Čtečka obrazovky pak může nabízet orientaci podle landmarků a nadpisů.
- Uživatel dosáhne ovládání Klávesa Tab prochází prvky v logickém pořadí. Aktivní prvek má zřetelný focus a akci lze provést bez přesného pohybu myší.
- Rozhraní sdělí stav Chyba, načítání, úspěch a změna obsahu nejsou předané jen barvou nebo animací. Potřebují srozumitelný text a někdy vhodné oznámení.
- Dynamická část zachová kontext Po navigaci SPA se aktualizuje název stránky, hlavní nadpis a podle potřeby focus. Dialog po zavření vrací focus na prvek, který jej otevřel.
- Scénář se otestuje Automatický audit zachytí část technických chyb. Ruční test tabulátorem, se zvětšením a ideálně s uživateli ověří, zda dává celek skutečně smysl.
Důležité související pojmy
Sémantika, focus a informace o stavu jsou základní stavební kameny.
Jednotlivá opatření se doplňují. Kontrast bez klávesnice ani ARIA bez smysluplného chování nevytvoří použitelnou komponentu.
Sémantické HTML
Nativní nav, main, h1, a, button, form, label a input předávají roli a očekávané chování. Před vlastním widgetem má být vždy otázka, zda ho neumí vhodný HTML prvek.
Klávesnice a focus
Focus ukazuje, kde se uživatel nachází. Nemá se odstranit bez stejné nebo lepší náhrady. Po otevření modalu, navigaci nebo chybě je třeba určit, kam se focus přesune.
Čtečka obrazovky
Čtečka pracuje se sémantikou a přístupnostním stromem, nikoli s pouhou vizuální podobou. Smysluplné názvy, nadpisy, labely a textové chyby jsou proto důležitější než dekorativní ARIA.
Kontrast a více kanálů
Barva nesmí být jediným nositelem chyby, stavu nebo instrukce. Text, ikona s popisem a vhodný kontrast pomáhají různým uživatelům i při horším displeji.
WCAG a testy
WCAG poskytuje ověřitelná kritéria a principy vnímatelnosti, ovladatelnosti, srozumitelnosti a robustnosti. Automatizace je užitečná, ale nezjistí například zda popisek dává v kontextu smysl.
Vztah k podobným pojmům
Přístupnost je širší než validní kód nebo mobilní layout.
Pojmy se překrývají, ale nemají stejný cíl ani stejný způsob ověření.
- Přístupnost a responzivita
- Responzivita upravuje rozhraní podle prostoru a podmínek zobrazení. Přístupnost navíc řeší sémantiku, klávesnici, čtečky obrazovky, kontrast a srozumitelnost.
- Přístupnost a použitelnost
- Použitelnost hodnotí, jak snadno lidé plní své cíle. Přístupnost zajišťuje, aby bariéra nevyloučila část uživatelů; obě disciplíny se často vzájemně posilují.
- Sémantické HTML a ARIA
- ARIA doplňuje informaci, pokud nativní HTML nestačí. Nevhodné ARIA může správné chování zhoršit, proto se nativní element preferuje před vlastním rolovaným divem.
- Automatický audit a uživatelský test
- Audit najde chybějící atribut nebo nízký kontrast. Neověří však spolehlivě textovou srozumitelnost, smysl pořadí, klávesovou cestu a reálný pracovní postup.
Výhody a omezení
Přístupnost rozšiřuje kvalitu rozhraní, ale vyžaduje průběžnou péči.
Přínosy
- více lidí dokáže dokončit stejný úkol bez speciální podpory
- sémantická struktura zlepšuje údržbu, testovatelnost a často i orientaci v obsahu
- klávesový focus, textové chyby a jasné stavy pomáhají i zkušeným uživatelům
- průběžné testování odhalí regresi dříve než jednorázová kontrola před vydáním
Rizika a časté chyby
- odstraněný focus outline bez funkční náhrady
- klikací div, odkaz bez href nebo vlastní widget bez klávesového chování
- informace předaná jen barvou, ikonou či rychlou animací
- modal bez přesunu a návratu focusu nebo dynamický obsah bez oznámení
- spoléhání na automatický audit jako na důkaz úplné přístupnosti
Praktické použití
Přístupný dialog s formulářem potřebuje víc než hezký vzhled.
Představme si modal pro úpravu doručovací adresy. Otevře jej skutečné tlačítko, dialog má viditelný název a při otevření přijme focus. Dokud je otevřený, klávesová navigace zůstává v relevantním obsahu; Escape ho může zavřít a po zavření se focus vrátí na původní tlačítko. Formulář uvnitř používá labely a při neplatném odeslání sdělí chybu textem propojeným s konkrétním polem.
Tohle chování se neověří jen pohledem na screenshot. Je potřeba projít dialog tabulátorem, vyzkoušet čtečku obrazovky a sledovat, zda se uživatel po chybě neztratí. Pokud stejnou akci provádí SPA bez reloadu, aplikace má ještě odpovědnost oznámit změnu a zachovat orientaci po klientské navigaci.
Na co myslet
Přístupnost patří do definice hotové funkce.
Pravidelná malá kontrola při tvorbě komponent stojí méně než oprava celé aplikace po dokončení.
- začít nativním HTML a ARIA přidávat jen tehdy, když nativní sémantika nestačí
- ověřit úplné ovládání klávesnicí, viditelný focus, Escape a návrat focusu u dialogů
- propojit formulářová pole s labely, nápovědou a chybami; informace nepředávat jen barvou
- testovat zoom, responzivní layout, omezený pohyb a dynamické aktualizace obsahu
- kombinovat automatické kontroly s ručním testem a podle možností s lidmi používajícími asistivní technologie
Časté otázky
Přístupnost webu v praxi
Stačí mít validní HTML?
Ne. Validita pomáhá odhalit část chyb, ale nezaručí logickou hierarchii, popisky, dostatečný kontrast, klávesovou cestu ani srozumitelnou zpětnou vazbu po akci.
Mám na všechno používat ARIA?
Ne. Pokud existuje vhodný nativní HTML prvek, obvykle poskytuje lepší chování i sémantiku. ARIA má doplňovat specifické informace nebo vlastní widget, jehož chování také sami plně implementujete.
Je automatický audit dostatečný?
Není. Je výborný pro opakovanou technickou kontrolu, ale nepozná všechny problémy s kontextem, pořadím, smyslem textu nebo skutečnou ovladatelností komplexního toku.
Týká se přístupnost jen nevidomých uživatelů?
Ne. Pomáhá také lidem s omezenou motorikou, sluchovým či kognitivním omezením, dočasným zraněním, malým displejem, zvětšeným textem nebo neobvyklým vstupním zařízením.
Jak vytvářím webové rozhraní v praxi
Použitelnost ověřuji na celé cestě, ne jen na jednotlivé komponentě.
Při vývoji webových aplikací řeším sémantiku, formuláře, dynamické stavy i rozvržení tak, aby rozhraní zůstalo srozumitelné při běžném i alternativním ovládání.