През 2025 г. ищците са завели 3 117 съдебни дела за достъпност на уебсайтове съгласно ADA Title III във федералните съдилища — ръст от 27 процента спрямо 2024 г. и най-високата годишна цифра от 2022 г. насам. Ако добавим и исковете в щатските съдилища, общият брой надхвърля 5 000. Дори тази водеща цифра подценява натиска: адвокатите по защита изчисляват, че през миналата година до американски компании са били изпратени между 35 000 и 50 000 писма с искания за достъпност, повечето от които се уреждат частно за суми между 1 000 и 25 000 долара, без изобщо да се появяват в съдебните регистри.
Ако вашият бизнес управлява уебсайт, мобилно приложение, онлайн магазин, уиджет за резервации или клиентски портал, вие вече сте потенциална мишена. А серийните ищци вече не се ограничават до малка група повтарящи се податели — приблизително 40 процента от федералните искове по ADA Title III през 2025 г. идват от лица, представляващи сами себе си, много от които използват скенери с изкуствен интелект, за да идентифицират потенциални ответници и да съставят жалби за минути.
Това ръководство разглежда какво всъщност изисква ADA Title III за дигиталните преживявания, защо WCAG 2.1 Level AA се превърна в де факто стандарт, как изглежда пътната карта за коригиране на несъответствията и как да изградите защитима документация, преди да пристигне писмо с искане.
Защо вашият уебсайт вече попада в обхвата на ADA Title III
Раздел III (Title III) от Закона за американците с увреждания (ADA) забранява дискриминацията въз основа на увреждане в местата за обществено ползване. Законът е написан през 1990 г. и никога не е споменавал изрично уебсайтове или мобилни приложения — но съдилищата прекараха последното десетилетие в разрешаване на тази двусмисленост, почти винаги в полза на ищците.
Наследството от делото Robles срещу Domino's Pizza
Единственото най-важно дело е Robles срещу Domino's Pizza. Гилермо Роблес, незрящ ищец в Калифорния, съди Domino's през 2016 г., след като открива, че не може да използва уебсайта или мобилното приложение на веригата пицарии с екранен четец. Първоначално окръжният съд прекрати делото на основание надлежния съдебен процес, мотивирайки се, че без публикувани разпоредби за уеб достъпност, Domino's не е имала справедливо известие за това какво се изисква за съответствие.
Деветият апелативен съд отмени това решение през 2019 г. Съдът постанови, че Раздел III обхваща уебсайта и приложението на Domino's, тъй като те имат връзка (nexus) с физическо място за обществено ползване (пицариите), и че налагането на отговорност не нарушава надлежния процес дори без публикувани технически стандарти. Върховният съд отказа да преразгледа решението на Деветия съд по-късно същата година, оставяйки правилото в сила. В крайна сметка Domino's постигна споразумение през юни 2022 г. след шест години съдебни спорове.
Практическият ефект е, че всеки бизнес с физическо местоположение — а в много съдебни райони дори изцяло онлайн бизнеси — сега е изложен на реален риск заради недостъпен уебсайт.
Правилото на Министерството на правосъдието (DOJ) от 2024 г. по Раздел II и неговото отражение върху Раздел III
През април 2024 г. Министерството на правосъдието издаде окончателно правило съгласно Раздел II от ADA, изискващо уебсайтовете и мобилните приложения на щатските и местните власти да отговарят на WCAG 2.1 Level AA. Въпреки че това правило формално обвързва само публични субекти, ищците и съдилищата веднага започнаха да го цитират като най-авторитетното федерално определение за това какво означава „достъпен“.
За частния бизнес правната ситуация се промени за една нощ. Дори ако за Раздел III все още няма публикуван технически стандарт, ищецът вече може да посочи обвързваща федерална разпоредба, която определя WCAG 2.1 Level AA като стандарт за сходни субекти по Раздел II. Повечето адвокати по защита вече съветват своите клиенти по Раздел III да третират WCAG 2.1 Level AA като задължителен минимум.
Какво всъщност изисква WCAG 2.1 Level AA
WCAG — Указания за достъпност на уеб съдържанието, поддържани от World Wide Web Consortium — са организирани около четири принципа, удобно обобщени с акронима POUR: Perceivable (Възприемаемост), Operable (Оперативност), Understandable (Разбираемост) и Robust (Стабилност). Ниво AA включва всеки критерий за успех от Ниво A плюс допълнителни критерии, специфични за AA. Общо има 50 критерия за успех на ниво AA, но няколко от тях са причина за огромното мнозинство от писмата с искания.
Контраст на цветовете (1.4.3 и 1.4.11)
Основният текст трябва да има коефициент на контраст от най-малко 4,5:1 спрямо фона си. Големият текст (18 пункта или 14 пункта получер) се нуждае от поне 3:1. Бутоните, рамките на полетата във формуляри, индикаторите за фокус и други интерактивни графични елементи трябва да отговарят на съотношение 3:1 спрямо съседните цветове. Много писма с искания произтичат оттук, тъй като автоматизираните скенери откриват грешки в контраста за секунди.
Текстови алтернативи за нетекстово съдържание (1.1.1)
Всяко изображение, икона, диаграма, снимка и графика, които носят смисъл, се нуждаят от alt атрибут, който предава същата информация. Декоративните изображения получават празен alt атрибут (alt=""), така че екранните четци да ги пропускат. Логотипите трябва да описват марката. Диаграмите и инфографиките се нуждаят от по-дълъг текстов еквивалент наблизо или чрез връзка. Иконите за въвеждане във формуляри се нуждаят от етикети. CAPTCHA проверките се нуждаят от аудио алтернатива.
Оперативност чрез клавиатура (2.1.1, 2.1.2, 2.4.3, 2.4.7)
Всеки интерактивен елемент — менюта, модални прозорци, въртележки (carousels), акордеони, раздели, персонализирани падащи менюта — трябва да бъде достъпен и използваем само чрез клавиатура. Потребителите никога не трябва да се оказват блокирани в уиджет без изход (класическият провал тип „модален прозорец, който не се затваря без мишка“). Редът на фокуса трябва да бъде логичен, а видимият индикатор за фокус винаги трябва да показва къде се намира потребителят на страницата.
Етикети на формуляри, грешки и инструкции (1.3.1, 3.3.1, 3.3.2, 3.3.3, 3.3.4)
Всяко поле за въвеждане във формуляр се нуждае от програмно свързан етикет (елемент <label for=""> или aria-label). Съобщенията за грешка трябва да посочват кое поле е сгрешено и какво трябва да се направи. При формуляри с висока важност (плащане, създаване на акаунт, правни потвърждения), потребителите се нуждаят от възможност за преглед и корекция преди изпращане.
Субтитри и аудио описания (1.2.2, 1.2.5)
Предварително записаното видео се нуждае от синхронизирани субтитри. Ако съществена информация се предава визуално, а не в аудио записа, са необходими и аудио описания. Видеото на живо при ниво AA се нуждае от субтитри в реално време.
Структура на заглавията и ориентири (1.3.1, 2.4.6)
Заглавията трябва да следват логическа йерархия (h1 → h2 → h3, без произволно прескачане на нива). Използвайте семантични HTML елементи — <nav>, <main>, <header>, <footer> — или ARIA ориентири (landmarks), за да могат потребителите на екранни четци да прескачат директно до желаната секция. Избягвайте стилизирането на <div>, за да изглежда като заглавие, без да му дадете правилната семантична роля.
Преоразмеряване и пренареждане (1.4.4, 1.4.10)
Текстът трябва да остане четлив при 200 процента увеличение без хоризонтално превъртане. Оформлението трябва да се пренарежда автоматично (reflow) при 320 CSS пиксела ширина на екрана без двуизмерно превъртане.
Къде са съсредоточени съдебните дела
Три федерални окръга представляват основната част от жалбите за достъпност на уебсайтове: Южният окръг на Ню Йорк, Централният окръг на Калифорния и Южният окръг на Флорида. Ню Йорк води със значителна преднина, отчасти защото Законът за правата на човека на щат Ню Йорк и Законът за правата на човека на град Ню Йорк предоставят допълнителни правни основания на щатско ниво и по-ниски изисквания за доказване в сравнение с федералните искове по ADA.
Калифорния добавя Закона за гражданските права „Unruh“, който предвижда 4000 долара законоустановени щети за всяко нарушение на ищец. Това драстично променя математиката на извънсъдебните споразумения — малък иск може бързо да се превърне в експозиция от шестцифрена сума, ако бъде сертифициран групов иск.
Флорида се очерта като третия център от 2020 г. насам, с шепа адвокатски кантори на ищци, развиващи практика с голям обем дела, насочени към ресторантски вериги, хотелиерски марки и онлайн магазини за директна продажба на потребители.
Изграждане на пътна карта за отстраняване на проблеми
Ако получите писмо с претенции (demand letter) — или, още по-добре, ако действате преди пристигането на такова — работата се разделя на приблизително пет фази. Гледайте на това като на проект с бюджет и краен срок, а не като на еднократен одит.
Фаза 1: Автоматизиран и ръчен одит
Започнете с автоматизирано сканиране, използвайки инструмент като axe DevTools, WAVE или Google Lighthouse. Автоматизираните инструменти улавят между 30 и 50 процента от несъответствията с WCAG — останалите изискват ръчно тестване с екранен четец (NVDA за Windows, VoiceOver за macOS и iOS, TalkBack за Android), навигация само с клавиатура и тестване за увеличение и пренареждане.
Документирайте всяко несъответствие с нарушения критерий на WCAG, засегнатата страница или шаблон, тежестта и очакваните усилия за отстраняване. Този одитен лог се превръща в гръбнака на всяка следваща фаза.
Фаза 2: Корекции на дизайн системата и компонентите
Повечето от най-честите пропуски се намират във вашата дизайн система: контраст на бутоните, индикатори за фокус, полета за въвеждане, модални модели, контроли за въртележки, навигационни менюта. Еднократното коригиране на компонента поправя всяко негово копие в сайта. Дайте приоритет на компонентите, които се появяват на най-много страници.
Фаза 3: Проверка на съдържанието
Алтернативният текст (alt text), субтитрите на видеоклиповете, структурата на заглавията и етикетите на формулярите обикновено са корекции на ниво съдържание, които засягат най-много шаблони и страници. Създайте контролен списък за съдържанието, който авторите трябва да следват за всяка нова страница, и списък със задачи за ретроактивно коригиране на съществуващите страници.
Фаза 4: Координация с външни доставчици
Повечето модерни уебсайтове вграждат уиджети на трети страни: формуляри за плащане, чат на живо, календари за резервации, видео плейъри, инструменти за анализ, уиджети за отзиви и изскачащи прозорци за събиране на имейли. Всеки един от тях може да внесе свои собствени проблеми с достъпността, а съдилищата по Title III обикновено приемат, че бизнесът носи отговорност за достъпността на кода на доставчика, който вгражда в собствения си сайт.
За всеки доставчик изискайте текущ VPAT (Voluntary Product Accessibility Template) или Доклад за съответствие с изискванията за достъпност (Accessibility Conformance Report). Уверете се, че версията, която предоставят, отговаря на WCAG 2.1 Ниво AA. Натиснете доставчиците, които не отговарят на изискванията, да ги отстранят или ги заменете.
Фаза 5: Декларация за достъпност и канал за обратна връзка
Публикувайте ясно видима декларация за достъпност, която посочва стандарта, към който се стремите (обикновено WCAG 2.1 Ниво AA), известните ограничения и канал за връзка (имейл и телефон), чрез който потребителите да съобщават за проблеми с достъпността. Декларацията не осигурява правен имунитет, но документира добросъвестност и дава на отговарящите на писма с претенции нещо конкретно, на което да се позоват.
Няколко думи за надстройките за достъпност
Разрастващата се индустрия на инструменти за „надстройка за достъпност“ (accessibility overlay) — JavaScript приспособления (widgets), които обещават незабавно съответствие с WCAG чрез един ред код — твърди, че решава проблема с достъпността бързо и евтино. Реалността е по-сложна. Надстройките са посочвани в десетки съдебни дела като причина за проблеми с достъпността, тъй като пречат на асистиращите технологии на потребителите. Няколко съдилища отхвърлиха аргумента, че само надстройката е достатъчна, за да опровергае иск по Раздел III (Title III).
Надстройките могат да играят ролята на допълнение към основното коригиране — за потребители, които трябва да приложат собствените си предпочитания върху вече достъпен сайт — но те не са заместител на поправянето на основния код. Адвокатските кантори на ищците сега конкретно се насочват към сайтове, използващи определени продукти за надстройка.
Документирайте всичко за целите на защитата
Когато пристигне покана за доброволно изпълнение или претенция, вашата стратегия за защита зависи почти изцяло от това какво можете да докажете за вашата програма за достъпност към момента на предполагаемото нарушение. Изградете документална следа, която включва:
- Одитни доклади с дата, показващи обхвата и констатациите
- Тикети за отстраняване на несъответствия с дати на приключване
- VPAT декларации от доставчици и доклади за съответствие на достъпността
- Записи от обучения за дизайнери и разработчици
- Вътрешни контролни списъци за преглед на достъпността, свързани с пускането на продукти
- Дневник на промените (change log) за декларацията за достъпност
- Обратна връзка от потребители, получена чрез вашия канал за контакт относно достъпността, и вашият отговор на нея
Тези записи не предотвратяват съдебни дела, но променят драстично преговорите за споразумение. Ищец, надяващ се на бързо извънсъдебно споразумение за 10 000 долара, е далеч по-малко заинтересован, когато ответникът може да представи актуален одит, документиран списък със задачи за отстраняване на грешки и VPAT декларация от доставчика за всяко вградено приспособление.
Счетоводната страна на съответствието за достъпност
Отстраняването на проблеми с достъпността рядко е еднократен разход. Обикновено то се появява във вашите книги като периодичен разход — фактури от агенции или изпълнители за одити, софтуерни лицензи за инструменти за тестване и услуги за мониторинг, разходи за преустройство на системата за дизайн, разходи за смяна на доставчици и неизбежните споразумения по претенции, които се промъкват въпреки най-добрите ви усилия.
Проследяването на тези разходи отделно от общите разходи за маркетинг или инженерна дейност улеснява няколко неща. Получавате ясна представа за реалната цена на съответствието във времето, което помага при планирането на бюджета за програмата за следващата година. Документирате разходите, ако по-късно се наложи да поискате данъчно облекчение или да амортизирате капитализирано подобрение на уебсайта. И ако някога се сблъскате с колективен иск от сериен ищец, можете бързо да представите финансов отчет за вашата добросъвестна инвестиция в достъпност — полезен както при преговори за споразумение, така и при всяка защита, базирана на разумни модификации.
Един прост сегмент в сметкоплана за „Съответствие за достъпност“ с подкатегории за одити, труд по отстраняване на несъответствия, инструменти за тестване, надлежна проверка на доставчиците и резерви за споразумения е много полезен. Комбинирайте го с тримесечни прегледи, за да не се окаже, че програмата тихомълком е изпаднала от бюджета.
Чести грешки, които трябва да избягвате
Няколко модела се появяват в почти всяка претенция, която виждам да получават собствениците на фирми.
Третиране на достъпността като еднократен проект. Сайтовете се променят постоянно. Нова продуктова страница, обновен процес на плащане, вграден чатбот — всяко от тези неща може да внесе нови грешки. Вградете достъпността във вашия жизнен цикъл на разработка, така че всяка промяна да се проверява преди внедряване.
Разчитане изцяло на автоматизирани сканирания. Автоматизираните инструменти улавят само малка част от несъответствията с WCAG. Ръчното тестване с асистиращи технологии е единственият начин да се открият проблеми като нелогичен ред на фокуса, подвеждащ алтернативен текст или неизползваеми персонализирани приспособления.
Игнориране на мобилните приложения. Ищците по Раздел III все по-често подават двойни искове, обхващащи както уебсайта, така и нативното мобилно приложение. iOS и Android имат свои собствени API за достъпност (UIAccessibility и TalkBack/AccessibilityService) и се прилагат същите принципи на WCAG, но се изисква специфично за платформата тестване.
Забравяне на PDF файловете. Данъчни формуляри, бели книги (white papers), менюта и ресурси за изтегляне, хоствани на вашия сайт, също са в обхвата. PDF файловете се нуждаят от правилен ред на четене, тагове, алтернативен текст и етикети на полетата на формулярите точно както HTML страниците.
Предположението, че платформа на трета страна се грижи за това вместо вас. Shopify, WordPress, Wix, Squarespace и подобни платформи предоставят известна рамка за достъпност, но изборът на тема, персонализираният код, вградените приспособления и съдържанието, което публикувате, остават ваша отговорност. Претенцията не се интересува дали темата е била готова предварително.
Пропускане на декларацията за достъпност. Публикуването ѝ не струва нищо и предоставя осезаемо доказателство за добросъвестност. Липсата на такава понякога се цитира конкретно в жалбите.
Поддържайте финансовите си записи за съответствие организирани от първия ден
Докато изграждате вашата програма за достъпност, придружаващите финансови записи — фактури за одити, договори с доставчици, труд по отстраняване на несъответствия, разходи за обучение и резерви за споразумения — трябва да се съхраняват някъде, където можете да ги намерите след години, ако сериен ищец назове вашия бизнес. Beancount.io предоставя счетоводство в обикновен текст (plain-text accounting), което ви дава пълна прозрачност и хронология с контрол на версиите за всеки запис, без „черни кутии“ и без обвързване с доставчик. Започнете безплатно и вижте защо разработчиците, финансовите екипи и операторите, загрижени за съответствието, избират счетоводството в обикновен текст, за да поддържат архив, защитим при одит.