Несоблюдение ГОСТ Р 52872-2019 приводит к предписаниям прокуратуры и штрафам, а техническая реализация версии для слабовидящих часто превращается в «заглушку», которая не проходит аудит. Реальная доступность — это не кнопка с увеличением шрифта, а соответствие стандартам WCAG 2.1, где критический порог контрастности текста к фону должен составлять не менее 4.5:1.
Технические требования ГОСТ Р 52872
Основной стандарт требует, чтобы интерфейс был воспринимаемым и управляемым без мыши. Ключевой параметр — поддержка экранных дикторов (screen readers) через правильную разметку ARIA и семантические теги HTML5. Если заголовок H1 реализован через
Практический кейс: при аудите муниципального портала было выявлено 40+ форм ввода без тегов <label>. В итоге время заполнения заявки пользователем с ридером увеличилось с 2 минут до 12 минут, что является грубым нарушением требований к доступности. Мой вывод: семантика важнее визуального дизайна; любой «красивый» элемент, ломающий иерархию заголовков, должен быть удален.
Цветовые схемы и контрастность интерфейса
Для версии для слабовидящих обязательны три режима: черный текст на белом фоне, белый на черном и желтый на синем. Важно, чтобы коэффициент контрастности соответствовал уровню AA (4.5:1 для обычного текста и 3:1 для крупного). Использование пастельных тонов или градиентов в функциональных зонах недопустимо.
Ошибкой является использование только цвета для передачи смысла (например, красная рамка у поля с ошибкой без текстового пояснения). Около 8% мужчин страдают протанопией, для которых красный и зеленый неразличимы. Экспертная оценка: внедряйте дублирование цветовых индикаторов текстовыми метками или иконками, иначе сайт не пройдет проверку на инклюзивность.
Пользователь должен иметь возможность перемещаться по всем активным элементам с помощью клавиши Tab. Обязательным является наличие «ссылки-прыжка» (skip link) в самом начале страницы, позволяющей перепрыгнуть меню и сразу перейти к основному контенту. Это сокращает путь до сути страницы с 20-30 нажатий Tab до одного.
Пример из практики: на сайте учреждения меню реализовано через JS-скрипты, которые не фокусируются при нажатии Tab. Результат — пользователь с моторными нарушениями физически не может попасть в раздел документов. Мой вердикт: любой интерактивный элемент должен иметь видимый фокус (outline), который нельзя скрывать через CSS свойство outline: none.
Инструменты проверки и стоимость внедрения
Для автоматизированного аудита используйте расширение Axe DevTools или Lighthouse (раздел Accessibility). Однако автоматика ловит лишь 30-40% ошибок; остальные 60% (логика навигации, осмысленность alt-текстов) проверяются только вручную. Стоимость разработки полноценного модуля доступности для среднего сайта учреждения варьируется от 30 000 до 80 000 рублей в зависимости от объема контента.
Частая ошибка — покупка дешевых JS-плагинов «для слабовидящих» за 5 000 рублей, которые просто меняют CSS-стили. Это не делает сайт доступным по ГОСТу. Правильный подход — интеграция требований в основной код, что на 20% увеличивает время разработки фронтенда, но полностью снимает юридические риски.
Оптимизация документов и реестров
Доступность сайта бесполезна, если документы в разделе «Сведения об организации» загружены в виде сканов (картинок) внутри PDF. Такие файлы не читаются скринридерами. Необходимо использовать текстовый PDF с размеченными тегами или дублировать информацию в HTML-таблицах.
Кейс: замена 150 тяжелых PDF-сканов на оптимизированные текстовые версии сократила вес страницы в 4 раза и позволила пользователям с нарушением зрения искать информацию через Ctrl+F. Рекомендую проводить оптимизацию скорости загрузки тяжелых реестров и документов параллельно с настройкой доступности, так как медленный отклик сайта критичен для людей с когнитивными нарушениями.
Вывод
Для государственного сайта доступность — это не опция, а юридическая обязанность. Начинать нужно с внедрения семантической верстки и проверки контрастности по WCAG 2.1. Категорически избегайте дешевых «переключателей версий», которые не меняют структуру DOM-дерева. Оптимальный путь: разработка одного адаптивного интерфейса, который корректно работает с экранными дикторами, вместо создания отдельной «черно-белой» страницы, которая обычно остается заброшенной и неактуальной.