Co je předmětem žalob: Praktický průvodce vzory uživatelského rozhraní, které stojí za 6 666 stížnostmi na nedostatečnou přístupnost

Záhlaví je první interaktivní prvek na každé stránce a tlačítko „hamburger“ je často první věcí, na kterou uživatel ovládající stránku pomocí klávesnice narazí. Pokud je toto tlačítko zobrazeno jako <div> pokud má prvek obrázek na pozadí v CSS, nemá přístupný název nebo rozbaluje nabídku, která zadržuje fokus nebo neoznamuje svůj stav (otevřeno/zavřeno), stává se celý web z hlediska struktury neovladatelný pomocí klávesnice ještě dříve, než se uživatel dostane k jakémukoli skutečnému obsahu.

Odkaz na přeskočení je příčinou poruchy. Funkční "Skip to main content" Odkaz „skip link“ je sice záležitost pěti řádků, ale zároveň představuje nejúčinnější způsob, jak zjistit, zda má vývojový tým přístupnost vůbec na svém seznamu úkolů. Stížnosti často zmiňují obojí v jednom odstavci, protože chybějící nebo nefunkční odkaz „skip link“ je jakousi varovnou signálem – pokud tým nezahrnul odkaz „skip link“, téměř jistě nezahrnul ani stavy atributu `aria-expanded`.

Zobrazit spouštěč nabídky jako skutečný <button> s viditelným textovým popiskem nebo popiskem dostupným pouze pro čtečky obrazovky a spravovaným aria-expanded atribut. Zadejte "Skip to main content" odkaz, který se zobrazí po zaostření a směřuje do <main> orientační bod. Zajistěte, aby se fokus při otevření přesunul do nabídky, při jejím zavření se vrátil na spouštěč a aby Esc zavře nabídku.

Na většině velkých webů je vyhledávání implementováno jako vlastní komponenta – jedná se o textové pole s odskokem, které při každém stisknutí klávesy odešle požadavek a zobrazí plovoucí seznam návrhů uvnitř prvku s absolutním umístěním <div>. Samotné zadávání textu obvykle funguje bez problémů. Seznam návrhů však téměř nikdy nefunguje správně. Je vykreslován mimo kontext DOM vstupního pole a nemá role="listbox", ne aria-activedescendanta při zobrazení výsledků se nezobrazí žádné upozornění na aktivní oblast. Uživatel čtečky obrazovky napíše text, nic neslyší, stiskne klávesu Enter a zobrazí se mu stránka s výsledky, o které nevěděl, že na něj čeká.

Stejný architektonický vzor se opakuje v panelech filtrů pro faceted search i v samotném seznamu výsledků: prvky, na které lze přesunout fokus klávesnicí, jsou sice vizuálně viditelné, ale nikdy nejsou hlasově ohlášeny. Stížnosti na vyhledávání se málokdy týkají samotného vyhledávacího pole; týkají se všeho, co se objeví poté, co uživatel něco napíše.

Použijte zavedený vzor WAI-ARIA pro rozbalovací seznam: role="combobox" na vstupu pomocí aria-expanded, aria-controlsa aria-activedescendant připojený k role="listbox" navrhů. Přidejte elegantní interaktivní oblast, která zobrazuje počet výsledků. Zajistěte, aby byl seznam návrhů přístupný pomocí šipky dolů, nikoli pouze myší.

Mřížka PLP sdružuje na jedné obrazovce hned několik nevhodných postupů. Každá dlaždice je obvykle klikatelnou kartou se třemi či čtyřmi interaktivními podprvky – odkazem na obrázek, odkazem na název, vzorníky barev a tlačítkem pro rychlé přidání –, které jsou navíc obaleny dalším odkazem na stránku produktu. Výsledkem jsou vnořené interaktivní prvky (což je chyba z hlediska HTML), nadbytečný text odkazů (čtyřikrát se opakující text „Hero Dash Three Graphic Image Link“) a vzorníky barev vytvořené z <div> prvky s obslužnými funkcemi pro kliknutí, které nemají ani roli, ani název.

