Кого на самом деле касается доступность сайтов
Когда мы слышим «доступность для людей с инвалидностью», в голове обычно возникает образ незрячего человека. Но реальность гораздо шире.
По данным ВОЗ, более миллиарда людей в мире живут с той или иной формой инвалидности. Это примерно 15% населения планеты. Но даже если отбросить статистику — подумайте о тех ситуациях, когда вы сами оказывались в «ограниченных условиях». Сломанная рука и невозможность пользоваться мышкой. Яркое солнце, из-за которого не видно экран. Шумное метро, где не разобрать звук в видео без субтитров. Пожилой родственник, который не может разобрать мелкий серый текст на светлом фоне.
Доступный сайт помогает не только людям с постоянной инвалидностью, но и всем нам в определённых жизненных ситуациях. Именно поэтому правильнее говорить не «версия для инвалидов», а «инклюзивный дизайн» — подход, при котором сайт удобен для максимально широкого круга пользователей.
Что такое WCAG и зачем мне в это вникать
WCAG (Web Content Accessibility Guidelines) — это международный стандарт доступности веб-контента, разработанный рабочей группой W3C. На март 2026 года актуальная версия — WCAG 2.2, которая в октябре 2025 года получила статус международного стандарта ISO/IEC 40500:2025.
Зачем разработчику знать про WCAG? Потому что именно этот документ лежит в основе законодательства о цифровой доступности во многих странах мира — от ADA в США до Европейского акта о доступности (European Accessibility Act), который стал обязательным для всех стран ЕС с июня 2025 года.
Четыре принципа, на которых всё держится
WCAG строится на четырёх принципах, и я запоминал их через простую мысленную проверку. Каждый раз, когда сдаю проект, прогоняю его через эти вопросы:
Воспринимаемость. Может ли пользователь в принципе получить информацию? Есть ли alt-тексты у изображений? Доступны ли субтитры к видео? Достаточен ли контраст текста?
Управляемость. Можно ли пользоваться сайтом без мышки — только с клавиатуры? Видно ли, какой элемент сейчас в фокусе? Достаточно ли крупные области нажатия на мобильных устройствах?
Понятность. Логична ли навигация? Понятны ли формы и сообщения об ошибках? Не запутает ли пользователя неожиданное поведение интерфейса?
Надёжность. Корректно ли работает сайт с разными вспомогательными технологиями — скринридерами, экранными лупами, альтернативными устройствами ввода?
Уровни соответствия: A, AA, AAA
WCAG определяет три уровня соответствия. Уровень A — это минимум, без которого сайт попросту непригоден для многих пользователей. Уровень AA — стандартный целевой уровень, на который ориентируется большинство законодательных актов. Уровень AAA — расширенные требования, которые актуальны для государственных и медицинских сервисов.
На практике я всегда рекомендую клиентам целиться в уровень AA. Это тот баланс, при котором сайт реально становится доступнее, но при этом не требует космических бюджетов.
Что нового в WCAG 2.2 и почему это важно именно сейчас
WCAG 2.2 добавил девять новых критериев успеха к предыдущей версии 2.1. Они обратно совместимы: если ваш сайт соответствует 2.2, он автоматически соответствует и 2.1, и 2.0.
Вот что появилось в 2.2 и на что я обращаю внимание в своих проектах:
Видимость фокуса (Focus Not Obscured). Когда пользователь перемещается по сайту с клавиатуры, элемент в фокусе не должен полностью перекрываться «липкими» шапками, футерами или модальными окнами. Звучит очевидно, но я видел десятки сайтов, где фиксированный хедер полностью закрывает текущий активный элемент.
Минимальный размер области нажатия (Target Size). Интерактивные элементы должны иметь минимальную область нажатия 24×24 CSS-пикселя на уровне AA. Это критично для мобильных устройств и для людей с нарушениями моторики.
Доступная аутентификация. Процесс авторизации не должен требовать когнитивных тестов — вроде запоминания пароля без возможности вставить его из менеджера паролей или решения сложных CAPTCHA. Альтернативные методы входа (биометрия, ссылка на email) должны быть доступны.
Согласованная помощь (Consistent Help). Если на сайте есть механизмы помощи — чат, телефон, FAQ — они должны находиться в одном и том же месте на всех страницах.
Альтернативы перетаскиванию (Dragging Movements). Любое действие, требующее drag-and-drop, должно иметь альтернативный способ выполнения — например, через кнопки «вверх» и «вниз» для сортировки.
Российская специфика: ГОСТ и свежие законодательные изменения
В России тема цифровой доступности долго оставалась на периферии, но в 2024–2026 годах произошёл заметный сдвиг.
Основной действующий стандарт — ГОСТ Р 52872-2019 «Интернет-ресурсы. Требования доступности для инвалидов по зрению». Он описывает технические параметры, которым должны соответствовать сайты: от разметки заголовков и альтернативных текстов до совместимости с программами экранного доступа.
Ещё один важный документ — ГОСТ Р 70176-2022, который устанавливает требования к доступности PDF-файлов для людей с инвалидностью.
Но самое значимое событие случилось совсем недавно. В феврале 2026 года Правительство РФ приняло Постановление № 102, которое устанавливает обязательные требования к доступности сайтов государственных органов и подведомственных организаций для инвалидов по зрению. Эти требования вступают в силу с 1 марта 2026 года — то есть прямо сейчас.
Что это означает на практике? Государственные сайты обязаны быть совместимы со скринридерами, документы должны быть размечены по ГОСТ Р 70176-2022, а движущийся контент должен иметь элементы управления (пауза, остановка). Также на сайтах должна быть возможность отправить обращение, если какие-то элементы недоступны.
Пока эти требования напрямую касаются госсектора, но тренд очевиден — коммерческие сайты тоже придут к этому. В Европе аналогичный путь от государственных сайтов к коммерческим занял около пяти лет.
Мой чек-лист accessibility-аудита: что проверяю на каждом проекте
За время работы я выработал свой порядок проверки. Делюсь — возможно, кому-то пригодится.
Первый шаг: автоматическая проверка
Начинаю с инструментов автоматического сканирования. Мои рабочие инструменты:
— axe DevTools — расширение для Chrome, которое находит распространённые проблемы прямо в DevTools. Бесплатное и быстрое.
— Lighthouse — встроен в Chrome, раздел Accessibility. Даёт оценку и список конкретных проблем с ссылками на документацию.
— WAVE — онлайн-инструмент и расширение от WebAIM. Визуализирует проблемы прямо на странице — удобно показывать клиенту.
Но тут важный момент: автоматические инструменты находят только 30–40% реальных проблем. Они хорошо ловят отсутствующие alt-тексты и недостаточный контраст, но не способны оценить, насколько логична навигация или понятен ли текст альтернативного описания.
Второй шаг: ручное тестирование с клавиатурой
Отключаю мышь и пробую пройти основные сценарии сайта только с клавиатуры. Tab для перемещения вперёд, Shift+Tab — назад, Enter для активации, Escape для закрытия.
На что обращаю внимание:
— Виден ли индикатор фокуса? Если outline убран «для красоты» через `outline: none` без замены — это критическая ошибка.
— Логичен ли порядок табуляции? Фокус не должен прыгать хаотично по странице.
— Можно ли закрыть модальное окно? И не «убегает» ли фокус за пределы модалки, когда она открыта?
— Доступны ли выпадающие меню, слайдеры, аккордеоны?
Третий шаг: проверка со скринридером
Включаю VoiceOver (macOS) или NVDA (Windows) и прохожу сайт заново. Это самый показательный этап — здесь вскрываются проблемы, которые невозможно увидеть глазами.
Типичные находки на этом этапе:
— Кнопки без текстовых меток. Скринридер читает «кнопка» — и всё. Какая кнопка? Что она делает? Непонятно.
— Изображения без alt-текста или с бессмысленным alt вроде «image1.jpg».
— Формы без привязки label к input. Скринридер не может сообщить, что именно нужно ввести в поле.
— Динамический контент, который обновляется без уведомления. Пользователь добавил товар в корзину, но скринридер молчит — потому что нет aria-live региона.
Четвёртый шаг: проверка контраста и визуальной доступности
Использую инструменты для проверки цветового контраста:
— Colour Contrast Analyser — десктопное приложение с пипеткой.
— DevTools в Chrome — во вкладке Elements при наведении на цвет текста показывается коэффициент контраста.
Минимальные требования WCAG AA: соотношение контраста 4.5:1 для обычного текста и 3:1 для крупного текста (от 18pt или 14pt жирного).
Также проверяю, как сайт выглядит при масштабировании до 200% — текст не должен обрезаться и наползать на другие элементы.
Самые частые ошибки, которые я встречаю
За последние пару лет я провёл десятки аудитов и вижу одни и те же проблемы снова и снова. По моим наблюдениям, следующие шесть ошибок покрывают подавляющее большинство нарушений доступности.
Низкий контраст текста. Серый текст на светло-сером фоне — бич современного веб-дизайна. Дизайнеры любят приглушённые цвета, но для людей со сниженным зрением такой текст просто нечитаем.
Отсутствие alt-текстов у изображений. Причём проблема не только в пустых alt, но и в бесполезных описаниях. «Фото» — это не alt-текст. «Команда разработчиков обсуждает макет за рабочим столом» — это alt-текст.
Формы без меток. Placeholder — это не замена label. Когда пользователь начинает вводить текст, placeholder исчезает, и он уже не помнит, что нужно было вводить. А скринридер вообще может не прочитать placeholder.
Неработающая клавиатурная навигация. Кастомные компоненты — модалки, дропдауны, табы — часто доступны только мышью. Если вы пишете интерактивный элемент на `<div>`, не забудьте про `tabindex`, `role` и обработку клавиатурных событий. Или просто используйте нативные HTML-элементы, которые уже имеют встроенную доступность.
Автовоспроизведение видео и анимации. Движущийся контент без возможности остановки — проблема не только для людей с когнитивными нарушениями, но и для пользователей с вестибулярными расстройствами. Правило простое: `prefers-reduced-motion` в CSS — ваш друг.
Отсутствие семантической разметки. Когда вся страница — это каша из `<div>`, скринридер не может определить структуру. Используйте `<nav>`, `<main>`, `<header>`, `<footer>`, `<article>`, `<section>` — они существуют не для SEO, а для людей.
Практические советы: как внедрять доступность в рабочий процесс
Доступность не должна быть чем-то, что прикручивается в конце проекта. Вот как я интегрирую её в свой процесс:
На этапе дизайна — проверяю цветовую палитру на контраст, закладываю достаточные размеры кликабельных областей, продумываю порядок чтения контента.
При вёрстке — использую семантический HTML как основу. Пишу разметку так, чтобы она имела смысл без стилей. Добавляю ARIA-атрибуты только там, где нативного HTML недостаточно (а не вместо него).
При разработке компонентов — каждый интерактивный компонент тестирую на клавиатурную доступность до того, как считаю его готовым. Это занимает 2–3 минуты, но экономит часы исправлений.
Перед сдачей — прогоняю полный аудит: автоматика + клавиатура + скринридер + контраст + масштабирование.
В документации — оставляю заметки для контент-менеджеров: какие alt-тексты писать, как оформлять заголовки, почему важна иерархия `h1`–`h6`.
Несколько слов о «версии для слабовидящих»
Отдельно хочу сказать про те самые кнопки «Версия для слабовидящих», которые до сих пор ставят на российские сайты. Чаще всего это отдельная упрощённая версия сайта с увеличенным шрифтом и высококонтрастной палитрой.
Проблемы этого подхода:
— Отдельная версия — это отдельная поддержка. Обновили основной сайт — надо обновить и «версию для слабовидящих». На практике она быстро устаревает.
— Чаще всего «версия для слабовидящих» не решает проблем незрячих пользователей, которые пользуются скринридерами. Увеличенный шрифт бесполезен, когда человек не видит экран.
— Это сегрегация: «для вас — отдельный вход». Инклюзивный подход предполагает, что один и тот же сайт работает для всех.
Правильный путь — делать основную версию сайта доступной. Контрастная тема, масштабируемый текст, семантическая разметка — всё это можно реализовать в основном дизайне, без костылей.
Доступность и бизнес: зачем это коммерческим сайтам
Часто слышу от клиентов: «У нас не государственный сайт, нам это не нужно». Вот несколько аргументов, которые обычно работают.
Аудитория. Люди с инвалидностью — это не маленькая группа. Плюс пожилые пользователи, люди в ситуативных ограничениях (яркий свет, сломанная рука, шумное место). Доступный сайт работает лучше для всех этих категорий.
SEO. Alt-тексты, семантическая разметка, логичная структура заголовков, текстовые расшифровки для видео — всё это одновременно улучшает индексацию поисковиками. Google и Яндекс лучше понимают структурированный, семантически верный контент.
Юридические риски. В Европе и США количество судебных исков за недоступность сайтов растёт из года в год. Россия пока мягче в этом отношении, но вектор задан — новые постановления это подтверждают.
Качество кода. Доступный сайт — почти всегда более чистый, структурированный и поддерживаемый. Работа над accessibility дисциплинирует и поднимает общий уровень разработки.
Полезные ресурсы, которые я использую
Для тех, кто хочет углубиться в тему, собрал свой список ресурсов, которые реально помогают в работе:
— Дока (doka.guide/a11y) — отличная русскоязычная документация по доступности. Написана понятным языком с примерами кода.
— WebAIM (webaim.org) — англоязычный ресурс с инструментами, статьями и ежегодным исследованием миллиона самых популярных сайтов на доступность.
— a11y-dialog — лёгкая библиотека для создания доступных модальных окон. Рекомендую вместо самописных решений.
— ГОСТ Р 52872-2019 — российский национальный стандарт, который полезно изучить, если работаете с государственными заказчиками.
— axe-core — движок для автоматического тестирования доступности, который можно интегрировать в CI/CD.
Что бы я сказал себе два года назад
Если бы я мог вернуться в прошлое, я бы сказал: не откладывай accessibility на потом, не считай это отдельной задачей. Это часть качественной разработки — как адаптивная вёрстка, как оптимизация производительности, как защита от XSS. Когда доступность встроена в процесс с самого начала, она не добавляет сложности. Она просто становится частью того, как ты пишешь код.
А ещё я бы попросил себя попробовать посидеть хотя бы час с закрытыми глазами, пользуясь компьютером только через скринридер. Это меняет перспективу навсегда.