Вебдоступность сайта: юридические риски и ответственность бизнеса

Еще несколько лет назад доступность сайта воспринималась как вопрос доброй воли компании. Теперь это нормативное требование: в ЕС оно уже применяется к коммерческим сервисам, в Украине — формализируется на уровне законодательства. Для бизнеса это означает, что недоступный интерфейс перестает быть чисто UX-проблемой и превращается в источник юридических, рыночных и репутационных рисков. Давайте разберем, какие требования действуют уже сегодня, для каких компаний они обязательны, как распределяется ответственность внутри команды и что проверяют в ходе аудита.

Вебдоступность как требование к современному бизнес-сайту

Аудитория сети огромна и неоднородна: среди посетителей любого сайта всегда есть и будут люди с нарушениями зрения, слуха, моторики или когнитивных функций. Именно поэтому необходима вебдоступность — это свойство цифрового продукта, при котором пользователь может получить информацию и завершить целевое действие вне зависимости от способа взаимодействия с интерфейсом: мышью, клавиатурой, скринридером, голосовым управлением, на экране с увеличенным масштабом или в режиме высокого контраста.

Наиболее критично доступность вебсайтов влияет на следующие группы пользователей:

• незрячие люди и люди с нарушениями зрения, работающие через screen reader или значительное увеличение картинки на дисплее;

• люди со слабым зрением и нарушениями цветовосприятия – для них важна контрастность текста и элементов управления;

• люди с нарушениями слуха, которым требуются субтитры и транскрипции для видеоконтента;

• люди с моторными нарушениями, которые не используют мышь и нуждаются в навигации с клавиатуры и достаточном размере целей нажатия;

• пользователи с когнитивными особенностями и дислексией – для них важны простой язык, предсказуемая навигация и понятные сообщения об ошибках;

• люди пожилого возраста, у которых одновременно может ухудшаться зрение, слух и точность движений.

Отдельная категория – ситуативные ограничения: яркое солнце на экране смартфона, сломанный тачпад, медленный интернет, работа одной рукой. Именно поэтому доступный вебдизайн почти всегда улучшает метрики для всей аудитории, а не только для людей с ограничениями.

В контексте проблематики веб-доступности не следует путать несколько близких терминов, имеющих разный объем. В частности, доступность сайта – это техническое соответствие конкретного ресурса требованиям стандартов. Цифровая доступность и цифровая безбарьерность — более широкие понятия, которые охватывают сайты, мобильные приложения, электронные документы, банкоматы, терминалы самообслуживания и каналы поддержки. Инклюзивный дизайн – это подход к проектированию, который учитывает разнообразие пользователей еще на этапе формирования продуктовой идеи и зачастую выходит за рамки нормативного минимума.

Что ограничивает доступность сайта? Типичные барьеры зависят от типа ресурса. На корпоративных ресурсах это меню, раскрывающееся только на hover, карусели с автопрокруткой, отсканированные PDF вместо текста, формы без программно связанных подписей. В сервисах и личных кабинетах – это модальные окна без управления фокусом, таблицы без семантической разметки, ошибки, отмеченные цветом, короткие таймауты сессии. В интернет-магазинах критическими становятся фильтры каталога, кастомные селекты размера и цвета, усложненные шаги оформления заказа, CAPTCHA и сторонние чат-виджеты: именно здесь недоступность напрямую блокирует покупку.

Для бизнеса практический вывод прост: большинство этих барьеров не имеют отдельной «accessibility-природы». Нарушенная структура заголовков одновременно вредит и скринридеру, и поисковым роботам. Отсутствующие одписи полей увеличивают количество ошибок в формах для всех пользователей. Маленькие кнопки в мобильной версии снижают конверсию вне зависимости от наличия ограничений у пользователя. Поэтому доступность сайта следует рассматривать не как отдельный проект "для меньшинства", а как часть технического качества продукта.

Какие законы и стандарты регулируют вебдоступность

Требования в Украине и роль ДСТУ EN 301 549:2022

