Доступность сайта по WCAG: чек‑лист и как внедрить в продукт

Доступность сайта WCAG — это не «галочка», а базовый стандарт качества интерфейса, влияющий на конверсию, SEO и юридические риски. Если кратко: WCAG определяет, как сделать контент воспринимаемым, управляемым, понятным и надёжным для людей с разными ограничениями и в разных контекстах использования.

WCAG: что это и почему важно для бизнеса

WCAG (Web Content Accessibility Guidelines) — рекомендации W3C, описывающие принципы доступности: воспринимаемость, управляемость, понятность, надёжность (POUR). Три уровня соответствия:

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

Что получает продукт: больший охват аудитории (в т.ч. временные ограничения, мобильные сценарии), рост удовлетворённости, улучшение индексации (структурированность кода, семантика), снижение рисков претензий по недискриминации. Если вам нужен внешний взгляд и план работ, подключайте Аудит и оптимизация сайта.

A11y на сайте: ключевые принципы и частые ошибки

• Семантика важнее «дивов»: используйте заголовки h2–h6 по иерархии, списки, ссылки вместо span-кнопок.
• Клавиатурность по умолчанию: всё, что кликается, должно быть фокусируемым и управляемым Tab/Shift+Tab/Enter/Space/Esc/стрелками.
• Достаточный контраст: минимум 4.5:1 для обычного текста и 3:1 для крупного (AA). Не забывайте про состояние «наведено/фокус».
• Ясные статусы и ошибки: текстовые сообщения рядом с полями, корректные роли и арии для ассистивных технологий.
• Медиа с альтернативой: alt-тексты, субтитры, транскрипты, описательные названия.

Типичные провалы: «скрытые» по клику попапы без фокуса, SVG-иконки без названия, свайпы без альтернативы, placeholder вместо label, кастомные селекты без ролей.

Доступность интерфейса: практики для дизайнеров и разработчиков

• Дизайн: закладывайте контраст и размеры шрифтов с начала. Тестируйте прототипы клавиатурой и скринридером на ключевых сценариях.
• Верстка: семантический HTML и логичный порядок табуляции. Не ломайте natively focusable элементы. Управляйте видимым фокусом (не убирайте его).
• JS-логика: управляемый фокус при открытии/закрытии модалок, циклирование фокуса внутри диалогов, отключение прокрутки фона.
• Текст: ясные, короткие формулировки, понятные подписи кнопок. Ссылки — по смыслу («Скачать отчёт» вместо «Подробнее»).
• Контент: не полагайтесь на цвет как единственный сигнал. Добавляйте иконки/подписи/паттерны.

Если нужен системный подход к макетам и паттернам — подключайте Дизайн интерфейсов и UX/UI дизайн веб-приложений.

ARIA атрибуты: примеры без магии

ARIA дополняет семантику, а не заменяет её. Сначала — нативные теги, потом ARIA.

• Роли: dialog/alertdialog для модалок, navigation для меню, status/alert для сообщений.
• Связи: aria-labelledby и aria-describedby связывают заголовки и описания с элементами (например, инпут + текст ошибки).
• Состояния: aria-expanded для спойлеров/аккордеонов, aria-selected для вкладок, aria-pressed для переключателей.
• Живые регионы: aria-live="polite" для обновлений корзины, aria-live="assertive" для критических ошибок.
• Примеры:
• Кнопка «гамбургер»: role="button" не нужен, если это <button>. Если див — добавьте role="button", tabindex="0", обработку Enter/Space и aria-expanded.
• Модалка: role="dialog", aria-modal="true", фокус на заголовок или первый интерактив, возврат фокуса по закрытию.
• Аккордеон: кнопка с aria-controls и aria-expanded, содержимое с id и role="region" плюс aria-labelledby.

Ошибки: «aria-hidden="true"» на интерактивном элементе; дублирование ролей на нативных тегах; использование aria-label вместо видимого лейбла там, где он нужен визуально.

Контраст и навигация с клавиатуры: что проверить в первую очередь

• Контраст текста/иконок к фону: обычный текст ≥ 4.5:1, крупный (≥ 18pt или 14pt bold) ≥ 3:1; элементы интерфейса (границы, иконки) ≥ 3:1.
• Видимый фокус: заметный стиль для активного элемента. Контраст фокус-рамки к фону ≥ 3:1.
• Порядок табуляции: логичный и предсказуемый. Не прыгайте через скрытые блоки.
• Скипаемая навигация: ссылка «К контенту» перед хедером.
• Управление модалками: Esc закрывает, фокус зациклен, фон недоступен.
• Трап-фокусы: отсутствие «ловушек», где пользователь не может уйти клавиатурой.

Проверка доступности сайта: инструменты и подход

• Автотесты браузера: Lighthouse (вкладка Accessibility), axe DevTools, WAVE. Они ловят 30–50% проблем.
• Скринридеры: NVDA/JAWS (Windows), VoiceOver (macOS/iOS), TalkBack (Android). Тестируйте основные флоу — вход, поиск, корзина, оформление.
• Консистентность кода: ESLint плагин jsx-a11y (React), линтеры для HTML; Storybook + addon-a11y для компонентов.
• Контраст: Stark, Color Contrast Analyzer. Проверяйте состояния «hover/focus/disabled/pressed».
• Регрессии: интеграция axe в CI, визуальные снапшоты фокуса, юнит-тесты для ARIA-состояний.

Не забывайте ручное тестирование сценариев. Автоинструменты не поймут смысл текстов и порядок логики.

