У 2025 році позивачі подали 3 117 позовів щодо доступності вебсайтів згідно з Розділом III ADA до федеральних судів — це на 27 відсотків більше, ніж у 2024 році, і є найвищим річним показником з 2022 року. Якщо додати позови до судів штатів, загальна кількість перевищить 5 000. Навіть ця вражаюча цифра недооцінює тиск: адвокати з боку захисту оцінюють, що минулого року американським підприємствам було надіслано від 35 000 до 50 000 претензійних листів щодо доступності, більшість із яких врегульовуються приватно за суми від 1 000 до 25 000 доларів, навіть не потрапляючи до судових реєстрів.
Якщо ваш бізнес має вебсайт, мобільний додаток, інтернет-магазин, віджет для бронювання або клієнтський портал, тепер ви є реальною мішенню. Серійні позивачі більше не обмежуються невеликою групою осіб, що подають повторні позови — приблизно 40 відсотків федеральних позовів за Розділом III ADA у 2025 році надійшли від осіб, які представляють себе самостійно, багато з яких використовують сканери на базі ШІ для виявлення потенційних відповідачів та підготовки скарг за лічені хвилини.
Цей посібник розповідає про те, чого насправді вимагає Розділ III ADA для цифрового досвіду, чому WCAG 2.1 рівня AA став еталоном де-факто, як виглядає дорожня карта виправлення недоліків і як створити доказову базу ще до того, як надійде претензійний лист.
Чому ваш вебсайт тепер підпадає під дію Розділу III ADA
Розділ III Закону про американців з інвалідністю (ADA) забороняє дискримінацію за ознакою інвалідності в місцях громадського користування. Закон був написаний у 1990 році і ніколи прямо не згадував вебсайти чи мобільні додатки — але суди провели останнє десятиліття, вирішуючи цю двозначність, майже завжди на користь позивачів.
Спадщина справи «Роблес проти Domino's Pizza»
Найважливішою справою є «Роблес проти Domino's Pizza». Гільєрмо Роблес, незрячий позивач із Каліфорнії, подав до суду на Domino's у 2016 році після того, як виявив, що не може користуватися вебсайтом або мобільним додатком мережі піцерій за допомогою програми зчитування з екрана. Окружний суд спочатку відхилив справу з мотивів належної правової процедури, аргументуючи це тим, що без опублікованих правил доступності вебсайтів Domino's не мала належного повідомлення про те, чого вимагає відповідність.
Дев'ятий апеляційний суд скасував це рішення у 2019 році. Суд постановив, що Розділ III поширюється на вебсайт і додаток Domino's, оскільки вони мають зв’язок із фізичним місцем громадського користування (піцеріями), і що притягнення до відповідальності не порушує належну правову процедуру навіть без опублікованих технічних стандартів. Верховний суд відмовився переглядати рішення Дев'ятого апеляційного суду пізніше того ж року, залишивши правило в силі. Domino's врешті-решт пішла на мирову угоду в червні 2022 року після шести років судових розглядів.
Практичний результат полягає в тому, що будь-який бізнес із фізичним місцезнаходженням — а в багатьох округах навіть виключно онлайн-бізнес — тепер стикається з реальною відповідальністю за недоступний вебсайт.
Правило Розділу II Міністерства юстиції 2024 року та його непрямий вплив на Розділ III
У квітні 2024 року Міністерство юстиції видало остаточне правило за Розділом II ADA, яке вимагає, щоб вебсайти та мобільні додатки органів влади штатів та місцевого самоврядування відповідали стандарту WCAG 2.1 рівня AA. Хоча це правило формально зобов'язує лише державні установи, позивачі та суди негайно почали цитувати його як найавторитетніше федеральне формулювання того, що означає «доступний».
Для приватного бізнесу правовий розрахунок змінився миттєво. Навіть якщо Розділ III досі не має опублікованого технічного стандарту, позивач тепер може вказати на обов'язкове федеральне регулювання, яке називає WCAG 2.1 рівня AA стандартом для матеріально схожих організацій Розділу II. Більшість адвокатів тепер радять своїм клієнтам за Розділом III розглядати WCAG 2.1 рівня AA як мінімальний поріг.
Що насправді вимагає WCAG 2.1 рівня AA
WCAG — Настанови з доступності вебконтенту, які підтримуються Консорціумом Всесвітньої павутини (W3C), — організовані навколо чотирьох принципів, які зручно резюмувати абревіатурою POUR: Perceivable (Сприйнятність), Operable (Керованість), Understandable (Зрозумілість) та Robust (Стійкість). Рівень AA включає всі критерії успіху рівня A плюс додаткові критерії, специфічні для AA. Усього на рівні AA налічується 50 критеріїв успіху, але лише кілька з них стають причиною переважної більшості претензійних листів.
Колірний контраст (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)
Кожен інтерактивний елемент — меню, модальні вікна, каруселі, акордеони, вкладки, власні спадні списки — має бути доступним і керованим лише за допомогою клавіатури. Користувачі ніколи не повинні опинятися в «пастці» всередині віджета без можливості виходу (класична помилка «модальне вікно, яке неможливо закрити без миші»). Порядок фокусування має бути логічним, а видимий індикатор фокуса завжди повинен показувати, де на сторінці знаходиться користувач.
Мітки форм, помилки та інструкції (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-орієнтири, щоб користувачі скринрідерів могли переходити до потрібного розділу. Уникайте стилізації <div> під заголовок без надання йому відповідної семантичної ролі.
Зміна розміру та перетікання контенту (1.4.4, 1.4.10)
Текст має залишатися читабельним при 200-відсотковому масштабуванні без появи горизонтальної прокрутки. Макети повинні адаптуватися (reflow) під область перегляду шириною 320 CSS-пікселів без появи двовимірної прокрутки.
Де зосереджені судові позови
Основна маса позовів щодо доступності вебсайтів припадає на три федеральні округи: Південний округ Нью-Йорка, Центральний округ Каліфорнії та Південний округ Флориди. Нью-Йорк лідирує з великим відривом, частково тому, що Закон штату Нью-Йорк про права людини та Закон міста Нью-Йорк про права людини надають додаткові юридичні важелі на рівні штату та мають нижчі вимоги до обґрунтування позову, ніж федеральні позови за законом ADA.
У Каліфорнії діє Закон Анру про цивільні права (Unruh Civil Rights Act), який передбачає 4 000 доларів США встановлених законом збитків за кожне порушення на одного позивача. Це кардинально змінює математику врегулювання — невеликий позов може швидко перетворитися на ризики в шестизначних сумах, якщо справу буде визнано колективним позовом.
Флорида стала третім центром з 2020 року, де кілька юридичних фірм з боку позивачів розвинули масштабну практику, орієнтовану на мережі ресторанів, готельні бренди та інтернет-магазини формату D2C (direct-to-consumer).
Побудова плану усунення недоліків
Якщо ви отримали лист-претензію — або, що ще краще, якщо ви почнете діяти до його отримання — робота поділяється приблизно на п'ять етапів. Ставтеся до цього як до проєкту з бюджетом і дедлайном, а не як до одноразового аудиту.
Фаза 1: Автоматизований та ручний аудит
Почніть з автоматичного сканування за допомогою таких інструментів, як axe DevTools, WAVE або Google Lighthouse. Автоматизовані інструменти виявляють від 30 до 50 відсотків порушень WCAG — решта потребує ручного тестування за допомогою скринрідера (NVDA на Windows, VoiceOver на macOS та iOS, TalkBack на Android), навігації лише з клавіатури, а також тестування масштабування та перетікання контенту.
Документуйте кожне порушення із зазначенням критерію WCAG, який було порушено, сторінки або шаблону, ступеня тяжкості та оцінки зусиль для виправлення. Цей журнал аудиту стане основою для всіх наступних етапів.
Фаза 2: Виправлення дизайн-системи та компонентів
Більшість найпоширеніших помилок криються у вашій дизайн-системі: контрастність кнопок, індикатори фокуса, поля введення форм, шаблони модальних вікон, елементи керування каруселлю, меню навігації. Виправлення компонента один раз усуває всі його копії на сайті. Пріоритезуйте компоненти, які з'являються на найбільшій кількості сторінок.
Фаза 3: Опрацювання контенту
Альтернативний текст, субтитри до відео, структура заголовків і мітки форм — це зазвичай виправлення на рівні контенту, які стосуються більшості шаблонів і сторінок. Створіть контрольний список контенту, якого автори повинні дотримуватися для кожної нової сторінки, і окреме завдання для ретроактивного виправлення існуючих сторінок.
Фаза 4: Координація зі сторонніми постачальниками
Більшість сучасних вебсайтів використовують сторонні віджети: платіжні форми, онлайн-чати, календарі бронювання, відеопрогравачі, аналітичні оверлеї, віджети відгуків і спливаючі вікна для збору електронних адрес. Кожен із них може містити власні помилки доступності, і суди за Розділом III зазвичай постановляють, що бізнес несе відповідальність за доступність коду сторонніх розробників, який він інтегрує на свій сайт.
Для кожного постачальника запитайте актуальний VPAT (Voluntary Product Accessibility Template) або звіт про відповідність доступності (Accessibility Conformance Report). Переконайтеся, що версія, яку вони надають, відповідає WCAG 2.1 рівня AA. Вимагайте від постачальників, які не відповідають стандартам, усунути недоліки або замініть їх.
Фаза 5: Заява про доступність та канал зворотного зв'язку
Опублікуйте заяву про доступність із чітким посиланням, де вказано стандарт, якого ви прагнете дотримуватися (зазвичай WCAG 2.1 Level AA), відомі обмеження та контактний канал (електронна пошта та телефон) для повідомлень про проблеми з доступністю. Така заява не дає юридичного імунітету, але вона документує ваші добрі наміри та дає конкретні аргументи у відповідь на листи-претензії.
Кілька слів про віджети доступності
Індустрія інструментів «надбудов доступності» (accessibility overlays) — JavaScript-віджетів, які обіцяють миттєву відповідність WCAG за допомогою одного рядка коду — стрімко розвивається, стверджуючи, що вирішує питання доступності швидко й дешево. Реальність складніша. Віджети фігурували в десятках судових позовів як такі, що самі спричиняють проблеми з доступністю, перешкоджаючи роботі допоміжних технологій користувачів. Кілька судів відхилили аргумент про те, що самої лише надбудови достатньо для спростування позову за Розділом III (Title III).
Віджети можуть відігравати роль доповнення до базового усунення недоліків — для користувачів, яким потрібно застосувати власні налаштування поверх уже доступного сайту — але вони не є заміною виправленню основного коду. Юридичні фірми позивачів тепер спеціально націлюються на сайти, що використовують певні продукти-надбудови.
Документуйте все для захисту
Коли надходить лист-претензія, ваша стратегія захисту майже повністю залежить від того, що ви можете довести щодо вашої програми доступності на момент імовірного порушення. Створіть документальний слід, який включає:
- Датовані звіти про аудит із зазначенням обсягу та результатів
- Тікети на усунення недоліків із датами закриття
- VPAT постачальників та звіти про відповідність вимогам доступності
- Записи про навчання дизайнерів та розробників
- Внутрішні контрольні списки перевірки доступності, прив'язані до запусків продуктів
- Журнал змін декларації про доступність
- Відгуки користувачів, отримані через ваш канал зв’язку щодо доступності, та ваші відповіді на них
Ці записи не запобігають позовам, але вони кардинально змінюють хід переговорів про врегулювання. Позивач, який сподівається на швидку виплату 10 000 доларів за дрібну претензію, набагато менше зацікавлений у справі, коли відповідач може надати актуальний аудит, задокументований план усунення недоліків та VPAT постачальника для кожного вбудованого віджета.
Бухгалтерська сторона відповідності вимогам доступності
Забезпечення доступності рідко буває одноразовою витратою. Зазвичай це відображається у ваших книгах як регулярні витрати — інвойси агентств або підрядників за аудити, ліцензії на програмне забезпечення для інструментів тестування та моніторингу, витрати на перебудову дизайн-системи, витрати на зміну постачальників та неминучі виплати за претензіями, які проскакують попри всі ваші зусилля.
Окреме відстеження цих витрат від загальних витрат на маркетинг або розробку спрощує кілька речей. Ви отримуєте чітке уявлення про реальну вартість відповідності вимогам з часом, що допомагає при плануванні бюджету програми на наступний рік. Ви документуєте витрати, якщо пізніше вам знадобиться заявити про податкове вирахування або амортизувати капіталізовані покращення вебсайту. І якщо ви колись зіткнетеся з колективним позовом від «серійного позивача», ви зможете швидко надати фінансовий звіт про ваші сумлінні інвестиції в доступність — це корисно як у переговорах про врегулювання, так і в будь-якому захисті на основі «розумного пристосування».
Простий сегмент плану рахунків для «Відповідності вимогам доступності» з підкатегоріями для аудитів, оплати праці з усунення недоліків, інструментів тестування, перевірки постачальників та резервів на врегулювання споров дає вагомий результат. Поєднуйте це з щоквартальними переглядами, щоб програма не зникла непомітно з бюджету.
Поширені помилки, яких слід уникати
Кілька паттернів з’являються майже в кожному листі-претензії, які отримують власники бізнесу.
Сприйняття доступності як одноразового проєкту. Сайти постійно змінюються. Нова сторінка продукту, оновлений процес оформлення замовлення, вбудований чат-бот — будь-що з цього може призвести до нових помилок. Впроваджуйте доступність у ваш життєвий цикл розробки, щоб кожна зміна перевірялася перед релізом.
Повна довіра автоматизованому скануванню. Автоматизовані інструменти виявляють лише меншу частину невідповідностей WCAG. Ручне тестування за допомогою допоміжних технологій — єдиний спосіб знайти такі проблеми, як нелогічний порядок фокусування, некоректний альтернативний текст або неробочі користувацькі віджети.
Ігнорування мобільних додатків. Позивачі за Розділом III дедалі частіше подають подвійні позови, що охоплюють як вебсайт, так і нативний мобільний додаток. iOS та Android мають власні API доступності (UIAccessibility та TalkBack/AccessibilityService), і хоча застосовуються ті самі принципи WCAG, вони вимагають специфічного для платформи тестування.
Забування про PDF-файли. Податкові форми, технічні документи, меню та завантажувані ресурси, розміщені на вашому сайті, також підпадають під вимоги. PDF-файли потребують належного порядку читання, тегів, альтернативного тексту та міток полів форм, як і HTML-сторінки.
Припущення, що стороння платформа зробить це за вас. Shopify, WordPress, Wix, Squarespace та подібні платформи надають певну базу для доступності, але вибір теми, власний код, вбудовані віджети та контент, який ви публікуєте, все одно залишаються вашою відповідальністю. У листі-претензії не має значення, чи була тема готовою.
Відсутність декларації про доступність. Публікація декларації нічого не коштує і є наочним доказом ваших добрих намірів. Її відсутність іноді прямо вказується у скаргах.
Тримайте фінанси вашої програми відповідності в порядку з першого дня
Поки ви розбудовуєте свою програму доступності, підтверджуючі фінансові документи — інвойси за аудити, угоди з постачальниками, витрати на оплату праці, витрати на навчання та резерви на врегулювання — мають зберігатися там, де ви зможете їх знайти через роки, якщо серійний позивач згадає ваш бізнес. Beancount.io пропонує текстовий бухгалтерський облік, який дає вам повну прозорість та історію кожної операції з контролем версій, без «чорних скриньок» і прив’язки до постачальника. Почніть безкоштовно і дізнайтеся, чому розробники, фінансові команди та відповідальні оператори обирають текстовий облік для створення записів, що витримають будь-який аудит.