Базовый национальный документ для Украины — ДСТУ EN 301 549:2022 “Информационные технологии. Требования касательно доступности продуктов и услуг ИКТ”, утвержденный приказом Национального центра стандартизации №68 от 5 мая 2022 года. Этот приказ идентичен европейскому стандарту EN 301 549 V3.2.1 (2021-03), поэтому фактически переносит в украинское правовое поле европейские технические требования. Для вебконтента стандарт опирается на WCAG 2.1 уровней A и AA, но охватывает более широкое поле: программное обеспечение, электронные документы, аппаратные терминалы, услуги поддержки.

Постановлением Кабинета Министров № 757 от 21 июля 2023 г. соблюдение этого стандарта стало обязательным для органов исполнительной власти при создании и модернизации их вебсайтов и информационно-коммуникационных систем. Предусмотрены и исключения — например, для аудио- и видеозаписей, опубликованных до вступления в силу постановления, и для прямых трансляций, кроме оповещения об угрозе жизни. Рамочным документом остается Национальная стратегия создания безбарьерного пространства до 2030 года, утвержденная указом Президента в 2021 году.

Здесь важно различать два европейских инструмента, которые часто путают. Директива (ЕС) 2016/2102 касается вебсайтов и приложений государственного сектора – именно ее логика уже отражена в украинских требованиях к органам власти. European Accessibility Act, в то же время, впервые распространяет обязанности на частный сектор. Украинские нормы пока двигаются по первой модели, тогда как бизнесу, работающему с ЕС, приходится ориентироваться на вторую.

Для частного бизнеса универсальной прямой нормы в Украине сейчас нет, но вектор движения зафиксирован. В ноябре 2025 года правительство одобрило и подало в Верховную Раду законопроект № 14278 «О цифровой доступности в Украине», впоследствии был зарегистрирован и альтернативный проект. Оба предусматривают распространение требований не только на государственные органы, но и на частный сектор в ключевых областях: банки, транспорт, интернет-магазины, медицина, образование, связь. Малый бизнес планируют вывести из-под основных обязанностей, а владельцев сервисов обязать публично отчитываться об уровне доступности, с государственным мониторингом исполнения. Закон на момент подготовки материала не принят, однако компаниям, которые сейчас планируют редизайн, дешевле будет сразу заложить в продукт accessibility requirements, чем перерабатывать интерфейс после вступления в силу новых норм.

Отдельные сегменты уже получили отраслевые ориентиры. Национальный банк в 2024 году утвердил методические рекомендации по инклюзивному предоставлению финансовых услуг, а требования к доступности все чаще появляются в тендерной документации и договорах с международными партнерами.

WCAG 2.2: уровни A, AA и AAA

Web Content Accessibility Guidelines (WCAG) – это требования веб-доступности, разработанные W3C – ведущей глобальной организацией по стандартизации Интернета. WCAG 2.2 получил статус рекомендации 5 октября 2023 года (с редакционным обновлением в декабре 2024-го). Уровень A – базовый минимум, без которого часть пользователей физически не может работать с сайтом. Уровень AA – практический ориентир, на который опираются регуляторы и процедуры. Уровень AAA не рассчитан на полное применение ко всему ресурсу и используется выборочно.

Именно поэтому в коммерческих проектах целевым значением почти всегда выбирается WCAG 2.2 AA. Уровень A оставляет слишком много реальных барьеров, в частности в части контраста и сообщений об ошибках, а ориентация на AAA делает требования невыполнимыми для типичного каталога с тысячами товаров и внешними интеграциями. AA – это тот уровень, который закрывает основные судебные и регуляторные риски и остается управляемым в типичной коммерческой разработке.

Для бизнеса важно, что WCAG 2.2 добавила критерии, которые прямо касаются бизнес-интерфейсов: минимальный размер цели нажатия, альтернатива для drag-and-drop, доступная аутентификация без обязательного воспроизведения капчи или пароля из памяти, отсутствие повторного ввода тех же данных в рамках процесса, последовательное размещение блоков помощи.

