Přístupnost přihlašování a CAPTCHA – Jak na přístupnost

Umělá inteligence a weboví roboti jsou stále sofistikovanější. Dřívější metody rozlišení, zda k webu přistupuje robot nebo člověk za účelem zamezení spamu či jiné nežádoucí aktivitě, tak přestávají být účinné. Situace se ještě více komplikuje s příchodem autonomních agentů, kteří by z přístupu být vyloučeni neměli. V tomto článku se podíváme na to, jak se k problematice různých podob opatření pro odlišení robotů od lidí na webu staví standard WCAG a hledisko přístupnosti.

CAPTCHA jako častá překážka

CAPTCHA, tedy zjednodušeně test pro odlišení skutečných uživatelů od robotů, je jednou z největších bariér, se kterou se uživatelé s nějakou formou postižení na webu potýkají. Poukazuje na to i závěr z průzkumu organizace WebAIM uskutečněného na přelomu roku 2023 a 2024, kdy uživatelé odečítačů označili CAPTCHA dokonce za nejpalčivější problém, na který na webu narážejí.

Proč je CAPTCHA problematická?

CAPTCHA představuje nejčastěji následující problémy v přístupnosti:

• Slabozrací a barvoslepí uživatelé mohou mít problém rozluštit obrázkovou CAPTCHA, pro nevidomé je obrázková CAPTCHA pochopitelně zcela nepřekonatelnou překážkou. Tito uživatelé mohou mít problém také se zvukovou CAPTCHA, a to především pokud jsou odkázáni na přepis textu z nekvalitní zvukové nahrávky nebo nahrávky v jazyce, kterému nerozumí.

• Lidé s motorickým postižením či lidé ovládající počítač pomocí hlasových povelů nebo výhradně pomocí klávesnice nemusejí být schopni pracovat s CAPTCHA, pokud její ovládání vyžaduje myš, dotykové nebo jiné polohovací zařízení.

• Lidé s kognitivním postižením nemusejí být schopni CAPTCHA vyřešit. Jedná se například o lidi se špatnou pamětí, dyslexií nebo dyskalkulií.

Ověření nevyžadující vyřešení úlohy

Moderní řešení jsou do značné míry schopna rozpoznat lidského návštěvníka, aniž by vyžadovaly ověření prostřednictvím vyřešení nějaké úlohy či provedení nějaké interakce s webovou stránkou. Striktně řečeno se tedy nejedná o CAPTCHA, ale o algoritmy, jež jsou nejčastěji založené na sledování chování uživatele napříč jednou nebo více stránkami, vyhodnocení reputace IP adresy návštěvníka a typicky využívají cookies z široké sítě stránek. Asi nejznámějšími příklady takových technologií jsou Cloudflare Turnstile, hCaptcha nebo reCAPTCHA od společnosti Google či její novější a doporučený nástupce Google Cloud Fraud Defense. Nutno ale dodat, že ani tato moderní řešení nejsou stoprocentně spolehlivá, a proto někteří autoři stránek v případě vyhodnocení, že návštěvník pravděpodobně není člověk, mohou jako pojistku i tak nakonec zobrazit klasickou CAPTCHA. Navíc některé z těchto technologií nemusí fungovat při anonymním prohlížení webových stránek.

Proč není CAPTCHA zakázána z důvodu špatné přístupnosti?

WCAG ve svém vysvětlujícím dokumentu ke kritériu úspěšnosti 1.1.1 – Non-text Content uvádí, že jakékoliv druhy CAPTCHA budou nepřekonatelné uživateli s určitou formou postižení. Kdyby však WCAG CAPTCHA jednoduše zakázalo, tak by hrozilo, že webové stránky by se místo odvrácení od CAPTCHA raději rozhodly nenásledovat standard WCAG, což by znamenalo vytvoření překážek pro mnohem více uživatelů s nějakou formou postižení. Proto WCAG formuluje požadavky na CAPTCHA tak, aby vyhovělo potřebám většiny uživatelů s postižením a zároveň aby tyto požadavky byly přijatelné autory webových stránek.

Požadavky na CAPTCHA

S ohledem na zmíněné důvody jsou ve WCAG stanoveny minimální požadavky na CAPTCHA tak, že webové stránky mají poskytnout alespoň dvě formy CAPTCHA, například obrázkovou a zvukovou. Autoři jsou však pobídnuti k tomu, aby splnili následující dodatečné požadavky:

• nabídnout tři nebo více forem CAPTCHA pro různé smysly;

• poskytnout přístup k lidské zákaznické podpoře, která může CAPTCHA obejít;

• nevyžadovat CAPTCHA pro autorizované uživatele.

Bezpečné přihlašování

