Checklist WCAG 2.2 AA pro SaaS produkty a webové aplikace

Checklist WCAG 2.2 AA pro SaaS: přihlášení, formuláře, dialogy, navigace v SPA, tabulky, grafy, přetahování, časové limity a ACR, který chtějí kupující.

Redakce FixReportsAktualizováno 26. října 20268 min čtení

SaaS produkt má dvě oblasti, kde na přístupnosti záleží: marketingový web, který ho prodává, a aplikaci, kterou lidé používají každý den. Marketingový web selhává stejně jako jakýkoli jiný web: nízký kontrast, chybějící alternativní texty a formuláře bez popisků. Aplikace přidává vlastní problémy: přihlášení, které blokuje správce hesel, dialogy, které uvězní fokus klávesnice, navigaci v jednostránkové aplikaci, které si čtečky obrazovky nevšimnou, datové tabulky a grafy bez textu, přetahování bez alternativy a relace, které vyprší bez varování. Tento checklist prochází WCAG 2.2 na úrovni AA podle částí typického SaaS produktu.

Hlavní body

WCAG 2.2 se stala doporučením W3C v říjnu 2023 a přidala devět kritérií úspěšnosti, z toho šest na úrovni A nebo AA (W3C (otevře se v nové kartě)).
Kritérium Accessible Authentication (3.3.8, AA) znamená, že přihlášení nesmí záviset na zapamatování nebo opsání hesla, pokud ho lidé nemohou vložit nebo použít správce hesel (W3C (otevře se v nové kartě)).
Interaktivní cíle musí mít alespoň 24 na 24 CSS pixelů, nebo kolem sebe dostatek volného místa (2.5.8, AA) (W3C (otevře se v nové kartě)).
Zprávy jako „Uloženo“ nebo „3 výsledky“ se musí dostat ke čtečkám obrazovky bez přesunu fokusu (4.1.3, AA) (W3C (otevře se v nové kartě)).
Firemní zákazníci a veřejný sektor často žádají zprávu o shodě s požadavky na přístupnost (Accessibility Conformance Report, ACR), obvykle zpracovanou na šabloně VPAT od Information Technology Industry Council (ITI (otevře se v nové kartě)).

Proč na přístupnosti v SaaS záleží víc než u prezentačního webu?

SaaS produkt lidé používají celé hodiny, často proto, že ho vybral jejich zaměstnavatel. Bariéra na marketingové stránce vás stojí návštěvníka; bariéra v produktu může někomu znemožnit dělat jeho práci. Proto se větší zákazníci, univerzity a veřejné instituce na přístupnost stále častěji ptají ještě před nákupem a proto musí odpověď pokrývat aplikaci, nejen web.

Záleží na tom i proto, že automatické testy zachytí jen část problému. Nástroje jako axe-core najdou chyby v kódu, například chybějící popisky a nízký kontrast. Nedokážou ale posoudit, zda dialog vrací fokus na správné místo, zda jsou data z grafu dostupná jako text nebo zda lze pracovní postup dokončit klávesnicí. Aplikace potřebuje automatické kontroly i ruční testování.

Jak zpřístupnit registraci a přihlášení?

Právě u přihlašování přidala WCAG 2.2 pro SaaS nejdůležitější nový požadavek.

Povolte vkládání a správce hesel (3.3.8, AA). Neblokujte vkládání do polí pro heslo nebo kód a používejte autocomplete="username", autocomplete="current-password" a autocomplete="one-time-code", aby je prohlížeče a správci hesel mohli vyplnit.
Hádanky nesmí být jedinou cestou dovnitř. CAPTCHA, která po lidech chce opsat zkreslený text nebo vyřešit hádanku, je testem kognitivních funkcí. Nabídněte alternativu a dávejte přednost ochraně, která nevyžaduje akci uživatele (W3C (otevře se v nové kartě)).
Opatřete každé pole popiskem (1.3.1 a 3.3.2, A). Použijte viditelný <label> propojený s polem; zástupný text zmizí, jakmile člověk začne psát, a popiskem není.
Popisujte chyby textem (3.3.1, A) a navrhujte opravy (3.3.3, AA). „Heslo musí mít alespoň 12 znaků“ pomůže; samotný červený rámeček ne.
Neptejte se dvakrát (3.3.7, A). Pokud se vícekroková registrace už zeptala na název firmy nebo adresu, vyplňte je automaticky nebo je nabídněte k výběru, místo aby je lidé psali znovu.
Držte nápovědu na stejném místě (3.2.6, A). Pokud nabízíte chat, odkaz na nápovědu nebo kontaktní údaje, umístěte je na každé stránce procesu na stejné relativní místo.

Které vzory formulářů a chyb způsobují nejvíc selhání?

Ve formulářích se skrývá většina chyb aplikací. Průzkum WebAIM z roku 2026, který zahrnul milion domovských stránek, našel chybějící popisky formulářů na 51 % z nich (WebAIM (otevře se v nové kartě)), a aplikace mají formulářů mnohem víc než domovské stránky.

