Prístupnosť webu po roku 2025: Čo má firma technicky skontrolovať

Čo znamená prístupnosť webu a prečo sa o nej hovorí práve teraz

Prístupnosť webu znamená, že stránku alebo aplikáciu dokáže použiť aj človek, ktorý nevidí obrazovku, neovláda myš, používa čítačku obrazovky alebo má inú formu obmedzenia. V praxi ide o kontrast textu, ktorý sa dá prečítať aj pri slabšom zraku, formuláre, ktoré sa dajú vyplniť len klávesnicou, a obsah, ktorý má zmysel aj bez farby ako jediného nositeľa informácie.

Téma sa v posledných mesiacoch objavuje častejšie z jedného konkrétneho dôvodu: European Accessibility Act, smernica Európskej únie o prístupnosti produktov a služieb, sa od 28. júna 2025 už reálne uplatňuje na relevantné produkty a služby na trhu EÚ. Firmy, ktoré tému doteraz odkladali ako „niečo pre veľké korporácie“, teraz zisťujú, že sa ich to týka priamejšie, než čakali, najmä v e-commerce a bankových službách.

WCAG 2.2 a European Accessibility Act: dva odlišné dokumenty, ktoré sa dopĺňajú

V komunikácii o prístupnosti webu sa často miešajú dva odlišné dokumenty, ktoré riešia rôzne otázky. Rozlíšenie medzi nimi rozhoduje o tom, čo firma vlastne potrebuje skontrolovať.

WCAG 2.2: technický štandard, nie zákon

Web Content Accessibility Guidelines (WCAG) je technický štandard konzorcia W3C, ktorý definuje konkrétne, testovateľné kritériá prístupnosti webového obsahu. Aktuálna verzia WCAG 2.2 je oficiálnym odporúčaním W3C od 12. decembra 2024 a nadväzuje na WCAG 2.1 z júna 2018. Obsah, ktorý spĺňa WCAG 2.2, automaticky spĺňa aj staršie verzie 2.0 a 2.1, takže prechod na 2.2 nič nekazí, len pridáva niekoľko nových kritérií, napríklad k viditeľnosti fokusu (kritérium „Focus Not Obscured“) a k prístupnej autentifikácii bez spoliehania sa výhradne na pamäťové úlohy.

WCAG samo osebe nie je zákon. Je to referenčný technický rámec, na ktorý sa právne predpisy v EÚ aj mimo nej bežne odvolávajú, keď definujú, čo znamená „prístupný“ digitálny obsah.

European Accessibility Act: právny rámec, ktorý sa odvoláva na štandardy

Smernica (EÚ) 2019/882, European Accessibility Act (EAA), je naopak právny predpis. Cieľom je zjednotiť požiadavky na prístupnosť vybraných produktov a služieb naprieč členskými štátmi EÚ, aby firmy nemuseli riešiť odlišné národné pravidlá v každej krajine zvlášť. Členské štáty mali smernicu transponovať do národného práva do 28. júna 2022 a samotné požiadavky sa na relevantné produkty a služby uplatňujú od 28. júna 2025.

Medzi oblasti, ktoré smernica pokrýva, patrí okrem iného e-commerce, bankové služby, telefónne a audiovizuálne služby, e-knihy a niektoré typy hardvéru a samoobslužných terminálov. Presný rozsah povinností, prípadné výnimky (napríklad pre mikropodniky) a to, či sa konkrétna povinnosť týka práve vášho biznisu, je potrebné vždy overiť priamo v aktuálnom znení smernice alebo s právnikom špecializovaným na túto oblasť. Tento článok zámerne neuvádza konkrétnu hranicu veľkosti firmy ako všeobecné pravidlo, pretože podmienky sa líšia podľa typu produktu či služby a podľa toho, ako smernicu do svojho práva premietol konkrétny členský štát.

Kto má prístupnosť webu na starosti

