Na co se často zapomíná u přístupnosti mobilních aplikací

V prvním dílu jsem shrnul, že přístupná musí být celá aplikace a že to není jen o nevidomých. Tady je konkrétní přehled toho, co bývá špatně, a jak to má vypadat. Většina těch věcí nevyžaduje změnu vizuálního designu, jde hlavně o sémantiku, popisky, pořadí prvků a jejich velikost. Změny jsou tedy prakticky jen na pozadí a oku neviditelné.

Ovládání a fokus

Na všechno se musí dát „dostat“., tedy Každé tlačítko, odkaz, pole a přepínač musí být dosažitelný čtečkou, tabulátorem na externí klávesnici, přepínačem i hlasem. Prvek, na který jde jen klepnout prstem, tedy typicky vlastní „nakreslené“ tlačítko, které ve skutečnosti není tlačítko, pro část lidí neexistuje.

Fokus musí být vidět. Ať je jasné, na kterém prvku uživatel právě je. Je tedy potřeba definovat rámeček nebo zvýraznění s dostatečným kontrastem.

Pořadí musí dávat smysl. Protože čtečka i fokus procházejí prvky tak, jak jdou vizuálně za sebou, ne „jak to vyšlo v kódu“. Častá chyba je, když po odeslání formuláře fokus skočí na začátek obrazovky nebo úplně zmizí, místo aby přešel na výsledek nebo na chybovou hlášku.

Fokusovaný prvek nesmí nic zakrývat: klávesnice, cookie lišta, spodní panel. Nejhůř se to projeví u potvrzovacího tlačítka, které uživatel „má“, ale nevidí ho a nestiskne jej.

Dotykové interaktivní prvky musí být dost velké: minimálně 24 × 24 px podle WCAG 2.2, prakticky spíš 44–48 dp podle doporučení Applu a Googlu a musí mezi prvky být dostatečné mezery. Drobná ikonka s křížkem „zavřít“ v rohu je učebnicový příklad, jak to nedělat.

Ke složitým gestům musí být alternativa. Například přejetí pro smazání, tažení posuvníku, dlouhý stisk, více prstová gesta: u každého musí jít totéž udělat i obyčejným klepnutím na tlačítko. A akce se má vykonat až při zvednutí prstu a jít zrušit odtažením mimo, aby nechtěné klepnutí na tlačítko „Koupit“ nespustilo rovnou platbu. Často se stává, že kroky tažením bez použití odečítače se rozcházejí s kroky, které provádí odečítač pomocí vlastních gest. Tím se stává takový prvek prakticky nepoužitelným.

Co čtečka řekne

Název prvku popisuje, co dělá, ne jak vypadá. Např. tlačítko s lupou má být „Vyhledat spojení“, ne „lupa“. Šipka zpět má být „Předchozí strana“, ne „šipka vlevo“. Platí to bez ohledu na to, jestli je ten popis ve viditelném textu, nebo jen v přístupnostním popisku.

Dekorativní grafika se před čtečkou skryje. Ikona vedle textu, který tu akci už pojmenovává, se nemá číst zvlášť. Jinak uživatel slyší „nahoru, šipka nahoru“.

Nic se nemá číst dvakrát. Když má nějaký kontejner vlastní název a zároveň nechá číst i text svých potomků, čtečka přečte obojí: „5 probíhajících výluk, 5“. Buď název kontejneru, nebo jeho obsah, ne obojí.

Struktura. Obrazovka má hierarchii nadpisů, dialog si ale svou hierarchii začíná od začátku: první nadpis v modálním okně je vždy nejvyšší úrovně. Opakující se výpisy (spoje, výluky, výsledky) jsou označené jako seznam, aby uživatel čtečky slyšel „seznam, 7 položek“ a mohl je přeskočit. Skutečná tabulková data jsou tabulka.

Dynamické změny se oznamují. Když se něco změní bez překreslení celé obrazovky, třeba se načtou výsledky, přepne se motiv nebo přijde zpoždění spoje, řekne se to čtečce živou oblastí, aniž by to přebralo fokus: „Nalezeno 7 spojení.“ „Tmavý motiv zapnut.“

Jazyk aplikace je nastavený programově, protože jinak čtečka čte anglické texty českou výslovností.

Vzhled (bez čtečky)

Kontrast: běžný text aspoň 4,5 : 1 vůči pozadí, velký text, ikony a ohraničení polí aspoň 3 : 1. Týká se to i stavů jako aktivní záložka nebo zvýrazněné pole s chybou.

Barva nesmí být jediný nosič informace. Jako platnost jízdenky, závažnost výluky, chyba ve formuláři, aktuální spoj: všechno musí mít i text, ikonu s přístupnostním popiskem (zvýrazněné tečkované či jiné ohraničení apod.). Uživatel s poruchou barvocitu ani nevidomý „červenou“ nevidí.