Dejte každému poli programově určitelný název a související ovládací prvky, například přepínače, seskupte pomocí <fieldset> a <legend>.
Informujte o chybách tam, kde si jich lidé všimnou: přesuňte fokus na souhrn chyb na začátku formuláře nebo na první neplatné pole a každou položku souhrnu propojte s jejím polem.
Povinná pole označujte textem, ne jen barvou (1.4.1, A).
Neodesílejte formulář ani neměňte kontext jen proto, že někdo vybral možnost (3.2.2, A); počkejte na výslovnou akci.

Jak se mají chovat dialogy, nabídky a vyskakovací panely?

Vlastní komponenty jsou místem, kde se podpora klávesnice a čteček obrazovky rozbíjí nejčastěji. Průvodce WAI-ARIA Authoring Practices Guide popisuje očekávané chování každého vzoru (W3C (otevře se v nové kartě)).

Dialogy: při otevření přesuňte fokus do dialogu, dokud je otevřený, držte v něm klávesu Tab, zavírejte ho klávesou Escape a vraťte fokus na prvek, který ho otevřel. Použijte nativní prvek <dialog> nebo role="dialog" s aria-modal="true" a názvem.
Žádné pasti pro klávesnici (2.1.2, A): z každé komponenty musí jít odejít klávesnicí.
Viditelný fokus (2.4.7, AA), který není schovaný za lepivými hlavičkami, cookie lištami ani chatovými widgety (2.4.11, AA, novinka ve verzi 2.2).
Bubliny a vyskakovací panely (1.4.13, AA), které lze zavřít klávesou Escape, nad které lze najet myší, aniž by zmizely, a které zůstanou zobrazené, dokud je člověk nezavře.
Jednoklávesové zkratky (2.1.4, A): pokud stisk klávesy s písmenem spouští akci, umožněte zkratky vypnout nebo přemapovat, nebo je aktivujte jen tehdy, když má fokus příslušná komponenta.

Jak řešit navigaci v jednostránkové aplikaci?

V jednostránkové aplikaci (SPA) se adresa URL mění bez načtení stránky, takže čtečky obrazovky nemusí oznámit, že se něco stalo.

Při každé změně trasy aktualizujte titulek dokumentu, aby měl každý pohled popisný titulek (2.4.2, A).
Přesuňte fokus na hlavní nadpis nového pohledu, nebo změnu oznamte ve zdvořilé živé oblasti (polite live region); frameworky jako Next.js k tomu mají vestavěný oznamovač změn tras (route announcer).
Zachovejte logické pořadí fokusu (2.4.3, A): po smazání položky by měl fokus přejít na rozumný sousední prvek, ne zpět na začátek stránky.
Umožněte přeskočit opakovanou navigaci (2.4.1, A), například odkazem pro přeskočení nebo orientačními oblastmi (landmarks).

Jak zpřístupnit dashboardy, datové tabulky a grafy?

Tabulky: používejte skutečné značky <table> s <th> a scope pro záhlaví a titulek tabulky (1.3.1, A). Mřížky postavené z prvků <div> potřebují úplný vzor ARIA grid, který je mnohem těžší udělat správně.
Grafy: dejte každému grafu textovou alternativu, která uvádí hlavní sdělení, a nabídněte data jako tabulku (1.1.1, A). K rozlišení datových řad nepoužívejte jen barvu (1.4.1, A); přidejte popisky nebo vzory.
Kontrast: text potřebuje 4.5:1 (1.4.3, AA) a čáry grafů, ikony a ohraničení polí potřebují 3:1 vůči pozadí (1.4.11, AA). Tmavý režim zkontrolujte zvlášť. Naše kontrola barevného kontrastu otestuje libovolnou dvojici barev.
Stavové zprávy (4.1.3, AA): „Uloženo“, „Nahrávání dokončeno“ a počty výsledků by měly používat role="status" nebo živou oblast, aby je čtečky obrazovky přečetly, aniž by lidé ztratili místo, kde právě jsou.

Co mění nová kritéria WCAG 2.2 ve webových aplikacích?

Kritérium	Úroveň	Co znamená v aplikaci
2.4.11 Focus Not Obscured (Minimum)	AA	Lepivé panely nástrojů, bannery a chatové widgety nesmí prvek s fokusem zcela zakrývat
2.5.7 Dragging Movements	AA	Cokoli, co se dělá tažením, například změna pořadí na kanbanové tabuli, potřebuje alternativu ovladatelnou jedním ukazatelem, například nabídku nebo tlačítka nahoru a dolů
2.5.8 Target Size (Minimum)	AA	Tlačítka a odkazy mají alespoň 24 × 24 CSS pixelů, nebo jsou rozmístěné tak, aby se kruh o průměru 24 pixelů kolem každého nepřekrýval s jiným
3.2.6 Consistent Help	A	Odkazy na nápovědu, chat a kontaktní údaje jsou na každé stránce na stejném relativním místě
3.3.7 Redundant Entry	A	Informace zadané už v tomtéž procesu se vyplní automaticky nebo je lze vybrat
3.3.8 Accessible Authentication (Minimum)	AA	Přihlášení bez memorování nebo opisování, pokud není povoleno vkládání, správci hesel nebo jiná metoda