Prístupnosť webu nemusí riešiť samostatné oddelenie. V menšej firme ju zvládne dizajnér alebo vývojár, ktorý si osvojí základnú disciplínu: kontrolovať kontrast a klávesovú navigáciu priebežne, nie až na konci. Väčší tím zvyčajne určí jednu zodpovednú osobu, ktorá nové komponenty pred nasadením prejde podľa kontrolného zoznamu nižšie a rieši spätnú väzbu od používateľov, ktorí na bariéru narazia.

Pri väčšom webe alebo pri projekte, kde je prístupnosť webu priamo spojená s právnou povinnosťou (napríklad e-shop alebo banková aplikácia v pôsobnosti European Accessibility Act), sa oplatí zveriť technickú kontrolu externému špecialistovi, ktorý pozná aktuálne kritériá WCAG 2.2 a nemá väzbu na pôvodné rozhodnutia dizajnu. Nezávislý pohľad odhalí bariéry, ktoré si tím zvyknutý na vlastný web už dávno prestal všímať.

Technický kontrolný zoznam prístupnosti webu

Nasledujúca tabuľka zhŕňa oblasti, ktoré sa pri technickej kontrole prístupnosti overujú najčastejšie, spolu s konkrétnym kritériom WCAG, na ktoré sa dá odvolať pri komunikácii s vývojárskym tímom.

Tabuľka slúži ako spoločný jazyk medzi firmou a vývojárskym tímom, nie ako vyčerpávajúci audit. Odvolanie sa na konkrétne číslo kritéria namiesto všeobecného „urobte to prístupnejšie“ výrazne skracuje diskusiu o tom, čo presne treba zmeniť.

Ako v praxi prebieha technická kontrola prístupnosti

1. Automatizovaná kontrola ako prvý filter. Nástroje na skenovanie stránky odhalia časť problémov (chýbajúci alt text, nedostatočný kontrast, chýbajúce popisky) rýchlo a lacno, ale bežne pokryjú len zlomok reálnych bariér.
2. Manuálna kontrola kľúčových tokov. Objednávka, registrácia, kontaktný formulár a hlavná navigácia sa prejdú výhradne klávesnicou a so zapnutou čítačkou obrazovky.
3. Kontrola sémantiky kódu. Overí sa, či stránka používa správne HTML značky namiesto vizuálne podobných, ale sémanticky prázdnych `div` prvkov, a či vlastné komponenty majú správne ARIA atribúty.
4. Test s reálnymi používateľmi, ak je to možné. Pozorovanie človeka, ktorý web ovláda čítačkou obrazovky alebo výhradne klávesnicou, odhalí bariéry, ktoré si automatizovaný nástroj ani interný tím nevšimnú.
5. Zoznam zistení zoradený podľa závažnosti. Rozlišuje sa medzi bariérou, ktorá úplne znemožní dokončiť úlohu, a menším nedostatkom, ktorý sťažuje, ale neblokuje.
6. Postupná náprava, nie jednorazový zásah. Kritické bariéry (napríklad nefunkčný checkout bez myši) sa riešia okamžite, ostatné podľa priority v pravidelných vydaniach.

Časté chyby, ktoré sa v praxi opakujú

Tieto nedostatky sa objavujú aj na weboch, ktoré inak pôsobia moderne a esteticky dobre navrhnuto, pretože prístupnosť sa málokedy testuje priebežne počas vývoja.