Zvětšené písmo se musí vejít, když si uživatel v systému zvětší písmo (běžně až na 200 %), text se zvětší a obsah přeskládá, bez oříznutí a bez vodorovného posuvníku. Pevně naškálované rozložení, kde „to nejde“, je chyba.

Obě orientace displeje. Spousta lidí má telefon nebo tablet natrvalo v držáku v jedné poloze.

QR nebo aztécký kód jízdenky potřebuje textovou alternativu podstatných údajů: druh dokladu, zóny, platnost. Kontrola revizorem ani řešení potíží nesmí záviset jen na tom, že kód někdo vidí. A konkrétně i takové kódy by měly mít textový přístupnostní popisek, aby i nevidomý věděl, zda je grafický kód na displeji a jestli je jej tedy možné načíst kontrolním zařízením.

Formuláře

Popisek pole je trvalý, ne jen šedý placeholder, který po začátku psaní zmizí.

Nápověda i chyba jsou programově svázané s polem (přes aria-describedby na webu, accessibilityHint / labely v aplikaci), ne jen umístěné vizuálně poblíž. Vizuální blízkost čtečka nemá jak zjistit a přiřadit.

Chyba se oznámí a řekne, co se stalo a jak to napravit: „Zadejte prosím cílovou zastávku“, ne „Chyba 22“.

Čas, pohyb, srozumitelnost

Dost času. Před vypršením relace, typicky u nákupu nebo přihlášení, přijde varování s možností ji prodloužit. Nákup jízdenky, který vyprší, zatímco uživatel se čtečkou zadává platební údaje, je reálná bariéra.

Pohyb jde vypnout. Nic neblikající víc než třikrát za sekundu, automatické animace jdou zastavit a aplikace respektuje systémové „omezit pohyb“.

Jednoduchý jazyk a jasné prázdné výsledky. Prázdný výsledek je vysvětlený větou („Pro tuto zastávku dnes nejsou žádné odjezdy.“) a ne prázdná plocha.

Konzistence. Stejné věci se ovládají stejně a jsou na stejném místě na všech obrazovkách.

Přihlášení a platba

Přihlášení nesmí stát na opisu kódů zpaměti ani na grafických hádankách. Umožněte vložení ze schránky, podpořte správce hesel a biometriku. To je jedno z nových kritérií WCAG 2.2. Lze také umožnit funkci, kdy si aplikace sama načte kód z SMS.

Před potvrzením platby se přečte celé shrnutí, tedy co, kde platí, dokdy, za kolik, a potvrzovací tlačítko je jednoznačně pojmenované: „Koupit jízdenku za 30 Kč“, ne jen „Potvrdit“.

Jak to ověřit

Automatický nástroj odhalí jen zlomek. Co funguje:

Projít klíčové scénáře se zapnutou čtečkou a zhasnutou obrazovkou (koupím jízdenku? najdu odjezd?). Jelikož ale práce se čtečkou vyžaduje znalost jejího ovládání, je lepší takové testování raději svěřit profesionálům.
Projít je jen klávesnicí, bez myši a bez dotyku.
Zapnout 200% písmo a projít je znovu.
Vyzkoušet ovládání hlasem. Což ale také nemusí být úplně triviální při samotestování nezkušeným testerem.
Testovat s lidmi s různým postižením, ne jen s nevidomými.

A k tomu formální část, kterou u aplikace veřejné služby vyžaduje zákon: aktuální prohlášení o přístupnosti (s pravdivým výčtem toho, co ještě není hotové) a funkční zpětná vazba pro hlášení bariér.

Na co nezapomenout (shrnutí)

Přístupná je celá aplikace, ne vybrané obrazovky.
Není to jen o nevidomých.
Na všechno se dá dostat čtečkou i klávesnicí, fokus je vidět, pořadí dává smysl.
Prvky mají názvy podle toho, co dělají, dekorace je skrytá a nic se nečte dvakrát.
Kontrast sedí a barva není jediný nosič informace.
Zvětšené písmo se vejde, obě orientace fungují.
Interaktivní prvky jsou dost velké, ke gestům je alternativa. Např. kroky posuvníku by měly být identické jak při tažení prvkem bez čtečky obrazovky, tak při patřičných gestech odečítače.
Formulářové popisky, nápovědy a chyby jsou svázané s poli a oznamované.
Nákup a přihlášení jsou proveditelné čtečkou od začátku do konce.
Ověřuje se to ručně a s uživateli, ne jen automatem, protože automat odhalí maximálně čtvrtinu přítomných chyb.