Modelová situace: jak e-shop zavádí přístupnost
Podívejme se, jak může e-shop přejít od prvního zmapování problémů k opravám, automatickým kontrolám a manuálnímu ověření přístupnosti.
Výchozí situace
Představme si středně velký e-shop, který prodává zákazníkům v EU. Vývojový tým má několik lidí a pravidelně nasazuje změny. Vedení ví o Evropském aktu o přístupnosti (EAA), přístupnost však zatím neřešilo systematicky – opravilo se jen to, na co si někdo konkrétně stěžoval.
Co se obvykle děje
Téma se otevře zvenčí: článkem, dotazem právníka nebo stížností zákazníka, po které může přijít kontrola. Firma si objedná jednorázový audit a dostane PDF se 180 nálezy. A tam vše skončí.
Report je totiž napsaný pro auditora, ne pro vývojáře. Polovina nálezů je tatáž chyba na dvaceti stránkách. Nikdo neví, čím začít a co je vlastně kritické. A i když se část nálezů opraví, za půl roku přijde redesign a problémy se vrátí.
To je jádro problému: přístupnost není jednorázová oprava a při změnách se může zhoršit. Strojově ověřitelnou část lze sledovat automatickými kontrolami při domluvených změnách, zbytek potřebuje pravidelné manuální ověření.
Jak postupovat od zjištění k průběžné kontrole
Začínáme bezplatným vstupním skenem klíčových stránek. Nejde o audit, ale o první odhad strojově rozpoznatelných problémů v domluveném rozsahu.
Potom podle rozsahu vybereme axe-core, IBM Equal Access nebo vhodnou kombinaci a kontroly zapojíme do vašeho CI/CD, například GitHub Actions či GitLab CI. Více nástrojů není automaticky lepší: jejich pravidla se mohou překrývat, proto výsledky sjednocujeme a odstraňujeme duplicity. Při domluvených bězích mohou upozornit na nové strojově rozpoznatelné problémy krátce po změně.
Kontroly nespouštíme jen na statických stránkách. Pomocí Playwrightu můžeme připravit stavy, které vzniknou až po interakci: po přihlášení, po otevření modálního okna a v jednotlivých krocích checkoutu a formulářů. Samotný statický sken se bez připraveného scénáře do těchto stavů nedostane; i po jejich otevření však automatika pokrývá pouze strojově rozpoznatelnou část.
Report strukturujeme podle závažnosti a nálezy mapujeme na relevantní kritéria WCAG a EN 301 549. Ke každému přidáme doporučení k opravě a duplicity sloučíme. Vývojář dostane seznam konkrétních úkolů a management přehled o stavu.
WCAG 2.2 používáme jako aktuálnější odborný cíl. Při povinném posuzování zároveň ověříme, kterou verzi normy vyžaduje konkrétní právní nebo smluvní rámec. Automatický report sám o sobě není právním potvrzením souladu.
Co vám takový postup přinese
- Místo pocitu víte, v jakém jste stavu, a máte to podložené.
- Snížíte riziko, že se již opravený strojově rozpoznatelný problém nepozorovaně vrátí.
- Pro případnou kontrolu máte technický podklad o zjištěném stavu; nejde však o automatický důkaz právního souladu.
- Vývojáři dostávají nálezy v době, kdy mají kód ještě v čerstvé paměti, ne až za půl roku.
První krok
Bezplatný vstupní sken poskytne první odhad strojově rozpoznatelných problémů v domluveném rozsahu, například na vybraných stránkách nákupního procesu a formulářů. Jeho rozsah domluvíme na nezávazné konzultaci.