Обновлено: .

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

Сначала определите границы проверки

Запишите версию продукта, целевую версию и уровень WCAG, страницы, процессы, языки, состояния и окружения. «Проверили сайт» ничего не говорит о том, проверяли ли оплату после истечения сессии или только главную страницу. Для выборки берите разные шаблоны, сложные компоненты и критические пути.

Наш рабочий маршрут: найти услугу → открыть описание → заполнить заявку → исправить ошибку → отправить → получить подтверждение. Для магазина добавляются корзина, оплата и возврат; для личного кабинета — вход и восстановление доступа. Если один обязательный шаг недоступен, предыдущие успешные шаги не спасают результат.

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

Автоматизация: быстрый поиск части дефектов

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

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

Ручной проход без мыши

  1. Начните с загрузки страницы. Проверьте возможность перейти к основному содержимому и логичный порядок фокуса.
  2. Пройдите задачу клавиатурой. Проверяйте доступность всех действий и отсутствие случайных ловушек.
  3. Откройте и закройте каждый сложный компонент. Следите, куда переместился фокус.
  4. Создайте ошибку и исправьте её. Убедитесь, что значение не потерялось и есть понятное объяснение.
  5. Проверьте подтверждение: пользователь должен понимать, выполнено ли действие.

Отдельно проверьте указатель. Минимальная цель 24 × 24 CSS px в WCAG 2.5.8 AA имеет исключения, включая достаточные промежутки между целями. 44 × 44 — другой, усиленный критерий, а не универсальный минимум AA. Для касания можно проектировать более крупные цели, не выдавая проектное решение за буквальное требование.

Перетаскивание должно иметь альтернативу простым указателем, если не действует исключение. Например, элемент можно переместить кнопками «Выше» и «Ниже». Одна клавиатурная альтернатива не покрывает потребности человека, который пользуется указателем, но не может удерживать и тянуть.

Проверка восприятия и настроек

Проверьте текст при 200%, переразмещение при эквиваленте ширины 320 CSS px, пользовательские интервалы и принудительные цвета. Просмотрите все темы, а не только основную. Обратите внимание на обрезанные ошибки, исчезающие подписи и перекрытия фиксированными панелями.

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

Для движения предусмотрите уменьшение необязательной анимации с учётом prefers-reduced-motion. Отдельно проверяйте автодвижущийся контент, возможность паузы и вспышки: один медиазапрос не подтверждает выполнение всех связанных требований. Простые инструкции, отсутствие ненужного давления временем и сохранение введённого после ошибки также влияют на возможность завершить задачу.

Скринридер и участие пользователей

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

Приглашайте людей с различными потребностями к проверке реальных задач и оплачивайте эту работу. Не сводите исследование к вопросу «вам нравится сайт?». Смотрите, удаётся ли выполнить действие, где требуется помощь и насколько понятно восстановление после ошибки. Участники не заменяют проверку критериев, а проверка критериев — участников.

Как выглядит полезный дефект

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

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

Как сделать результат устойчивым

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

В итоговом отчёте разделяйте найденные проблемы, проверенную область, ограничения проверки и оставшиеся риски. Формулировка «в проверенной выборке таких-то состояний не найдено таких-то нарушений» информативнее, чем ничем не ограниченное «сайт на 100% доступен».

Чтобы включить эти проверки в разработку с ИИ-помощником, можно установить скилл Accessible UI из GitHub. В первой статье есть инструкция по установке в Codex и Claude Code.

По результатам исследования мы создали открытые скиллы для Codex и Claude Code, которые помогают анализировать и улучшать сайты и приложения. Accessible UI направляет агента при проверке семантики, клавиатурного управления, фокуса, форм и контраста; Adaptive Interfaces помогает адаптировать интерфейс к размерам окна, масштабу текста, клавиатуре и складным устройствам. Агент изучает текущий проект, предлагает обоснованные улучшения и проверяет согласованные изменения. Скиллы не заменяют проверку с пользователями и вспомогательными технологиями.

Источники и статус стандартов проверены 5 ноября 2026 года.