Postranní panel s filtry přidává druhou kategorii chyb. Filtrační kritéria jsou obvykle seznamy zaškrtávacích políček, jsou však vytvořena pomocí vlastních prvků div a span, které jsou stylizovány tak, aby vypadaly jako zaškrtávací políčka, přičemž skutečné <input> skrytý mimo zobrazenou plochu. Jakmile tento skrytý vstup ztratí svou vazbu – ať už kvůli pravidlu CSS, obslužné rutině JavaScriptu, která zachycuje stisknutí mezerníku, nebo kvůli chybějícímu for atribut na viditelném štítku – filtr lze ovládat pouze myší.

Používejte jednu kotvu na každou dlaždici s popisným textem, nikoli tři odkazy na jeden produkt. Zobrazujte vzorky tak, jak vypadají ve skutečnosti <button> prvky uvnitř role="radiogroup". Vytvořte filtrační kritéria na základě skutečných <input type="checkbox"> prvky s přidruženými <label> tagy; vstupní pole vizuálně upravte, místo abyste je skrývali. O změnách ve filtru informujte pomocí zdvořilého živého regionu.

Na stránce s podrobnostmi o produktu musí uživatel čtečky obrazovky provést několik konkrétních kroků ve správném pořadí: vybrat barvu, vybrat velikost, zadat počet kusů a poté přidat do košíku. Každý z těchto kroků je v moderním e-shopu realizován jako vlastní widget – obvykle se jedná o vodorovný řádek <button>ve tvaru <div>Co se týče velikostí, jedná se o barevné dlaždice vytvořené z prvků div se styly CSS a číselný posuvník tvořený dvěma ikonovými tlačítky po stranách vstupního pole. Tlačítka pro zvýšení a snížení se běžně dodávají bez přístupného názvu; stížnosti je popisují jako oznámeno jako „button, button“ aniž by bylo zřejmé, čím se zabývají.

Průvodci velikostmi a tabulky velikostí představují samostatný problém: téměř vždy se nacházejí za odkazem „Tabulka velikostí“, který otevírá modální okno, přičemž samotný odkaz často nemá žádný popisek, modální okno často nemá žádný zobrazený název a tabulka uvnitř často neobsahuje žádné záhlaví řádků ani sloupců.

Používejte skutečné ovládací prvky formulářů. Vzorky barev a voliče velikosti by měly být role="radiogroup" z role="radio" tlačítka (nebo skutečné přepínače stylizované tak, aby nebyly viditelné), z nichž každé má přístupný název, například „Velikost: Střední“. Posuvník pro nastavení množství by měl být číselné pole s popiskou a dvojicí tlačítek pro zvýšení a snížení, jejichž přístupné názvy obsahují popis akce a aktuální množství. Celý blok výběru obalte do pole s popiskou.

Funkce „Přidat do košíku“ je nejčastěji testovaným bodem v každém e-commerce nákupním procesu a zároveň jedním z těch, které uživatelům asistivních technologií nejčastěji nefungují. Schéma je mechanické: návštěvník stiskne tlačítko, na dvě až tři sekundy se objeví malé potvrzovací okénko nebo vysouvací panel s košíkem a ikona košíku v záhlaví aktualizuje počet položek. Uživatelé s normálním zrakem vidí všechny tři signály. Uživatelé čteček obrazovky obvykle nevidí nic. Oznámení se zobrazí mimo jakoukoli aktivní oblast, zásuvka se objeví bez řízení fokusu a změna počtu v košíku je doručena jako prostá změna DOM, kterou žádná čtečka obrazovky neoznámí.

