V roku 2025 podali žalobcovia na federálnych súdoch 3 117 žalôb týkajúcich sa prístupnosti webových stránok podľa ADA Title III — čo predstavuje 27-percentný nárast oproti roku 2024 a najvyššie ročné číslo od roku 2022. Ak pripočítame podania na štátnych súdoch, celkový počet presahuje 5 000. Dokonca aj toto hlavné číslo podhodnocuje skutočný tlak: obhajcovia odhadujú, že minulý rok bolo americkým podnikom zaslaných 35 000 až 50 000 predžalobných výziev týkajúcich sa prístupnosti, z ktorých väčšina sa urovná súkromne za sumu od 1 000 do 25 000 USD bez toho, aby sa kedykoľvek objavili v súdnom registri.
Ak vaša firma prevádzkuje webovú stránku, mobilnú aplikáciu, online obchod, rezervačný widget alebo zákaznícky portál, ste teraz reálnym cieľom. A sérioví žalobcovia sa už neobmedzujú len na malú skupinu opakovaných sťažovateľov — približne 40 percent federálnych podaní podľa ADA Title III v roku 2025 pochádzalo od jednotlivcov zastupujúcich sa sami, z ktorých mnohí používajú skenery s podporou umelej inteligencie na identifikáciu potenciálnych žalovaných a vypracovanie žalôb v priebehu niekoľkých minút.
Táto príručka prechádza tým, čo ADA Title III v skutočnosti vyžaduje pre digitálne skúsenosti, prečo sa WCAG 2.1 úrovne AA stalo de facto referenčným bodom, ako vyzerá plán nápravy a ako si vybudovať obhájiteľnú dokumentáciu skôr, než dorazí predžalobná výzva.
Prečo váš web teraz spadá pod ADA Title III
Hlava III zákona o Američanoch so zdravotným postihnutím (ADA Title III) zakazuje diskrimináciu na základe zdravotného postihnutia v miestach verejných služieb a ubytovania. Zákon bol napísaný v roku 1990 a nikdy výslovne nespomínal webové stránky ani mobilné aplikácie — ale súdy strávili posledné desaťročie riešením tejto nejednoznačnosti, takmer vždy v prospech žalobcov.
Odkaz prípadu Robles v. Domino's Pizza
Jedným z najdôležitejších prípadov je Robles v. Domino's Pizza. Guillermo Robles, nevidiaci žalobca v Kalifornii, zažaloval Domino's v roku 2016 po tom, čo zistil, že nemôže používať webovú stránku ani mobilnú aplikáciu tohto reťazca pizzerií s čítačkou obrazovky. Okresný súd pôvodne žalobu zamietol z procesných dôvodov s odôvodnením, že bez zverejnených predpisov o prístupnosti webu nemala spoločnosť Domino's jasné upozornenie o tom, čo súlad vyžaduje.
Odvolací súd deviateho obvodu toto rozhodnutie v roku 2019 zrušil. Súd rozhodol, že Title III sa vzťahuje na webovú stránku a aplikáciu Domino's, pretože mali prepojenie s fyzickým miestom verejnej prevádzky (pizzeriami), a že vyvodenie zodpovednosti neporušuje procesné práva ani bez zverejnených technických noriem. Najvyšší súd neskôr v tom istom roku odmietol preskúmať rozhodnutie deviateho obvodu, čím ponechal pravidlo v platnosti. Spoločnosť Domino's sa nakoniec po šiestich rokoch súdnych sporov v júni 2022 dohodla na mimosúdnom vyrovnaní.
Praktickým dôsledkom je, že každý podnik s fyzickou pobočkou — a v mnohých súdnych obvodoch dokonca aj čisto online podniky — teraz čelí reálnemu riziku v prípade neprístupnej webovej stránky.
Pravidlo Title II ministerstva spravodlivosti (DOJ) z roku 2024 a jeho presah do Title III
V apríli 2024 vydalo Ministerstvo spravodlivosti USA konečné pravidlo podľa Title II ADA, ktoré vyžaduje, aby webové stránky a mobilné aplikácie štátnej a miestnej správy vyhovovali štandardu WCAG 2.1 úrovne AA. Hoci toto pravidlo formálne zaväzuje len verejné subjekty, žalobcovia a súdy ho okamžite začali citovať ako najautoritatívnejšie federálne vyjadrenie toho, čo znamená „prístupný“.
Pre súkromný podnik sa právna kalkulácia zmenila zo dňa na deň. Aj keď Title III stále nemá zverejnený technický štandard, žalobca môže teraz poukázať na záväzný federálny predpis, ktorý uvádza WCAG 2.1 úrovne AA ako štandard pre vecne podobné subjekty patriace pod Title II. Väčšina obhajcov teraz odporúča svojim klientom v rámci Title III považovať WCAG 2.1 úrovne AA za nevyhnutné minimum.
Čo v skutočnosti vyžaduje WCAG 2.1 úrovne AA
WCAG — Pravidlá prístupnosti webového obsahu, spravované konzorciom World Wide Web Consortium — sú organizované okolo štyroch princípov, pohodlne zhrnutých akronymom POUR: Perceivable (Vnímateľnosť), Operable (Ovládateľnosť), Understandable (Zrozumiteľnosť) a Robust (Robustnosť). Úroveň AA zahŕňa každé kritérium úspešnosti úrovne A plus ďalšie špecifické kritériá pre AA. Na úrovni AA je celkovo 50 kritérií úspešnosti, ale len niekoľko z nich generuje drvivú väčšinu predžalobných výziev.
Farebný kontrast (1.4.3 a 1.4.11)
Text v tele stránky musí mať kontrastný pomer aspoň 4,5:1 voči pozadiu. Veľký text (18 bodov alebo 14 bodov tučne) potrebuje aspoň 3:1. Tlačidlá, ohraničenia formulárových polí, indikátory zamerania (fókus) a iné interaktívne grafické prvky musia spĺňať pomer 3:1 voči susediacim farbám. Mnoho predžalobných výziev vzniká tu, pretože automatizované skenery detegujú chyby v kontraste v priebehu sekúnd.
Textové alternatívy pre netextový obsah (1.1.1)
Každý obrázok, ikona, graf, fotografia a grafika, ktoré nesú význam, potrebujú atribút alt, ktorý sprostredkuje rovnakú informáciu. Dekoratívne obrázky dostávajú prázdny atribút alt (alt=""), aby ich čítačky obrazovky preskočili. Logá by mali popisovať značku. Grafy a infografiky potrebujú dlhší textový ekvivalent v blízkosti alebo prostredníctvom odkazu. Ikony vstupných polí formulárov potrebujú štítky. Testy CAPTCHA potrebujú zvukovú alternatívu.
Prístupnosť z klávesnice (2.1.1, 2.1.2, 2.4.3, 2.4.7)
Každý interaktívny prvok — ponuky, modálne okná, karusely, harmoniky, karty, vlastné rozbaľovacie zoznamy — musí byť dosiahnuteľný a ovládateľný iba pomocou klávesnice. Používatelia nesmú nikdy uviaznuť vo vnútri miniaplikácie bez možnosti odísť (klasické zlyhanie „modálne okno, ktoré sa nedá zavrieť bez myši“). Poradie zamerania (focus) musí byť logické a viditeľný indikátor zamerania musí vždy ukazovať, kde sa používateľ na stránke nachádza.
Popisky formulárov, chyby a pokyny (1.3.1, 3.3.1, 3.3.2, 3.3.3, 3.3.4)
Každý vstup formulára vyžaduje programovo priradený popisok (element <label for=""> alebo aria-label). Chybové správy musia identifikovať, ktoré pole zlyhalo a čo s tým robiť. Pri dôležitých formulároch (pokladňa, vytvorenie účtu, právne potvrdenia) potrebujú používatelia možnosť skontrolovať a opraviť údaje pred odoslaním.
Titulky a zvukové popisy (1.2.2, 1.2.5)
Vopred nahraté video potrebuje synchronizované titulky. Ak sú dôležité informácie odovzdávané vizuálne a nie v zvukovej stope, potrebujete aj zvukové popisy. Živé video na úrovni AA vyžaduje živé titulky.
Štruktúra nadpisov a orientačné body (1.3.1, 2.4.6)
Nadpisy musia dodržiavať logickú hierarchiu (h1 → h2 → h3, bez ľubovoľného vynechávania úrovní). Používajte sémantické HTML prvky — <nav>, <main>, <header>, <footer> — alebo orientačné body ARIA, aby používatelia čítačiek obrazovky mohli skočiť na sekciu, ktorú chcú. Vyhnite sa štýlovaniu <div> tak, aby vyzeral ako nadpis, bez toho, aby ste mu priradili správnu sémantickú rolu.
Zmena veľkosti a prispôsobenie (1.4.4, 1.4.10)
Text musí zostať čitateľný pri 200-percentnom priblížení bez horizontálneho posúvania. Rozloženia sa musia prispôsobiť zobrazeniu so šírkou 320 CSS pixelov bez dvojrozmerného posúvania.
Kde sa sústreďujú súdne spory
Väčšinu podaní týkajúcich sa prístupnosti webových stránok tvoria tri federálne obvody: Južný obvod New Yorku, Centrálny obvod Kalifornie a Južný obvod Floridy. New York vedie s veľkým náskokom, čiastočne preto, že zákon štátu New York o ľudských právach a zákon mesta New York o ľudských právach poskytujú ďalšie právne nástroje na úrovni štátu a nižšie požiadavky na podanie žaloby než federálne nároky podľa zákona ADA.
Kalifornia pridáva zákon Unruh Civil Rights Act, ktorý stanovuje zákonné odškodné vo výške 4 000 USD za každé porušenie na jedného žalobcu. To dramaticky mení výpočty pri urovnaní — malý nárok sa môže rýchlo zmeniť na šesťciferné riziko, ak dôjde k certifikácii hromadnej žaloby.
Florida sa od roku 2020 stala tretím centrom, kde niekoľko právnických firiem zastupujúcich žalobcov vyvinulo veľkoobjemovú prax zameranú na reštauračné siete, značky v pohostinstve a e-shopy zamerané priamo na spotrebiteľa.
Budovanie plánu nápravy
Ak dostanete predžalobnú výzvu — alebo lepšie, ak zasiahnete skôr, než príde — práca sa delí zhruba do piatich fáz. Pristupujte k tomu ako k projektu s rozpočtom a termínom, nie ako k jednorazovému auditu.
Fáza 1: Automatizovaný a manuálny audit
Začnite automatizovaným skenovaním pomocou nástrojov ako axe DevTools, WAVE alebo Google Lighthouse. Automatizované nástroje zachytia 30 až 50 percent zlyhaní WCAG — zvyšok vyžaduje manuálne testovanie s čítačkou obrazovky (NVDA v systéme Windows, VoiceOver v systémoch macOS a iOS, TalkBack v systéme Android), navigáciu iba pomocou klávesnice a testovanie priblíženia a prispôsobenia (reflow).
Zdokumentujte každé zlyhanie s porušeným kritériom WCAG, dotknutou stránkou alebo šablónou, závažnosťou a odhadovaným úsilím na nápravu. Tento protokol auditu sa stane základom každej neskoršej fázy.
Fáza 2: Opravy dizajnového systému a komponentov
Väčšina najčastejších zlyhaní sa nachádza vo vašom dizajnovom systéme: kontrast tlačidiel, indikátory zamerania, vstupy formulárov, vzory modálnych okien, ovládacie prvky karuselov, navigačné ponuky. Jednorazová oprava komponentu opraví každý jeho výskyt. Uprednostnite komponenty, ktoré sa nachádzajú na najväčšom počte stránok.
Fáza 3: Kontrola obsahu
Alternatívny text, titulky k videám, štruktúra nadpisov a popisky formulárov sú zvyčajne opravy na úrovni obsahu, ktoré sa dotýkajú väčšiny šablón a stránok. Vytvorte kontrolný zoznam obsahu, ktorý musia autori dodržiavať pri každej novej stránke, a položku v backlogu na spätnú opravu existujúcich stránok.
Fáza 4: Koordinácia s dodávateľmi tretích strán
Väčšina moderných webových stránok obsahuje miniaplikácie tretích strán: platobné formuláre, živý čet, rezervačné kalendáre, video prehrávače, analytické vrstvy, recenzné widgety a vyskakovacie okná na zber e-mailov. Každý z nich môže spôsobiť vlastné chyby v prístupnosti a súdy v rámci hlavy III (Title III) vo všeobecnosti rozhodli, že firma je zodpovedná za prístupnosť kódu dodávateľa, ktorý vloží na svoju vlastnú stránku.
Od každého dodávateľa si vyžiadajte aktuálnu šablónu VPAT (Voluntary Product Accessibility Template) alebo správu o zhode s prístupnosťou (Accessibility Conformance Report). Overte, či verzia, ktorú dodávajú, spĺňa úroveň WCAG 2.1 Level AA. Tlačte na dodávateľov, ktorí zaostávajú, aby vykonali nápravu, alebo ich vymeňte.
Fáza 5: Vyhlásenie o prístupnosti a kanál spätnej väzby
Zverejnite jasne odkazované vyhlásenie o prístupnosti, ktoré uvádza štandard, ktorý sa snažíte splniť (zvyčajne WCAG 2.1 Level AA), známe obmedzenia a kontaktný kanál (e-mail a telefón), cez ktorý môžu používatelia nahlásiť problémy s prístupnosťou. Vyhlásenie neposkytuje právnu imunitu, ale dokumentuje dobrú vôľu a dáva subjektom odpovedajúcim na predžalobné výzvy niečo konkrétne, na čo sa môžu odvolať.
Slovo o prekrytiach prístupnosti (Accessibility Overlays)
Rýchlo rastúce odvetvie nástrojov „prekrytia prístupnosti“ – JavaScript widgetov, ktoré sľubujú okamžitý súlad s WCAG prostredníctvom jediného riadku kódu – tvrdí, že rieši prístupnosť rýchlo a lacno. Realita je však zložitejšia. Prekrytia boli uvedené v desiatkach súdnych sporov ako nástroje, ktoré samy osebe spôsobujú problémy s prístupnosťou tým, že zasahujú do asistenčných technológií používateľov. Niekoľko súdov zamietlo argument, že samotné prekrytie postačuje na zamietnutie nároku podľa hlavy III (Title III).
Prekrytia môžu hrať úlohu ako doplnok k základnej náprave – pre používateľov, ktorí potrebujú aplikovať vlastné preferencie na už prístupnej stránke – nie sú však náhradou za opravu základného kódu. Právnické firmy zastupujúce žalobcov sa teraz konkrétne zameriavajú na stránky, ktoré používajú určité produkty na prekrytie prístupnosti.
Dokumentujte všetko pre potreby obhajoby
Keď dorazí výzva na nápravu (demand letter), vaša stratégia obhajoby závisí takmer výlučne od toho, čo dokážete preukázať o svojom programe prístupnosti v čase údajného porušenia. Vytvorte si dokumentačnú stopu, ktorá obsahuje:
- Datované správy z auditov s uvedením rozsahu a zistení
- Tikety na nápravu s dátumami ich uzavretia
- VPAT dokumentáciu a správy o zhode prístupnosti od dodávateľov
- Záznamy o školeniach dizajnérov a vývojárov
- Interné kontrolné zoznamy prístupnosti viazané na uvedenie produktov na trh
- Záznam zmien (change log) vyhlásenia o prístupnosti
- Spätnú väzbu od používateľov prijatú prostredníctvom vášho kontaktného kanála pre prístupnosť a vašu reakciu na ňu
Tieto záznamy nezabránia žalobám, ale dramaticky menia pozíciu pri vyjednávaní o urovnaní. Žalobca dúfajúci v rýchle mimosúdne vyrovnanie vo výške 10 000 USD má oveľa menší záujem, ak žalovaný dokáže predložiť aktuálny audit, zdokumentovaný zoznam nevyriešených úloh (backlog) a VPAT od dodávateľa pre každý vložený widget.
Účtovná stránka súladu s prístupnosťou
Náprava prístupnosti je zriedka jednorazovým výdavkom. Vo vašom účtovníctve sa zvyčajne objavuje ako opakujúci sa výdavok – faktúry od agentúr alebo dodávateľov za audity, softvérové licencie na testovacie nástroje a monitorovacie služby, náklady na prestavbu dizajnového systému, náklady na zmenu dodávateľa a nevyhnutné vyrovnania na základe výziev, ktoré sa vyskytnú napriek vášmu maximálnemu úsiliu.
Sledovanie týchto výdavkov oddelene od všeobecných nákladov na marketing alebo inžiniering uľahčuje niekoľko vecí. Získate jasný prehľad o skutočných nákladoch na zabezpečenie súladu v čase, čo pomáha pri plánovaní rozpočtu na ďalší rok. Zdokumentujete výdavky pre prípad, že si neskôr budete potrebovať uplatniť odpis alebo amortizovať kapitalizované vylepšenie webovej stránky. A ak by ste niekedy čelili hromadnej žalobe zo strany sériových žalobcov, môžete rýchlo predložiť finančný záznam o vašej investícii do prístupnosti v dobrej viere – čo je užitočné pri vyjednávaní o urovnaní aj pri akejkoľvek obhajobe založenej na vykonaní primeraných úprav.
Jednoduchý segment účtovnej osnovy pre „Súlad s prístupnosťou“ s podkategóriami pre audity, prácu na náprave, testovacie nástroje, hĺbkovú previerku dodávateľov a rezervy na vyrovnanie vám veľmi pomôže. Spárujte ho s kvartálnymi kontrolami, aby program potichu nevypadol z rozpočtu.
Časté chyby, ktorým sa treba vyhnúť
V takmer každej výzve na nápravu, ktorú vidím majiteľov firiem dostávať, sa objavuje niekoľko rovnakých vzorcov.
Považovanie prístupnosti za jednorazový projekt. Stránky sa neustále menia. Nová produktová stránka, prepracovaný proces nákupu, vložený chatbot – čokoľvek z toho môže priniesť nové nedostatky. Zakomponujte prístupnosť priamo do cyklu vývoja, aby sa každá zmena skontrolovala ešte pred nasadením.
Spoliehanie sa výlučne na automatizované skeny. Automatizované nástroje zachytia len menšinu porušení WCAG. Manuálne testovanie s asistenčnými technológiami je jediný spôsob, ako nájsť problémy, ako je nelogické poradie zamerania (focus order), zavádzajúci alternatívny text alebo nepoužiteľné vlastné widgety.
Ignorovanie mobilných aplikácií. Žalobcovia podľa hlavy III čoraz častejšie podávajú duálne nároky pokrývajúce webovú stránku aj natívnu mobilnú aplikáciu. iOS a Android majú svoje vlastné API pre prístupnosť (UIAccessibility a TalkBack/AccessibilityService) a hoci platia rovnaké princípy WCAG, vyžadujú si testovanie špecifické pre danú platformu.
Zabúdanie na PDF súbory. Daňové formuláre, biele knihy (white papers), menu a stiahnuteľné zdroje umiestnené na vašom webe sú tiež súčasťou rozsahu. Súbory PDF potrebujú správne poradie čítania, tagy, alternatívny text a popisy formulárových polí rovnako ako HTML stránky.
Predpoklad, že platforma tretej strany to vyrieši za vás. Shopify, WordPress, Wix, Squarespace a podobné platformy poskytujú určitú kostru prístupnosti, ale výber témy, vlastný kód, vložené widgety a obsah, ktorý zverejňujete, sú stále vašou zodpovednosťou. Výzva na nápravu neberie ohľad na to, či bola téma predpripravená.
Vynechanie vyhlásenia o prístupnosti. Zverejnenie nič nestojí a poskytuje preukázateľný dôkaz o dobrej viere. Jeho absencia sa v sťažnostiach niekedy uvádza ako konkrétny bod.
Udržujte si poriadok vo financiách súvisiacich so súladom od prvého dňa
Keď budujete svoj program prístupnosti, sprievodné finančné záznamy – faktúry za audity, zmluvy s dodávateľmi, náklady na prácu pri náprave, náklady na školenia a rezervy na vyrovnania – musia byť uložené na mieste, kde ich nájdete aj po rokoch, ak vašu firmu označí sériový žalobca. Beancount.io poskytuje účtovníctvo v čistom texte, ktoré vám dáva úplnú transparentnosť a históriu kontrolovanú verziami pre každú položku, bez skrytých procesov a závislosti od konkrétneho dodávateľa. Začnite zadarmo a zistite, prečo si vývojári, finančné tímy a operátori dbajúci na dodržiavanie predpisov vyberajú plain-text accounting na vedenie záznamov obhájiteľných pri audite.