Чек‑лист доступности сайта по WCAG: как проверить и исправить основные проблемы

Кому подходит этот чек‑лист и что ожидать

Этот чек‑лист рассчитан на владельцев сайтов, разработчиков и продуктовых менеджеров, которые хотят привести проект к базовым требованиям WCAG. Материал покрывает те шаги, которые можно выполнить собственными силами или с минимальным привлечением эксперта: подготовка, простые правки HTML/CSS/JS и сценарии ручного тестирования.

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

Чек‑лист ориентирован на практические действия: какие файлы собрать перед проверкой, какие автоматизированные инструменты использовать, какие правки внести в код и как организовать финальное ручное тестирование. Мы избегаем общей теории и даём конкретные рекомендации для исправления типичных проблем.

Подготовка: что собрать перед началом проверки

Перед проверкой соберите базовую информацию о проекте: адреса тестовых страниц, типовые сценарии пользователей (регистрация, поиск, оформление заказа), список интерактивных компонентов и используемые библиотеки UI. Это ускорит анализ и позволит концентрироваться на ключевых путях пользователя.

Экспортируйте актуальные версии HTML/CSS/JS или дайте доступ к тестовой среде, где можно безопасно вносить изменения. Если сайт использует серверную платформу (.NET, WordPress, 1С‑Битрикс), подготовьте инструкцию для разработчиков, где указываете, какие файлы и шаблоны отвечают за проблемные участки.

Подготовьте список устройств и браузеров для тестирования: настольные браузеры с расширениями для тестирования доступности, мобильные устройства и экранные читалки (например NVDA, VoiceOver). Если нет возможности развернуть весь набор инструментов, отметьте приоритетные комбинации для вашего аудитории.

• Список ключовых страниц и сценариев
• Доступ к тестовой среде или копия шаблонов
• Инструменты: валидатор, расширения и экранные читалки
• Список библиотек и фреймворков, влияющих на UI

Шаг 1. Проверка структуры и семантики HTML

Правильная семантика — база доступности. Убедитесь, что заголовки оформлены при помощи тэгов h1–h6 по иерархии, а не визуально через CSS. Проверяйте наличие основного landmark‑контейнера (header, nav, main, footer) для удобного перехода в экранных читалках.

Проверьте, что все интерактивные элементы имеют корректную роль и метки: кнопки — тэг button, ссылки — a с href, элементы управления формами имеют связанный label. Избегайте использования non‑semantic тегов для интерактивности без соответствующих ARIA‑атрибутов.

Используйте автоматические валидаторы HTML и линтеры, но дополнительно выполняйте ручные проверки: просмотрите DOM в браузере, отключите CSS и проверьте, остаётся ли контент логичным. Исправления обычно включают добавление правильных тэгов, корректных атрибутов alt и упорядочение заголовков.

• Проверить иерархию заголовков
• Добавить landmark‑элементы
• Заменить div/span на semantic tags где нужно
• Убедиться в наличии атрибутов aria‑role, aria‑label при необходимости

Шаг 2. Клавиатурная навигация и управление фокусом

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

Убедитесь, что фокус видим: outline не должен быть полностью убран в CSS. Для модальных окон и динамического содержимого обеспечьте перенос фокуса внутрь компонента и возврат в исходное место после закрытия. Это важно для навигации с клавиатуры и для пользователей экранных читалок.

Избегайте управления фокусом через JavaScript без надобности; когда управление требуется, используйте стандартизированные паттерны: focus trapping в модалках, aria‑hidden для скрываемых частей, корректные aria‑expanded и aria‑controls для раскрывающихся списков.

Шаг 3. Текст, контраст и масштабирование

Проверьте читаемость контента: размер шрифта, межстрочный интервал и адаптивность при увеличении масштаба. WCAG требует, чтобы текст можно было увеличить без потери функциональности; протестируйте страницы при 125–200% масштабировании и на узких экранах.

Контраст текста и фона — частая проблема. Используйте автоматические проверки контраста для основных текстовых элементов и UI‑элементов. При низком контрасте корректируйте цвета или добавляйте дополнительные визуальные индикаторы, но избегайте цветовой индикации как единственного способа передачи информации.

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

