Аудит доступности сайта по WCAG 2.2: практический план проверки

Что важно понять до начала

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

WCAG 2.2 удобно использовать как систему критериев, а не как формальный чек-лист. Сначала команда выбирает уровень соответствия и критичные шаблоны, затем соединяет автоматические тесты с ручной проверкой и описывает дефекты через пользовательский эффект.

Типичные ошибки

Большинство сбоев возникает на границах ответственности: когда техническая проверка не связана с бизнес-сценарием, данными и действиями пользователя.

• Считать нулевой отчёт автоматического сканера доказательством полной доступности.
• Проверять только главную страницу, игнорируя формы и состояния после взаимодействия.
• Добавлять ARIA поверх неверной HTML-семантики без проверки поведения.
• Исправлять цвет по таблице, не оценивая понятность сценария целиком.

Что подготовить

До изменений зафиксируйте границы задачи, исходные данные, ответственных и критерий готовности. Это делает проверку воспроизводимой и защищает рабочие процессы.

• Составить перечень шаблонов и критичных путей: навигация, поиск, форма, регистрация, покупка и личный кабинет.
• Зафиксировать целевой уровень WCAG и браузеры со вспомогательными технологиями, которые входят в охват.
• Подготовить тестовые данные, состояния ошибок, модальные окна и динамический контент.
• Назначить владельцев исправлений между дизайном, контентом, frontend и QA.

Как закрепить результат

Разовая настройка быстро устаревает. Правила, тесты и владельцы нужны, чтобы качество сохранялось при следующих релизах и новых интеграциях.

• Автоматические правила запускаются в CI на основных шаблонах.
• Компоненты дизайн-системы имеют проверенные клавиатурные модели и состояния фокуса.
• Новые функции получают критерии доступности в постановке задачи и тест-кейсах.
• Ручная регрессия проходит перед крупными релизами и после смены базовых компонентов.

Пошаговый план

Работайте небольшими проверяемыми этапами: каждый шаг должен оставлять наблюдаемый результат, который можно проверить до выпуска и после него.

• Проверить семантическую структуру страницы: язык, заголовки, ориентиры и порядок чтения.
• Пройти каждый сценарий только клавиатурой, контролируя видимость и последовательность фокуса.
• Проверить доступные имена элементов, подписи полей и объявления ошибок скринридером.
• Оценить контраст, масштабирование текста, reflow и работу при увеличении до 200–400%.
• Проверить таймеры, анимацию, перетаскивание и альтернативы сложным жестам.
• Описать дефекты с критерием WCAG, шагами воспроизведения, влиянием и ожидаемым результатом.

Что измерять

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

• Доля критичных сценариев, полностью проходимых клавиатурой и скринридером.
• Количество блокирующих дефектов по шаблонам и компонентам.
• Покрытие автоматическими и ручными проверками в релизном процессе.
• Среднее время устранения дефекта доступности и доля повторных ошибок.

Результат работы

Доступность проверяют на реальных сценариях: автоматический отчёт помогает найти часть ошибок, но не заменяет ручное тестирование.

Готовое решение включает не только исправление или настройку, но и документированный способ повторной проверки. Так команда может безопасно развивать продукт без возврата прежней проблемы.