Управление фокусом: фокус — состояние приложения, и владеете им вы

Смена роута никуда не переносит фокус

При полной загрузке страницы браузер делает три работы по доступности бесплатно: сбрасывает фокус на верх нового документа, объявляет заголовок документа и начинает порядок чтения с известного места. Клиентская смена роута не делает ни одной. React меняет поддерево; фокус либо остаётся на том, что пережило дифф (ссылка в навигации, далёкая от нового контента), либо — если ранее сфокусированный элемент демонтирован — падает на body, скринридер молчит, и следующий Tab пользователя стартует оттуда, где похоронили покойника. Стандартное лечение — считать навигацию событием фокуса: после коммита нового вью сфокусировать его h1, которому задан tabIndex={-1}, и обновить document.title. Это -1 существенно: оно делает заголовок фокусируемым программно, не вставляя его в Tab-порядок, — иначе клавиатурные пользователи навсегда получили бы лишнюю остановку на неинтерактивном элементе. Фокус на заголовке отрабатывает дважды: скринридер его объявляет (контекст: «Детали платежа, заголовок первого уровня»), и последовательный фокус теперь продолжается с верха нового контента, а не со старой позиции в DOM.

function RouteHeading({ children }) {
  const ref = useRef(null);
  useEffect(() => {
    // при монтировании нового роута: объявить + переставить фокус
    ref.current?.focus();
  }, []);
  return <h1 tabIndex={-1} ref={ref}>{children}</h1>;
}

Альтернатива — live-region-объявлятель маршрутов (элемент с aria-live="polite", которому вы записываете имя новой страницы): он объявляет, не трогая фокус, что подходит для случаев, где перенос фокуса был бы разрушительным, но он не чинит вторую половину проблемы — «следующий Tab стартует из ниоткуда». Продакшен-роутеры и фреймворки поставляют варианты обоих приёмов; ваша зона ответственности — выбор целевого фокуса по типу навигации: шагу визарда нужен заголовок, обновлению фильтра внутри страницы — обычно нетронутый фокус плюс вежливое объявление количества результатов.

Фокусный контракт диалога

Модальный диалог — это фокусный контракт из четырёх пунктов, и APG их проговаривает. При открытии: перенести фокус внутрь — на первый осмысленный фокусируемый элемент или на сам контейнер диалога для подтверждений, где фокус на кнопке «Удалить навсегда» был бы заряженным ружьём. Пока открыт: фокус заперт — Tab с последнего элемента заворачивает на первый, а страница позади инертна; современный механизм — атрибут inert на фоновом контейнере (или нативный элемент dialog с showModal(), который даёт top-layer, Escape и инертность фона одним ходом). inert — та важная половина, которую самодельные ловушки забывают: ловушка клавиши Tab останавливает клавиатуру, но без инертности виртуальный курсор скринридера спокойно выходит из диалога в фоновую страницу. По Escape: закрыть. При закрытии: вернуть фокус элементу, открывшему диалог — сохраните ссылку на document.activeElement до переноса фокуса и восстановите после демонтирования.

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

Гонки, удаления и два псевдокласса фокуса

Фокус может встать только на узел, который существует. Классическая гонка React: обработчик вызывает setShowPanel(true), а следующей строкой — panelRef.current.focus(), но обновления состояния батчатся и асинхронны, панель ещё не отрендерена, panelRef.current равен null, и фокус молча уходит в никуда. flushSync из react-dom существует ровно для этого: оберните обновление состояния в flushSync(() => setShowPanel(true)) — React синхронно закоммитит DOM до следующей строки, и вызов focus() найдёт узел. Это осознанный аварийный люк с реальной ценой — синхронный рендер затронутого поддерева в обход батчинга, — поэтому правило такое: flushSync для позиционирования фокуса (а также прокрутки и выделения) после монтирования, управляемого состоянием, и ни для чего больше.

Удаление — та же теорема с другой стороны: когда сфокусированный элемент демонтируется, браузер переносит фокус на body — эвристики «ближайший сосед» в платформе нет. Поэтому вычисляйте преемника до мутации: фокус на аналогичный контрол следующей строки, иначе предыдущей, иначе на заголовок списка с tabIndex={-1}. Ваша модель данных знает соседа; DOM после удаления — нет.

Две смежные дистинкции завершают набор. :focus срабатывает всегда, когда у элемента фокус; :focus-visible — когда эвристики браузера говорят, что индикатор стоит показать: при клавиатурном взаимодействии да, при клике мышью обычно нет. Современный паттерн — выразительное кольцо на :focus-visible вместо удаления обводок (древнее преступление outline: none мотивировалось кольцами от кликов мыши; :focus-visible устраняет мотивацию). И scrollIntoView — это не фокус: он двигает пиксели, а не позицию последовательного фокуса — после прокрутки элемента в видимую область следующий Tab пользователя всё равно продолжится со старого места. Если пользователь должен взаимодействовать с нового места — фокусируйте; если должен лишь увидеть — прокручивайте; делать одно, имея в виду другое, — категориальная ошибка, которую переживают только клавиатурные пользователи.