Меня зовут Максим, я веб-разработчик. Тема доступности сайтов долго оставалась на периферии российского веба — «это для госсайтов, нас не касается». Но в 2025–2026 году ситуация изменилась. Во-первых, обновлённый ГОСТ Р 52872 стал де-факто стандартом, на который ссылаются суды при рассмотрении жалоб. Во-вторых, Роскомнадзор включил доступность в список проверяемых параметров для ряда категорий сайтов. В-третьих — и это главное — в России более 11 миллионов людей с инвалидностью, и значительная часть из них пользуется интернетом. Если ваш сайт для них недоступен — вы теряете клиентов. Расскажу, что конкретно нужно сделать и сколько это стоит.

О каких нарушениях идёт речь

Когда говорят «доступность сайта» (web accessibility), имеют в виду возможность пользоваться сайтом для людей с различными ограничениями:

Нарушения зрения. От полной слепоты до слабовидения и дальтонизма. Незрячие пользователи работают через программы экранного доступа (screen readers) — NVDA, JAWS, VoiceOver. Программа читает вслух содержимое страницы, и пользователь навигирует с клавиатуры. Если сайт свёрстан без семантики — экранный доступ «видит» хаос.

Нарушения слуха. Глухие и слабослышащие пользователи не воспринимают аудио- и видеоконтент без субтитров.

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

Когнитивные нарушения. Дислексия, СДВГ, РАС, интеллектуальные нарушения. Сложный язык, перегруженный интерфейс, отсутствие предсказуемости — барьеры для этой аудитории.

ГОСТ Р 52872: что это и кого обязывает

ГОСТ Р 52872-2019 «Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности» — это российский стандарт, основанный на международных рекомендациях WCAG 2.1.

Кого обязывает

Государственные сайты. Федеральные и муниципальные органы власти, госучреждения — обязаны соответствовать. Это закреплено в 419-ФЗ «О социальной защите инвалидов».

Социально значимые сервисы. Банки, страховые, телеком-операторы, транспортные компании — Роскомнадзор и ФАС всё чаще проверяют их сайты на доступность.

Коммерческие сайты. Формально ГОСТ не обязывает частный бизнес (он носит рекомендательный характер). Но: судебная практика показывает, что суды принимают жалобы на недоступность коммерческих сайтов, ссылаясь на 419-ФЗ и антидискриминационное законодательство. В 2024–2025 годах количество таких дел выросло.

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

WCAG 2.1: четыре принципа доступности

ГОСТ Р 52872 основан на WCAG (Web Content Accessibility Guidelines) — международном стандарте, разработанном W3C. Четыре принципа:

1. Воспринимаемость (Perceivable)

Контент должен быть доступен для восприятия. Конкретные требования:

Alt-тексты для изображений. Каждое информативное изображение должно иметь атрибут `alt` с описанием содержимого. Декоративные изображения — `alt=""` (пустой alt), чтобы экранный доступ их пропускал.

Пример: фото товара — `alt="Кресло офисное Ergon-3000, чёрное, сетчатая спинка"`. Декоративная линия — `alt=""`.

Субтитры для видео. Все видеоматериалы с речью должны иметь текстовые субтитры. Для аудиоконтента — текстовая расшифровка.

Контрастность текста. Соотношение контраста текста к фону — минимум 4,5:1 для обычного текста, 3:1 для крупного текста (18px+ обычный или 14px+ жирный). Проверяется инструментами: WebAIM Contrast Checker, axe DevTools.

Масштабирование. Сайт должен корректно работать при увеличении масштаба до 200% без потери функциональности и читаемости. Никакого `user-scalable=no` в метатеге viewport.

2. Управляемость (Operable)

Все функции сайта должны быть доступны с клавиатуры.

Навигация табом. Пользователь должен иметь возможность перемещаться между всеми интерактивными элементами (ссылки, кнопки, поля формы) с помощью клавиши Tab. Порядок перемещения — логичный, соответствующий визуальному порядку.

Видимый фокус. Когда элемент получает фокус (при навигации табом) — он должен быть визуально выделен. Многие дизайнеры убирают `outline: none` для «красоты» — это делает сайт недоступным для клавиатурных пользователей.

Отсутствие ловушек фокуса. Пользователь не должен «застревать» в модальном окне или виджете без возможности выйти клавишей Escape.

Достаточное время. Если на сайте есть таймеры (например, время сессии) — пользователь должен иметь возможность продлить время.

Избегание мерцания. Контент не должен мерцать чаще 3 раз в секунду — это может вызвать эпилептический приступ.

3. Понятность (Understandable)

Контент и интерфейс должны быть понятными.

Язык страницы. Атрибут `lang="ru"` на теге `<html>`. Экранный доступ использует его для выбора правильного голосового движка.

Предсказуемость. Навигация одинакова на всех страницах. Элементы управления ведут себя ожидаемо. Фокус не перемещается самопроизвольно.

Помощь при ошибках. Формы должны чётко сообщать об ошибках: что не так, как исправить. Не просто «Ошибка» красным цветом, а «Поле "Телефон" заполнено некорректно. Укажите номер в формате +7 (XXX) XXX-XX-XX».

