Выберите сценарий и получите воспроизводимый протокол
Ручная проверка доступности отвечает на конкретный вопрос: может ли человек выполнить выбранную задачу с клавиатуры, увидеть место фокуса, понять элементы и исправить ошибку. Полезный результат — список проверенных состояний и воспроизводимых препятствий, а не один зелёный балл автоматического сканера. В этом гайде проверяются навигация, меню, диалог, сообщения формы, масштаб и смысловая структура страницы.
Начните с реального маршрута: найти услугу, открыть материал, скачать файл или пройти тестовую форму. Зафиксируйте браузер и его версию, размер окна, масштаб, версию сайта и начальное состояние. Для действий с отправкой используйте тестовый контур или согласованный перехват запроса; успешная проверка управления не требует отправлять настоящую заявку.
Протокол опирается на технические принципы W3C. Он не охватывает все требования WCAG, сочетания вспомогательных технологий и состояния сайта. Прохождение выбранных шагов не устанавливает полное соответствие стандарту или правовым требованиям.
1. Пройдите маршрут без мыши
Откройте страницу заново и уберите указатель мыши из рабочей области. Настройте браузер/ОС так, чтобы клавиатурная навигация достигала нужных элементов; настройку запишите в протокол. Двигайтесь Tab вперёд и Shift+Tab назад. На каждой остановке смотрите, виден ли фокус и соответствует ли порядок смыслу задачи. Не подменяйте этот тест программным вызовом focus(): он не показывает фактический путь пользователя.
Проверьте переход к основному содержимому, ссылки и кнопки. Активируйте их ожидаемой клавишей; для стандартных кнопок проверьте привычные Enter и Space. Если элемент действует только по наведению мыши, попытайтесь выполнить ту же функцию с клавиатуры и опишите, на каком шаге это не получилось. По принципу Keyboard W3C нужна клавиатурная возможность выполнить функциональность с предусмотренными стандартом исключениями.
Сравните движение вперёд и назад. Фокус не должен неожиданно прыгать в неподходящий контекст или исчезать на скрытом элементе. Focus Order требует сохранения смысла и возможности работы, а не одного универсального расположения. Опишите препятствие через задачу: «после заголовка переход в скрытый блок, кнопка загрузки пропущена» точнее, чем «плохой tabindex».
2. Проверьте меню, диалог и возвращение фокуса
Откройте меню с клавиатуры, найдите нужный пункт и закройте меню. Проверьте, можно ли продолжить движение и есть ли понятный способ выйти. Учитывайте стандартные клавиши выбранного компонента: не все меню работают одинаково. Если нужен специальный способ выхода, пользователь должен иметь возможность его узнать. No Keyboard Trap отдельно рассматривает невозможность выйти из компонента.
Для модального диалога запишите элемент, который его открыл. После открытия проверьте начальный фокус, доступность всех действий и закрытие. Пока диалог открыт, фокус не должен уходить в недоступное для работы фоновое содержимое. После закрытия проверьте понятное возвращение к исходной задаче. Видимое затемнение само по себе не доказывает работу диалога с клавиатуры.
Проверьте липкую шапку, нижнюю панель, уведомление и всплывающее окно. Виден ли сфокусированный элемент после прокрутки? Может ли человек понять, где он находится? Для Focus Visible важен видимый индикатор. Минимальный критерий Focus Not Obscured касается элемента, который не должен быть полностью скрыт авторским содержимым; он не требует полного отсутствия любого частичного перекрытия. Частичное неудобное перекрытие тоже занесите в протокол, отдельно от утверждения о нарушении конкретного критерия.
3. Проверьте подписи, ошибки и сохранность введённого
На тестовой форме найдите название каждого поля, указание обязательности и ожидаемый формат. Placeholder, исчезающий при вводе, не заменяет постоянную понятную подпись. Проверьте, можно ли перейти к полю и активировать связанный элемент. Если есть несколько одинаковых кнопок «Отправить», их контекст должен позволять понять, какое действие будет выполнено.
Создайте в тестовом контуре исправимую ошибку: например, пропустите обязательное поле. Затем проверьте, где появился фокус, указано ли проблемное поле и объяснён ли способ исправления. Одного красного цвета недостаточно для понимания причины. Исправьте значение с клавиатуры и убедитесь, что остальные введённые поля не исчезли без необходимости. Серверное сообщение, задержка и неизвестный результат отправки рассматриваются отдельно от ошибки заполнения.
Проверка доступного имени, роли и связи сообщения с полем включает инструменты разработчика и тест с выбранной вспомогательной технологией. Для начальной ручной проверки зафиксируйте наблюдаемое препятствие; не объявляйте совместимость со всеми скринридерами по одному визуальному просмотру. Этот набор действий нужно расширить, если продукт используется с конкретной технологией доступа.
4. Проверьте чтение, увеличение и изображения
Увеличьте масштаб и повторите ключевой маршрут. В качестве учебного состояния CSV использует 200%; это зафиксированный режим конкретной проверки, не универсальное условие приёмки. Смотрите, не обрезаны ли подписи, не перекрыты ли действия и можно ли прочитать содержимое без постоянного движения в двух направлениях. Таблицы и другие сложные компоненты проверяйте отдельно: их прокрутка не должна уводить всю страницу за пределы окна.
Просмотрите заголовки и порядок чтения. Должно быть понятно, где начинается основной материал и как связаны его разделы. Не выбирайте уровень заголовка только ради размера шрифта. Найдите ссылки с одинаковым текстом и проверьте, различимы ли их назначения из контекста. Для файлов укажите понятное название и формат; проверка продолжается внутри документа, если пользователь должен его прочитать.
Разделите изображения на содержательные и декоративные. У содержательного нужна подходящая текстовая замена; у декоративного не должно быть лишнего мешающего описания. Для графика или схемы краткое название часто недостаточно: изложите важный вывод и данные доступным текстом. Наличие атрибута alt не доказывает качество его содержания. Первичный W3C Easy Checks помогает начать такие проверки и прямо ограничивает полноту предварительного обзора.
5. Запишите дефект так, чтобы другой человек повторил его
| Поле | Что указать | Учебный пример |
|---|---|---|
| Начальное состояние | Маршрут, окно, масштаб, версия, состояние компонента | DEMO-страница; меню закрыто; обычный масштаб |
| Шаги | Последовательность действий клавиатурой | Tab до меню → Enter → Tab до ссылки → закрыть |
| Ожидаемое и фактическое | Влияние на задачу пользователя | Ожидали выйти из меню; фокус остаётся внутри |
| Доказательство и повтор | Место записи/снимка, результат повторного прогона | DEMO-EVIDENCE-01; воспроизведено на той же версии |
Различайте «прошло», «обнаружено препятствие», «не проверено» и «не применимо». Если компонент отсутствует, это не успешный тест его поведения. Для blocker укажите, какую задачу нельзя закончить и существует ли доступный обходной путь. Предполагаемую техническую причину храните отдельно от наблюдаемого результата.
После исправления повторите исходные шаги и соседние сценарии: закрытие диалога, обратное движение, изменение масштаба и другую ширину. Запишите новую версию и сохраните прежнюю запись. Скриншот полезен для видимости фокуса, но для порядка движения и выхода из ловушки нужен сам воспроизводимый сценарий. Итог включает coverage маршрутов и состояний, открытые препятствия и непроверенные компоненты.
Границы и дальнейшая работа
Этот набор не заменяет полную оценку доступности: в него не включены все критерии, контрастные измерения, все типы контента и комбинации браузеров/вспомогательных технологий. WCAG Understanding — объясняющие материалы к стандарту; ограниченный протокол не является сертификатом, юридическим заключением или обещанием полного соответствия сайта.
Для общей проверки поставленного продукта есть гайд проверки сайта и ПО перед приёмкой; он решает более широкую задачу. Направление разработки описано на странице сайтов и порталов. Обсудить конкретные сценарии и требуемую глубину проверки можно через существующие контакты НЬЮ-ССТ, передав список маршрутов и описание препятствий.