Как проверить интерфейс с клавиатуры: порядок фокуса, формы и диалоги

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

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

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

Запишите задачу обычными словами: «Выбрать специалиста и отправить заявку на консультацию». Затем перечислите обязательные действия и возможные отклонения: открыть список, выбрать карточку, заполнить поля, исправить ошибку, открыть пояснение и вернуться к форме. Если проверить только кнопку отправки, можно пропустить недоступный выбор специалиста в начале пути.

В объяснении WCAG 2.1.1 говорится о доступности функций через клавиатурный интерфейс, с оговорённым исключением для ввода, зависящего от траектории движения. Из этого не следует, что все действия должны запускаться одной клавишей. Важно, можно ли выполнить нужную функцию без обязательного обращения к указателю.

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

Начните с последовательного перехода

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

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

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

Проверьте видимость фокуса

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

WCAG 2.4.7 описывает видимый индикатор клавиатурного фокуса. Проверьте его на светлом и тёмном фоне, около соседних элементов и при прокрутке. Если обводка появляется на мгновение и исчезает, человек может потерять текущее положение. Для разбора состояний используйте термин «Клавиатурный фокус».

Отдельная проверка нужна для закреплённых панелей и баннеров. В WCAG 2.4.11 минимальное требование касается элемента в фокусе, который не должен быть полностью скрыт созданным автором содержимым, с уточнениями в самом критерии. Для удобства желательно видеть элемент целиком; не подменяйте этим пожеланием точную формулировку минимального требования.

Выполните действия, а не только обойдите элементы

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

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

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

Откройте и закройте модальное окно

Предположим, ссылка «Что входит в консультацию» открывает диалог с пояснением. Проверьте, куда попал фокус после открытия, доступны ли действия внутри и как человек возвращается к форме. Если фон визуально затемнён, но клавиатура продолжает перемещаться по скрытым элементам страницы, внешнее представление и управление расходятся.

В паттерне модального диалога WAI-ARIA APG фокус перемещается внутрь окна, последовательность Tab остаётся внутри, а Escape закрывает диалог. Начальная точка зависит от содержимого. В длинном пояснении полезно сначала дать воспринять структуру, а не автоматически отправлять человека к последней кнопке.

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

Убедитесь, что из компонента можно выйти

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

На практике проверьте встроенные редакторы, карты и всплывающие панели. Запишите последовательность, после которой движение прекращается, и попробуйте предусмотренный выход. Не закрывайте проблему выводом «пользователь может щёлкнуть снаружи»: это возвращает обязательную зависимость от мыши, которую вы и проверяете.

Повторите путь с ошибкой формы

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

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

Передайте наблюдения так, чтобы их можно было повторить

Хорошая запись дефекта содержит исходное состояние, шаги, ожидаемое поведение и фактический результат. Например: «Открыть пояснение из формы; закрыть Escape; нажать Tab. Ожидалось продолжение рядом с ссылкой пояснения, фактически переход начинается с первой ссылки шапки». Это полезнее общего комментария «исправить доступность».

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

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