Krátký, vyhraněný kontrolní seznam pro přístupná webová tlačítka

Problém s radami k přístupnosti tlačítek

Většina doporučení k přístupnosti tlačítek spadá do dvou táborů: buď jde o čtyřicetistránkový výklad WCAG, který nikdo nečte, nebo o vágní radu „udělejte tlačítka přístupná“ bez konkrétních kroků. Ani jedno nepomůže, když ve čtvrtek nasazujete novou funkci.

Tento kontrolní seznam pokrývá pět nejčastějších selhání přístupnosti tlačítek, která vídáme v produkci. Neudělá z vás experta na WCAG, ale zachytí problémy, které uživatele skutečně ovlivňují.

1. Pro tlačítka používejte element button

Pokud se něco chová jako tlačítko, mělo by to být element <button>. Ne <div> s onclick, ne <span> s role="button", ne <a> s href="#" a preventDefault.

Element <button> vám zdarma poskytne navigaci klávesnicí, správu fokusu i oznámení pro čtečky obrazovky. Když použijete <div>, budujete to všechno znovu od nuly — a uděláte v tom chybu.

Jediná výjimka: pokud akce přechází na novou stránku nebo mění URL, použijte element <a>. Odkazy a tlačítka mají odlišnou sémantiku. Uživatelé čteček obrazovky se pohybují podle typu elementu a očekávají, že tlačítka budou provádět akce a odkazy budou sloužit k navigaci.

2. Nastavte cílovou oblast alespoň 44×44 pixelů

WCAG 2.5.5 (Level AAA) vyžaduje, aby interaktivní prvky měly minimální cílovou velikost 44×44 CSS pixelů. Nejde o vizuální velikost — jde o oblast, na kterou lze kliknout.

Můžete mít malé vizuální tlačítko s dostatečným odsazením, nebo můžete cílovou oblast rozšířit pomocí pseudo-elementu. Důležité je, aby uživatel nemusel mířit přesně.

Mobilní uživatelé, lidé s motorickým omezením a kdokoli, kdo používá zařízení v pohybu, malé cíle mine. Ikonové tlačítko o velikosti 24×24 pixelů může vypadat čistě, ale z hlediska použitelnosti selhává.

3. Zajistěte viditelné stavy fokusu, které nejsou jen výchozí nastavení prohlížeče

Výchozí obrys fokusu v prohlížeči je lepší než nic, ale napříč prohlížeči je nekonzistentní a na některých pozadích často neviditelný. Potřebujete vlastní stav fokusu, který funguje ve vašem design systému.

Dobrý indikátor fokusu má tři vlastnosti:

• Vysoký kontrast: alespoň 3:1 vůči sousedním barvám
• Viditelné odsazení: není skrytý vlastním okrajem nebo pozadím tlačítka
• Konzistentní tvar: uživatelé by ho měli v celém rozhraní rozpoznat jako indikátor fokusu

Neodstraňujte outline: none, aniž byste ho nahradili něčím lepším. A nedělejte stavy fokusu tak nenápadné, že je za dokonalého osvětlení vidíte jen vy.

4. Pište popisky tlačítek, které dávají smysl i bez kontextu

Uživatelé čteček obrazovky se často pohybují tak, že přeskakují mezi tlačítky. Když to dělají, slyší seznam popisků tlačítek bez okolního kontextu.

Tlačítko označené „Zjistit více“ je v takovém seznamu k ničemu. Stejně tak „Klikněte zde“ nebo „Odeslat“. Popisek by měl popisovat akci: „Stáhnout kontrolní seznam přístupnosti“, „Odebírat aktualizace“, „Smazat tento komentář“.

Pokud váš návrh vyžaduje krátký vizuální popisek, použijte aria-label a poskytněte popisnou alternativu. Lepším řešením je ale psát popisky, které fungují pro všechny.

U tlačítek tvořených pouze ikonou je aria-label povinný. Tlačítko jen s ikonou lupy potřebuje aria-label="Search" nebo ekvivalentní text. Ikona není pro čtečky obrazovky přístupná.

5. Zajistěte dostatečný barevný kontrast

WCAG 2.1 vyžaduje kontrastní poměr alespoň 4.5:1 pro běžný text a 3:1 pro velký text (18pt nebo 14pt tučně). Popisky tlačítek jsou obvykle běžný text.

Světle šedý text na bílém tlačítku nevyhoví. Bledě modrá na světle modrém pozadí nevyhoví. Tyto kombinace mohou působit sofistikovaně, ale vylučují uživatele se slabým zrakem, barvoslepostí i kohokoli, kdo se na obrazovku dívá na ostrém slunci.

Používejte kontrolu kontrastu už během návrhu, ne až po spuštění. Oprava problémů s kontrastem v produkci je drahá, protože často vyžaduje změny v design systému.

Pokud pracujete s nástroji pro zpracování obrázků, zpracování na straně klienta může pomoci zachovat soukromí při generování přístupných vizuálních podkladů — zvlášť při testování barevných kombinací nebo generování náhledových stavů.

Co tento kontrolní seznam nepokrývá

Tento seznam je záměrně neúplný. Nepokrývá sémantiku zakázaných stavů, načítací stavy, ošetření chyb ani složité vzory tlačítek, jako jsou rozdělená tlačítka nebo spouštěče rozbalovacích nabídek. Tyto vzory potřebují vlastní doporučení.