Výsledkem je tlačítko, které z pohledu uživatele nefunguje. Stisknou ho, nic se neozve, domnívají se, že selhalo, a stisknou ho znovu. V některých stížnostech se uvádí, že uživatelé tlačítko stiskli pětkrát či šestkrát, než si uvědomili, že se do košíku tiše nashromáždilo pět nebo šest položek.

Obalte oblast cart-status do aria-live="polite" a při každém úspěšném přidání položky aktualizujte jeho text. Pokud návrh využívá potvrzovací panel, přesuňte fokus na tento panel při jeho otevření a po jeho zavření vraťte fokus zpět na původní tlačítko. Aktualizujte štítek s počtem položek v košíku tak, aby obsahoval hlášení určené pouze pro čtečky obrazovky, například: „Přidána 1 položka. Celkem v košíku: 3 položky.“

Ovládací prvky tvořené pouze ikonami selhávají předvídatelným způsobem: viditelný obsah představuje symbol ve formátu SVG nebo z ikonového fontu, přístupný obsah je prázdný a výstup čtečky obrazovky se omezí na strukturální roli prvku bez názvu. Ikona košíku je nakonec oznámena jako „odkaz“ nebo „sbaleno“; bublinka chatu jako „tlačítko“; řada ikon sociálních sítí v zápatí jako „odkaz, odkaz, odkaz, odkaz, odkaz“. Uživatel nemá žádný způsob, jak zjistit, k čemu který z nich slouží.

Ikony nákupního košíku selhávají častěji než jiné ikony z architektonického důvodu: mnoho implementací vykresluje počet položek v košíku přímo v přístupném názvu ikony (např. ikona zobrazuje uvnitř SVG hodnotu „0“) a čtečka obrazovky zachytí pouze tuto číslici. Stížnosti uvádějí, že ikona nákupního košíku je ohlášena jako „3, odkaz“ nebo „0, odkaz“, aniž by bylo jasné, že číslo „3“ označuje počet položek v nákupním košíku.

Každý ovládací prvek tvořený pouze ikonou musí mít přístupný název. Přidejte aria-label na tlačítko nebo do něj vložit textový popisek, který nebude viditelný: "Shopping cart, 3 items". Vyhněte se vkládání číselných znaků do popisného názvu ikony bez kontextu. U dekorativních ikon, které se nacházejí vedle viditelného textu, použijte aria-hidden="true" klikněte na ikonu a nechte text sloužit jako popisek.

Stránka pokladny v sobě soustřeďuje více rizik souvisejících s dodržováním předpisů na jeden pixel než jakákoli jiná stránka e-shopu a výskyt chyb je zde velmi častý. Rozbalovací seznamy adres zobrazené jako vlastní <div> komponenty, které ignorují mezerník. Označení povinných polí se zobrazují pouze jako červená hvězdička, bez aria-required a bez programového propojení. Chybové hlášky se zobrazují červeným textem přímo pod polem, bez aria-describedby propojení pole s chybou a absence upozornění v aktivní oblasti v případě neúspěšné validace. Uživatel vyplní formulář, stiskne tlačítko „Pokračovat“, je bez varování přesměrován zpět a nemá možnost zjistit, která pole byla neplatná ani proč.

Ve stovkách případů se opakují stejné stížnosti: chybová hlášení nejsou hlasově oznamována, jsou nekonkrétní, nelze zadat platební údaje. Nejedná se o ojedinělé chyby. Jde o standardní chování většiny komponent pro dokončení nákupu, které jsou dodávány bez výslovné úpravy z hlediska přístupnosti.

Použijte skutečné <label> prvky přiřazené k vstupům pomocí for/id. Povinná pole označte pomocí aria-required="true" a označte povinnost viditelným textem, nikoli pouze barvou. V případě neúspěšné validace zobrazte chybovou zprávu uvnitř pole aria-describedby cíl, zadejte pole, u kterého došlo k chybě aria-invalid="true"a přesuňte fokus klávesnice na první neplatné pole. V horní části formuláře vytvořte souhrnnou oblast s chybami, která bude obsahovat odkazy na jednotlivá pole s chybami.

