Уявімо відвідувача, який відкриває сайт студії та хоче перейти з головної сторінки до послуг, а потім до контактів, не торкаючись миші. Чи зрозуміло йому, де він перебуває? Чи відкривається потрібний розділ? Такий короткий маршрут добре показує, чи продумана навігація як робочий інструмент, а не лише як композиція в макеті. У поясненні W3C WAI щодо клавіатури основний принцип простий: функції інтерфейсу мають бути доступні з клавіатури.
Почніть зі зрозумілої структури
Для звичайної навігації використовуйте посилання, згруповані у списки всередині елемента nav. Цю основу описує посібник WAI зі структури меню. Посилання веде на сторінку, а кнопка відкриває або закриває підменю. Якщо пункт «Послуги» має і власну сторінку, і вкладені розділи, розділіть ці дії. Так легше пояснити поведінку компонента ще до розробки: назва веде до огляду, сусідня кнопка показує додаткові варіанти.
Продумайте послідовність переходів
Натискання Tab має вести зрозумілим маршрутом, а Shift + Tab дозволяти повернутися назад. WAI пояснює порядок фокуса через збереження змісту та можливості керування. Для проєкту корисно намалювати цей маршрут прямо на макеті: логотип, основні пункти, кнопка звернення, наступний елемент сторінки. Якщо фокус несподівано перестрибує між віддаленими зонами, перевірте порядок елементів у коді, а не лише їхнє візуальне розташування. Погодьте очікувану послідовність до додавання анімації.
Зробіть фокус помітним
Фокус показує, який елемент зараз отримає дію з клавіатури. За поясненням Focus Visible, його індикатор має залишатися видимим, поки елемент у фокусі. Не прибирайте стандартний контур без помітної заміни. У посібнику зі стилізації меню окремо розглядаються фокус і поточна сторінка: це різні стани. Для власного макета підготуйте обидва одночасно. Наприклад, підкреслення може позначати відкритий розділ, а виразна рамка показувати поточну позицію клавіатури.
Підменю має відкриватися навмисно
Не залишайте наведення миші єдиним способом відкрити вкладені посилання. WAI радить передбачити керування підменю та передавати його відкритий або закритий стан через aria-expanded. Для звичайної навігації не потрібно автоматично додавати роль menu. У прикладі disclosure-навігації WAI кнопки працюють через Enter і пробіл, а Escape закриває підменю та повертає фокус на його кнопку. Це конкретний шаблон поведінки, який треба перевірити у власній реалізації, а не просто скопіювати як готове рішення.
Пройдіть один реальний маршрут
- Відкрийте головну сторінку та відкладіть мишу. Знайдіть перший пункт меню клавішею Tab.
- Перейдіть до «Послуг», відкрийте підменю та виберіть одну сторінку. Повторіть шлях у зворотному напрямку.
- Закрийте підменю, знову відкрийте його та перевірте, де з’являється фокус після кожної дії.
- Повторіть маршрут у вузькому вікні та зі збільшенням сторінки. Залиште видимими наявні повідомлення й закріплені панелі.
Окремо перевірте перекриття: WAI застерігає від повного приховування сфокусованого елемента вмістом сторінки. Також користувач повинен мати можливість вийти з компонента за допомогою клавіатури. Звичайне меню не має безкінечно утримувати його всередині.
Фіксуйте поведінку, а не загальне враження
Корисний запис для виправлення містить адресу сторінки, браузер, ширину вікна, послідовність клавіш і очікуваний результат. Замість «меню незручне» напишіть: «Після закриття підменю фокус зникає, наступне натискання Tab починає маршрут заново». Така конкретика спрощує повторну перевірку. Цей короткий сценарій допомагає знайти проблеми навігації, але не замінює повного оцінювання доступності та сам собою не підтверджує відповідність WCAG.