Ошибки навигации клавишей Tab в React-компонентах: причины и способы исправления

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

Ошибка 3. Потеря фокуса после перерисовки или удаления элемента

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

Типичные сценарии:

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

Решение: управляемый перевод фокуса

После удаления или замены элемента программно переместите фокус на логичную цель. Элемент-приёмник помечается tabindex=»-1″, чтобы он не добавлял лишний стоп в обход Tab, но принимал программный фокус:

1. Определите осмысленную цель: заголовок обновлённого списка, следующая строка, кнопка закрытия уведомления.
2. Добавьте ей tabIndex={-1} и ref.
3. В момент изменения состояния вызовите ref.current.focus().

Удобный паттерн — хранить в состоянии идентификатор элемента, которому нужно вернуть фокус, и обрабатывать это в useEffect после перерисовки. Так вы не привязываетесь к конкретному месту в дереве компонентов.

Ошибка 4. Ломаные ловушки фокуса в модальных окнах

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

Частые нарушения:

• Фокус остаётся под оверлеем. Окно открыто, но Tab продолжает водить по затемнённой странице. Пользователь взаимодействует с невидимыми элементами.
• Фокус не переносится внутрь при открытии. Скринридер продолжает читать фон, пользователь не понимает, что появилось диалоговое окно.
• Нет возврата фокуса при закрытии. После закрытия модалки Tab начинается с начала страницы.
• Ловушка без выхода. Обратная ситуация: фокус заперт внутри, но кнопка закрытия недоступна с клавиатуры или Escape не работает.

Как реализовать корректно

1. При монтировании окна сохраните document.activeElement — это точка возврата.
2. Переведите фокус на первый интерактивный элемент окна или на сам контейнер с tabindex=»-1″.
3. Повесьте обработчик keydown: при Tab находите первый и последний фокусируемые элементы внутри окна и зацикливайте переход; при Escape вызывайте закрытие.
4. При размонтировании верните фокус на сохранённый элемент.

Если проект уже использует библиотеку компонентов, проверьте, поддерживает ли её компонент модального окна эти четыре поведения. Большинство зрелых решений (Radix UI, Headless UI, Reach UI и подобные) делают это из коробки — тогда задача сводится к тому, чтобы не обходить их механизмы своими обработчиками.

Ошибка 5. Скрытые, но доступные для Tab элементы

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

• скрытие через opacity: 0 или смещение за экран вместо display: none — такие элементы остаются в порядке табуляции;
• карусели и слайдеры, где неактивные слайды спрятаны визуально, но присутствуют в DOM;
• аккордеоны, где свёрнутая панель скрыта только высотой (max-height: 0) без visibility или hidden-атрибута;
• отрисованные заранее шаги многошаговой формы.

Исправление зависит от подхода. Надёжные варианты: использовать условный рендеринг (React просто не создаёт элемент), применять атрибут hidden или свойство visibility: hidden, которые убирают элемент из табуляции, либо добавлять tabIndex={-1} и inert-подобное поведение для неактивных областей. Атрибут inert, поддерживаемый современными браузерами, отключает и фокус, и взаимодействие сразу для целого поддерева — удобно для неактивных слайдов карусели.

Ошибка 6. Пропуск и дублирование стопов из-за сторонних компонентов

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

Что проверить при выборе и подключении такого компонента:

• документирует ли автор поведение клавиатуры и есть ли настройки управления фокусом;
• можно ли выйти из виджета клавиатурой (стандартный паттерн — выход по Escape);
• сколько стопов табуляции занимает виджет и можно ли сократить их группировкой внутренних элементов;
• что происходит с фокусом при инициализации: некоторые виджеты сами забирают фокус при загрузке страницы, что раздражает пользователей.

Ошибка 7. Нестандартное поведение в составных виджетах

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

Практические ориентиры:

• радиокнопки: один стоп Tab на всю группу, переключение стрелками — это даёт нативный input type=»radio» с общим name;
• меню: Tab открывает меню, стрелки ходят по пунктам, Escape закрывает;
• табы: Tab переводит на список вкладок, стрелки переключают активную вкладку;
• списки с выбором (listbox): активный элемент управляется стрелками, фокус единый.

Реализовать эти паттерны вручную непросто, поэтому разумнее взять готовые headless-компоненты, где логика уже написана, а внешний вид остаётся за вами.

Как диагностировать проблемы навигации

Большинство ошибок находится вручную за несколько минут. Порядок проверки:

1. Отключите мышь физически или просто не трогайте её. Пройдите по странице от адресной строки до конца, отмечая каждый стоп Tab.
2. Сверяйте: совпадает ли порядок фокуса с визуальным порядком? Нет ли «невидимых» стопов? Нет ли элементов, до которых Tab не доходит?
3. Проверьте, всегда ли видно, где фокус: стандартная рамка может быть удалена стилями. Если вы убираете outline, замените его другим заметным индикатором — например, через псевдокласс focus-visible.
4. Протестируйте ключевые сценарии: открытие и закрытие модалки, удаление элемента списка, отправку формы, переключение вкладок.
5. Полезно включить отображение фокуса принудительно или использовать расширения браузера, подсвечивающие текущий активный элемент.

Из инструментов автоматизации помогают аудиты доступности в Lighthouse и линтеры вроде eslint-plugin-jsx-a11y: они ловят очевидные вещи — кликабельные div без роли, картинки без alt, неправильное использование aria-атрибутов. Но автоматика не проверит логику порядка и поведение фокуса в динамике, поэтому ручной проход с клавиатурой остаётся обязательным.

Таблица: симптом, причина, решение

Типичные ошибки при исправлении

• Гасить outline полностью. Удаление рамки фокуса «для красоты» лишает пользователя клавиатуры единственного ориентира. Используйте :focus-visible, чтобы индикатор показывался только при клавиатурной навигации.
• Вешать tabindex=»0″ на всё подряд. Абзацы и заголовки с tabindex создают шум: пользователь вынужден пролистывать неинтерактивный текст. Табулируются только интерактивные элементы.
• Перехватывать Tab глобально. Попытка «улучшить» навигацию через document-level обработчик обычно ломает ожидаемое поведение во всех остальных местах страницы.
• Забывать про мобильные сценарии. На сенсорных устройствах Tab нет, но та же логика фокуса влияет на экранные дикторы и автозаполнение форм, поэтому исправления полезны и там.

Сценарии: что делать в вашей ситуации

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

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

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

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

Практические рекомендации

• Держите порядок табуляции равным порядку DOM и визуальному порядку — это снимает большинство проблем.
• Никогда не используйте положительный tabindex.
• Любой кликабельный нестандартный элемент делайте фокусируемым и отзывчивым на Enter и пробел.
• После любого изменения интерфейса, затрагивающего активный элемент, явно управляйте фокусом.
• Модальные окна реализуйте с полным циклом: перенос фокуса внутрь, ловушка, Escape, возврат фокуса.
• Регулярно проходите ключевые сценарии приложения только с клавиатурой — это самый быстрый регрессионный тест навигации.

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