Проверка сайта клавиатурой: меню, формы и модальные окна

Клавиатура и выделенный элемент на макете страницы.

Оглавление

• Что приготовить для проверки
• Ссылки и кнопки ведут себя по-разному
• Меню: открыть мало, нужно ещё добраться до пунктов
• Модальное окно не должно становиться ловушкой
• Составьте маршрут, который заканчивается результатом
• Убедитесь, что проверяете сайт, а не настройку компьютера
• Порядок фокуса: проверяем логику, а не геометрию
• Разные виджеты требуют разных сценариев
• Проверяем перекрытия и динамические изменения
• Пример отчёта, который можно передать разработчику
• Что включить в повторную проверку
• В форме важен путь после ошибки
• По теме

Что приготовить для проверки

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

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

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

Ссылки и кнопки ведут себя по-разному

Обычная ссылка открывается Enter. Нативная кнопка обычно активируется Enter и пробелом. Поэтому кликабельный прямоугольник из произвольного элемента не становится полноценной кнопкой только от добавленного обработчика мыши. Разработчику приходится отдельно обеспечивать семантику и клавиатурное поведение; часто проще сразу выбрать правильный HTML-элемент.

Проверьте, можно ли различить действие до активации. Подпись «Подробнее» у десятка карточек неудобна без контекста. Доступное название должно помогать понять, о какой карточке речь. Это особенно важно при дополнительной проверке скринридером, но неоднозначные подписи заметны и визуально.

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

Меню: открыть мало, нужно ещё добраться до пунктов

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

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

Положительный tabindex для ручного выстраивания порядка обхода — повод присмотреться к разметке. При изменении страницы такой порядок легко ломается. Обычно последовательность в DOM должна сама соответствовать логике чтения и выполнения задачи.

Модальное окно не должно становиться ловушкой

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

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

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

Непрерывный маршрут как образ логичного порядка фокуса.

Составьте маршрут, который заканчивается результатом

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

У каждого маршрута зафиксируйте начальные условия. Авторизован ли пользователь? Приняты ли cookies? Есть ли товары в корзине? На каком разрешении открыт сайт? Скрытый баннер, который уже закрыт у тестировщика, может перекрывать первое поле у нового посетителя. Поэтому полезно повторять путь в чистом профиле браузера и в обычной пользовательской сессии.

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

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

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

Убедитесь, что проверяете сайт, а не настройку компьютера

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

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

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

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

Порядок фокуса: проверяем логику, а не геометрию

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

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

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

Положительные значения tabindex позволяют построить отдельную очередь поверх порядка документа. Это хрупкий способ: новый элемент может вклиниться в неожиданное место. Если команда предлагает исправить один скачок значением 99, попросите проверить всю последовательность после изменения. Зачастую надёжнее исправить структуру или отказаться от ненужной визуальной перестановки.

Ссылка пропуска навигации

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

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

Разные виджеты требуют разных сценариев

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

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

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

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

У ползунка диапазона важна возможность изменить значение и понять результат. Если рядом есть числовое поле, проверьте согласованность: изменение одного элемента отражается в другом. Для задач, где нужна точная сумма или размер, ввод числа нередко практичнее многократного нажатия стрелки. Наличие такого пути стоит обсудить до детальной анимации ползунка.

Перетаскивание карточек тоже нуждается в альтернативе, если оно требуется для выполнения задачи. Кнопки перемещения, выбор позиции или другой клавиатурный способ должны давать тот же осмысленный результат. Фраза «нажмите и перетащите мышью» не является альтернативой для человека, который мышью не пользуется.

Возврат к исходной кнопке после закрытия окна.

Проверяем перекрытия и динамические изменения

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

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

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

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

Если появляется уведомление, оно не должно перекрывать важное управление или исчезать до того, как человек успеет воспользоваться действием. Особенно внимательно проверяйте «Отменить удаление» и сообщения о завершении загрузки. Клавиатурный пользователь должен иметь реальную возможность достичь предложенного действия, а не только увидеть его на секунду.

Пример отчёта, который можно передать разработчику

Плохое описание: «У формы проблема с доступностью». Оно не показывает место, причину и тяжесть. Хорошее описание воспроизводится без созвона: «В карточке услуги открыть “Получить расчёт” клавишей Enter. Нажать Tab шесть раз. Фокус уходит на ссылку в подвале, хотя модальная форма остаётся открытой. Ожидается обход доступных элементов диалога».

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

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

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

Что включить в повторную проверку

После изменения компонента вернитесь к полному маршруту и соседним вариантам. Исправление одного диалога может затронуть все окна, использующие общий компонент. Если добавили управление фокусом, проверьте закрытие кнопкой, Escape и завершением действия; эти пути не всегда вызывают одинаковую логику.

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

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

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

В форме важен путь после ошибки

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

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

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

По теме

• Как проверить сайт на мобильных устройствах — инструкция
• Форма обратной связи: как сделать правильно
• Pop-up на сайте: как использовать без вреда для UX, SEO и конверсии