Technologie

Testování přístupnosti webu pro uživatele se znevýhodněním: audit

Stanka 0

Proč a jak testovat přístupnost pro uživatele se znevýhodněním

Webová přístupnost není jen zákonný požadavek nebo kontrolní seznam, ale soubor postupů, které zajišťují, že web je použitelný pro co nejširší spektrum lidí – včetně uživatelů se zrakovým, sluchovým, motorickým či kognitivním znevýhodněním. Testování přístupnosti (A11y) ověřuje, zda rozhraní splňuje principy WCAG (Perceivable, Operable, Understandable, Robust) a zda je v praxi ovladatelné pomocí asistivních technologií. Tento článek představuje metodický rámec, nástroje, scénáře a měřitelné výstupy přístupnostních testů.

Rámec: WCAG 2.x a principy POUR

  • Vnímatelné (Perceivable): obsah musí být prezentován způsoby, které mohou uživatelé vnímat (textové alternativy, kontrast, strukturovaná média).
  • Ovládatelné (Operable): rozhraní musí být ovladatelné bez klávesových pastí, s dostatečnou dobou na reakci a bez zbytečných pohybových aktivací.
  • Srozumitelné (Understandable): předvídatelné chování, jasné popisy, srozumitelné chybové zprávy a asistence při zadávání dat.
  • Robustní (Robust): kompatibilita s asistivními technologiemi a standardy (HTML, ARIA), stabilní DOM a korektní role/stavy.

Role testování: kombinace automatizace, manuální kontroly a uživatelských studií

Žádná jediná metoda nepokryje vše. Úspěšné programy přístupnosti kombinují:

  • Automatizované skeny: rychlá detekce typických porušení (atributy alt, kontrasty, role, názvy ovládacích prvků).
  • Manuální heuristiky: hodnocení ovladatelnosti klávesnicí, čitelnosti, logiky fokusů, navigačních vzorů a validace formulářů.
  • Testy s asistivními technologiemi: čtení screen readerem, ovládání výhradně klávesnicí, hlasové ovládání.
  • Studie s uživateli se znevýhodněním: validace reálného použití, odhalení bariér překračujících standardní požadavky.

Plán testování: rozsah, priority a definice „Done“

  1. Definujte cíle: které uživatelské cesty (registrace, nákup, vyhledání informací) musí být bezbariérové.
  2. Vyberte kritéria: úroveň WCAG (A/AA) jako minimální cílový standard, u kritických produktů zvažte i úroveň AAA.
  3. Stanovte priority: kritické bariéry (blokující dokončení úkolu) > závažné > střední > nízké.
  4. Definujte „Definition of Done“: žádné blokující a závažné chyby, 100 % klíčových cest splňuje úroveň AA, automatizace integrována v CI.

Nástroje: automatizovaná kontrola a CI/CD

  • Prohlížečové doplňky: inspekce kontrastu, atributů role/aria-*, názvů ovládacích prvků, titulků a hierarchie nadpisů.
  • CLI a CI: integrace testovacích nástrojů do pipeline, nastavení prahových hodnot (například „0 kritických chyb“ jako blokátor buildu).
  • Snapshoty a vizuální testy: ověření, že změny CSS nezpůsobily ztrátu viditelnosti fokusu či kontrastu.
  • Linting šablon: statická analýza HTML/JSX (zakázat použití „onClick“ bez klávesové alternativy, vyžadovat label a for).

Manuální test: pouze klávesnice

  1. Navigace Tab/Shift+Tab: ověřte logické pořadí, absence pastí a dosažitelnost všech interaktivních prvků.
  2. Viditelný fokus: prvek ve fokusu musí mít výraznou vizuální indikaci i při vysokém kontrastu.
  3. Klávesové alternativy: akce dostupné kliknutím musí být proveditelné stiskem Enter nebo Space; rozbalovací prvky ovládejte šipkami.
  4. Skip link: odkaz „Přeskočit na obsah“ musí být viditelný při fokusu a funkční na všech stránkách.

Manuální test: kontrast, barvy a režimy

  • Kontrast: text proti pozadí splňuje minimálně poměr 4,5:1 (úroveň AA) pro běžný text, 3:1 pro velký text (≥18 pt nebo 14 pt tučně).
  • Barva není jediný nosič informace: doplňte informaci vzorem, tvarem nebo textem.
  • Vysoký kontrast a tmavý režim: ověřte, že systémové režimy nezpůsobí neviditelnost prvků.

Formuláře: popisky, chyby a nápověda

  • Explicitní popisky: každý input musí mít viditelný label a programový název (Accessible Name).
  • Chybové zprávy: konkrétní, připojené k poli, oznamované živě (například pomocí aria-live="polite").
  • Skupiny polí: používejte fieldset a legend pro logické celky (například výběr pohlaví).
  • Tipy a příklady: uveďte očekávaný formát, masky zadávání nesmí bránit čtečkám obrazovky.

Semantika a ARIA: kdy ano a kdy ne

  • Preferujte nativní prvky: tlačítka, odkazy, seznamy, tabulky, nadpisy (h1–h6).
  • ARIA používejte s rozvahou: přidávejte pouze tam, kde nelze využít nativní semantiku; nikdy nepřepisujte nativní role.
  • Landmarky: prvky jako header, nav, main, aside, footer umožňují rychlé skoky v screen readeru.
  • Stavy a názvy: ověřujte Accessible Name/Description Computation (například u ikonických tlačítek).

Fokus management a dialogy

  • Trapování fokusu: modální okno musí zachytit fokus uvnitř a po zavření jej vrátit na předchozí prvek.
  • Oznámení otevření: dialog má roli dialog nebo alertdialog, nadpis a popis.
  • ESC a uzavření: umožněte bezpečné klávesové zavření bez ztráty stavu.