Platební blok je neobvyklý tím, že je často poskytován prostřednictvím vloženého iframe od třetí strany – Stripe Elements, Braintree Hosted Fields nebo Adyen drop-in. Uvnitř iframe je vlastní formulář poskytovatele platebních služeb obvykle jasně označen. Jakmile však web vytvoří vlastní zadávací pole pro kartu nebo vloží pole do vlastního rozvržení, které přepíše popisky vizuálními zástupnými symboly, stanou se tato čtyři pole – číslo, datum platnosti, CVV, PSČ – pro čtečku obrazovky řadou prázdných vstupních polí.

Pole pro CVV je nejčastěji nesprávně označené, protože vývojáři obvykle nahrazují jeho popisek ikonou otazníku, která po kliknutí otevře popisek vysvětlující, co je to CVV. Tento popisek však není skutečným popiskem; pole stále potřebuje programový název. Pokud jej nemá, čtečka obrazovky ohlásí celý platební blok jako „edit, edit, edit, edit“ a transakce se zastaví.

Pokud využíváte integraci hostovaných polí od jiného poskytovatele, řiďte se jeho pokyny k přístupnosti – většina z nich nabízí zdokumentovaný postup pro označování polí mimo rámec iframe. Pokud vytváříte vlastní formulář pro zadávání údajů, musí mít každý vstupní prvek skutečný <label> prvek s viditelným textovým popiskem, a navíc autocomplete="cc-number" / cc-exp" / cc-csc" atributy, aby správci hesel a asistenční technologie mohly pole identifikovat podle účelu.

Na stránce košíku se opakuje stejná chyba jako u posuvníku množství na stránce produktu, tentokrát však s vážnějšími důsledky: uživatel čtečky obrazovky, který posuvník nedokáže ovládat, nemůže objednávku dokončit. Ovládací prvek „Odstranit“ je sám o sobě protipříkladem – obvykle se jedná o malou ikonu ve tvaru křížku vedle každé položky, často bez viditelného textu, bez aria-label, a při odstranění řádku se nezobrazí žádné hlášení. Uživatel stiskne tlačítko, o kterém se domnívá, že slouží k odstranění, řádek zmizí a čtečka obrazovky mlčí. Neexistuje žádný způsob, jak ověřit, zda se akce podařila.

Několik stížností popisuje podobný druh selhání: celková částka v košíku se dynamicky aktualizuje při změně množství nebo vyřazení položek, avšak nová částka se zobrazuje jako běžný text v DOM mimo jakoukoli živou oblast, takže uživatel nemá ponětí, kolik mu bude účtováno.

U každé položky by mělo být k dispozici označené tlačítko pro odstranění (např. "Remove Blue T-Shirt, size M, from cart"). Ovládací prvky pro nastavení množství by měly oznamovat svou aktuální hodnotu jako součást přístupného názvu nebo prostřednictvím spárovaných aktualizací živé oblasti. Mezičíslo košíku by mělo být umístěno uvnitř aria-live="polite" v dané oblasti, takže jsou změny oznamovány. Odstranění potvrďte pomocí funkce pro vrácení zpět.

Jedná se o nejrozsáhlejší kategorii v datovém souboru, protože jde o problém, jehož odhalení je nejméně nákladné, zatímco jeho ignorování je nejnákladnější. Čtečka obrazovky prochází strukturu DOM a narazí na <input>a přečte jeho popisný název, který vypočítá z následujících údajů v tomto pořadí: aria-labelledby, aria-label, přidružený <label for>, title atribut nebo zástupný symbol. Pokud žádný z nich neexistuje, čtečka obrazovky přečte pouze roli: „editovací pole“ nebo „editovací pole, prázdné“. Tato fráze se téměř doslovně opakuje ve stovkách záznamů o stížnostech.