• Тестирование масштабирования до 200%
• Проверка контраста для текста и UI
• Проверка читаемости мелких элементов

Шаг 4. Мультимедиа: субтитры, транскрипты и управление проигрывателем

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

Проверяйте управление проигрывателем с клавиатуры и наличие меток у кнопок воспроизведения, паузы, громкости и полноэкранного режима. Автоматическое воспроизведение медиа, которое мешает пользователю, следует отключать или делать управляемым — предоставьте явную кнопку паузы и предупреждение о звуке.

Для аудио без визуального контента используйте подробную транскрипцию. В интерфейсах с визуальными подсказками добавляйте текстовые альтернативы. Там, где важна последовательность визуальных событий, предусмотрите аудио‑описание.

Шаг 5. Формы: метки, подсказки и обработка ошибок

Формы — источник множества проблем: без меток, с некорректной валидацией и непонятными сообщениями об ошибке. Убедитесь, что у каждого поля есть явный label, а подсказки связаны с полем через aria-describedby или title при необходимости.

Сообщения об ошибках должны быть понятными, связаны с полем и появляться в фокусируемой области. Реализуйте inline‑валидацию и общие сообщения о состоянии формы. При отправке формы с ошибками фокус должен перемещаться на первое проблемное поле и предоставлять пользователю доступные инструкции для исправления.

Для сложных полей (автозаполнение, маски ввода) сохраняйте совместимость с экранными читалками и клавиатурой. Там, где нужен ввода по образцу (дата, телефон), предоставьте подсказку и возможность вводить данные в любом удобном формате с последующей нормализацией на сервере.

Шаг 6. ARIA и динамический контент: применять аккуратно

ARIA‑атрибуты полезны, но их неправильное использование ухудшает доступность. Используйте ARIA только когда семантических элементов недостаточно. Не переопределяйте нативные элементы ролями, если поведение уже реализовано браузером.

При динамических изменениях контента помечайте обновления через aria‑live для уведомлений и следите за корректными ролями и свойствами. Для видимых/скрытых блоков используйте aria‑hidden, но не забывайте обновлять атрибут при переключениях, чтобы читалки видели актуальное состояние.

Тестируйте ARIA‑решения в нескольких читалках и браузерах — поведение может отличаться. Если вы добавляете кастомные элементы управления, реализуйте полную поддержку клавиатуры, роли, состояния и свойства, чтобы задать ожидаемое поведение для вспомогательных технологий.

Тестирование: сочетание автоматических и ручных проверок

Автоматические инструменты (валидаторы, расширения) помогают быстро найти очевидные ошибки: отсутствие alt, проблемы с контрастом, неверные ARIA. Но автоматические проверки покрывают лишь часть критериев WCAG. Поэтому сочетайте их с ручными тестами и тестами с участием людей с ограничениями.

Простой тестовый набор: 1) пройти ключевые сценарии с клавиатурой; 2) использовать экранную читалку для проверки логики и меток; 3) проверить масштабирование и контраст; 4) пройти формы, модалки и мультимедиа. Для каждого найденного бага фиксируйте шаги воспроизведения и рекомендуемое исправление.

Включите в процесс smoke‑тесты после каждой релизной сборки: короткий набор автоматических и ручных проверок, которые гарантируют, что критичные элементы доступны. Для более глубокой оценки периодически проводите расширенный аудит с привлечением тестировщиков с особыми потребностями.

• Автоматические инструменты: валидатор, проверка контраста, линтер ARIA
• Ручные проверки: клавиатура, экранные читалки, масштабирование
• Пользовательские тесты: фидбэк от реальных пользователей

Контрольные точки перед запуском (чек‑лист)

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

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

Если в процессе обнаружены серьёзные нарушения (недоступные платежные формы, потерянные заголовки, отсутствие навигации по клавиатуре), отложите релиз до исправления или подготовьте план быстрого исправления и отката.

• Главная страница: заголовок h1 и landmark‑блок main
• Все формы: видимые label и понятные сообщения об ошибке
• Модалки: перенос фокуса внутрь и возвращение после закрытия
• Клавиатурная навигация: все интерактивные элементы доступны
• Контраст: основной текст и кнопки соответствуют требованиям
• Мультимедиа: субтитры/транскрипты для видео и аудио

Частые вопросы