Přístupnost mobilní aplikace: VoiceOver, TalkBack a větší písmo

01Přístupnost začíná dokončeným úkolem

Aplikace je použitelná teprve tehdy, když člověk najde potřebnou funkci, pochopí její stav a dokončí práci. Přístupnost neřeší jen nevidomé uživatele. Velký text, dostatečné ovládací plochy, přehledné chyby a alternativy ke gestům pomáhají také při slabším zraku, omezené pohyblivosti nebo práci jednou rukou.

Vyberte hlavní cesty: vytvoření účtu, přihlášení, hledání položky, objednávku, platbu, zrušení a kontakt na podporu. U každé napište přijatelný výsledek. „Čtečka něco přečte“ není dostatečné kritérium. Uživatel musí poznat, co kupuje, za kolik a zda se akce skutečně povedla.

02Stanovte rozsah, platformy a odpovědnost

Sepište podporované systémy, typy zařízení, jazyky a důležité externí obrazovky. Platební brána, vložený web i přihlášení přes jinou službu patří do skutečné cesty uživatele. Rozdělte odpovědnost mezi návrháře, vývojáře, testera a vlastníka produktu. Ke každému nedostatku musí existovat člověk, který rozhodne o opravě.

W3C zveřejňuje pracovní, informativní návrh metodiky pro aplikaci WCAG na mobilní aplikace. Dokument sám nestanovuje nové požadavky. Při zadávání odlišujte nativní aplikaci, vložený web a mobilní web. Automatický sken ani použití systémových komponent samo nedokládá splnění celého standardu. Případný požadavek na konkrétní normu musí mít jasný rozsah a způsob posouzení.

03VoiceOver: Projděte obrazovku sluchem

VoiceOver je čtečka obrazovky iPhonu. Zapnutí mění ovládací gesta, proto si nejprve projděte systémový nácvik. V nastavení zpřístupnění si připravte také rychlý způsob vypnutí. Test provádějte se sluchátky a bez čtení obrazovky, ale nezaměňujte vlastní nácvik za zkušenost běžného uživatele čtečky.

Postupujte po prvcích a zapisujte, co slyšíte. Má tlačítko přesný název? Poznáte přepínač a jeho stav? Nepředčítá se stejný obsah několikrát? Po otevření dialogu má být jasné, co se otevřelo a jak ho zavřít. Po jeho zavření ověřte, kam se vrátilo zaměření.

U seznamu objednávek nestačí deset tlačítek „Detail“. Zvažte přístupný název, který odliší objednávku, aniž by každé přejetí četlo celý řádek znovu. Dekorativní ikony nemají vytvářet další prázdné zastávky. Vlastní graf a mapu doplňte jiným způsobem získání podstatných informací.

04TalkBack: Ověřte druhou platformu samostatně

Android popisuje ruční testování s TalkBack i kombinaci automatických kontrol a zpětné vazby lidí. Čtečku zapnete v nastavení přístupnosti; konkrétní nabídka se může podle zařízení lišit. Projděte systémový návod a potom stejný úkol jako na iPhonu.

Nečekejte totožné chování jen proto, že aplikace sdílí zdrojový kód. Ověřte pořadí prvků, sloučení popisků, oznamování chyb a práci s klávesnicí. Zvlášť vyzkoušejte spodní panel, dialog, výběr data a ovládací prvek vytvořený na míru. Ty často vypadají dobře a přitom se obtížně používají bez zraku.

V protokolu vždy uveďte model telefonu, verzi systému, aplikace a čtečky. Věta „na Androidu nefunguje“ není dostatečná pro reprodukci. Přidejte přesné kroky, očekávané oznámení a skutečné chování.

05Každý prvek potřebuje název, roli a stav

Vizuální košík potřebuje srozumitelný název, přepínač informaci o zapnutí a pole trvalý popisek. Místo „ikona 3“ použijte význam akce. Neopakujte mechanicky slovo tlačítko, pokud je správně předané rolí. Název má pomoci rozhodnout, nikoli popisovat vzhled.

Principy přístupnosti Androidu zdůrazňují významové popisky a ovladatelné cíle. Na tomto základě si vytvořte vlastní pravidla komponent. U karty produktu rozhodněte, zda se má číst jako celek a které její akce musí zůstat samostatné.

06Větší písmo musí změnit i rozložení

Na iOS počítejte s Dynamic Type a se změnou rozložení při větším textu. Nestačí zvětšit znaky v pevně vysoké kartě. V testu používejte i dlouhé názvy, větší částky a slovenské či anglické překlady. Krátký ukázkový text mnoho chyb skryje.

Na Androidu vyzkoušejte systémové zvětšení písma i zobrazení. Pro text používejte mechanismy, které uživatelské nastavení respektují. Klíčová informace ani potvrzovací tlačítko nesmějí zmizet pod ořezem. Dva sloupce může být potřeba změnit na jeden, krátký řádek na více řádků a pevnou kartu na obsahově proměnnou.

WCAG pro web popisuje zvětšení textu až na 200 % bez ztráty obsahu či funkce, s uvedenými výjimkami. Nezaměňujte toto číslo za univerzální jediný test nativní aplikace. Tam ověřte podporované systémové velikosti včetně přístupnostních nastavení a skutečné dokončení úkolu.

07Dotykové cíle, kontrast a pohyb