Důvod, proč je to tak běžné, je strukturální. Moderní designové systémy často zobrazují v poli pro zadávání text náhradní text, který nahrazuje viditelný popisek, a vývojáři se domnívají, že tento náhradní text plní funkci popisku. Není tomu tak. Náhradní text zmizí, jakmile uživatel začne psát, nezanechá žádný programový název a pole se stane nepoužitelným pro kohokoli, kdo k němu dorazí později v rámci procesu nebo se k němu vrátí po chybě.

Každý interaktivní ovládací prvek má viditelný popisek, který je k němu přiřazen programově. <label for="email">Email</label><input id="email" type="email"> je standardní postup. Zástupné symboly slouží pouze jako doplňkové vodítko, nikoli jako náhrada. U ovládacích prvků, u nichž je viditelný popisek skutečně nežádoucí (vyhledávací pole, tlačítka s ikonami), použijte aria-label s popisným textem – nikdy s duplicitním zástupným symbolem.

Fráze „nebylo oznámeno ani nebylo přiděleno fokus“ se doslovně objevuje ve více než 400 záznamech stížností a patří k nejčastěji opakovaným větám v celém souboru dat. Popisuje konkrétní typ selhání: na stránce se objeví modální okno nebo dialog (často automaticky – přihlášení k odběru newsletteru, ověření věku, potvrzení polohy), viditelný obsah se posune, ale čtečka obrazovky nedostane žádný signál, že se něco změnilo. Fokus zůstává na původní stránce. Uživatel pokračuje v procházení pomocí klávesy Tab tím, co bylo pod modálním oknem, aniž by si vůbec uvědomil, že se objevilo blokující dialogové okno.

Toto je typický příklad modálního okna, které selhává ve všech ohledech najednou: ne role="dialog", ne aria-modal="true", nedochází k programovému přesunu fokus na otevření, nedochází k uvíznutí fokusu při otevření, nedochází k zavření stisknutím klávesy Esc, nezobrazuje se hlášení o názvu. Jelikož se všechny tyto chyby vyskytují společně, opravou pouze jedné z nich se na stavu případu nic nezmění.

Použijte zavedený vzor dialogového okna (vzorem je specifikace WAI-ARIA Authoring Practices). Při otevření: přesuňte fokus na první prvek v dialogovém okně, na který lze zaměřit fokus, nastavte aria-modal="true" a role="dialog", pojmenujte dialogové okno aria-labelledby s odkazem na jeho nadpis. Během zobrazení: udržujte fokus uvnitř dialogového okna. Při zavření: vraťte fokus na prvek, který okno vyvolal. Respektujte klávesu Esc. Pokud modální okno narušuje průběh akce (např. automatické přehrávání při načtení stránky), poskytněte uživateli jediný způsob, jak jej trvale zavřít.

Indikátory zaostření jsou obvykle záměrně odstraněny vývojářem nebo designérem, který vnímal výchozí obrys prohlížeče jako vizuální rušení a napsal *:focus { outline: none; } do globálního stylu. Stránka nyní působí na vidoucího uživatele s myší přehledněji. Pro vidoucího uživatele s klávesnicí – včetně většiny uživatelů se slabozrakostí, uživatelů s motorickým postižením a uživatelů, kteří se pohybují po stránce bez myši – se však stránka stává nepoužitelnou. Uživatel může stisknout klávesu Tab, ale nevidí, kde se právě nachází.

Jedná se o jeden z mála typů chyb, které lze odhalit i bez použití asistenčních technologií. Kontrolor kvality, který jednou projde domovskou stránku pomocí klávesy Tab bez použití dalších nástrojů, na ni narazí za méně než minutu. Skutečnost, že týmy pro přístupnost ji v rámci sporných webů nacházejí opakovaně, zatímco interní kontrola ji přehlédla, je jedním z nejspolehlivějších signálů v datovém souboru, že daný web vůbec neprošel testováním pomocí klávesnice.

