Как проверить новый сайт с клавиатуры перед запуском

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

Для первой проверки не нужен специальный сервис. Положите мышь в сторону и пройдите ключевые страницы клавишами Tab, Shift+Tab, стрелками, Enter, пробелом и Escape. Ниже — маршрут, по которому можно принять сайт до публикации.

Начните с короткого пользовательского маршрута

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

Откройте страницу, установите курсор в адресную строку и больше не касайтесь мыши. Нажимайте Tab для движения вперёд и Shift+Tab для возврата. На каждом шаге отвечайте на три вопроса: видно ли, где находится фокус; логично ли он переместился; можно ли выполнить действие.

Фокус должен быть заметным и двигаться предсказуемо

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

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

Отдельно проверьте обратный путь. Если Shift+Tab возвращает фокус в неожиданное место или элемент приходится проходить дважды, запишите точные шаги и адрес страницы. Так разработчику будет проще воспроизвести дефект.

Меню и модальные окна проверяйте как отдельные сценарии

Кнопка меню должна получать фокус и открываться клавишей Enter или пробелом. Внутри меню перемещение зависит от выбранного паттерна: это могут быть Tab и Shift+Tab либо стрелки. Важно, чтобы способ был последовательным, все пункты были достижимы, а раскрытый блок можно было закрыть.

У модального окна проверка строже:

после открытия фокус переходит внутрь окна;
Tab не уводит его к кнопкам и ссылкам под затемнённым слоем;
Escape или видимая кнопка закрывают окно;
после закрытия фокус возвращается к кнопке, которая открыла окно;
внутренние поля и действия проходят в понятной последовательности.

Если фокус остаётся на скрытой странице, пользователь может нажать действие, которого не видит. Если выйти из окна нельзя, возникает клавиатурная ловушка.

Форму нужно не только заполнить, но и исправить

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

Затем намеренно отправьте пустую форму. Ошибка должна быть понятна не только по цвету. После сообщения об ошибке проверьте, можно ли быстро найти проблемное поле, исправить значение и повторить отправку. Наконец, заполните форму корректно и убедитесь, что подтверждение не забирает фокус в неизвестное место.

Фиксированные панели не должны прятать активный элемент

Cookie-баннер, чат, липкая шапка или нижняя кнопка могут перекрыть элемент, на который уже перешёл фокус. В WCAG 2.2 для уровня AA появилось отдельное требование: компонент с клавиатурным фокусом не должен быть полностью скрыт контентом, который разместил автор страницы.

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

Записывайте дефекты как маршрут, а не как впечатление

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

Ручной проход не подтверждает полное соответствие WCAG: для этого нужен более широкий аудит разметки, контраста, подписей, сообщений и работы с ассистивными технологиями. Но такая приёмка быстро находит критичные ошибки основной навигации до того, как их увидят посетители.

Чек-лист клавиатурной приёмки

Все ссылки, кнопки, поля и элементы управления достигаются клавишей Tab.
Из каждого элемента можно уйти вперёд и назад без ловушки.
Фокус заметен на светлом, тёмном и цветном фоне.
Переходы следуют смыслу и визуальной структуре страницы.
Меню открывается, управляется и закрывается без мыши.
Модальное окно принимает фокус и возвращает его после закрытия.
Форму можно заполнить, отправить, исправить после ошибки и отправить повторно.
Cookie-плашка, чат и липкие панели не скрывают активный элемент.
Проверены главная, ключевая услуга, контакты и основной путь заявки.
Для каждого дефекта записаны URL, браузер, размер окна и точные клавиши.

Вопросы о клавиатурной проверке сайта

Если сайт проходит клавиатурный маршрут, он уже соответствует WCAG?

Нет. Ручной проход проверяет важную часть доступности, но не охватывает все требования к разметке, контрасту, текстовым альтернативам, сообщениям и ассистивным технологиям. Его лучше использовать как обязательный этап приёмки, а не как сертификат полного соответствия.

Нужно ли добавлять фокус ко всем текстам и заголовкам?

Обычно нет. Последовательная навигация нужна прежде всего для интерактивных элементов. Лишние остановки на статическом тексте удлиняют маршрут и могут запутать пользователя.

Можно ли включить такую проверку в разработку сайта VOWE?

На странице создания сайта VOWE в состав работ включены структура, дизайн, вёрстка, программирование, запуск и дальнейшее сопровождение. Там же указано тестирование на мобильных устройствах и в разных браузерах. Требования к клавиатурным сценариям лучше отдельно зафиксировать в критериях приёмки до разработки.