European Accessibility Act и рынок ЕС

European Accessibility Act — Директива ЕС 2019/882 – была принята в 2019 году, транспонирована государствами-членами до 28 июня 2022 года и применяется к экономическим операторам с 28 июня 2025 года. Ее сфера охватывает e-Commerce, потребительские банковские услуги, электронные коммуникации, элементы пассажирских перевозок, электронные книги, аудиовизуальные медиасервисы, а также продукты: банкоматы, платежные и самообслуживающие терминалы, ридеры и т.д.

Технической базой соответствия выступает европейский стандарт EN 301 549: в действующей редакции V3.2.1 он содержит WCAG 2.1 AA, но в подготовке уже находится новая версия, ориентированная на WCAG 2.2. Следовательно, сегодня целевое проектирование ресурса под WCAG 2.2 AA — это не перестраховка, а разумный шаг с прицелом под будущие обновления.

Для украинских компаний ключевой фактор — не место регистрации, а факт предоставления услуг потребителям в ЕС. Если украинский интернет-магазин, SaaS-сервис или маркетплейс принимает заказы от европейских покупателей, требования EAA 2025 касаются его так или иначе. 

Директива EAA предусматривает переходные режимы: договоры о предоставлении услуг, заключенные до 28 июня 2025 года, могут выполняться по-прежнему не дольше, чем до 28 июня 2027 года, а для терминалов самообслуживания действуют значительно более мягкие сроки.

Для каких компаний вебдоступность может быть юридически обязательной

• Интернет-магазины, ритейл и онлайн-продажи. Доступность e-Commerce – один из краеугольных кейсов EAA. Под требования попадает весь путь покупателя: поиск, каталог, карточка товара, корзина, оформление, оплата, статус заказа и возврат.

• Банки, денежные сервисы и электронные платежи. Помимо веб-сайта и приложения оценивается доступность аутентификации, подписания документов, платежных форм и клиентской поддержки.

• Телекоммуникационные компании и цифровые сервисы. Здесь добавляются требования к экстренной связи, тарифной информации и самообслуживанию в личном кабинете.

• Транспортные, туристические и другие клиентские онлайн-сервисы. Бронирование, покупка билетов, регистрация, электронные талоны и сообщения об изменениях в рейсе.

• Медицинские, образовательные и причастные к государству сервисы. В украинских законопроектах эти сферы определены четко: онлайн-запись к врачу, электронные кабинеты пациента, обучающие платформы и т.д.

• Украинский бизнес, продающий товары или услуги клиентам в ЕС. Обязанности возникают из самого факта выхода на потребительский рынок ЕС независимо от страны разработки сайта или места пребывания команды.

Отдельная, менее очевидная категория – B2B-компании и разработчики, поставляющие цифровые продукты охваченным отраслям. Формально требования адресованы оператору услуги, но на практике они переносятся в контракт с поставщиком: если модуль или виджет делает сервис клиента несоответствующим требованиям, это становится коммерческой проблемой его вендора.

Исключения существуют, но они уже, чем кажется. От требований к сервису освобождены микропредприятия – компании с менее чем 10 работниками и годовым оборотом или балансом до 2 млн. евро; при этом микропредприятие, производящее или распространяющее охваченные регуляцией продукты, обязанностей не теряет. Второй механизм – принцип непропорциональной нагрузки: бизнес может доказать, что выполнение отдельного требования создает чрезмерное бремя, но это требует задокументированной оценки, сообщения надзорного органа и периодического пересмотра. Это процедура, а не бессрочное увольнение, и именно здесь компании чаще всего остаются без доказательств своей позиции.

Кто отвечает за доступность на сайте?

Вопрос «какой человек отвечает за доступность на вебсайте?» на практике имеет неудобный ответ: одного ответственного здесь выделить невозможно, а попытка назначить им одного разработчика гарантированно проваливается. Frontend-инженер не может исправить недостаточную контрастность, утвержденную в макете, а дизайнер не отвечает за alt-текст, который контент-менеджер добавит через два месяца после релиза.