Nikdy nevypínejte vše najednou :focus obrysy bez náhrady. Použijte styl zvýraznění – obvykle obrys o šířce 2–3 px s dostatečným kontrastem jak vůči prvku, tak vůči jeho pozadí – pomocí :focus-visible takže se indikátor zobrazuje při navigaci pomocí klávesnice, ale ne při kliknutí myší. Ověřte to u všech interaktivních komponent, včetně vlastních widgetů, odkazů uvnitř karet a prvků s tabindex.

Logo je nejčastěji navštěvovaným obrázkem na webových stránkách a zároveň jedním z těch, u nichž dochází nejčastěji k chybám. Obvykle je součástí odkazu, který přesměrovává zpět na domovskou stránku, ale obrázek se načítá bez alt, ne aria-label na odkazu a žádný okolní text. Čtečka obrazovky přečte pouze „odkaz“, aniž by bylo jasné, kam to vede. A to na každé stránce webu.

Širší kategorie – obrázky bez alternativního textu – zahrnuje bannerové grafiky, fotografie produktů, úvodní ilustrace, symboly sociálních sítí a rozsáhlý katalog marketingových obrázků, které typický e-shop obsahuje. Stížnosti v této kategorii často uvádějí konkrétní názvy souborů obrázků, což naznačuje, že znalec žalobce provedl automatickou kontrolu, která vypsala všechny obrázky, u nichž alt atribut chyběl nebo byl prázdný, ačkoli měl být popisný.

Loga by měla obsahovat alternativní text popisující název společnosti a, pokud logo odkazuje na nějakou stránku, také její adresu — alt="Acme Co. — homepage". Dekorativní obrázky mají prázdný atribut alt (alt=""), což je záměrně skrývá před asistenčními technologiemi. Informační obrázky by měly mít popisný alternativní text. Vyhněte se automatickému generování alternativního textu z názvů souborů nebo popisků vytvořených umělou inteligencí bez lidské kontroly; v záznamech o stížnostech se opakovaně objevují případy, kdy nástroje pro překryvný text označily firemní logo jako „modro-žlutý znak“.

Čtečky obrazovky zobrazují režim „seznamu odkazů“, který zkušení uživatelé hojně využívají k rychlému prohledání stránky během několika vteřin. V tomto režimu se zobrazuje pouze text odkazu, oddělený od okolního odstavce. Stránka, na které každý úvodní odstavec blogu končí značkou „Číst dále“ se v tomto zobrazení zobrazí jako patnáct stejných položek. Stránka s pěti prázdnými odkazy — <a href="..."></a>, k čemuž často dochází, když jsou ikony umístěny v obalech odkazů bez náhradního textu — vygeneruje pět mezer.

Řešení je dobře známé a chyba je dobře známá, a proto se tento problém v stížnostech stále objevuje – jeho přetrvávání naznačuje, že vývojový proces neobsahuje automatizovanou kontrolu textu odkazů ani ruční kontrolu pomocí čtečky obrazovky.

Každý odkaz musí mít popisný název, který vystihuje jeho cíl nebo funkci. Nahraďte obecné výrazy popisnými — „Číst dále“ stane se „Přečtěte si více o výsledcích za třetí čtvrtletí“. U odkazů tvořených pouze ikonou přidejte vizuálně skrytý text nebo aria-label. Proveďte automatickou kontrolu (axe, Lighthouse atd.) na prázdné <a> prvky během CI.

Ve stížnostech se videa objevují ve dvou podobách. První je zřejmá: marketingové video, ukázka produktu nebo vysvětlující video je zveřejněno bez titulků, přepisu nebo jakékoli textové alternativy – a návštěvník, který je neslyšící nebo má sluchové postižení, tak k obsahu nemá přístup. Druhý je subtilnější: úvodní video, které se spustí automaticky při načtení stránky, což narušuje výstup čtečky obrazovky a porušuje požadavky na ovládací prvky pro pozastavení/zastavení očekávané na úrovni WCAG 2.2 AA (podle SC 2.2.2 Pozastavit, zastavit, skrýt pro pohyblivý obsah a SC 1.4.2 pro jakýkoli zvuk).