Média: titulky, přepisy a popisy

  • Video: synchronní titulky, případně audio popis vizuálních informací.
  • Audio: textový přepis, ovladatelný přehrávač s podporou klávesnice i čteček obrazovky.
  • Automatické přehrávání: vypnuté nebo snadno zastavitelné; respektujte uživatelskou preferenci „reduced motion“.

Testy se screen readery: praktický postup

  1. Zvolte kombinace: Windows+NVDA, Windows+JAWS, macOS+VoiceOver, iOS+VoiceOver, Android+TalkBack.
  2. Scénářové testy: dokončení nákupu, vyplnění formuláře, filtr výsledků, práce s tabulkou.
  3. Navigační rychlopříkazy: skoky podle nadpisů, formulářových polí, odkazů či regionů; kontrola čtecího pořadí.
  4. Výstup a očekávání: zaznamenávejte přesné verbální výstupy a porovnejte je s očekávanými názvy, rolemi a stavy.

Motorická přístupnost: alternativní vstupy a zóny kliků

  • Velikost cíle: minimální rozměry 24×24 px; dostatečné rozestupy pro dotykové ovládání.
  • Alternativy gestům: například „táhni“ musí mít ekvivalentní tlačítko; nepoužívejte gesto shake či poklep bez alternativy.
  • Hlasové ovládání: prvky musí mít stabilní, srozumitelné názvy pro hlasové systémy.

Kognitivní přístupnost: srozumitelnost a kognitivní zátěž

  • Jasný jazyk: krátké věty, vyvarujte se žargonu; vysvětlete důležité pojmy.
  • Průvodci a postupy: složité úkony rozdělte do kroků s indikátorem průběhu.
  • Předvídatelnost: konzistentní umístění navigace, žádné neočekávané přesuny fokusu.

Mobilní přístupnost: orientace, zvětšení a rotace

  • Responzivní layout: zajistěte, aby textové bloky nevyžadovaly horizontální posun.
  • Zvětšení: podporujte systémové zvětšení písma bez narušení rozhraní.
  • Orientace: aplikace by neměla beze zdůvodnění vynucovat jedinou orientaci.

Tabulky, grafy a komplexní komponenty

  • Datové tabulky: definujte záhlaví pomocí <th scope="col/row">; komplexní tabulky opatřete atributy headers a id.
  • Grafy: poskytněte textový souhrn trendu a klíčových hodnot, přístupnou legendu a popisky os.
  • Drag & drop: klávesové alternativy (tlačítka „přesunout nahoru/dolů“) a živá oznámení změny pořadí.

PDF a dokumenty: alternativy a tagování

  • Preferujte HTML: dokumentace na webu by měla být v HTML s možností tisku.
  • Accessible PDF: pokud je PDF nezbytné, zajistěte tagování, správné čtecí pořadí, záložky, alternativní texty a odpovídající kontrast.

Testovací scénáře: uživatelské cesty end-to-end

  1. Najít informace: vyhledání článku, přechod z výsledků, čtení a stažení souboru.
  2. Odeslat formulář: přihlášení k odběru, validace, chybové stavy, potvrzení.
  3. Nákup: přidání do košíku, změna varianty, platba, rekapitulace.
  4. Správa účtu: změna hesla, dvoufaktorová autentizace, nastavení preferencí.

Zapojení osob se znevýhodněním: etika a metodika

  • Nábor: zahrňte diverzní profily (zrak, sluch, motorika, kognitivní) a různé asistivní technologie.
  • Souhlas a odměna: zajistěte informovaný souhlas, bezpečné prostředí a přiměřenou kompenzaci.
  • Moderace: zaměřte se na úkolově orientované scénáře, bez navádění, zachyťte verbální i neverbální signály.

Reporting: jak psát nálezy, aby vedly k opravám

  • Struktura nálezu: název, závažnost, příslušné WCAG kritérium, kroky k reprodukci, očekávané vs. skutečné chování, screenshoty/video, návrh řešení.
  • Prioritizace: blokující (nelze dokončit úkol), závažné (výrazná bariéra), střední, nízké.
  • Sledovatelnost: propojte nález s user story nebo test case; sledujte stav v backlogu.

Kontinuální zlepšování: metriky a governance

  • KPI: procento cest splňujících úroveň AA, počet kritických chyb mezi releasy, doba nápravy, skóre automatizace.
  • Školení: pravidelné vzdělávací kurzy pro designéry, vývojáře i testery; knihovna přístupných komponent.
  • Design systém: dokumentované vzory s příklady kódu, požadavky na ARIA a testovací checklisty.

Checklist: rychlá kontrola pro každou stránku

  • Nadpisy tvoří logickou hierarchii a odpovídají struktuře obsahu.
  • Všechny interaktivní prvky jsou dostupné a ovladatelné klávesnicí, fokus je viditelný.
  • Textové alternativy správně popisují význam ne-textových prvků.
  • Kontrast splňuje minimální poměry, barva není jediným nosičem informace.
  • Formuláře mají popisy, chybové zprávy a nápovědu; chyby jsou oznamovány.
  • Dialogy správně zachycují fokus a informují screen reader.
  • Média obsahují titulky/přepisy; animace respektují preferenci „reduced motion“.
  • HTML je validní, role, stavy a názvy odpovídají očekáváním asistivních technologií.

Příklady běžných antipatternů a jejich náprava

  • Ikonické tlačítko bez názvu: doplňte aria-label nebo viditelný text.
  • Custom select bez klávesnicového ovládání: použijte nativní <select> nebo doplňte ARIA, roli listbox a klávesové chování.
  • Neviditelný fokus: přidejte styl s dostatečným kontrastem a tloušťkou.
  • Chybové zprávy
Stanka

Website:

Related Story