На практике работает только многогранная модель контроля требований, которая должна укорениться в бизнес-культуре. Свою роль отыгрывают все стороны:  

• Владелец бизнеса и руководство. Топ-менеджмент принимает accessibility policy, выделяет бюджет на аудит веб-доступности и ремедиацию, определяет целевой уровень соответствия. Юридическая ответственность бизнеса за недоступный сервис остается на компании, а не на подрядчике.

• UX/UI-дизайнер. Контраст, состояние фокуса, размеры интерактивных элементов, логика порядка чтения, текстовые подписи вместо одних лишь иконок, доступные паттерны для сложных компонентов – все это зона ответственности специалиста по UX/UI.

• Frontend-разработчик. Он отвечает за семантический HTML, корректную структуру заголовков, управление фокусом в модальных окнах, поддержку масштабирования и клавиатуры, корректные ARIA-атрибуты и .д. 

• QA-специалист. На него возлагаются тест-кейсы по accessibility testing в регрессии: проход сценариев только с клавиатурой, проверка со скринридером, контроль сообщений об ошибках в формах и т.д.

• Контент-менеджер. Адаптированные alt-тексты, осмысленные тексты ссылок, корректная иерархия заголовков в статьях, субтитры и транскрипции, доступные версии документов – все это можно проконтролировать только на уровне специалиста по контенту. 

• Accessibility Lead или accessibility coordinator. Отдельная роль оправдана, когда продукт очень масштабный, релизы выходят чаще раза в месяц, имеется несколько команд или жесткое регуляторное давление. Профильный менеджер по вебдоступности проверяет единые критерии на всех уровнях, ведет реестр нарушений и готовит accessibility statement.

Чтобы это не осталось декларацией, ответственность фиксируют в процессах: требования доступности вносятся в definition of done, в чеклист code review, в критерии приема макетов и в инструкции для редакторов контента. Без этого accessibility compliance держится на конкретных добросовестных людях и исчезает, если они покидают проект. 

Отдельно следует урегулировать работу с подрядчиками. Передача разработки в аутсорс не переносит юридической ответственности на исполнителя, поэтому целевой уровень соответствия, объем проверок и порядок устранения выявленных нарушений должны быть частью договора и критериев приемки, а не устной договоренностью.

Нехватка вебдоступности на сайте: юридические риски для бизнеса

Юридические проблемы сайта редко начинаются сразу с суда. Типичная последовательность иная: жалоба пользователя, публичная огласка, обращение к регулятору, а затем - судебный или административный трек. Бизнес, пренебрегающий требованиями вебдоступности, рискует столкнуться с целым спектром последствий:

• Жалобы и претензии по дискриминации. Невозможность самостоятельно оформить заказ или воспользоваться услугой трактуется как дискриминация пользователей по признаку инвалидности — это распространенное основание обращений.

• Проверки, предписания и санкции. В юрисдикциях, где действуют требования, надзорные органы могут потребовать плана исправлений в сжатые сроки. Ремедиация «под давлением» почти всегда дороже плановой.

• Судебные споры и расходы по защите. Даже выигранное дело означает затраты на юристов, техническую экспертизу и подготовку доказательств того, что компания работала над доступностью.

• Ограничение выхода на рынки ЕС. Партнеры, платежные провайдеры и маркетплейсы еврозоны все чаще требуют подтверждения соответствия перед подключением.

• Риски для тендеров и корпоративных закупок. В публичных закупках соответствие WCAG или EN 301 549 может быть квалификационным условием: несоответствие просто снимает предложение с рассмотрения.

• Удар по репутации и потеря клиентов. Недоступный checkout – это не абстрактная проблема, а незавершенные заказы и отрицательные отзывы, долго живущие в поиске.

Еще один недооцененный риск — накопленный технический долг. Если доступность не была заложена в дизайн-систему, правку после претензии приходится делать быстро и точечно, в режиме патчей. Такие патчи редко согласованы между собой, они усложняют дальнейшую поддержку и почти гарантированно возвращают часть нарушений уже через несколько релизов.