4. Надёжность (Robust)

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

Валидный HTML. Правильная семантическая разметка: заголовки (h1–h6) в правильной иерархии, списки — через `<ul>/<ol>`, таблицы — через `<table>` с заголовками `<th>`, формы — с `<label>`.

ARIA-атрибуты. Для сложных интерактивных компонентов (табы, аккордеоны, модальные окна, слайдеры) — ARIA-роли и атрибуты, которые объясняют экранному доступу, что это за элемент и как с ним взаимодействовать.

Что конкретно нужно проверить на вашем сайте

Вот чек-лист, который я использую при аудите доступности:

Изображения. У каждого `<img>` есть осмысленный alt? Декоративные изображения имеют пустой alt?

Заголовки. Иерархия h1–h6 соблюдена? Нет пропусков (h1 → h3 без h2)?

[Формы](/blog/forma-obratnoj-svyazi-na-sajte). Каждое поле имеет `<label>`? Обязательные поля отмечены не только цветом? Сообщения об ошибках — текстовые и конкретные?

Контраст. Текст и фон — соотношение минимум 4,5:1?

Клавиатура. Все элементы доступны табом? Видимый фокус? Нет ловушек?

Ссылки. Текст ссылки описывает назначение? Нет «нажмите сюда» и «подробнее» без контекста?

Видео. Есть субтитры?

[Мобильная версия](/blog/adaptivnaya-vyorstka-sajta). Элементы управления достаточно крупные (минимум 44×44px)? Можно увеличить масштаб?

Язык. `lang="ru"` указан?

Скорость. Анимации можно отключить (prefers-reduced-motion)?

Как я внедряю доступность на проектах

Этап 1: Аудит

Использую комбинацию автоматических и ручных проверок:

Автоматические инструменты. axe DevTools (расширение для браузера), Lighthouse (встроен в Chrome DevTools), WAVE (WebAIM). Находят около 30–40% проблем: отсутствие alt, низкий контраст, отсутствие label.

Ручная проверка. Прохожу сайт с клавиатуры (без мыши). Включаю экранный доступ (NVDA — бесплатный для Windows) и слушаю, как он читает страницу. Проверяю формы, навигацию, модальные окна. Это находит оставшиеся 60–70% проблем.

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

Этап 2: Исправление

Приоритизирую по критичности:

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

Важные — затрудняют использование: низкий контраст, отсутствие label, неправильная иерархия заголовков.

Рекомендуемые — улучшают опыт: субтитры, расширенные ARIA-описания, поддержка prefers-reduced-motion.

Этап 3: Интеграция в процесс разработки

Доступность — не разовая акция, а часть процесса. Я добавляю:

  • Линтер (eslint-plugin-jsx-a11y для React) — ловит проблемы на этапе написания кода
  • Автоматические тесты доступности (axe-core в CI/CD) — при каждом деплое
  • Чек-лист доступности в Definition of Done — ни одна задача не закрывается без проверки

Виджет доступности: панацея или театр?

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

Плюсы. Формально показывает, что компания заботится о доступности. Некоторые пользователи действительно используют увеличение шрифта и высокий контраст.

Минусы. Виджет не решает проблему. Если сайт не имеет семантической разметки — экранный доступ всё равно не работает. Если навигация не доступна с клавиатуры — виджет не поможет. Это как поставить пандус перед зданием, в котором все двери заперты.

Моя рекомендация. Виджет — опционально, как дополнение. Базовая доступность (семантика, контраст, клавиатурная навигация, alt-тексты) — обязательно. Сначала фундамент, потом — украшения.

Стоимость внедрения доступности

Аудит существующего сайта (автоматический + ручной, отчёт с приоритизированным списком проблем). Срок: 3–7 дней. Бюджет: 30–80 тысяч рублей.

Исправление проблем на существующем сайте. Зависит от масштаба проблем. Для среднего корпоративного сайта (20–50 страниц): 50–200 тысяч рублей. Для интернет-магазина с тысячами страниц: 150–500 тысяч рублей.

Разработка нового сайта с учётом доступности. Надбавка к стоимости: 10–20%. Значительно дешевле, чем переделывать потом.

Виджет доступности (если нужен): 15–40 тысяч рублей за кастомную разработку. Или бесплатные готовые решения (но с ограничениями).

Бизнес-аргумент для руководства

Если вы — разработчик или маркетолог, которому нужно убедить руководство инвестировать в доступность:

  1. 11 миллионов потенциальных клиентов с инвалидностью в России. Плюс люди с временными ограничениями (сломанная рука, усталость глаз) и возрастные пользователи (55+).
  1. SEO-бонусы. Семантическая разметка, alt-тексты, правильная структура заголовков, быстрая загрузка — всё это факторы ранжирования в Яндексе. Доступный сайт = SEO-оптимизированный сайт.
  1. Юридическая защита. Количество судебных исков за недоступность сайтов растёт. Превентивные вложения — дешевле, чем судебные издержки.
  1. Репутация. Компания, которая заботится о доступности — воспринимается как социально ответственная. Это работает на бренд.

Если нужна помощь с аудитом или внедрением доступности на вашем сайте — обращайтесь.