• Farba ako jediný nositeľ informácie. Chybové pole formulára je označené len červeným orámovaním bez textu, takže človek, ktorý farby nerozlišuje, chybu nezaregistruje.
• Placeholder text namiesto skutočného popisku. Text v poli zmizne po kliknutí, takže si používateľ nepamätá, čo pole vyžadovalo, a čítačka obrazovky pole často ani neoznámi správne.
• Nekonzistentná klávesová navigácia. Rozbaľovacie menu alebo modálne okno sa dá otvoriť myšou, ale nedá sa ovládať ani zavrieť klávesnicou.
• Chýbajúci alebo zavádzajúci alternatívny text. Obrázok má alt text „image123.jpg“ alebo je úplne prázdny aj tam, kde nesie dôležitú informáciu.
• Automatické prehrávanie videa alebo animácie bez možnosti zastaviť. Pohyblivý obsah rozptyľuje a u niektorých používateľov spôsobuje fyzické ťažkosti, ak sa nedá vypnúť.
• Testovanie prístupnosti len na konci projektu. Vo fáze wireframu stačí prekresliť rozloženie. Po spustení už ide o prerobenie hotového kódu a opätovné testovanie celého toku.

Podrobnejšie o tom, ako sa vôbec odhaľujú problémy s použiteľnosťou webu vrátane prístupnosti, píšeme v článku o UX audite webu a e-shopu. Audit prístupnosti je v podstate špecializovaná podmnožina bežného UX auditu, zameraná na konkrétne technické kritériá namiesto všeobecného hodnotenia použiteľnosti.

Čo ovplyvňuje čas a náklady na nápravu

Presnú sumu nemá zmysel paušalizovať bez konkrétneho zadania, ale faktory, ktoré náklady posúvajú, sú predvídateľné. Najviac rozhoduje to, či sa prístupnosť rieši od začiatku dizajnového procesu, alebo sa dolaďuje na hotovom webe postavenom bez ohľadu na tieto kritériá. Oprava kontrastu alebo popiskov formulára je lacná úprava. Zmena štruktúry celého navigačného systému alebo nahradenie vlastného JavaScriptového komponentu za prístupnú alternatívu je zásah do architektúry, ktorý si vyžaduje čas vývojárov aj opätovné testovanie.

Ak plánujete web alebo redizajn od základu vrátane rozpočtu na dizajn, orientačné rozpätia nájdete v článku o tom, koľko stojí UI/UX dizajn na Slovensku. Prístupnosť zahrnutá už vo fáze wireframu a dizajn systému výrazne znižuje náklady oproti dodatočnej náprave po spustení; o tom, ako dizajn systém pomáha udržať konzistentné, prístupné komponenty naprieč celou aplikáciou, píšeme v článku o design systéme pre SaaS a aplikácie.

Kontrolný zoznam pred nasadením

Súvisiace návody a zdroje

• UX audit webu a e-shopu: čo odhalí a kedy sa oplatí
• Používateľské testovanie webu: ako ho pripraviť a čo merať
• Design systém pre SaaS a aplikácie
• Wireframe vs mockup vs prototyp: aký je medzi nimi rozdiel
• Koľko stojí UI/UX dizajn na Slovensku
• Redizajn webu alebo priebežná UX optimalizácia: čo je lepšie
• Prístupné animácie na webe: prefers-reduced-motion, ovládanie a bezpečný pohyb

Na záver

Prístupnosť webu po roku 2025 stojí na konkrétnych technických kritériách, na ktoré sa dá odvolať a ktoré sa dajú overiť, nielen na dobrom UX vkuse. Najlacnejšie sa rieši priebežne počas dizajnu a vývoja, nie ako núdzová oprava po sťažnosti zákazníka alebo po zistení, že sa smernica týka aj vás.

Ak ste doteraz prístupnosť riešili len intuitívne, technická kontrola podľa konkrétnych kritérií WCAG 2.2 je rýchly spôsob, ako zistiť, kde presne stojíte, a rozhodnúť sa, čo opraviť najskôr. Táto kontrola uzatvára aj náš seriál o UX rozhodnutiach, ktorý sme začali auditom existujúceho webu a pokračovali cez wireframy, prototypy, dizajn systémy a používateľské testovanie: prístupnosť je poslednou, no rovnako dôležitou vrstvou, ktorá rozhoduje o tom, či web naozaj funguje pre každého návštevníka.

Časté otázky