Что проверяют при аудите вебдоступности сайта

Accessibility audit — это не просто обзор или тестирование сайта, а структурированная проверка всех ключевых сценариев. Перед его началом фиксируют scope: список шаблонов страниц, пользовательские пути, версии браузеров и вспомогательных технологий, целевой стандарт. Без этого результаты невозможно ни сравнить во времени, ни использовать в качестве доказательства перед регуляторными органами. Практический объем проверки таков:

• Навигация с клавиатуры. Можно ли пройти весь путь — от меню до подтверждения заказа — без мышки, видимый ли фокус, не «проваливается» ли он в скрытые элементы, работает ли выход из модальных окон.

• Контрастность. Текст, кнопки, поля ввода, состояние ошибки, элементы на изображениях и градиентах, а также неактивные, но значимые элементы.

• Alt-тексты и изображения. Содержательные описания для информативной графики, пустой alt для декоративной, текстовые альтернативы для таблиц и схем.

• Структура и семантика. Один H1, последовательная иерархия заголовков, семантический HTML для списков, таблиц и landmark-регионов, ARIA-атрибуты без конфликта с нативной семантикой.

• Доступные вебформы. Программно связанные подписи, понятные сообщения об ошибках с передачей в assistive technologies, подсказки по формату, сохранение введенных данных и доступная аутентификация.

• Поиск и динамический контент. Автодополнение, счетчики результатов, подгрузка товаров во время скрола – все это должно корректно сообщаться вспомогательным технологиям, а не меняться “по-тихому”.

• Совместимость со скринридерами. Проверка по меньшей мере в двух комбинациях, например, NVDA из Firefox и VoiceOver из Safari: результаты могут заметно различаться.

• Видео и аудио. Субтитры, транскрипции, управление проигрывателем с клавиатуры, отсутствие автозапуска звука.

• Мобильная версия. Работа с включенными вспомогательными технологиями, поддержка ориентации экрана, размер целей нажатия, корректное масштабирование без горизонтального скрола.

Дополнительно проверяют параметры, которые легко пропустить: корректно указанный язык страницы и язык отдельных фрагментов, возможность удлинить или выключить таймауты, управление анимацией и автопрокруткой, работоспособность интерфейса при увеличении текста до 200%, а также сохранение функциональности без CSS.

Отдельно проверяют сторонние интеграции: виджеты чатов, платежные iframe, баннеры согласия на cookie. Формально это чужой код, но для пользователя и регулятора это часть сервиса сайта.

WCAG 2.2 AA как ориентир для уменьшения accessibility-рисков

Стандарты WCAG базируются на четырех принципах: 

• Perceivable  — контент можно воспринять через любой доступный канал; 

• Operable — интерфейсом можно управлять разными способами ввода; 

• Understandable — поведение системы предсказуемое, а ошибки ясны; 

• Robust — разметка корректно интерпретируется браузерами и вспомогательными технологиями.

Коммерческие сайты чаще всего нарушают достаточно узкий набор критериев: недостаточная контрастность текста, отсутствующие или бессмысленные текстовые альтернативы, кастомные компоненты без доступного имени и роли, невидимый фокус, формы без подписей, нарушенная структура заголовков, маленькие цели нажатия, недоступная аутентификация. Хорошая новость заключается в том, что исправление этого набора снимает большую часть практических барьеров.

Автоматизированной проверки недостаточно. Валидаторы хорошо ловят формальные дефекты – недостаток alt, низкий контраст, нарушение порядка заголовков, — но не оценивают, имеет ли alt-текст смысл, логичен ли порядок фокуса, понятно ли сообщение об ошибке, можно ли завершить оформление заказа скринридером. Поэтому рабочая схема проверки на WCAG состоит из трех слоев: автоматизированное сканирование в CI, ручной аудит критических сценариев и тестирование с реальными assistive technologies. Оптимальный подход к аудиту — когда ручную часть выполняет человек, который ежедневно работает со скринридером, или хотя бы регулярно проходит сценарии только на клавиатуре: иначе проверка сводится к формальному прохождению чеклиста без понимания реального пользовательского опыта.

