NovКлавиатурная навигация в фильтрах — это реальная функция, а не формальность
Как понять, что фильтрами действительно можно пользоваться без мыши, и почему доступность должна проверяться по завершённой задаче выбора недвижимости.
Материал отражает практическую позицию указанного эксперта. Как готовятся и проверяются публикации — в редакционной политике NovAsia.
Фильтр может выглядеть аккуратно и даже получать фокус при нажатии клавиши перехода, но это ещё не означает, что им можно пользоваться с клавиатуры. Человеку нужно не просто добраться до элемента. Ему нужно открыть выбор, изменить значение, понять, что выбрано, применить условие, увидеть обновившийся результат, при необходимости снять фильтр и продолжить путь без ловушки.
Для сайта недвижимости это полноценная пользовательская функция. Поиск часто состоит из серии действий: город, тип объекта, бюджет, стадия, дополнительные условия, сортировка. Если мышь отсутствует или неудобна, каждая из этих операций должна оставаться доступной. Причины могут быть разными — постоянная потребность, временная травма, использование вспомогательной технологии или просто привычка работать с клавиатурой. Технической системе не нужно угадывать причину; ей нужно не отбирать возможность закончить задачу.
Фильтр считается доступным, когда человек может закончить поиск
Самый слабый тест звучит так: «до элемента можно дойти клавиатурой». Более полезный — «можно ли от начала до конца получить нужную выборку без мыши». В этом маршруте сразу проявляются реальные дефекты.
Фокус должен двигаться в понятном порядке. Если раскрывающийся список открылся, человек должен понимать, где находится и как выбрать значение. После выбора нужно увидеть или услышать состояние элемента. Если результаты обновляются автоматически, пользователь не должен внезапно терять позицию. Если есть отдельная кнопка применения, до неё нужно добраться и активировать её. Очистка условия тоже является частью функции, а не второстепенной роскошью.
Особенно неприятны ловушки. Пользователь открыл сложный фильтр, фокус оказался внутри, а выйти обычной клавиатурной навигацией невозможно. Формально элемент «поддерживает клавиатуру», практически поиск закончился. WCAG 2.2 рассматривает клавиатурную доступность как возможность выполнять функциональность через клавиатурный интерфейс. Это хорошая проверка здравого смысла: доступность измеряется не наличием обработчика клавиши, а достижением результата.
Фокус должен быть и заметен. Человек, который видит экран и не использует мышь, ориентируется по текущей позиции. Если визуальный индикатор исчезает на сложном компоненте, интерфейс становится игрой на память. При этом я бы не превращал статью в перечень норм контраста и размеров — для реализации есть профильные требования и тестирование. На уровне продукта важнее понимать, что невидимый фокус делает реальную функцию трудноиспользуемой даже при корректной внутренней логике.
Фильтры добавляют ещё одну сложность: состояние. Допустим, выбраны «Бангкок», «кондоминиум» и верхний бюджет. После обновления результатов пользователь должен сохранить эти условия и понимать, что они активны. Если клавиатурный сценарий сбрасывает один параметр, меняет порядок или заставляет заново проходить десятки элементов после каждого выбора, формально доступный интерфейс может оказаться практически непригодным.
Клавиатура хорошо показывает, где компонент слишком много решает сам
Проверка без мыши полезна не только для доступности. Она быстро обнаруживает архитектурные слабости интерфейса: скрытые кликабельные области, неоднозначные состояния, элементы без понятного имени, автоматические скачки и действия, которые завязаны только на указатель.
Представим фильтр бюджета с двумя полями и готовыми диапазонами. Мышью человек может нажать куда угодно и быстро исправиться. С клавиатурой становится заметно, что порядок неясен: сначала готовые диапазоны, затем поле «от», потом кнопка закрытия, затем поле «до». Это не обязательно нарушение само по себе, но сигнал посмотреть на реальную логику задачи. Хороший порядок следует тому, как человек формирует условие, а не тому, как компоненты случайно расположились в реализации.
То же относится к пользовательским сообщениям. Если после применения фильтра найдено ноль вариантов, этот результат должен быть понятен и не превращать человека в пленника пустой выдачи. Он должен иметь возможность вернуться к условиям, изменить одно из них и продолжить. Клавиатурный путь особенно чувствителен к таким разрывам, потому что «просто нажать мышью в нужное место» нельзя.
На двуязычном сайте я бы проверял сценарий в обеих версиях. Длина подписей меняется, но назначение управления — нет. Переведённая надпись не должна ломать доступ к кнопке, обрезать смысл или менять порядок так, что функция фактически становится другой.
Важно и не заявлять соответствие стандарту только по одной ручной проверке. WCAG включает набор требований шире клавиатурной навигации, а полноценная оценка доступности требует системной проверки. Но для конкретного фильтра есть простой продуктовый вопрос, который можно задавать на каждом выпуске: человек без мыши способен сформировать условия, получить выдачу, изменить выбор и выйти из компонента без потери контекста?
Если ответ «да», клавиатурная навигация перестаёт быть скрытым техническим пунктом и становится тем, чем должна быть, — частью работающего поиска. Если ответ «почти», значит функция для части пользователей пока существует только на картинке.
Источники
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 2.1.1 Keyboard; требование доступности функциональности через клавиатурный интерфейс; дата обращения: 6 октября 2026 года.
- W3C Web Accessibility Initiative — Technique G202: Ensuring keyboard control for all functionality; пояснение пользовательской цели клавиатурного управления; дата обращения: 6 октября 2026 года.