Окно заявки и клавиатура: как проверить фокус

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

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

Подготовьте проверяемый сценарий

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

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

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

Открытие окна должно менять место работы

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

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

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

Пройдите весь маршрут в обе стороны

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

Проверьте, что активный элемент различим. W3C отдельно объясняет видимость фокуса и порядок переходов как разные свойства. Красивый порядок не помогает, если посетитель не видит текущую позицию. Яркая рамка тоже не исправляет прыжок к скрытой кнопке. В отчёте о проверке отмечайте эти проблемы отдельно, чтобы исправление одного свойства не закрывало вторую задачу формально.

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

Ошибка ввода создаёт новое состояние формы

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

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

Разберите также отказ со стороны сервера в тестовом окружении. Если вся форма перерисовывается, ранее активное поле может исчезнуть из документа. Пользователь не должен оставаться в неопределённом месте с потерянным содержимым. Специалист проверяет выбранный маршрут после ответа, а владелец — возможность продолжить исправление. Успешная локальная проверка поля не заменяет этот сценарий.

Закрытие и продолжение работы нужно согласовать

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

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

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

Две кнопки открытия помогают найти скрытую ошибку

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

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

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

Что считать исправленным результатом

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

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

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