Apple doporučuje ovládací plochy alespoň 44 × 44 bodů; Android ve své dokumentaci pracuje s doporučením 48 × 48 dp. Jde o jednotky rozhraní jednotlivých platforem, nikoli fyzické pixely screenshotu. Zvětšovat lze dotykovou oblast, ale nesmí se překrývat se sousední akcí.

Pro kontrolu textového kontrastu použijte měření, ne dojem z monitoru. WCAG stanovuje 4,5 : 1 pro běžný text a 3 : 1 pro velký text za podmínek daného kritéria. Zkontrolujte světlý i tmavý režim, text nad fotografií a stavy chyby či výběru.

Barva nemá být jediným nositelem významu. Chybu doplňte textem, vybranou možnost zřetelným stavem. U pohybu respektujte systémové omezení animací a nabídněte klidnější průchod. Pokyn „přetáhněte položku“ potřebuje dostupnou alternativu, pokud je přesun důležitý pro dokončení práce.

08Formuláře a změny stavu testujte v celém průchodu

Vyplňte formulář správně i chybně. Trvalý popisek musí přežít psaní; placeholder ho nenahradí. Ověřte výběr typu klávesnice, přechod mezi poli, dostupnost potvrzení a chybovou zprávu. Po opravě se nemají ztratit ostatní údaje. Při časovém limitu musí člověk rozumět tomu, co se stane s prací.

Uložení, změna ceny a nedostupnost termínu jsou důležité i bez vizuálního upozornění. Oznámení mají přijít ve správnou chvíli a nemají přerušovat každé slovo čtečky. Při opakovaném načítání otestujte, zda se zaměření neztratí nebo neposune na začátek dlouhé obrazovky.

09Modelová rezervace od vyhledání po potvrzení

1. Najděte službu pomocí čtečky a otevřete její detail.
2. Zvolte datum a čas; rozlište volné a obsazené termíny bez barvy.
3. Vyplňte kontaktní pole a úmyslně vyvolejte chybu.
4. Opravte ji, zkontrolujte cenu a pokračujte s velkým písmem.
5. Dokončete rezervaci a zjistěte číslo potvrzení i způsob zrušení.
6. Vraťte se zpět a ověřte, že aplikace nevytvořila nechtěnou duplicitu.

Jde o modelový testovací scénář, nikoli výsledek měření konkrétní aplikace. Pro vlastní produkt jej nahraďte nejdůležitějším úkolem. Projděte i stav bez internetu a návrat po chybě externí služby. Přístupné potvrzení na konci nepomůže, pokud se člověk nedostane přes výběr termínu.

10Sdílený kód nenahrazuje dva testy

U React Native, Flutteru i jiného multiplatformního řešení kontrolujte skutečný výsledek na obou systémech. Správně nastavená komponenta může pomoci konzistenci, ale vlastní knihovna nebo aktualizace může její chování změnit. Rozhodnutí o technologii vysvětluje také naše srovnání nativních a multiplatformních aplikací.

Vytvořte malou sadu schválených prvků: tlačítko, pole, přepínač, dialog, seznam a hlášení stavu. U každého popište název, roli, stav, zaměření a velké písmo. Návrhář pak nedodává pouze obrázek a vývojář nemusí pokaždé hádat požadované chování.

11Automatizace pomůže, lidé ověří použitelnost

Automatické kontroly používejte při vývoji a před vydáním. Vhodně doplní kontrolu popisků, některých kontrastů nebo rozměrů. Smysluplnost názvu, srozumitelnost dialogu a dokončení složitého úkolu však ověřujte ručně. Výsledek „bez nálezů“ není důkazem úplné přístupnosti.

Zapojte uživatele, kteří běžně používají čtečku či jiné pomůcky, a dejte jim realistický úkol. Neveďte jejich ruku po správné cestě. Ptejte se, kde ztratili orientaci, co očekávali a zda by práci zvládli sami. Domluvte odměnu, souhlas se záznamem a bezpečná testovací data.

Nedostatky řaďte podle dopadu: nemožnost dokončit platbu má přednost před zbytečně upovídanou ikonou. U každé opravy opakujte původní scénář i sousední kroky. V testovacím protokolu evidujte zařízení, verze, nastavení, pozorování, závažnost, vlastníka a stav opětovné kontroly.

12Ovládání bez přesného dotyku a bez zvuku

Vedle čtečky vyzkoušejte externí klávesnici a podporované alternativní ovládání. Android například popisuje Switch Access a hlasové ovládání. U vlastního produktu ověřte, že lze všechny důležité akce dosažitelně vybrat, že zaměření zůstává viditelné a že se nikdo nezasekne v dialogu.

Oznámení úspěchu nemá být pouze zvuk. U instruktážního videa připravte titulky a potřebný textový obsah. U rozhraní s limitem času vyzkoušejte člověka, který píše pomalu nebo používá jiný vstup. Délku úkolu nepřizpůsobujte pouze nejrychlejšímu testerovi.

Do požadavku na opravu napište konkrétní překážku: „Potvrzení objednávky nelze dosáhnout klávesnicí po otevření podmínek.“ Vývojář tak dostane reprodukovatelný problém a produktový tým chápe obchodní důsledek. Obecný požadavek „zlepšit přístupnost“ se přebírá a plánuje mnohem obtížněji.

13Časté otázky k mobilní přístupnosti

Připravujete mobilní produkt nebo přebíráte hotovou aplikaci? V rámci vývoje mobilních aplikací si nechte dohodnout konkrétní přístupnostní scénáře a důkazy jejich ověření. Začněte úkolem, který musí každý zákazník dokončit.