Nástroje pro automatické testování dostupnosti webu: Přehled pro designéry a vývojáře

Přístupný web není jen technická povinnost – je to základ dobrého designu. Přesto mnoho projektů skončí s desítkami přehlédnutých problémů, které uživatelům se zrakovým postižením nebo pohybovým omezením zásadně komplikují práci. Automatické testování přístupnosti je první obranná linie, která tyto problémy odhalí ještě před spuštěním webu.

Co je automatické testování přístupnosti a proč na něm záleží

Automatické testování přístupnosti je proces, při kterém softwarové nástroje analyzují webové stránky a porovnávají je s definovanými pravidly přístupnosti – především se standardem WCAG (Web Content Accessibility Guidelines). Výsledkem je přehled chyb a varování, které mohou bránit uživatelům v plnohodnotném přístupu k obsahu.

Proč na tom záleží? Podle dat Světové zdravotnické organizace žije s nějakou formou postižení přibližně 1,3 miliardy lidí. Nepřístupný web tyto uživatele fakticky vylučuje. A to nemluvíme jen o morální dimenzi – v řadě zemí EU přístupnost webů veřejného sektoru ukládá zákon, a požadavky se postupně rozšiřují i na komerční sféru.

Pro designéry a vývojáře je automatické testování konkrétní, opakovatelný způsob, jak sledovat kvalitu projektu v čase. Bez nástrojů se přístupnost snadno stává abstraktním pojmem; s nimi se mění na seznam konkrétních úkolů.

Jak automatické nástroje fungují a co dokážou odhalit

Automatické nástroje pro přístupnost pracují tak, že analyzují DOM (Document Object Model) stránky a porovnávají strukturu, atributy a vizuální vlastnosti prvků s pravidly odvozenými z WCAG. Výsledek je obvykle kategorizovaný seznam chyb s odkazem na konkrétní prvek na stránce.

Typické problémy, které nástroje spolehlivě odhalí:

Barevný kontrast – nedostatečný poměr kontrastu textu vůči pozadí (WCAG vyžaduje minimálně 4,5:1 pro normální text)
Chybějící nebo nevhodné alternativní texty obrázků (alt atributy)
Nesprávná struktura nadpisů (přeskočení úrovní H1 → H3)
Formulářové prvky bez popisků (label)
Chybějící nebo špatně implementované ARIA atributy
Nedostupné interaktivní prvky (tlačítka bez textu, odkazy bez smysluplného popisu)

Nástroje pracují buď staticky (analýza HTML kódu), nebo dynamicky (spuštění stránky v prohlížeči a analýza výsledného DOM). Dynamická analýza je přesnější, protože zachytí i obsah generovaný JavaScriptem.

Omezení automatického testování: co stroje neodhalí

Automatizace pokryje odhadem 30–40 % všech přístupnostních problémů. Zbytek vyžaduje lidský úsudek – a to je důvod, proč automatické nástroje nelze brát jako finální certifikát přístupnosti.

Co stroje spolehlivě neodhalí:

Zda je alternativní text obrázku smysluplný (nástroj ověří jeho existenci, ne kvalitu)
Logiku navigace a srozumitelnost toku stránky pro uživatele čtečky obrazovky
Kognitivní přístupnost – zda je obsah pochopitelný pro lidi s dyslexií nebo kognitivním postižením
Použitelnost pouze s klávesnicí v komplexních interakcích (modální okna, drag-and-drop)
Správnost dynamického obsahu a ARIA live regions v reálném použití

Dobrá praxe je kombinovat automatické testování s manuální kontrolou a občasným testováním se skutečnými uživateli nebo se čtečkou obrazovky jako NVDA nebo VoiceOver. Automatizace šetří čas na rutinní chyby; manuální testování řeší zbytek.

Přehled nejpoužívanějších nástrojů pro testování přístupnosti

Na trhu existuje několik nástrojů, které se staly de facto standardem – každý s trochu jiným zaměřením a formou použití.

axe-core

axe-core je open-source testovací engine od společnosti Deque Systems, který pohání desítky dalších nástrojů a rozšíření. Lze ho integrovat přímo do testovacích frameworků (Jest, Cypress, Playwright) nebo použít jako samostatné rozšíření prohlížeče axe DevTools. Jeho výhodou je velmi nízká míra falešných pozitivních výsledků – hlásí jen to, co je skutečně problém.

Lighthouse

Lighthouse od Googlu je auditní nástroj zabudovaný přímo do Chrome DevTools. Hodnotí přístupnost jako součást širšího auditu (výkon, SEO, best practices). Přístupnostní skóre je přehledné a srozumitelné i pro netechnické uživatele, ale pokrývá méně pravidel než specializované nástroje. Hodí se jako rychlý první pohled nebo pravidelná kontrola v CI/CD pipeline přes Lighthouse CI.

WAVE

WAVE (Web Accessibility Evaluation Tool) od WebAIM je oblíbený zejména mezi designéry, protože vizuálně překrývá stránku ikonami přímo na místě problémů. Okamžitě vidíte, kde chybí popisek nebo kde je nedostatečný kontrast – bez nutnosti číst technické reporty. Dostupný jako rozšíření prohlížeče i online nástroj na wave.webaim.org.

Další nástroje, které stojí za zmínku

Pa11y – CLI nástroj vhodný pro automatizaci a CI/CD integrace, postavený na axe-core a HTMLCodeSniffer
Accessibility Insights – rozšíření od Microsoftu s průvodcem pro manuální testování
Stark – plugin pro Figmu a Sketch zaměřený na kontrast a barvoslepost, ideální ve fázi prototypování
Siteimprove Accessibility – komerční platforma pro průběžné monitorování celých webů

