Доступность сайта по ГОСТ: требования и внедрение
В России более 11 миллионов людей с инвалидностью, из них около 290 тысяч — с нарушениями зрения. Ещё миллионы людей имеют временные ограничения: сломанная рука, мигрень, яркое солнце на экране. Все они пользуются интернетом — и далеко не каждый сайт готов к этому.
ГОСТ Р 52872-2019 «Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Приёмы создания контента, доступного для пользователей с ограниченными возможностями» — основной российский стандарт веб-доступности. Для государственных сайтов он обязателен. Для коммерческих — пока рекомендателен, но тенденция к ужесточению требований очевидна.
В этой статье разберём, что именно требует ГОСТ, как он соотносится с международным WCAG, какие инструменты использовать для тестирования и как внедрить доступность в существующий сайт без полной переработки.
Зачем бизнесу доступность
Прежде чем погружаться в технические требования, давайте разберёмся, зачем коммерческому сайту доступность, если она пока не обязательна.
Расширение аудитории. 11 миллионов людей с инвалидностью — это огромный рынок. Добавьте сюда людей с возрастными изменениями зрения (каждый третий после 40 лет) и временными ограничениями. Суммарно — до 25% населения может столкнуться с проблемами доступности на вашем сайте.
SEO-эффект. Многие требования доступности совпадают с факторами ранжирования: семантическая разметка, alt-тексты изображений, чёткая структура заголовков, быстрая загрузка. Внедрение доступности улучшает позиции в поиске — мы фиксировали рост органического трафика на 12–18% после доработок.
Юридическая перспектива. В США количество исков по ADA (закон о доступности) для сайтов выросло с 814 в 2017 году до 4 605 в 2025. Россия движется в том же направлении — вопрос времени. Те, кто внедрит доступность сейчас, будут готовы к изменениям.
Юзабилити для всех. Доступный сайт — это удобный сайт. Крупные кнопки, контрастный текст, понятная навигация, работающие формы — всё это улучшает опыт любого пользователя. По данным наших проектов, конверсия форм вырастает на 8–15% после внедрения стандартов доступности.
ГОСТ Р 52872 и WCAG: как они связаны
ГОСТ Р 52872-2019 основан на международных рекомендациях WCAG 2.0 (Web Content Accessibility Guidelines), но адаптирован для российского законодательства и реалий. Ключевое отличие — ГОСТ формулирует требования как обязательный стандарт для определённых категорий сайтов, тогда как WCAG — это рекомендации.
Уровни соответствия WCAG:
- Уровень A — минимальный. Базовые требования, без которых сайт непригоден для части пользователей
- Уровень AA — рекомендуемый. Именно этот уровень соответствует ГОСТ Р 52872 и требуется для госсайтов
- Уровень AAA — максимальный. Полная доступность, на практике достигается редко
ГОСТ Р 52872 в основном соответствует WCAG 2.0 Level AA, но содержит дополнительные требования, специфичные для русскоязычного контента и российского законодательства.
Четыре принципа доступности
И ГОСТ, и WCAG строятся на четырёх фундаментальных принципах. Если вы их понимаете — конкретные требования становятся логичными.
Воспринимаемость
Информация и элементы интерфейса должны быть представлены так, чтобы пользователь мог их воспринять. Это значит:
- Текстовые альтернативы для нетекстового контента (изображения, видео, аудио)
- Субтитры для видео и расшифровки для аудио
- Контент можно представить разными способами без потери информации
- Контент легко видеть и слышать
Управляемость
Элементы интерфейса и навигация должны быть управляемыми. Это значит:
- Вся функциональность доступна с клавиатуры
- У пользователя достаточно времени для взаимодействия
- Контент не вызывает приступов (мигающие элементы)
- Пользователь может найти нужный контент и ориентироваться
Понятность
Информация и управление интерфейсом должны быть понятными. Это значит:
- Текст читаем и понятен
- Веб-страницы работают предсказуемо
- Пользователю помогают избегать ошибок и исправлять их
Надёжность
Контент должен быть достаточно надёжным, чтобы его могли интерпретировать разные пользовательские агенты, включая вспомогательные технологии. Это значит:
- Валидный HTML-код
- Корректное использование ARIA-атрибутов
- Совместимость со скринридерами
Обязательные требования для государственных сайтов
Для сайтов государственных органов и подведомственных организаций доступность регулируется:
- Приказ Минцифры №600 от 18.11.2020 — требования к сайтам госорганов
- ГОСТ Р 52872-2019 — технический стандарт доступности
- Федеральный закон №181-ФЗ «О социальной защите инвалидов» — общие требования
Несоблюдение этих требований — основание для прокурорской проверки и предписания об устранении нарушений.
Что обязательно для госсайтов:
- Версия для слабовидящих (или полная доступность основной версии)
- Уровень контрастности не ниже 4.5:1 для обычного текста
- Все изображения имеют alt-тексты
- Формы содержат label-элементы
- Навигация доступна с клавиатуры
- Видео имеет субтитры
- Документы в доступных форматах (не только PDF-картинки)
Технические требования: что проверять
Структура и семантика
Заголовки (h1–h6) — иерархическая структура без пропусков уровней. На каждой странице один h1, подразделы — h2, подподразделы — h3 и далее. Скринридеры используют заголовки как оглавление страницы.
Landmark-регионы — используйте семантические элементы HTML5: header, nav, main, aside, footer. Или ARIA-роли: role="banner", role="navigation", role="main", role="complementary", role="contentinfo".
Списки — маркированные (ul) и нумерованные (ol) списки должны быть размечены соответствующими тегами, а не абзацами с дефисами.
Таблицы — используйте thead, th, scope для обозначения заголовков строк и столбцов. Добавляйте caption для описания таблицы.
Изображения и медиа
Alt-тексты — каждое информативное изображение должно иметь атрибут alt с описанием содержимого. Декоративные изображения — alt="" (пустой, но обязательно присутствующий).
Правила написания alt-текстов:
- Описывайте содержание, а не формат: «График роста продаж за 2025 год: с 1,2 до 3,8 млн» вместо «Картинка с графиком»
- Не начинайте с «Изображение...» или «Картинка...» — скринридер и так объявит это
- Для сложных изображений (инфографика, схемы) добавляйте развёрнутое описание в тексте страницы
- Логотипы: alt="Название компании — главная страница"
Видео и аудио:
- Субтитры для всех видео с речью
- Аудиодескрипция для видео с визуальной информацией
- Текстовая расшифровка для подкастов и аудиоматериалов
- Управление воспроизведением с клавиатуры
Цвет и контраст
Коэффициент контрастности:
- Обычный текст (менее 18pt / 14pt bold): минимум 4.5:1
- Крупный текст (18pt+ / 14pt bold+): минимум 3:1
- Элементы интерфейса и графика: минимум 3:1
Цвет не единственный способ передачи информации. Ошибка в форме не может обозначаться только красным цветом — нужен текст, иконка или другой индикатор. Ссылки в тексте — не только цветом, но и подчёркиванием или другим визуальным маркером.
Формы и интерактивные элементы
Каждый input имеет label. Не placeholder вместо label — он исчезает при вводе. Label должен быть связан с полем через атрибут for/id или вложенностью.
Сообщения об ошибках — конкретные, привязанные к полю, доступные скринридеру. Используйте aria-describedby для связи поля с сообщением об ошибке и role="alert" для динамических уведомлений.
Фокус — все интерактивные элементы видимо выделяются при фокусе (outline). Никогда не ставьте outline: none без альтернативного стиля фокуса. Порядок фокуса (tab order) должен быть логичным.
Инструменты тестирования доступности
Автоматические
- axe DevTools (расширение браузера) — бесплатно, находит до 60% проблем
- Lighthouse (встроен в Chrome DevTools) — раздел Accessibility
- WAVE (wave.webaim.org) — визуальный отчёт с маркерами на странице
- Pa11y — CLI-инструмент для CI/CD интеграции
- Яндекс.Вебмастер — раздел «Доступность» (экспериментальный)
Ручные проверки
Автоматические инструменты находят только 30–50% проблем. Остальное — ручное тестирование:
- Навигация клавиатурой. Отключите мышь и попробуйте пользоваться сайтом только с клавиатуры. Tab, Shift+Tab, Enter, Space, стрелки. Можете ли вы достичь каждого элемента? Видите ли фокус?
- Скринридер. Установите NVDA (бесплатно, Windows) или VoiceOver (встроен в macOS/iOS). Послушайте, как звучит ваш сайт. Понятна ли навигация? Читаются ли формы?
- Масштабирование. Увеличьте страницу до 200%. Всё ли читается? Нет ли горизонтальной прокрутки?
- Без изображений. Отключите загрузку картинок. Понятен ли контент?
Чек-лист ручного тестирования
- Все изображения имеют осмысленные alt-тексты
- Заголовки образуют логическую иерархию
- Контрастность текста соответствует 4.5:1
- Все формы имеют видимые label
- Фокус виден и следует логичному порядку
- Все функции доступны с клавиатуры
- Нет контента, мигающего чаще 3 раз в секунду
- Ссылки понятны вне контекста (не «нажмите сюда»)
- Язык страницы указан в атрибуте lang
- Таблицы имеют заголовки
Доступность динамического контента
Современные сайты — это не статичные HTML-страницы. Модальные окна, аккордеоны, табы, выпадающие меню, бесконечный скролл — всё это требует отдельного внимания к доступности.
Модальные окна. При открытии модального окна фокус должен переместиться внутрь него. Клавиша Tab не должна выходить за пределы модалки (фокус-ловушка). При закрытии — фокус возвращается к элементу, который открыл окно. Escape закрывает модалку. Атрибуты: role="dialog", aria-modal="true", aria-labelledby для заголовка.
Аккордеоны и табы. Кнопки управления — button с aria-expanded (true/false). Связь между кнопкой и содержимым — через aria-controls. Для табов: role="tablist" на контейнере, role="tab" на вкладках, role="tabpanel" на содержимом. Навигация стрелками между табами, Tab перемещает к содержимому.
Выпадающие меню. При наведении мышью — открывается. А с клавиатуры? Enter или Space на кнопке открывает меню, стрелки навигируют по пунктам, Escape закрывает. Без этого — меню недоступно для клавиатурных пользователей.
Уведомления и тосты. Динамические сообщения (успешная отправка формы, ошибка, предупреждение) должны объявляться скринридеру. Используйте role="alert" для важных уведомлений (ошибки) и role="status" для информационных (успешная отправка). Атрибут aria-live="polite" для неважных, aria-live="assertive" для критичных.
Бесконечный скролл. Для скринридеров бесконечный скролл — кошмар: пользователь не может добраться до footer, не знает общее количество элементов, теряет ориентацию. Альтернатива: кнопка «Загрузить ещё» с указанием «Показано 20 из 150 результатов». Или пагинация — она доступнее по умолчанию.
Автозаполнение и подсказки. Поле поиска с выпадающим списком подсказок должно быть реализовано как combobox: role="combobox" на input, role="listbox" на списке, role="option" на каждой подсказке. aria-activedescendant указывает текущий выбранный элемент. Без этой разметки скринридер не озвучит подсказки.
Пошаговое внедрение доступности
Фаза 1: Аудит (1–2 недели)
Начните с автоматизированного сканирования всех страниц. Затем — ручная проверка ключевых страниц (главная, каталог, форма заявки, контакты). Составьте список проблем с приоритизацией.
При заказе аудита сайта в нашей компании доступность входит в стандартный чек-лист проверки.
Фаза 2: Быстрые победы (1–2 недели)
Исправления, которые дают максимальный эффект при минимальных усилиях:
- Добавить alt-тексты ко всем изображениям
- Связать label с полями форм
- Исправить контрастность текста
- Добавить lang="ru" в html-тег
- Убедиться, что outline фокуса не отключён
- Добавить skip-link для перехода к основному контенту
Фаза 3: Структурные изменения (2–4 недели)
Более глубокие доработки:
- Переработать навигацию для клавиатурного доступа
- Добавить ARIA-атрибуты к кастомным компонентам
- Обеспечить корректное поведение модальных окон (фокус-ловушка)
- Добавить субтитры к видео
- Переработать сообщения об ошибках в формах
Фаза 4: Процессы (постоянно)
Встроить доступность в процесс разработки:
- Добавить axe в CI/CD пайплайн
- Включить проверку доступности в код-ревью
- Тестировать новые функции со скринридером
- Обучить дизайнеров и контент-менеджеров
Типичные ошибки при внедрении
Версия для слабовидящих вместо доступности. Отдельная «версия для слабовидящих» с кнопкой переключения — устаревший подход. Она обычно ограничена по функциональности, не обновляется синхронно с основным сайтом и создаёт сегрегацию. Правильный подход — делать основной сайт доступным для всех.
ARIA вместо семантики. Прежде чем добавлять ARIA-атрибуты, используйте правильные HTML-элементы. Button вместо div с role="button". Nav вместо div с role="navigation". ARIA — это дополнение, а не замена семантического HTML.
Скрытие контента вместо адаптации. Не прячьте элементы от скринридеров с помощью aria-hidden, если в них есть полезная информация. Лучше адаптируйте их.
Бизнес-кейс: ROI доступности
Один из наших клиентов — сеть медицинских клиник — внедрил стандарты доступности на сайте в рамках комплексного юзабилити-аудита. Результаты за 6 месяцев:
- Органический трафик вырос на 15% (SEO-эффект семантической разметки)
- Конверсия форм записи увеличилась на 11%
- Показатель отказов снизился на 8%
- Время на сайте выросло на 22%
- Поступило 340+ записей от пользователей со скринридерами (новая аудитория)
Стоимость внедрения: 180 000 рублей. Дополнительная выручка за 6 месяцев: более 2,4 миллиона рублей.
Доступность мобильной версии
Мобильный трафик составляет более 75% в рунете, и требования доступности для мобильных устройств имеют свою специфику.
Сенсорные цели (Touch Targets). WCAG 2.2 вводит критерий «Target Size» — интерактивные элементы должны быть не менее 24x24 CSS-пикселей (уровень AA) или 44x44 пикселей (уровень AAA). На практике мы рекомендуем минимум 44x44 — это совпадает с рекомендациями Apple и Google для мобильных интерфейсов. Расстояние между кликабельными элементами — не менее 8 пикселей.
Ориентация экрана. Сайт должен корректно работать как в портретной, так и в ландшафтной ориентации. Нельзя блокировать поворот экрана — некоторые пользователи с моторными нарушениями используют устройства только в одной ориентации, закреплённые на кресле или подставке.
Жесты. Все функции, доступные через сложные жесты (pinch-zoom, свайп, long press), должны иметь альтернативу в виде простого нажатия. Свайп для удаления элемента — удобен, но должна быть и кнопка «Удалить».
Масштабирование. Никогда не ставьте maximum-scale=1.0 и user-scalable=no в meta viewport. Это блокирует увеличение текста для слабовидящих. Сайт должен корректно отображаться при увеличении до 200%.
Экранные клавиатуры. Используйте правильные типы input: type="tel" для телефона, type="email" для email, inputmode="numeric" для числовых полей. Это вызывает соответствующую клавиатуру и упрощает ввод для всех пользователей, особенно для людей с моторными нарушениями.
Доступность контента: текст, изображения, документы
Текстовый контент
Язык страницы. Атрибут lang="ru" на теге html — обязателен. Если на странице есть фрагменты на другом языке, оберните их в span с соответствующим lang: span lang="en" для английского текста. Скринридеры используют этот атрибут для переключения синтезатора речи.
Читаемость текста. ГОСТ рекомендует писать тексты, понятные широкой аудитории. Для государственных сайтов — уровень понимания восьмиклассника. Для коммерческих — зависит от аудитории, но общие принципы: короткие предложения (15–20 слов), абзацы по 3–5 предложений, подзаголовки каждые 300–500 слов.
Аббревиатуры. При первом использовании аббревиатуры — расшифровывайте: «CRO (Conversion Rate Optimization — оптимизация конверсии)». Используйте тег abbr с атрибутом title для пояснения.
Документы для скачивания
PDF-файлы. Самая частая проблема на госсайтах — PDF как отсканированное изображение. Такой файл невидим для скринридера. Требования к доступным PDF: текстовый слой (не скан), размеченная структура (теги заголовков), alt-тексты для изображений внутри PDF, указанный язык документа.
Офисные документы. Word и Excel — используйте встроенные стили заголовков, описания для изображений (альтернативный текст в свойствах рисунка), правильную структуру таблиц. Проверяйте доступность через встроенный инструмент Office: «Рецензирование» → «Проверка читаемости».
Организация процесса: как не терять доступность
Внедрить доступность — половина задачи. Вторая половина — не потерять её при обновлениях сайта.
Дизайн-система. Заложите требования доступности в компоненты дизайн-системы: минимальные размеры кнопок, контрастные цветовые пары, стандартные состояния фокуса. Тогда дизайнеры физически не смогут создать недоступный макет.
Чек-лист для контент-менеджеров. При публикации нового контента: заполнен alt для изображений, заголовки используют h2–h3 (не bold-текст), ссылки имеют понятный текст, видео имеет субтитры. Распечатайте чек-лист и повесьте у монитора каждого контент-менеджера.
Автоматические проверки в CI/CD. Добавьте axe-core или Pa11y в процесс деплоя. Если новый код нарушает доступность — сборка не проходит. Это ловит регрессии на ранней стадии.
Регулярный аудит. Раз в квартал — полный аудит доступности ключевых страниц. Раз в год — тестирование с реальными пользователями вспомогательных технологий. При проведении юзабилити-аудита мы всегда включаем блок доступности.
Обучение команды. Проведите воркшоп для разработчиков, дизайнеров и контент-менеджеров. Покажите, как работает скринридер. Дайте попользоваться сайтом только с клавиатуры. Эмпатия через личный опыт — самый эффективный инструмент обучения.
Стоимость внедрения доступности
Бюджет зависит от текущего состояния сайта и требуемого уровня соответствия:
- Экспресс-аудит (автоматическая проверка + рекомендации): 15 000–30 000 ₽
- Полный аудит (автоматический + ручной + тестирование со скринридером): 50 000–120 000 ₽
- Исправление критичных ошибок (alt-тексты, фокус, контраст, label): 30 000–80 000 ₽
- Глубокая доработка (ARIA, клавиатурная навигация, модальные окна, динамический контент): 100 000–300 000 ₽
- Полная переработка (версия для слабовидящих или рефакторинг для полной доступности): 200 000–500 000 ₽
Для сравнения: штраф за несоблюдение требований к доступности госсайта — предписание прокуратуры с конкретными сроками устранения, а за неисполнение предписания — административная ответственность. Для коммерческих сайтов прямых штрафов пока нет, но судебные иски от пользователей с ограниченными возможностями — уже реальность.
Будущее веб-доступности в России
Тренд однозначный — требования будут ужесточаться. В 2025 году Минцифры уже анонсировало разработку нового стандарта на базе WCAG 2.1, который планируется сделать обязательным для всех социально значимых сайтов (банки, страховые, медицина, образование, транспорт).
Европейский опыт показывает направление: European Accessibility Act (EAA) вступает в силу в 2025 году и распространяется на все коммерческие сайты в ЕС. Россия, вероятно, пойдёт по аналогичному пути — начиная с социально значимых отраслей и постепенно расширяя требования на весь коммерческий сектор.
Если вы при создании сайтов закладываете доступность с самого начала — это стоит на 15–20% дороже, чем «обычная» разработка. Но добавить доступность в уже работающий сайт — в 3–5 раз дороже.
Заключение
Доступность — это не благотворительность и не формальность. Это инженерное качество продукта, которое влияет на SEO, конверсию и охват аудитории. ГОСТ Р 52872 задаёт минимальную планку, WCAG 2.1 AA — разумный ориентир для любого серьёзного веб-проекта.
Начните с аудита. Исправьте очевидное. Встройте доступность в процесс. И помните: доступный сайт — это удобный сайт для всех.