Выберите реальные задачи посетителя
Проверку доступности удобно начинать с действия: найти услугу, прочитать условия, заполнить заявку или скачать документ. Хороший макет сам по себе не показывает, сможет ли человек пройти этот путь с клавиатурой, увеличенным текстом или программой чтения с экрана. Приёмка должна включать рабочую страницу и её состояния.
Для первой проверки составьте небольшую карту маршрута: откуда человек приходит, какую информацию ищет, где принимает решение и чем заканчивается действие. Добавьте пустой результат поиска, ошибку формы и открытое меню. Обычно именно такие состояния остаются за пределами презентации дизайна.
Назначьте каждому маршруту ответственного и сохраните замечания со ссылкой на страницу. Тогда проверка становится задачей команды, а не разовым обсуждением вкуса.
Пройдите маршрут с клавиатуры
Отложите мышь и начните с клавиши Tab. Проверьте, что переходы между интерактивными элементами последовательны, текущий элемент заметен, а действие можно выполнить с клавиатуры. Откройте меню и модальное окно, затем вернитесь к основному содержанию. На каждом шаге должно быть понятно, где вы находитесь.
Зафиксируйте места, в которых фокус исчезает за закреплённой шапкой, попадает на невидимые кнопки или не позволяет выйти из открытого блока. Рамка фокуса — часть интерфейса, её нельзя оценивать только по тому, нравится ли её цвет. Практический порядок такого первичного обхода описан в W3C WAI Easy Checks.
Условный пример: посетитель открыл форму записи, выбрал дату и хочет отменить действие. Добавьте этот маршрут в приёмку вместе с обычной успешной отправкой.
Проверьте подписи и ошибки формы
Поле «Телефон» должно оставаться понятным после начала ввода. Подсказка внутри пустого поля исчезает, поэтому она не заменяет постоянную подпись. В руководстве W3C по подписям полей также описана программная связь подписи с элементом управления: благодаря ей вспомогательные технологии получают его название.
Заполните форму с намеренной ошибкой. Прочитайте сообщение: объясняет ли оно, какое значение нужно исправить? Сохранены ли остальные данные? Можно ли добраться до проблемного поля? Согласуйте текст ошибки с тем же вниманием, что и текст основной кнопки.
Для условной формы заявки полезно заранее записать три ситуации: пустой обязательный контакт, неверный формат и ошибка отправки. Для каждой нужен понятный результат, чтобы посетитель не повторял действие вслепую.
Разберите изображения по назначению
Для содержательной картинки альтернативное описание передаёт важную информацию. Для изображения, работающего как кнопка или ссылка, оно должно объяснять действие. Декоративная иллюстрация может иметь пустой alt, если её смысл уже не нужен для понимания страницы. Эти различия разобраны в руководстве W3C по изображениям.
При подготовке материалов пройдите каждую обложку, схему и фотографию. Вместо имени файла опишите то, что действительно помогает читателю. Для сложной схемы полезно предусмотреть текстовое объяснение рядом: одно короткое предложение не всегда передаёт все связи.
Отдельно договоритесь, кто добавляет описания новых изображений в админке. Иначе подготовленные правила исчезнут после нескольких обновлений контента. В редакционном списке можно хранить назначение изображения и готовую подпись.
Посмотрите на контраст и увеличенный текст
Контраст оценивают для реальных сочетаний текста и фона, включая обе темы, второстепенные подписи и состояния элементов. Например, критерий 1.4.3 в WCAG 2.2 задаёт для обычного текста уровень AA с отношением не менее 4,5:1; для крупного текста предусмотрен порог 3:1. У критерия есть оговорённые исключения, поэтому проверяющий должен учитывать назначение элемента.
Увеличьте текст и сузьте окно. Заголовок, описание и кнопка должны сохранять смысл и порядок чтения. Обратите внимание на обрезанные подписи, перекрывающиеся карточки и действия, уехавшие за край. Подготовьте для команды скриншот проблемы и исходные настройки масштаба, чтобы ситуацию можно было повторить.
Включите проверку в приёмку
Для каждого ключевого маршрута сохраните результат:
- действие удалось завершить с клавиатуры;
- положение фокуса понятно;
- поля имеют подписи, ошибки объясняют следующий шаг;
- назначение важных изображений доступно в тексте;
- контраст проверен инструментом;
- увеличение текста не скрывает содержание;
- замечания имеют владельца и срок исправления.
Такой обход помогает обнаружить явные препятствия, но не доказывает полного соответствия WCAG. Для заявленного уровня нужен согласованный объём аудита и проверка всех применимых критериев. Базовые требования стоит включать в проектирование интерфейса, пока структуру и компоненты ещё легко менять. Для оценки существующего сайта можно прислать адрес и основные пользовательские задачи через контакты DDRW.