Integrace nástrojů do designového a vývojového procesu

Nejefektivnější přístup je zapojit testování přístupnosti co nejdříve – ideálně ještě ve fázi designu, ne až při finálním QA.

V praxi to může vypadat takto:

Fáze designu: Plugin Stark ve Figmě kontroluje barevný kontrast a simuluje barvoslepost přímo při tvorbě vizuálů. Chyby se opraví dřív, než se vůbec začne kódovat.
Fáze vývoje: axe-core integrovaný do unit nebo end-to-end testů hlásí přístupnostní regrese automaticky při každém commitu.
CI/CD pipeline: Lighthouse CI nebo Pa11y spuštěné jako součást build procesu zajistí, že žádný deploy neprojde s kritickými přístupnostními chybami.
Průběžné monitorování: Komerční nástroje jako Siteimprove nebo Monsido sledují přístupnost celého webu v čase a upozorní na nové problémy způsobené aktualizacemi obsahu.

Klíčové je, aby testování přístupnosti nebylo jednorázová akce před spuštěním, ale součást standardního vývojového cyklu – stejně jako testování výkonu nebo bezpečnosti.

Tipy pro výběr správného nástroje podle vašich potřeb

Volba nástroje závisí na velikosti projektu, složení týmu a fázi vývoje. Neexistuje jedno univerzální řešení.

Pokud jste designér bez hlubokých technických znalostí, začněte s WAVE nebo Stark. Vizuální zpětná vazba přímo na stránce nebo v návrhovém nástroji je srozumitelná bez nutnosti číst technické reporty.

Pokud jste vývojář pracující na středně velkém projektu, axe DevTools jako rozšíření prohlížeče plus integrace axe-core do vašich testů pokryje většinu potřeb. Je open-source, dobře zdokumentovaný a má aktivní komunitu.

Pro velké weby nebo agentury spravující více klientů má smysl investovat do komerčního řešení s průběžným monitorováním a reportingem – Siteimprove nebo podobné platformy ušetří hodiny manuální práce.

Majitelé menších webů, kteří nepíší kód, mohou začít jednoduše: nainstalovat rozšíření WAVE nebo Lighthouse do Chromu a spustit audit na svém webu. Výsledky jsou srozumitelné i bez technického zázemí.

Dobrý základ: typografie a vizuální design jako základ přístupnosti

Žádný nástroj neopraví špatně navržený web. Přístupnost začíná designovými rozhodnutími, která předcházejí jakémukoli testování.

Sémantické HTML je základ, na kterém všechny nástroje stavějí. Správně strukturovaný dokument s nadpisy, seznamy a oblastmi stránky (header, main, footer) je přístupný téměř automaticky – a nástroje ho snáze auditují.

Typografie hraje zásadní roli. Dostatečná velikost písma (minimálně 16px pro tělo textu), rozumný řádkový proklad a dobrý kontrast nejsou jen estetická rozhodnutí – jsou to přístupnostní požadavky. Web s krásným písmem v šedé barvě na bílém pozadí může selhat v WCAG testu kontrastu a zároveň být nečitelný pro uživatele s oslabeným zrakem.

Vizuální hierarchie – jasné rozlišení nadpisů, odstavců a interaktivních prvků – pomáhá nejen uživatelům čteček obrazovky, ale všem. Přístupný design je zkrátka dobrý design.

Časté otázky

Jaký je rozdíl mezi automatickým a manuálním testováním přístupnosti?

Automatické testování používá software k rychlé analýze kódu a odhalí přibližně 30–40 % přístupnostních problémů – zejména technické chyby jako chybějící atributy nebo nedostatečný kontrast. Manuální testování zahrnuje procházení webu klávesnicí, testování se čtečkou obrazovky a hodnocení srozumitelnosti obsahu. Obě metody se doplňují a nelze jednu nahradit druhou.

Musím splňovat WCAG, i když nejsem státní instituce?

Formálně závisí na legislativě vaší země. V EU se požadavky na přístupnost rozšiřují i na soukromý sektor prostřednictvím Evropského aktu o přístupnosti (EAA), který vstoupí v platnost v červnu 2025. Prakticky vzato ale přístupný web oslovuje širší publikum, lépe se indexuje ve vyhledávačích a snižuje právní rizika – takže má smysl i bez zákonné povinnosti.

Dokáže Lighthouse nahradit specializované nástroje jako axe nebo WAVE?

Ne zcela. Lighthouse je skvělý pro rychlý přehled a integraci do CI/CD, ale jeho přístupnostní audit pokrývá méně pravidel než axe-core nebo WAVE. Pro seriózní přístupnostní audit doporučujeme Lighthouse doplnit alespoň jedním specializovaným nástrojem.

Jak často bych měl přístupnost webu testovat?

Ideálně průběžně – automatické testy by měly běžet při každém nasazení nové verze. Komplexnější manuální audit má smysl provádět při větších redesignech nebo přibližně jednou za rok. Weby s dynamickým obsahem (e-shopy, zpravodajské portály) by měly mít nastavené průběžné monitorování.

Jsou tyto nástroje vhodné i pro testování mobilních webů?

Ano. Lighthouse, axe DevTools i WAVE testují responzivní weby a mobilní zobrazení. Lighthouse navíc umí simulovat mobilní zařízení přímo v Chrome DevTools. Nicméně pro testování nativních mobilních aplikací jsou potřeba jiné nástroje – například Accessibility Scanner od Googlu pro Android nebo Xcode Accessibility Inspector pro iOS.