Nepokrývá ani širší otázku, kdy použít tlačítko místo jiných interaktivních prvků. K tomu musíte rozumět sémantickému HTML a stromu přístupnosti — tématům, která si zaslouží vlastní články.

Pokrývá však snadno dosažitelné věci: chyby, které se objevují téměř v každé revizi kódu, ovlivňují nejvíce uživatelů a během vývoje se nejsnáze opravují.

Jak to začlenit do pracovního postupu

Kontrolní seznamy přístupnosti fungují jen tehdy, když jsou součástí vývojového procesu, ne když se přidají až dodatečně. Jak toho dosáhnout:

V návrhu: přidejte do designových souborů stavy fokusu a anotace cílové oblasti. Nenechávejte vývojáře, aby je hádali.

Při revizi kódu: kontrolujte elementy <button>, aria-label u ikonových tlačítek a CSS pro stav fokusu. To se dá rychle odhalit.

Při testování: projděte rozhraní klávesnicí pomocí tabulátoru. Pokud se k tlačítku nedostanete nebo nevidíte, kde je fokus, nedokážou to ani vaši uživatelé.

V dokumentaci: zahrňte požadavky na přístupnost tlačítek do knihovny komponent. Usnadněte udělat správnou věc víc než tu špatnou.

Pokud ladíte problémy v produkci, nástroje pro kontrolu HTTP hlaviček a přesměrování vám mohou pomoci pochopit, jak asistenční technologie interpretují vaše značkování — zvlášť při řešení správy fokusu po navigaci.

Cena za přeskočení této práce

Nepřístupná tlačítka neznamenají jen nesoulad s WCAG — rozbíjejí pracovní postupy. Uživatel, který nemůže kliknout na tlačítko pro odeslání, nemůže dokončit formulář. Uživatel, který nevidí stavy fokusu, nemůže navigovat klávesnicí. Uživatel, který nerozezná text tlačítka od pozadí, si popisek nepřečte.

Nejsou to okrajové případy. Přibližně 15 % světové populace má nějakou formu postižení a dočasná omezení (rozbitá myš, ostré slunce, dítě v náručí) nakonec ovlivní každého.

Dobrá zpráva je, že přístupnost tlačítek je z velké části vyřešený problém. Nemusíte vymýšlet nové vzory ani čekat na podporu prohlížečů. Stačí správně používat platformu a testovat svou práci.

Klíčové poznatky

• Používejte elementy <button> pro tlačítka a elementy <a> pro navigaci — sémantický rozdíl je pro asistenční technologie důležitý
• Zajistěte, aby cílové oblasti měly alespoň 44×44 CSS pixelů a vyhovovaly lidem s motorickým omezením i mobilním uživatelům
• Poskytněte viditelné, vysoce kontrastní stavy fokusu, které fungují napříč vaším design systémem
• Pište popisky tlačítek, které dávají smysl při čtení samostatně, a pro tlačítka pouze s ikonou používejte aria-label
• Kontrolujte barevný kontrast během návrhu, ne až po spuštění, abyste se vyhnuli drahým dodatečným úpravám

FAQ

Q: Můžu použít role="button" na <div>, když přidám obsluhu klávesnice?

A: Můžete, ale neměli byste. Budete muset ručně řešit Enter, mezerník, správu fokusu a zakázané stavy — a nevyhnutelně něco přehlédnete. Element <button> to všechno ve výchozím stavu řeší správně. Používejte ho.

Q: A co tlačítka, která přepínají stav, například tlačítko přehrát/pozastavit?

A: Použijte aria-pressed="true" nebo aria-pressed="false" k označení aktuálního stavu. Popisek tlačítka by měl zároveň odrážet akci, která se stane po kliknutí („Pozastavit“, když se přehrává, „Přehrát“, když je pozastaveno), ne aktuální stav. Uživatelé čteček obrazovky potřebují vědět, co tlačítko udělá, ne v jakém stavu systém je.

Q: Musí zakázaná tlačítka splňovat požadavky na kontrast?

A: WCAG 2.1 vyjímá zakázané ovládací prvky z požadavků na kontrast (1.4.3), ale je to kontroverzní. Zakázaná tlačítka se špatným kontrastem jsou obtížně vnímatelná pro všechny. Pokud zakázané tlačítko zobrazujete, udělejte ho čitelné. Ještě lépe ho skryjte nebo vysvětlete, proč je zakázané.

Q: Jak otestuju přístupnost tlačítek bez čtečky obrazovky?

A: Použijte klávesnici. Projděte rozhraní tabulátorem a ověřte, že se dostanete ke každému tlačítku, vidíte, kde je fokus, a můžete tlačítka aktivovat klávesami Enter nebo mezerníkem. Tím zachytíte většinu problémů. Pro hlubší testování použijte inspector přístupnosti v Chrome nebo Firefox DevTools a zkontrolujte vypočtenou roli a popisek.

Q: Jaký je rozdíl mezi aria-label a aria-labelledby?

A: aria-label poskytuje textový řetězec přímo. aria-labelledby odkazuje na ID jiného elementu, jehož textový obsah se stane popiskem. Používejte aria-labelledby, když text popisku už existuje jinde v DOM. Používejte aria-label, když potřebujete dodat popisek, který není na obrazovce viditelný.

Zdroje

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM