Kontroly přístupnosti

Přístupný checkout: co musí zvládnout zákazník bez myši

Zákazník prošel katalog, vybral produkt a vložil ho do košíku. Potom vyplní formulář, stiskne tlačítko „Objednat“ a nic se nestane. Někde je chyba, ale on ji nevidí – odečítač obrazovky mu ji nepřečetl. Zkusí to znovu, opět bez odezvy, a odejde. Vy uvidíte jen opuštěný košík.

Checkout patří mezi nejcitlivější části e-shopu. Zákazník v něm musí dokončit několik navazujících kroků a bariéra může vést k opuštění nákupu. Proto má při kontrole přístupnosti vysokou prioritu.

Běžné problémy v checkoutu a jak je řešit

Každé pole musí mít popisek propojený v kódu, nestačí jen text, který se u něj vizuálně zobrazuje. Pokud ho nemá, odečítač obrazovky oznámí „textové pole“ a zákazník netuší, zda má napsat jméno, město nebo číslo domu.

Časté chyby, které nacházíme:

Chyby je třeba oznámit, ne jen obarvit

Jde o závažný typ bariéry v checkoutu. Chybová hláška může být v HTML, ale nemusí být programově propojena s polem ani oznámena odečítači obrazovky. Uživatel potom vidí nebo slyší jen část informace potřebné k opravě vstupu.

Přístupný formulář musí chybu oznámit, propojit ji s konkrétním polem a umožnit uživateli snadno se k ní dostat. Podle návrhu může pomoci přesun zaměření na souhrn chyb nebo na první chybné pole; nejde o jedno univerzální pravidlo pro každý formulář. Text hlášky má říci, co je špatně a jak to napravit – „Neplatný vstup“ nestačí. Chyba navíc nesmí být oznámena pouze barvou; červený rámeček s nízkým kontrastem nemusí slabozraký zákazník vidět.

Pořadí prvků a časové limity

Pořadí, ve kterém se zaměření posouvá klávesou Tab, musí zachovat význam a ovladatelnost obsahu; nemusí mechanicky kopírovat jeho vizuální rozložení. V dynamickém checkoutu se kroky vykreslují postupně, sekce se rozbalují a zaměření může zůstat tam, kde už nic není. Po otevření skutečně modálního okna, například při výběru pobočky nebo potvrzení adresy, se zaměření přesune dovnitř a zůstane v něm. Okno musí mít způsob zavření dostupný z klávesnice; Escape je běžná možnost, ne jediný přípustný mechanismus.

Časové limity jsou další častou překážkou. Rezervace košíku, vypršení platnosti platební relace či automatické odhlášení mohou mít své opodstatnění, zákazník používající klávesnici nebo odečítač však může potřebovat více času. Pokud nejde o výjimku povolenou příslušným kritériem WCAG, musí být uživatel na limit upozorněn a dostat možnost ho vypnout, upravit nebo prodloužit.

Výběr dopravy a platby

Nákup se zde může přerušit kvůli vlastním ovládacím prvkům vytvořeným místo standardních přepínačů. Výsledkem mohou být dlaždice s logy dopravců, na které nelze přesunout zaměření nebo které po zaměření nelze vybrat klávesnicí.

Ověřujeme, že lze každou možnost vybrat klávesnicí, že odečítač přečte její název i cenu, že je zřejmé, která možnost je právě zvolena, a že se zákazník po změně dopravy dozví, co se přepočítalo. Stejně kontrolujeme krok platby včetně vložených rámců platební brány – ty jsou součástí vašeho nákupního procesu bez ohledu na to, kdo je dodal.

Co vám přístupný checkout přinese

Strojově ověřitelné části checkoutu kontrolujeme automatizovaně napříč reálnými stavy – po přihlášení, po otevření modálního okna či po odeslání formuláře. Scénáře ovládané klávesnicí a smysluplnost chybových hlášek prověří také člověk. Tato kombinace pomáhá odhalit chyby po změně, aniž by slibovala úplné pokrytí.

Výstupem je report s mapováním na relevantní kritéria WCAG a EN 301 549. WCAG 2.2 používáme jako aktuálnější odborný cíl; pro právní nebo smluvní posouzení je třeba potvrdit požadovanou verzi normy. Report poskytne technické podklady, ne automatickou právní záruku souladu.

Další krok

Pokud máte podezření, že bariéry v checkoutu brání dokončení nákupu, domluvíme na nezávazné konzultaci vhodný rozsah automatické i manuální kontroly.

Související témata

Mohlo by vás také zajímat

Na část nových chyb může upozornit už kontrola při release

Automatizované kontroly mohou při release upozornit na nové strojově zjistitelné chyby v již zkontrolovaných částech.