Доступность для слабовидящих: нюансы интерфейса и контента

• Текст и иконки: не завязывайтесь только на цвет. Добавляйте подписи, увеличивайте кегль, следите за межстрочными интервалами (минимум 1.5 для абзацев), длиной строки (45–90 знаков).
• Масштабирование: интерфейс должен корректно работать при 200% зуме без горизонтального скролла для одноколоночных макетов.
• Темная тема: проверяйте контраст в обоих режимах. Не инвертируйте «как есть» — валидируйте палитры отдельно.
• Ссылки: визуально отличимы от текста не только цветом (подчёркивание, толщина). Активные области — достаточно крупные.

Как сделать сайт доступным: процесс внедрения в продукт

1) Цели и baseline. Определите целевой уровень (обычно WCAG 2.1/2.2 AA). Проведите скриннинг: топ‑страницы и ключевые сценарии.

2) Аудит. Составьте карту проблем: семантика, контраст, клавиатура, формы, медиа, компоненты дизайна. Разбейте на эпики/тикеты с приоритетом «блокер/высокий/средний».

3) Дизайн‑система. Фиксируйте токены контраста, размеры шрифтов, фокус‑стили, состояния. Документируйте паттерны модалок, аккордеонов, табов.

4) Разработка. Внедрите линтеры, axe в CI, тестовые сценарии под скринридер. Рефакторьте компоненты по одному, начиная с навигации и форм.

5) Контент. Обновите тексты alt, заголовки, подписи к полям и сообщения об ошибках. Нормализуйте названия ссылок и кнопок.

6) Тестирование. Комбо: автоинструменты + ручные сценарии + пользовательские сессии с ассистивными технологиями.

7) Релиз и поддержка. Добавьте a11y‑контроль в DoD: «контраст ок», «клавиатура ок», «ARIA ок», «скринридер ок». Проводите периодические регрессы.

Если нужен сопровождаемый план и команда под внедрение — подключаемся через Аудит и оптимизация сайта.

Доступность сайта WCAG: чек‑лист для команды

• Страницы имеют корректную иерархию заголовков: один H2 уровня экрана, далее логичные H3–H5.
• Все изображения имеют alt: информативный — описывает смысл; декоративный — alt="" и aria-hidden="true" при необходимости.
• Ссылки и кнопки различимы, имеют понятный текст, цель ссылки понятна вне контекста.
• Форма: у каждого поля есть видимый label, есть aria-describedby для подсказок/ошибок. Ошибка озвучивается и выделяется.
• Клавиатура: доступ ко всем интерактивным элементам, предсказуемый порядок фокуса, видимый фокус‑стиль, нет «ловушек».
• Модалки/попапы: роль dialog или alertdialog, aria-modal="true", фокус внутри, Esc закрывает, фоновый контент недоступен.
• Навигация: ссылка «К основному контенту» в начале, логичная структура меню (role="navigation", списки для пунктов).
• Компоненты UI: табы с role="tablist/tab/tabpanels", аккордеон с aria-expanded/aria-controls, переключатели с aria-pressed.
• Контраст: текст ≥ 4.5:1 (обычный) и ≥ 3:1 (крупный), элементы интерфейса ≥ 3:1, состояния hover/focus проверены.
• Медиа: субтитры для видео, описательная дорожка/транскрипт при необходимости, управление с клавиатуры.
• Фокус‑управление: при открытии диалога фокус на заголовок или первый элемент; по закрытии — возврат к источнику.
• Респонсив: при 200% зуме контент не ломается, функциональность сохраняется без горизонтальной прокрутки (там, где это применимо).
• Язык страницы: lang установлен корректно; смена языков внутри текста помечена.
• Ошибки и успех: роли alert/status для динамических сообщений; aria-live для обновлений.
• Производительность: компоненты не тормозят скринридер; нет бесконечных анимаций без контроля пользователя.

Интеграция с UX и аналитикой: как измерять эффект

• Метрики поведения: глубина и конверсия на формах после исправления доступности; снижение отказов при зуме 200% и на клавиатуре.
• Технические метрики: Lighthouse Accessibility score, количество ошибок axe в CI, покрытие компонентных сценариев в Storybook.
• Обратная связь: быстрые Inline‑опросы по сценариям («нашли ли вы…»), сбор фидбэка от пользователей ассистивных технологий.

Параллельно полезно выстроить аналитику событий и A/B‑тестирование гипотез улучшений. Подробнее — в статье «A/B-тестирование: как проверять гипотезы на сайте» (https://lightson.agency/blog/stati/a-b-testirovanie-kak-proveryat-gipotezy-na-sajte).

Риски и правовые аспекты: о чём помнить

• Регуляторика и договоры: для части рынков и госконтрактов WCAG AA де‑факто является требованием. Проверьте условия тендеров/партнёрских соглашений.
• Бренд и PR: недоступные сервисы = риск негативной повестки; исправления задним числом дороже, чем плановое внедрение.
• Технический долг: чем дольше ждать, тем сложнее перевёрстывать паттерны. Внедряйте a11y в дизайн‑систему и CI раньше.

Вывод: доступность — это качество продукта, а не опция

WCAG помогает сделать интерфейс понятным, предсказуемым и удобным для всех, а не только для части аудитории. Начните с аудита, зафиксируйте стандарты в дизайн‑системе, автоматизируйте проверки и покрывайте ключевые сценарии ручными тестами. Нужна помощь с планом и реализацией — обращайтесь: Аудит и оптимизация сайта, Дизайн интерфейсов, UX/UI дизайн веб-приложений.