WCAG 2.2 také zrušila kritérium 4.1.1 Parsing, které už nemá na přístupnost praktický vliv (W3C (otevře se v nové kartě)).

A co časové limity, rozvržení a zvětšení?

Časové limity relace (2.2.1, A): varujte lidi, než relace vyprší, a umožněte jim ji prodloužit jednoduchou akcí, pokud časový limit není nezbytný nebo delší než 20 hodin. Ukládání rozpracované práce zabrání nejhoršímu výsledku.
Přeskupení obsahu (1.4.10, AA): obsah musí fungovat při šířce 320 CSS pixelů (což odpovídá zvětšení na 400 % na obrazovce široké 1280 pixelů) bez posouvání ve dvou směrech; datové tabulky a podobný obsah jsou výjimkou.
Mezery v textu (1.4.12, AA): zvětšení výšky řádku a mezer mezi písmeny by nemělo text oříznout, což se u kontejnerů s pevnou výškou často stává.
Orientace (1.3.4, AA): nezamykejte aplikaci na výšku ani na šířku, pokud to není nezbytné.

Co je ACR a potřebujete ho?

Zpráva o shodě s požadavky na přístupnost (Accessibility Conformance Report, ACR) dokumentuje, jak produkt splňuje jednotlivá kritéria přístupnosti: podporuje, částečně podporuje, nebo nepodporuje, s poznámkami. Většina se zpracovává na šabloně VPAT, kterou vydává Information Technology Industry Council a která má verze pro WCAG, americké standardy Section 508 a evropskou normu EN 301 549 (ITI (otevře se v nové kartě)).

Federální úřady v USA musí podle Section 508 nakupovat přístupné technologie (Section508.gov (otevře se v nové kartě)) a veřejné instituce v EU se odvolávají na normu EN 301 549, takže B2B produkty, které těmto zákazníkům prodávají, jsou o ACR během zadávacího řízení často žádány. Poctivé ACR se seznamem známých nedostatků je pro kupující užitečnější než takové, které tvrdí plnou podporu. Mělo by vycházet z testování produktu včetně ručního; samotný automatický sken ho vyplnit nedokáže.

Pokud prodáváte spotřebitelům v EU, může se na způsob, jakým prodáváte online, vztahovat i Evropský akt o přístupnosti; jeho rozsah vysvětluje náš průvodce aktem EAA. Nejde o právní radu.

Jak má SaaS tým testovat přístupnost?

Automatizujte základy. Spouštějte axe-core nebo podobný engine v end-to-end testech a na marketingovém webu a při nových porušeních nechte build selhat. Náš bezplatný test přístupnosti spustí stejný engine na libovolné veřejné stránce.
Testujte klávesnicí. Projděte hlavní pracovní postupy, jako je registrace, vytvoření záznamu a změna nastavení, jen pomocí kláves Tab, Shift+Tab, Enter, mezerníku, Escape a šipek.
Testujte se čtečkou obrazovky. NVDA ve Windows a VoiceOver v macOS a iOS jsou zdarma. Ověřte, že se oznamují názvy, role, stavy a zprávy.
Zvětšujte a měňte velikost okna. Zkontrolujte zvětšení textu na 200 % a okno široké 320 pixelů.
Opravujte v design systému. Většina chyb pochází ze sdílených komponent; když tlačítko nebo dialog opravíte jednou, opravíte ho všude.

Často kladené otázky

Vztahuje se WCAG na části webové aplikace za přihlášením?

WCAG se vztahuje na jakýkoli webový obsah včetně stránek za přihlášením. Zda zákon vyžaduje, aby ji konkrétní produkt splňoval, záleží na jurisdikci a zákazníkovi, ale kupující, kteří se na přístupnost ptají, obvykle myslí celý produkt.

Může overlay zpřístupnit SaaS produkt?

Ne. Overlaye nemění kód vlastních komponent, a právě tam se chyby aplikací skrývají. Náš průvodce přístupnostními overlayi popisuje zásah FTC proti přednímu dodavateli overlayů.

Jakou část WCAG dokážou zkontrolovat automatické nástroje?

Jen část. Automatická pravidla spolehlivě najdou chybějící názvy, popisky a chyby kontrastu, ale mnoho kritérií, například smysluplné pořadí fokusu, užitečný alternativní text a srozumitelné chybové zprávy, musí posoudit člověk.

Na kterou verzi WCAG se zaměřit?

Aktuální verzí je WCAG 2.2 na úrovni AA. Mnoho zákonů a pravidel pro zadávání zakázek stále odkazuje na WCAG 2.1 AA; splnění 2.2 AA znamená i splnění 2.1 AA, s výjimkou zrušeného kritéria Parsing.

Musíme splnit úroveň AAA?

W3C nedoporučuje vyžadovat úroveň AAA pro celé produkty, protože některý obsah nemůže splnit všechna kritéria AAA. Obvyklým cílem je úroveň AA.