Завершающий шаг – accessibility statement на сайте. Следует указать целевой стандарт и уровень (например, WCAG 2.2 AA), дату последней оценки, известные ограничения и сроки их устранения, канал обратной связи для сообщений о барьерах. Публичное заявление само по себе не делает сайт доступным, но демонстрирует системную работу. Именно оно становится первым документом, который будут запрашивать после жалобы.

Как бизнесу организовать соответствие требованиям вебдоступности

Шаг 1. Определить нормативные требования. Зафиксируйте страны продаж, отрасль, тип услуг и целевой стандарт. Для бизнеса, ориентированного на ЕС, это EN 301 549 да WCAG 2.2 AA как рабочий уровень

Шаг 2. Провести accessibility-аудит сайта. Начинать следует не со всего сразу, а с критических путей пользователя: главная, каталог, карточка товара, checkout, авторизация, формы контакта, личный кабинет.

Шаг 3. Приоритезировать нарушения. Сначала следует исправить блокеры, которые делают невозможным завершение сценария, затем существенные барьеры, и только дальше – косметические дефекты.

Шаг 4. Внести требования к дизайн-системе. Доступные компоненты в UI-kit дают кумулятивный эффект: одна правка распространяется на все страницы, где использован компонент.

Шаг 5. Проверить контент и внешние модули. PDF-файлы, презентации, видео, виджеты, платежные формы. Здесь накапливается больше всего «нового долга» после релиза.

Шаг 6. Ввести постоянный accessibility testing. Автопроверка в pipeline, accessibility-регрессия перед релизом, ручной проход ключевых сценариев после больших изменений.

Шаг 7. Назначить ответственное лицо и начать документирование. Важно вести реестр нарушений со статусами, отчеты аудитов, даты проверок, обновленный accessibility statement. Документация — это и рабочий инструмент и доказательная база в коммуникации с регуляторами. 

Данный план намеренно поэтапный. Попытка привести весь обширный сайт к полному соответствию за один спринт зачастую заканчивается либо срывом сроков, либо формальным «закрытием» пунктов без реального эффекта. Гораздо результативнее будет зафиксировать целевой уровень, закрыть блокеры на критических сценариях, а по остальным двигаться вперед планово, вместе с продуктовым бэклогом.

Вебдоступность при разработке и редизайне: как избежать дорогостоящих исправлений

Стоимость исправления растет накопительно: правка в макете недорогая, правка в компоненте дизайн-системы стоит умеренно, а переработка уже реализуемого функционала на продакшене – самая дорогая, потому что влечет за собой регрессию и повторное тестирование.

Что следует заложить:

• Техническое задание. Прямое указание целевого стандарта и уровня доступности, требований к клавиатурной навигации, контрасту, формам, сообщениям об ошибках, мультимедиа и т.д.

• Дизайн. Токены контраста и видимого фокуса в дизайн-системе, доступные паттерны для модальных окон, табов, аккордеонов, кастомных селектов и датапикеров.

• Разработка. Приоритет нативных элементов над кастомными, линтеры доступности в IDE и CI, ARIA только как дополнение к семантике.

• Критерии приемки. Проход основных сценариев на клавиатуре перед запуском, проверка скринридером, отчет об отсутствии блокирующих нарушений WCAG. Такие критерии следует прописывать в договоре с подрядчиком.

• Контроль после релиза. Инструкция для редакторов и контент-менеджеров, обязательный alt при загрузке изображений в CMS, повторная проверка после обновления функционала и подключения новых интеграций.

Редизайн – самая дешевая точка входа в accessibility compliance, потому что компоненты и контент так или иначе перерабатываются. Если проект уже в активной разработке, минимальный шаг – добавить доступность к критериям приемки новых компонентов, чтобы не наращивать технический долг. 

FAQ