Příprava mobilních aplikací na evropský akt o přístupnosti (EAA)

Co se změnilo a koho se to týká

Povinná digitální přístupnost platila léta jen pro veřejný sektor. Evropský akt o přístupnosti (anglicky European Accessibility Act, zkráceně EAA; směrnice 2019/882, v Česku zákon č. 424/2023 Sb.) ji od 28. června 2025 poprvé vyžaduje i po komerčních službách: internetovém prodeji, spotřebitelském bankovnictví, prodeji jízdenek, telekomunikacích, streamování a e-knihách.

Povinnost se vztahuje na službu jako celek: provozujete-li e-shop, platí pro web i mobilní aplikaci stejně. Nové služby musí vyhovět hned, ty provozované už před červnem 2025 mají čas do 28. června 2030. Výjimku mají mikropodniky poskytující služby, tedy firmy do 10 zaměstnanců s obratem do 2 milionů eur.

Dohled vykonává především Česká obchodní inspekce a zákon počítá s pokutami až do 10 milionů korun. Pro většinu firem jsou ale podstatnější praktické důvody, protože přístupnost bývá podmínkou veřejných zakázek i firemních výběrových řízení a funkce přístupnosti, jako je čtečka obrazovky nebo zvětšení písma, běžně používá 10 až 15 % uživatelů mobilních aplikací, kterým nepřístupná aplikace komplikuje nebo znemožňuje nákup.

Co přístupnost znamená v praxi

Technickým měřítkem je evropská norma EN 301 549, která pro aplikace přebírá pravidla WCAG 2.1 úrovně AA. Co požadují, je nejlépe vidět na situacích, které v aplikacích nastávají každý den.

Nevidomý uživatel ovládá telefon čtečkou obrazovky: VoiceOver na iOS, TalkBack na Androidu. Čtečka mu předčítá, na čem má prst. V dobře postavené aplikaci slyší „Přidat do košíku, tlačítko". Ve špatně postavené slyší jen „tlačítko", u ikony bez popisku vůbec nic, a nákup nedokončí. Slabozraký uživatel si zvětší písmo a nepřipravená aplikace mu ořeže texty nebo rozbije rozložení obrazovky. Člověk s třesem rukou potřebuje dostatečně velké dotykové plochy a funkce nesmí záviset na přesném gestu.

Z pohledu vývoje jde o soubor ověřitelných vlastností:

Jak se přístupnost ověřuje a udržuje

Postupujeme krok za krokem:

1. 1

   Vstupní audit

   Aplikaci projdeme z pohledu uživatelů s různými omezeními, ručně otestujeme klíčové scénáře s asistivními technologiemi a výsledek doplníme automatickými kontrolami.

2. 2

   Soupis nálezů a plán úprav

   Každá závada dostane prioritu podle dopadu na uživatele. K tomu připravíme plán oprav s odhadem náročnosti, potřebných podkladů a vhodného postupu.

3. 3

   Automatizovatelné opravy

   Část nálezů vyřeší nástroje a AI, například sémantické popisky komponent, popisy obrázků pomocí rozpoznávání obrazu nebo titulky k videím.

4. 4

   Kontrola automatických úprav

   Výstupy nástrojů a AI ručně ověříme. Co nedokážeme posoudit sami, například popisy a texty specifické pro váš obor, odsouhlasíme s klientem.

5. 5

   Úpravy vyžadující úsudek

   Zbývá práce, kterou žádný nástroj nezastane, protože potřebuje lidské posouzení, typicky srozumitelnost hlášek, pořadí čtení obrazovek nebo logika navigace.

6. 6

   Závěrečný audit

   Opakovaný průchod ověří, že aplikace požadavky splňuje.

7. 7

   Výstup

   Prohlášení o přístupnosti, které vychází ze skutečně provedených úprav a testů.

Jak přístupnost řešíme při vývoji

U nových aplikací zabudováváme přístupnost od návrhu, pokud o ni projekt stojí. Rozsah přizpůsobujeme předpisům, které na aplikaci skutečně dopadají, protože požadavky se liší podle odvětví i podle zemí, kde bude služba dostupná.

Velkou výhodu tu přináší multiplatformní vývoj. Ve Flutteru, ve kterém aplikace stavíme, vzniká z jednoho kódu verze pro iOS, Android, web i desktop. Přístupnost se proto nepřizpůsobuje každé platformě zvlášť. Stačí ji vyřešit jednou a platí všude. U oddělených nativních aplikací se tatáž práce opakuje pro každou platformu.

Zvláštní kapitolou jsou projekty, na které zákon zatím nedopadá. I u nich se vyplatí stavět na komponentách se správnou strukturou a na designu s rezervou v kontrastech. Aplikace tak zůstává otevřená: až přístupnost začne být potřeba, ať už kvůli legislativě, zakázce, nebo novým uživatelům, doplní se popisky a testy bez přestavby obrazovek.

Zdravotnické aplikace: šedá zóna zákona

Zdravotnické prostředky jsou z působnosti aktu výslovně vyňaté a čistě léčebný obsah aplikace, jako je záznam obtíží nebo přehled medikace, mezi vyjmenovanými službami není. Jakmile ale aplikace obsahuje prvky spotřebitelské smlouvy, typicky registraci účtu, přihlášení nebo předplatné, dostává se do „e-commerce" služeb, na které se akt vztahuje. Kde přesně tato hranice v konkrétní aplikaci leží, není jednoznačné a právníci se na jejím výkladu v jednotlivých zemích EU neshodnou.

S touto nejednoznačností jsme se setkali u klienta Teva a jeho aplikace Migréna Kompas, deníku migrény pro pacienty a lékaře, který lokalizujeme do dalších zemí.