Některé stížnosti v tomto souboru dat tvrdí, že „absence skrytých titulků u videí na webových stránkách představuje porušení zákona ADA“, což je formulováno jako právní závěr. To, zda tato interpretace obstojí, se liší podle jurisdikce a okolností; jistější však je, že tato videa soustavně nesplňují požadavky normy WCAG 2.2 AA, kterou většina soudů a mimosoudních dohod považuje za rozhodující měřítko shody.

Zajistěte synchronizované titulky pro všechna předem nahraná videa se zvukem. Připojte také textový přepis; přepisy jsou užitečné pro uživatele s vypnutým zvukem, v prostředích s nízkou šířkou pásma a pro účely indexování. Vyhněte se automatickému přehrávání; pokud je automatické přehrávání nezbytné z designových důvodů, zajistěte ovládací prvky pro pozastavení/zastavení, které jsou okamžitě dostupné pomocí klávesnice. U obsahu, který obsahuje pouze video (bez zvuku), zajistěte zvukový popis nebo textovou alternativu.

Přihlášení je klíčovým bodem celého procesu ověřování. Pokud formulář selže, všechny následující stránky se stanou nedostupnými a uživatelé často vnímají tuto řetězovou reakci jako jedinou překážku. Jedná se o stejnou chybu v označení formuláře jako u E·01, často v kombinaci se třemi konkrétními dílčími chybami: přepínač „Zobrazit heslo“ implementovaný jako tlačítko pouze s ikonou bez názvu a bez oznámení o změně stavu, CAPTCHA, která zcela znemožňuje použití čtečky obrazovky, a inline chyby („neplatné přihlašovací údaje“), které se zobrazují na obrazovce, ale nejsou oznamovány.

Zaškrtávací políčko „Zapamatovat si mě“ představuje další opakující se dílčí chybu: je zobrazeno jako stylizovaný <div>, přičemž skutečný <input> Jelikož je zaškrtávací políčko skryté mimo obrazovku, lze jej ovládat myší, nikoli však klávesnicí ani čtečkou obrazovky. Uživatel nemá možnost zvolit si trvalou relaci.

Použijte skutečné <input>, <label>a <button> prvky. Udělejte z přepínače pro zobrazení/skrytí hesla skutečné tlačítko s popisným názvem, který se mění podle aktuálního stavu ("Show password" / "Hide password") a oznámit tuto změnu pomocí aria-pressed. Zajistěte bezbariérovou alternativu k obrazovým CAPTCHÁM (zvuková CAPTCHA nebo – v ideálním případě – nahraďte CAPTCHU ověřením založeným na riziku či bezbariérovými variantami hCaptcha).

Čtečky obrazovky zobrazují stránku ve třech režimech navigace: podle nadpisů, podle orientačních bodů a podle odkazů. Stránka, která se dodává bez <h1>, aniž by <main>, <nav>a <footer> památky a bez lang="en" atribut na <html> prvek odstranil všechny tři tyto navigační režimy najednou. Uživatelé nemají možnost procházet stránku, nemají možnost přejít přímo k obsahu a čtečka obrazovky nemůže načíst správný modul pro výslovnost.

Jedná se o neobvykle závažnou chybu: chybějící jediný orientační bod vyvolá řetězovou reakci stížností, protože selhávají všechny navigační strategie čteček obrazovky, které se na něm zakládají. Stížnosti této kategorie obvykle uvádějí čtyři či pět konkrétních strukturálních problémů najednou a prezentují je jako důkaz toho, že web postrádá sémantický základ.

