Начните с задач и компактной информационной архитектуры
Информационная архитектура — это то, как контент и функции сгруппированы, названы и связаны. Перечислите задачи посетителей, затем сопоставьте для каждой задачи стартовую страницу, следующую страницу и успешное конечное состояние. Это покажет, полезен ли пункт меню или это внутреннее название, которое посетителям придётся расшифровывать. Держите основную навигацию сфокусированной на разделах, которые инициируют эти задачи.
Навигация — это не карта сайта. GOV.UK рекомендует перечислять полезные верхнеуровневые разделы, а не каждую часть сервиса. Когда путь требует обязательного порядка, покажите это в контенте или списке задач вместо того, чтобы заставлять людей догадываться по глобальному меню.
Объединяйте страницы там, где посетители ожидают одинакового ответа или действия, а не потому что ими управляет одна команда.
Используйте лендинги и контекстные ссылки для деталей вместо плотного хедера.
Используйте метки, предсказывающие назначение
Метка — это обещание о том, что последует дальше. Предпочитайте знакомые названия вроде «Pricing», «Documentation», «Get support» или «Manage account», когда они соответствуют назначению. Избегайте расплывчатых меток вроде «Resources» или «Explore», если посетитель не может предсказать содержимое. Поддерживайте согласованность формулировок и порядка.
Google рекомендует лаконичный и релевантный текст ссылок, понятный вне контекста. Общие «click here» и списки ключевых слов этого не выполняют. Дайте элементу управления только с иконкой доступное имя, описывающее его действие.
Используйте «View plans» вместо «Learn more», когда цель — перейти на страницу с тарифами.
Отмечайте активное назначение визуально и программно; W3C описывает aria-current=page для отображаемой страницы.
Сделайте цели индексируемыми и структурно понятными
Назначение навигации обычно должно быть HTML‑якорём (<a> с href), разрешающимся в реальный веб‑адрес. Google говорит, что он обычно может обходить такую форму, включая динамически вставленные якоря, если отрисованный HTML сохраняет эту структуру. Обработчик клика или нестандартный атрибут сами по себе не являются надёжной заменой. Проверяйте отрисованный выход, а не только исходный код фреймворка.
Используйте семантическую структуру вокруг основной навигации. W3C рекомендует элемент nav и, для обычной навигации сайта, список. Если на странице несколько областей навигации, помечайте каждую, чтобы пользователь скрин‑ридера мог отличить основную навигацию от футера или локальной навигации.
Убедитесь, что важные десктопные и мобильные назначения представлены якорями с href после клиентского рендеринга.
URL Inspection даёт информацию о обходе, индексировании и показе в Google; это не доказательство того, что посетители могут найти страницу.
Проектируйте мобильное меню как полноценное взаимодействие
Адаптивная навигация может сворачиваться, но назначения, которые остаются, должны сохранять те же формулировки, порядок и цели на разных размерах экрана. W3C допускает сворачивание или скрытие пунктов в субнавигации, при этом требуя согласованности. Не делайте критический маршрут доступным только на десктопе из‑за тесного хедера; переместите материал низшего приоритета или пересмотрите иерархию.
Для меню с показом/скрытием используйте кнопку для управления группой ссылок и сообщайте, открыто ли оно. Пример disclosure‑navigation у W3C использует aria-expanded и aria-controls и документирует поведение Tab, Shift+Tab и Escape. Это обучающий пример, поэтому тестируйте ваш компонент с комбинациями, которые используют ваши пользователи.
Когда нужна и ссылка на родительскую страницу, и её дочерние ссылки, разграничьте ссылку‑страницу и контрол для раскрытия.
Любой контент, появляющийся при наведении указателя, должен быть доступен при фокусе клавиатуры и касании.
Поддерживайте ориентацию и навигацию с клавиатуры
Доступ с клавиатуры — это не декоративная доработка. WCAG 2.1 Success Criterion 2.1.1 требует, чтобы функциональность была управляемой через интерфейс клавиатуры, за исключением вводов, зависящих от пути. В хедере посетитель должен иметь возможность перемещаться по контролам с помощью Tab, видеть фокус, активировать ссылки и кнопки и уходить с элемента без ловушки.
Повторяющиеся ссылки в хедере могут затруднить перемещение по странице. Ссылка‑пропуск (skip link) в начале даёт клавиатурным пользователям маршрут к основному контенту. GOV.UK объясняет, что такая ссылка визуально скрыта до тех пор, пока не активируется клавиатурой. Проверьте, что она попадает на осмысленную цель.
Не убирайте индикатор фокуса браузера без явной альтернативы, которая остаётся видимой при увеличении.
Используйте Tab, Shift+Tab, Enter, Space и Escape от хедера к целевой странице.
Тестируйте обнаруживаемость до и после релиза
Попросите репрезентативных людей выполнить реалистичную задачу, например найти инструкцию по отмене подписки или сравнить тарифы. Наблюдайте, куда они ожидают пойти, какие метки они неверно читают и прибегают ли они к поиску, потому что навигация их подвела. Не направляйте их к предполагаемой метке. Записывайте каждое препятствие и минимальное изменение, которое его уберёт.
Сочетайте тест задач с техническими проверками. Руководство W3C Easy Checks рекомендует тестировать без мыши, включая видимость фокуса, порядок табуляции, ловушки клавиатуры и выпадающие списки. Повторяйте ключевые задачи на узких ширинах и при большом размере шрифта. Автоматические проверки могут выявить проблемы с разметкой, но не установят, понятна ли метка человеку.
Запишите предполагаемую конечную точку и поддерживаемое устройство или метод ввода до тестирования.
Тестируйте старый и новый маршрут по одним и тем же задачам, вместо того чтобы полагаться на предпочтения заинтересованных лиц.
Относитесь к изменениям навигации как к релизам, влияющим на доступность
Хедер может загрузиться, но критический путь при этом фактически окажется недоступен: оформление заказа, вход, страница поддержки или документация могут быть скрыты из‑за сломанного состояния, устаревшей ссылки или неправильного редиректа. До релиза инвентаризируйте критические назначения, протестируйте десктопные и мобильные маршруты и подтвердите, что отрисованные ссылки ведут на нужную страницу. Используйте авторизованные окружения для аутентифицированных или региональных путей.
Роль SIU — проактивное исправление: выполните предполётную проверку, подтвердите важнейшие пути после деплоя и сделайте исправление обратимым. Сохраняйте версионированную конфигурацию меню, указывайте лицо, которое сможет её восстановить, и валидируйте восстановленные пути. Это ограничит влияние релиза; это не заменяет юзабилити‑исследования или мониторинг живого статуса.
Блокируйте публикацию, если критическое назначение отсутствует, неверно или недоступно с клавиатуры и касанием.
Задокументируйте предыдущую конфигурацию, ответственного, триггер и шаги валидации до реструктуризации.