Выпадающее меню, которое нельзя полноценно использовать без мыши, — одна из самых частых проблем доступности интерфейсов. Пользователи с нарушениями зрения, моторики или те, кто просто предпочитает клавиатуру, упираются в меню, которое не открывается, не позволяет перемещаться по пунктам или «теряет» фокус. В этой статье — практическая методика тестирования клавиатурного доступа к выпадающим меню: какие сценарии проверять, какие сочетания клавиш ожидать, как фиксировать дефекты и когда проблему стоит эскалировать разработчикам.
Главный ориентир простой: все действия, доступные мышью, должны быть доступны с клавиатуры, а текущий элемент должен быть всегда виден пользователю. Если хотя бы одно из этих условий не выполняется, меню считается недоступным.
- Что именно проверяем и почему это важно
- Подготовка к тестированию
- Базовые сценарии клавиатурного тестирования
- 1. Открытие и закрытие меню
- 2. Навигация внутри открытого меню
- 3. Активация пункта
- 4. Видимость фокуса
- 5. Поведение заблокированных и выбранных пунктов
- Различия между типами выпадающих элементов
- Проверка со скринридером
- Типичные дефекты и как их описывать
- Чек-лист для быстрой проверки
- Когда передавать проблему дальше
- С чего начать прямо сейчас
Что именно проверяем и почему это важно
Клавиатурная навигация строится на понятии фокуса — маркера, который показывает, какой элемент интерфейса сейчас получит нажатия клавиш. Выпадающее меню корректно работает с клавиатурой, если фокус предсказуемо перемещается между триггером (кнопкой или полем), самим меню и его пунктами, а пользователь в любой момент понимает, где находится.
От качества этой навигации зависят:
- Доступность для людей с инвалидностью — скринридеры и альтернативные устройства ввода полагаются на стандартное поведение фокуса.
- Удобство для опытных пользователей — многие работают преимущественно с клавиатуры и воспринимают недоступное меню как брак продукта.
- Соответствие требованиям — критерии WCAG (например, управляемость с клавиатуры и видимость фокуса) входят в требования законодательства о доступности в ряде стран, включая европейский European Accessibility Act.
Подготовка к тестированию
Перед началом убедитесь, что у вас есть всё необходимое:
- Браузер с инструментами разработчика — они позволяют видеть, куда реально попадает фокус, даже если визуально он не отрисован.
- Скринридер для проверки озвучивания: NVDA или JAWS на Windows, VoiceOver на macOS, TalkBack на Android. Достаточно одного, но при возможности полезно проверить два разных.
- Список всех выпадающих меню приложения: навигационные меню, селекты в формах, контекстные меню, автодополнение, кастомные комбобоксы. Это разные компоненты с разным ожидаемым поведением.
- Чек-лист сценариев (приведён ниже) и шаблон баг-репорта.
Важно заранее договориться с командой, какое поведение считается эталоном. Для стандартных элементов (
Базовые сценарии клавиатурного тестирования
1. Открытие и закрытие меню
Переместите фокус к триггеру меню клавишей Tab (или Shift+Tab в обратном направлении) и проверьте:
- Меню открывается по Enter и/или пробелу. Для кнопок-триггеров обычно ожидаются обе клавиши; для некоторых паттернов допустима также стрелка вниз.
- После открытия фокус оказывается в логичном месте: на первом пункте меню либо остаётся на триггере (оба варианта допустимы, но поведение должно быть единообразным во всём приложении).
- Меню закрывается клавишей Escape, а фокус возвращается на триггер. Потеря фокуса после закрытия — частый и раздражающий дефект: пользователь вынужден заново искать место на странице.
- Повторное открытие работает так же стабильно, как первое.
- Клик вне меню (эмулируется переводом фокуса за пределы) закрывает его, если такое поведение заявлено дизайном.
2. Навигация внутри открытого меню
С открытым меню пройдите по всем пунктам и проверьте:
- Стрелки вверх/вниз перемещают фокус между пунктами последовательно, без пропусков и «застреваний».
- Зацикливание: после последнего пункта фокус возвращается на первый (и наоборот). Это ожидаемое поведение для большинства меню, но оно должно быть осознанным решением, а не случайностью.
- Home и End переходят к первому и последнему пункту — если это предусмотрено паттерном.
- Ввод первых букв: в длинных списках набор символов должен перемещать фокус к пункту, начинающемуся с этих букв (typeahead).
- Горизонтальные стрелки работают в многоуровневых меню: стрелка вправо открывает подменю, влево закрывает его и возвращает фокус на родительский пункт.
- Tab внутри меню: в классическом паттерне меню Tab не используется для навигации по пунктам — для этого служат стрелки. Однако Tab должен уводить фокус из меню дальше по странице, а не запирать его внутри (ловушка фокуса допустима только в модальных окнах).
3. Активация пункта
Выберите пункт клавишей Enter (для кнопкообразных пунктов — также пробелом) и проверьте, что действие выполняется: происходит переход, отправляется форма, меняется значение. После активации фокус должен оказаться в предсказуемом месте — обычно на целевой странице или на следующем логичном элементе формы.
4. Видимость фокуса
Пройдите по всему пути с клавиатуры и следите глазами: всегда ли понятно, какой элемент активен? Типичные проблемы:
- Обводка фокуса удалена через CSS (например, обнуление outline без замены другим индикатором).
- Фокус визуально есть, но сливается с фоном — например, тёмная рамка на тёмной кнопке.
- Фокус «уезжает» на скрытый элемент: пользователь жмёт Tab, ничего не происходит, потому что фокус попал на невидимый пункт закрытого меню.
Если сомневаетесь, откройте инструменты разработчика и посмотрите, на каком элементе стоит document.activeElement — это объективная проверка.
5. Поведение заблокированных и выбранных пунктов
Если в меню есть отключённые (disabled) пункты, проверьте, что они пропускаются при навигации стрелками или явно объявляются скринридером как недоступные — но не получают фокус молча. Текущий выбранный пункт в селектах должен быть обозначен для вспомогательных технологий (обычно через атрибут aria-selected или aria-checked).
Различия между типами выпадающих элементов
Ошибка новичка — тестировать все выпадающие элементы по одной схеме. Ожидания различаются:
| Компонент | Открытие | Навигация | Особенности проверки |
|---|---|---|---|
| Нативный select | Enter, пробел, стрелки — поведение браузера | Стрелки, ввод букв | Почти всегда доступен «из коробки»; проблемы возникают при стилизации поверх нативного элемента |
| Навигационное меню сайта | Enter на пункте-триггере, часто также стрелка вниз | Стрелки, Tab уходит из меню | Проверить многоуровневость и возврат фокуса при закрытии подменю |
| Кастомный комбобокс / автодополнение | Фокус на поле + ввод текста или стрелка вниз | Стрелки по списку предложений | Фокус остаётся на поле ввода, список анонсируется отдельно; проверить фильтрацию и очистку |
| Контекстное меню | Специальным сочетанием (например, Shift+F10 или клавишей Menu) | Стрелки | Часто полностью недоступно с клавиатуры в вебе — проверить хотя бы наличие альтернативного пути к тем же действиям |
| Меню в модальном окне | Как обычное меню | Стрелки | Проверить взаимодействие с ловушкой фокуса модального окна |
Проверка со скринридером
Клавиатурная навигация и работа скринридера связаны, но не совпадают. Меню может корректно принимать фокус, но быть бесполезным для незрячего пользователя. При проверке со скринридером слушайте:
- Роль и состояние: скринридер должен сообщать «меню», «пункт меню», «развёрнуто/свёрнуто» (expanded/collapsed), «выбрано». Если вместо этого читается просто текст без роли — разметка ARIA отсутствует или неверна.
- Анонсирование изменений: открытие и закрытие меню, появление новых пунктов в автодополнении должны озвучиваться автоматически.
- Понятность названий: каждый пункт имеет осмысленную подпись, а не «кнопка» или пустоту из-за иконки без текстовой альтернативы.
- Отсутствие лишнего шума: дублирование текста, чтение скрытых пунктов закрытого меню.
Совет: сначала освойте базовые команды скринридера (переход по элементам, чтение текущего элемента) на заведомо доступном сайте — иначе легко принять собственную неопытность за дефект продукта.
Типичные дефекты и как их описывать
Наиболее распространённые находки при таком тестировании:
- Меню не открывается с клавиатуры вообще — триггер реализован как div с обработчиком клика.
- Escape закрывает меню, но фокус исчезает со страницы целиком.
- Стрелки прокручивают страницу вместо перемещения по пунктам (отсутствует preventDefault).
- Закрытое меню оставляет свои пункты в порядке табуляции — «фантомные» остановки Tab.
- Индикатор фокуса удалён стилями.
- Подменю второго уровня невозможно открыть или из него нельзя вернуться назад.
- Скринридер не сообщает состояние «развёрнуто/свёрнуто».
Чтобы дефект было легко исправить, в баг-репорте указывайте:
- URL страницы и точный путь до меню (какие шаги приводят к нему).
- Браузер, ОС и скринридер, если использовался.
- Последовательность действий: «Tab до кнопки „Каталог“ → Enter → стрелка вниз ×3 → Escape».
- Ожидаемый результат со ссылкой на паттерн или требование.
- Фактический результат, включая значение document.activeElement, если проблема с фокусом.
- Скриншот или короткую видеозапись — для проблем с видимостью фокуса это ускоряет разбор в разы.
Чек-лист для быстрой проверки
- Меню открывается с клавиатуры (Enter, пробел или стрелка — согласно выбранному паттерну).
- Все пункты достижимы стрелками, порядок обхода логичный.
- Escape закрывает меню и возвращает фокус на триггер.
- Tab не запирает фокус внутри меню и не попадает на скрытые пункты.
- Enter/пробел активируют пункт, действие выполняется.
- Индикатор фокуса виден на всём пути.
- Disabled-пункты корректно обрабатываются.
- Скринридер объявляет роль, состояние и изменения меню.
- Многоуровневые меню открываются и закрываются в обе стороны.
- Поведение одинаково во всех однотипных меню приложения.
Когда передавать проблему дальше
Самостоятельное тестирование заканчивается там, где начинается проектирование. Если вы обнаружили, что ожидаемое поведение не определено (команда не выбрала паттерн), если исправление требует изменения архитектуры компонента или если дефект воспроизводится только в конкретной связке скринридер+браузер, которую сложно локализовать, — зафиксируйте наблюдения максимально подробно и передайте их разработчикам или специалисту по доступности. Ваша задача как тестировщика — точно описать воспроизведение, ожидание и факт, а не самостоятельно решать, каким должен быть паттерн взаимодействия.
С чего начать прямо сейчас
Возьмите главное меню вашего продукта и пройдите один полный сценарий без мыши: Tab до триггера, открытие, обход всех пунктов стрелками, активация одного из них, закрытие Escape. Засеките время и отметьте каждую точку, где пришлось задуматься или где фокус потерялся. Этот пятиминутный прогон выявит большинство грубых проблем. Затем повторите его со скринридером и дополните чек-лист специфичными для ваших компонентов случаями — селектами в формах, автодополнением, контекстными действиями. Регулярный короткий прогон при каждом релизе надёжнее редкого глубокого аудита.
Материал носит информационный характер и описывает общую практику тестирования. Конкретные требования к доступности зависят от применимого законодательства, стандартов и внутренних политик вашей организации — уточняйте актуальные требования перед принятием решений о соответствии продукта.