Навигация с клавиатуры: проверьте свой сайт

Когда говорят «сайт должен быть доступен с клавиатуры», обычно представляют пользователя с инвалидностью. Но клавиатурой пользуются и обычные посетители: кто-то быстрее так заполняет формы, кто-то работает на ноутбуке без мышки, кто-то пришёл с экраном на 27 дюймов и не хочет тянуться к трекпаду. И главное — то же самое поведение видит ваш скринридер. Так что клавиатурный тест — это два тестa в одном.

01Почему это важно даже без разговора о доступности

Реальные ситуации, в которых клавиатура важнее мышки:

• Пользователи с инвалидностью. Кто-то не может пользоваться мышкой из-за тремора, кто-то незрячий и работает только клавиатурой через скринридер.
• Опытные пользователи. Менеджер, который оформляет десятую заявку за день, не хочет хвататься за мышку — Tab быстрее.
• Временные ограничения. Сломалась мышка, рука в гипсе, ребёнок на коленях.
• SEO и поиск. Если сайт нельзя пройти клавиатурой, его сложнее обходить и автоматизированным проверкам, и поисковому роботу — особенно если за этим стоят кастомные виджеты.

Бывает так, что красивая корзина или модальное окно «оставить заявку» вообще не открывается с клавиатуры. И вы об этом не знаете, потому что сами всегда пользуетесь мышкой.

02Базовые клавиши, которые должны работать

Чтобы тест имел смысл, договоримся о словаре. На любом сайте должны работать эти клавиши:

• Tab — переход к следующему интерактивному элементу: ссылка, кнопка, поле формы.
• Shift + Tab — то же самое, но назад.
• Enter — нажать на кнопку или перейти по ссылке.
• Пробел — нажать на кнопку, поставить или снять чекбокс.
• Стрелки — двигаться внутри радиокнопок, выпадающих списков, табов.
• Esc — закрыть модальное окно, выпадающее меню или подсказку.

Если сайт не реагирует на одну из этих клавиш в типичном сценарии — это уже находка для разработчика.

03Видимый фокус — главное правило

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

Правило простое: видимый фокус должен быть всегда. Можно сделать его аккуратным под бренд (своя обводка, своя тень), но он должен быть. Это требование WCAG и обычная вежливость к пользователю, который не видит курсора.

Если в CSS встречается outline: none без альтернативы — это красный флаг. Откройте сайт сами, понажимайте Tab и посмотрите, видно ли, где вы.

04Тест за 10 минут

Отложите мышку. Откройте сайт. Пройдите по сценариям, которые приносят заявки:

Шаг 1. Главная страница

Нажмите Tab несколько раз. Фокус виден? Он движется в логичном порядке: сначала меню, потом контент, потом подвал? Если порядок странный — «прыгает» с шапки в подвал и обратно — у вас проблема с разметкой.

Шаг 2. Меню

Дойдите Tab’ом до меню. Если есть выпадающие подменю — они открываются с клавиатуры (Enter или стрелка)? Закрываются Esc? Если выпадашка открывается только наведением мышки, для клавиатурного пользователя её просто нет.

Шаг 3. Форма заявки

Дойдите до формы. Каждое поле получает фокус? Текстовая метка читается рядом? После отправки видно сообщение об успехе или ошибке — и это сообщение хорошо заметно? Подробности — в материале «Доступность форм: метки, ошибки, подсказки».

Шаг 4. Модальное окно

Откройте любое модальное окно (заказ обратного звонка, например). Tab внутри окна остаётся внутри окна (не уходит в фон)? Esc закрывает окно? Фокус возвращается на кнопку, которая окно открыла? Если хоть на одном пункте «нет» — нужно чинить.

Шаг 5. Корзина или каталог (для e-commerce)

Можно ли добавить товар в корзину с клавиатуры? Изменить количество? Дойти до оформления? Это критично для интернет-магазинов — мы пишем об этом в обзоре маркетинга для интернет-магазинов.

05Частые проблемы и как они выглядят

• Фокус не видно. Tab нажимаете, а где курсор — непонятно. Лечится возвратом видимой обводки фокуса.
• «Невидимые» элементы получают фокус. Tab идёт по картинкам или ссылкам, которые скрыты CSS — пользователь застревает в пустоте.
• Кастомные кнопки сделаны на <div>. Tab их пропускает, Enter не работает. Нужно либо вернуть тег <button>, либо вручную добавлять tabindex и обработчики.
• Модальное окно не ловит фокус. Tab уходит на фон, пользователь теряет, где он. Это классическая ошибка кастомных модалок.
• Логотип-картинка без alt. Фокус на него встаёт, скринридер читает «IMG underscore 123». Лечится в одну строку HTML.

Эти грабли обычно лежат на сайтах, которые делали быстро и без проверки. Они одновременно бьют и по доступности, и по обычному юзабилити сайта — поэтому исправляются с двойной выгодой.

06Что делать дальше

Если тест показал проблемы, обычно нужны три вещи:

• Аудит. Разработчик или специалист по доступности проходит сайт целиком и фиксирует все находки. Параллельно прогоняется автоматическая проверка (Lighthouse, axe).
• Технические правки. Возврат видимого фокуса, замена «кнопок-дивов» на нормальные кнопки, починка модалок, корректные роли ARIA там, где без них не обойтись.
• Поддержка стандарта. При каждой новой странице и доработке проверка повторяется — иначе через полгода сайт снова «сломается» по части клавиатуры.

На сайтах малого бизнеса это редко делают отдельным проектом — экономнее закрывать в рамках общей поддержки и развития сайта.

Официальная документация по теме — Справка Яндекс.Вебмастера.