S tématem CAPTCHA souvisí také zajištění autentizace uživatele, tedy ověření jeho totožnosti, například při přihlašování nebo registraci, neboť prostředkem pro autentizaci může být právě CAPTCHA.

Test kognitivních funkcí

WCAG při popisu požadavků na přístupné a bezpečné přihlašování pracuje s pojmem „test kognitivních funkcí“, přičemž webová stránka nesmí tento test po uživateli vyžadovat, nejedná-li se o výjimku, viz níže. Za tento test se považují následující způsoby ověření uživatele:

• zapamatování si nějaké informace nebo obrázku, například uživatelského jména a hesla, dříve uživatelem nahraného obrázku či nakreslení nějakého vzorce;

• přepsání nějakého textu, například z jiného zařízení nebo z audio nahrávky;

• vyřešení nějakého rébusu nebo matematické úlohy.

Výjimka pro rozpoznávání objektů

Na úrovni AA standardu WCAG, která je dostačující pro splnění požadavků české a evropské legislativy, existuje výjimka pro test kognitivních funkcí, kdy je z hlediska přístupnosti přijatelné, jestliže tento test spočívá v rozpoznávání objektů. Například uživateli je zobrazena mřížka obrázků a úkolem uživatele je vybrat obrázky, na kterých se vyskytuje auto. Jiným příkladem může být výběr obrázku, který uživatel nahrál do systému dříve při vytváření účtu. Tato výjimka se vyskytuje konkrétně v kritériu úspěšnosti 3.3.8 – Accessible Authentication (Minimum) ale už neexistuje v kritériu úspěšnosti 3.3.9 – Accessible Authentication (Enhanced), které však spadá do úrovně AAA nevyžadované legislativou.

Používání správců hesel

Vyžadování zadání uživatelského jména a hesla webovou stránkou není přestupkem vůči požadavkům WCAG na přístupnost za podmínek, že není webovou stránkou blokováno vkládání těchto přihlašovacích údajů ze systémové schránky nebo automatické vyplnění prostřednictvím doplňků do webových prohlížečů, což jsou metody používané správci hesel.

Vícefaktorové ověření

Vícefaktorové ověření čili například potvrzení přihlášení na druhém zařízení, pokud tedy splňuje požadavky již zmíněného kritéria úspěšnosti 3.3.8 – Accessible Authentication (Minimum), je považováno za přijatelnou a přístupnou formu ověření uživatele. Je tomu tak i v případě, kdy je potřeba přepsat ověřovací kód z druhého zařízení do prvního, jestliže je možné kód zkopírovat a přeposlat do prvního zařízení například pomocí e-mailu. Pro posílení bezpečnosti zde navíc může být potřeba ověřit svou totožnost prostřednictvím biometrických údajů jako otisk prstu nebo sken obličeje. To ale samo osobě může také představovat bariéru v přístupnosti, takže je doporučeno nabídnout volbu mezi různými metodami biometrického ověření nebo ověření pomocí PINu.

Přihlášení pomocí účtu třetí strany

Další doporučenou možností pro bezpečné přihlašování ke zvážení je umožnit uživatelům přihlásit se pomocí uživatelského účtu třetí strany, například přes Google, Facebook nebo Apple, případně využít bankovní identitu. Nevýhodou tohoto řešení však pochopitelně je, že nemusí být zachována anonymita uživatele.

Passkey

Passkey je moderní, bezpečnou a přístupnou alternativou ke klasickému přihlašování pomocí uživatelského jména a hesla, která je v případě webových stránek založená na webovém standardu WebAuthn. Webová stránka v případě této technologie spolupracuje s operačním systémem nebo webovým prohlížečem, přičemž uživatel ověřuje svou totožnost na základě vlastnictví zařízení, které Passkey ověřuje, a poskytnutí biometrických údajů (např. otiskem prstu či rozpoznáním obličeje) nebo PINu.

Závěr

Bohužel nelze doporučit nějaké jednoznačné nebo univerzální řešení. Vždy závisí na konkrétní webové stránce a analýze rizik či limitů spojených s různými metodami ověření uživatele. Obecně by ale měla být snaha nevyžadovat po uživatelích interakci v podobě náročných úloh. Pokud jde o CAPTCHA, tak bližšímu srovnání dostupných řešení a doporučení se případně věnuje článek od autority W3C Inaccessibility of CAPTCHA.

Související kritéria úspěšnosti standardu WCAG

Výše zmíněná doporučení vycházejí jednak z dobré praxe, jednak z následujících kritérií úspěšnosti webového standardu WCAG 2.2:

• 1.1.1 – Non-text Content.

• 3.3.8 – Accessible Authentication (Minimum).

• 3.3.9 – Accessible Authentication (Enhanced).

Autor: Adam Samec