Аудит доступности интерфейсов показывает, может ли пользователь выполнить задачу с клавиатурой, скринридером, увеличенным текстом или другими способами взаимодействия. Проверяем не только внешний вид экрана, но и рабочий путь: найти информацию, заполнить форму, исправить ошибку и получить результат. Границы, платформы и применимые критерии согласуем до начала проверки.
Объём проверки и сценарии
Выбираем репрезентативные страницы и компоненты: навигацию, поиск, форму, карточку, таблицу, диалог и оформление заказа, если оно есть. Фиксируем состояния после ошибки, загрузки и отправки. Для веба определяем браузеры и вспомогательные технологии; для мобильного приложения — платформы и поддерживаемые версии.
Сопоставляем проверку с выбранной версией и уровнем WCAG там, где это применимо. Проверка нескольких экранов не позволяет объявить соответствующим весь продукт. В отчёте явно указываем выборку, исключения и обнаруженные ограничения.
Клавиатура, фокус и навигация
Проходим интерфейс без мыши: порядок Tab, активацию кнопок, раскрытие меню, закрытие диалога и возвращение фокуса. Ищем ловушки, невидимый фокус и элементы, которые доступны только при наведении. Проверяем, не перекрывают ли закреплённые панели активный элемент.
Для таблиц, вкладок и составных элементов важны согласованные правила управления. Наличие обработчика Enter не делает любой div полноценной кнопкой: проверяем семантику, имя и состояние элемента. Приоритет отдаём дефектам, которые полностью останавливают сценарий.
Скринридеры и структура
Проверяем заголовки, области страницы, доступные имена и связь подписей с полями. Для изображений оцениваем назначение альтернативного текста; декоративная графика не должна создавать лишний шум. Изменения после запроса и ошибки должны быть доступны без визуального поиска по экрану.
Используем подходящие связки, например NVDA с браузером в Windows или VoiceOver на устройствах Apple, в согласованном объёме. Успех на одной связке не объявляем доказательством работы на всех устройствах. Автоматическая проверка дерева доступности дополняется прохождением задачи человеком.
Формы, контраст и масштабирование
Проверяем обязательность полей, инструкции, сообщения ошибок и восстановление введённых данных. Цвет не должен быть единственным признаком ошибки. Назначение кнопки и формат ввода должны быть понятны до отправки.
Измеряем контраст применимых элементов, смотрим увеличение текста, переносы и доступность контента при узкой ширине. Не ограничиваемся одной палитрой в макете: реальные состояния disabled, hover, focus и фон изображения могут менять результат. Для видео и документов фиксируем отдельные ограничения содержания.
Отчёт и повторная проверка
Каждое замечание содержит шаги, фактический результат, ожидаемое поведение, связанный критерий и приоритет. Для команды разработки добавляем рекомендацию по исправлению, не подменяя её абстрактным требованием «сделать доступнее». Инструменты вроде axe или Lighthouse помогают найти часть проблем, но не покрывают всё взаимодействие.
Результат аудита доступности — перечень проверенных сценариев, дефекты и порядок исправления. После доработок проводим повторный проход, включая соседние состояния. Исправление кода, обновление дизайн-системы и проверка всего продукта могут быть отдельными этапами.
Исправления в повторяющихся компонентах
Если проблема встречается во всех формах и диалогах, полезно закрепить исправленное поведение в дизайн-системе, а не исправлять каждый экран независимо.
Дизайн-система интерфейсовВопросы перед началом работ
Достаточно автоматического сканера?
Нет. Он обнаруживает часть формальных проблем, но не может полностью оценить понятность, порядок действий и возможность завершить задачу. Нужны ручная проверка и работа со вспомогательными технологиями.
Аудит гарантирует соответствие всего сайта WCAG?
Только в пределах явно определённой методики и области оценки можно делать обоснованный вывод. Проверка выбранных страниц не означает автоматическую сертификацию всего сайта. Ограничения указываются в отчёте.
Можно проверить только дизайн в Figma?
Можно оценить часть визуальных решений, контраст и предполагаемые состояния. Клавиатуру, семантику и фактическую работу скринридера нужно проверять в реализации. Эти виды проверки не заменяют друг друга.
Какие ошибки исправлять первыми?
Сначала блокирующие выполнение основной задачи: недоступная кнопка, ловушка фокуса, непонятное обязательное поле. Затем системные дефекты повторяющихся компонентов и остальные замечания по согласованным приоритетам.
Проверяете мобильные приложения?
Да, в отдельно согласованном объёме платформ и сценариев. Используем применимые технологии доступности iOS или Android и не переносим веб-проверку механически на нативный интерфейс.