Každá stránka má přesně jednu <h1>, s podnadpisy (<h2>, <h3>) logicky vnořené. Oblasti obalte do prvků HTML5 pro orientační body: <header>, <nav>, <main>, <aside>, <footer>. Nastavit lang v kořenovém adresáři <html> prvek. Ověřte pomocí nástroje pro kontrolu obrysů nebo spusťte document.querySelectorAll('h1').length === 1 jako zkušební test v CI.

Většina testování přístupnosti se provádí v prohlížečích na stolních počítačích s NVDA nebo JAWS. Mobilní asistenční technologie – VoiceOver v systému iOS, TalkBack v systému Android – zobrazují stejný DOM odlišně, často s jinými chybami. Stížnosti opakovaně používají zkratku „mobile SRU“ (uživatel mobilního čtečky obrazovky) k označení selhání, která jsou specifická pro mobilní zobrazení: hamburgerové menu, které funguje s NVDA na stolním počítači, ale v VoiceOveru nereaguje, tlačítko Apple Pay, které je dostupné na notebooku, ale ne na ekvivalentní stránce pro iPhone, chybové zprávy, které se oznamují na stolním počítači, ale ne na mobilu.

Data naznačují, že žalovaní, u nichž je přístupnost na stolních počítačích jinak bezchybná, jsou i nadále žalováni kvůli problémům specifickým pro mobilní zařízení. Sladění s mobilními verzemi je samostatným kritériem pro úspěšné absolvování auditu.

Aplikaci otestujte alespoň pomocí funkcí VoiceOver v prohlížeči Safari pro iOS a TalkBack v prohlížeči Chrome pro Android, a to na stejných scénářích, jaké pokrývá testování kvality na počítači. Zvláštní pozornost věnujte interakcím pomocí gest, nativním platebním tlačítkům a hlášení o polích formuláře při jejich aktivaci. Pokud existuje nativní aplikace, proveďte u ní stejnou kontrolu – stížnosti se často týkají jak webové verze, tak aplikace v rámci stejného případu.

Překryv pro přístupnost je jediným příkladem v tomto katalogu, kde chyba vůbec nespočívá v samotném webu – nachází se v údajné opravné vrstvě, která byla přidána za účelem jejího odstranění. Stížnosti v této kategorii popisují dvě odlišné problémy. Prvním je, že překryvy ve skutečnosti neodstraňují základní překážky, takže se uživatel setkává se stejnými nefunkčními modálními okny, nesprávně označenými formuláři a neoznámenými chybami bez ohledu na to, zda je daný prvek přítomen. Druhá je ještě závažnější: překryvy někdy způsobují nové chyby tím, že vkládají nesprávné popisky, nesprávně používají role ARIA nebo zasahují do konfigurace asistenčních technologií uživatele.

Za zmínku stojí jedna podrobnost: stížnosti z let 2024 a 2025 stále častěji uvádějí jméno dodavatele overlayového řešení. Dvě konkrétní pasáže ve stížnostech jednoznačně zmiňují společnosti UserWay a AccessiBe, a nedávná opatření Federální obchodní komise (FTC) vedla k tomu, že přidání overlayového řešení nyní představuje výslovné riziko, že bude považováno za důkaz neuskutečnění skutečných nápravných opatření – nikoli za obranu proti soudnímu sporu.

Považujte překryvné vrstvy za dočasné řešení, nikoli za trvalou nápravu. Pokud je některá z nich v současné době nasazena, připravte plán skutečné nápravy, který se zaměří na základní kód, místo aby jej pouze maskoval. Osvědčeným postupem je kombinace následujících prvků: automatizovaný skener integrovaný do procesu CI, manuální kontrola podle standardu WCAG 2.2 AA, ruční testování s využitím alespoň jednoho čtečky obrazovky a navigace pouze pomocí klávesnice a průběžná kontrola přístupnosti v rámci procesu návrhu a vývoje.