В 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 — Руководство по обеспечению доступности веб-контента, поддерживаемое Консорциумом Всемирной паутины — организовано вокруг четырех принципов, удобно сокращенных аббревиатурой 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 (landmarks), чтобы пользователи программ чтения экрана могли быстро переходить к нужному разделу. Избегайте стилизации <div> под заголовок без присвоения ему соответствующей семантической роли.
Изменение размера и перекомпоновка (1.4.4, 1.4.10)
Текст должен оставаться читаемым при 200-процентном увеличении без появления горизонтальной прокрутки. Макеты должны перекомпоновываться (Reflow) при ширине области просмотра 320 CSS-пикселей без необходимости двумерной прокрутки.
Где сосредоточено большинство судебных исков
На три федеральных округа приходится основная масса исков о доступности веб-сайтов: Южный округ Нью-Йорка, Центральный округ Калифорнии и Южный округ Флориды. Нью-Йорк лидирует с большим отрывом, отчасти потому, что Закон штата Нью-Йорк о правах человека и Закон города Нью-Йорка о правах человека предоставляют дополнительные рычаги на уровне штата и имеют более низкие пороги для подачи исков, чем федеральные требования ADA.
Калифорния дополняет это Законом Анру о гражданских правах (Unruh Civil Rights Act), который предусматривает компенсацию установленных законом убытков в размере 4000 долларов за каждое нарушение на одного истца. Это кардинально меняет математику урегулирования: небольшая претензия может быстро превратиться в риск выплаты шестизначной суммы, если иск получит статус коллективного.
Флорида стала третьим центром с 2020 года: несколько юридических фирм со стороны истцов развили масштабную практику, нацеленную на ресторанные сети, гостиничные бренды и интернет-магазины, работающие напрямую с потребителями (D2C).
Разработка дорожной карты устранения нарушений
Если вы получили претензионное письмо — или, что еще лучше, если вы начали действовать до его появления — работа разбивается примерно на пять этапов. Относитесь к этому как к проекту с бюджетом и дедлайном, а не как к разовому аудиту.
Этап 1: Автоматизированный и ручной аудит
Начните с автоматизированного сканирования с помощью таких инструментов, как axe DevTools, WAVE или Google Lighthouse. Автоматизированные инструменты выявляют от 30 до 50 процентов нарушений WCAG — остальные требуют ручного тестирования с использованием программ чтения экрана (NVDA на Windows, VoiceOver на macOS и iOS, TalkBack на Android), навигации только с клавиатуры, а также тестирования масштабирования и перекомпоновки.
Документируйте каждое нарушение с указанием критерия WCAG, затронутой страницы или шаблона, степени серьезности и расчетных усилий на исправление. Этот журнал аудита станет основой для всех последующих этапов.
Этап 2: Исправление дизайн-системы и компонентов
Большинство массовых ошибок кроется в вашей дизайн-системе: контрастность кнопок, индикаторы фокуса, поля ввода форм, шаблоны модальных окон, элементы управления каруселью, навигационные меню. Исправление компонента один раз устраняет ошибку во всех местах его использования. Отдайте приоритет компонентам, которые встречаются на большинстве страниц.
Этап 3: Проверка контента
Альтернативный текст для изображений, субтитры к видео, структура заголовков и метки форм — это обычно исправления на уровне контента, которые затрагивают большинство шаблонов и страниц. Создайте чек-лист для авторов, которому они должны следовать при создании каждой новой страницы, и задачу в бэклоге для ретроактивного исправления существующих страниц.
Этап 4: Координация со сторонними поставщиками
Большинство современных сайтов используют сторонние виджеты: формы оплаты, онлайн-чаты, календари бронирования, видеоплееры, аналитические оверлеи, виджеты отзывов и всплывающие окна для сбора email. Каждый из них может содержать свои нарушения доступности, и суды по Разделу III (Title III), как правило, признают бизнес ответственным за доступность кода сторонних поставщиков, внедренного на его сайте.
Для каждого поставщика запросите актуальный VPAT (Voluntary Product Accessibility Template) или Отчет о соответствии требованиям доступности. Убедитесь, что поставляемая ими версия соответствует WCAG 2.1 уровня AA. Требуйте от поставщиков исправления недостатков или замените их.
Этап 5: Заявление о доступности и канал обратной связи
Опубликуйте на видном месте ссылку на заявление о доступности, в котором указан стандарт, которому вы стремитесь соответствовать (обычно WCAG 2.1 уровня AA), известные ограничения и канал связи (email и телефон) для сообщений пользователей о проблемах с доступностью. Такое заявление не дает юридического иммунитета, но подтверждает добросовестность ваших намерений и дает ответчикам по претензионным письмам конкретный аргумент в свою защиту.
Несколько слов об оверлеях доступности
Процветающая индустрия инструментов «оверлеев доступности» (accessibility overlays) — JavaScript-виджетов, которые обещают мгновенное соответствие стандартам WCAG с помощью одной строки кода — заявляет о быстром и дешевом решении проблем доступности. Реальность намного сложнее. Оверлеи фигурируют в десятках судебных исков как инструменты, которые сами создают проблемы с доступностью, мешая работе ассистивных технологий пользователей. Ряд судов отклонил аргумент о том, что одного оверлея достаточно для защиты от иска по Разделу III (Title III ADA).
Оверлеи могут играть роль дополнения к основным исправлениям — для пользователей, которым нужно применить собственные предпочтения поверх уже доступного сайта, — но они не являются заменой исправлению исходного кода. Юридические фирмы истцов теперь специально нацеливаются на сайты, использующие определенные продукты-оверлеи.
Документируйте всё для защиты
Когда приходит претензия (demand letter), ваша стратегия защиты почти полностью зависит от того, что вы сможете доказать относительно вашей программы обеспечения доступности на момент предполагаемого нарушения. Создайте документальный след, который включает:
- Датированные отчеты об аудите с указанием объема и результатов
- Тикеты на исправление ошибок с датами закрытия
- Шаблоны VPAT от поставщиков и отчеты о соответствии доступности
- Записи об обучении дизайнеров и разработчиков
- Внутренние чек-листы проверки доступности, привязанные к запускам продуктов
- Журнал изменений заявления о доступности (accessibility statement)
- Отзывы пользователей, полученные через ваш канал связи по вопросам доступности, и ваши ответы на них
Эти записи не предотвращают иски, но они кардинально меняют ход переговоров о мировом соглашении. Истец, рассчитывающий на быструю выплату 10 000 долларов за «причиненные неудобства», гораздо меньше заинтересован в деле, когда ответчик может предъявить актуальный аудит, задокументированный план исправлений и VPAT на каждый встроенный виджет.
Бухгалтерская сторона соблюдения доступности
Исправление проблем с доступностью редко бывает разовой тратой. Обычно в бухгалтерском учете это отражается как регулярные расходы — счета от агентств или подрядчиков за аудиты, лицензии на ПО для тестирования и мониторинга, затраты на переработку дизайн-системы, расходы на смену поставщиков и неизбежные выплаты по претензиям, которые проскакивают вопреки всем усилиям.
Отдельное отслеживание этих расходов от общих затрат на маркетинг или разработку упрощает несколько вещей. Вы получите четкое представление об истинной стоимости комплаенса во времени, что поможет при планировании бюджета на следующий год. Вы задокументируете расходы на случай, если позже потребуется заявить о налоговом вычете или амортизировать капитализированные улучшения сайта. И если вы когда-либо столкнетесь с коллективным иском от серийного истца, вы сможете быстро предоставить финансовый отчет о ваших добросовестных инвестициях в доступность — это полезно как в переговорах о мировом соглашении, так и при защите, основанной на принципе «разумной модификации».
Простой сегмент в плане счетов «Соблюдение доступности» с подкатегориями для аудитов, трудозатрат на исправления, инструментов тестирования, проверки поставщиков и резервов на выплаты по претензиям — это важный шаг. Совместите это с ежеквартальными проверками, чтобы программа не выпала из бюджета.
Распространенные ошибки, которых следует избегать
В почти каждой претензии, которую получают владельцы бизнеса, прослеживается несколько закономерностей.
Отношение к доступности как к разовому проекту. Сайты постоянно меняются. Новая страница продукта, обновленное оформление заказа, встроенный чат-бот — любой из этих элементов может привести к новым ошибкам. Внедрите доступность в жизненный цикл разработки, чтобы каждое изменение проверялось перед выпуском.
Полное доверие автоматическим сканерам. Автоматизированные инструменты находят лишь малую часть нарушений WCAG. Ручное тестирование с помощью ассистивных технологий — единственный способ обнаружить такие проблемы, как нелогичный порядок фокуса, вводящий в заблуждение альтернативный текст или неработоспособные кастомные виджеты.
Игнорирование мобильных приложений. Истцы по Разделу III всё чаще подают двойные иски, охватывающие как веб-сайт, так и нативное мобильное приложение. У iOS и Android есть свои собственные API доступности (UIAccessibility и TalkBack/AccessibilityService); принципы WCAG те же, но требуется специфическое для платформ тестирование.
Забытые PDF-файлы. Налоговые формы, аналитические отчеты, меню и загружаемые ресурсы на вашем сайте — всё это входит в область ответственности. PDF-файлам нужны правильный порядок чтения, теги, альтернативный текст и метки полей форм, так же как и HTML-страницам.
Предположение, что сторонние платформы сделают всё за вас. Shopify, WordPress, Wix, Squarespace и подобные платформы предоставляют определенную базу для доступности, но выбор темы, кастомный код, встроенные виджеты и публикуемый контент остаются вашей ответственностью. В претензии не имеет значения, была ли тема готовой.
Отсутствие заявления о доступности. Его публикация ничего не стоит и является наглядным доказательством добросовестности. Отсутствие такого заявления иногда специально указывается в жалобах.
Держите финансы по комплаенсу в порядке с первого дня
По мере того как вы выстраиваете программу доступности, подтверждающие финансовые документы — счета за аудиты, соглашения с поставщиками, трудозатраты на исправления, расходы на обучение и резервы на выплаты — должны храниться там, где вы сможете найти их через несколько лет, если серийный истец назовет имя вашего бизнеса. Beancount.io предлагает текстовый бухгалтерский учет (plain-text accounting), который обеспечивает полную прозрачность и историю каждой позиции с контролем версий, без «черных ящиков» и привязки к конкретному поставщику. Начните бесплатно и узнайте, почему разработчики, финансовые команды и операторы, заботящиеся о комплаенсе, выбирают plain-text accounting для ведения записей, пригодных для судебной защиты.