Форма выглядит аккуратно и отправляет тестовую заявку мышью. Этого недостаточно для приёмки: кнопка может не получать фокус, порядок переходов — перескакивать между блоками, а ошибка — обозначаться только красной рамкой.
Проверьте один полный путь с клавиатуры: открыть форму, заполнить поля, вызвать ошибку, исправить её и получить подтверждение. Такой проход занимает меньше времени, чем полный аудит доступности, но находит блокирующие дефекты до запуска рекламы или рассылки.
Что именно проверяет проход
Критерий WCAG 2.1.1 требует, чтобы функциональность работала через клавиатурный интерфейс, кроме действий, которым действительно нужна траектория движения, например свободного рисования. Для обычной формы это означает, что пользователь может добраться до поля, выбрать вариант и отправить данные без указателя.
Отдельные критерии уточняют путь. Порядок фокуса должен сохранять смысл и работоспособность интерфейса, а индикатор фокуса — оставаться видимым. Полям нужны понятные подписи или инструкции. Если форма обнаружила ошибку, проблемное поле должно быть названо, а причина — описана текстом согласно критерию 3.3.1.
Один ручной проход не подтверждает соответствие всей страницы WCAG. Он даёт проверяемый результат для конкретного сценария: форму можно заполнить, исправить и отправить с клавиатуры.
Подготовьте реалистичный сценарий
Выберите тот путь, ради которого существует форма: заявка, подписка, регистрация или заказ. Проверяйте опубликованную версию либо тестовый контур с теми же компонентами. Не отправляйте реальные персональные данные: заранее подготовьте тестовые значения и способ отличить тестовую запись в CRM.
Запишите четыре условия приёмки:
- Каждый интерактивный элемент доступен с клавиатуры.
- Фокус движется в понятном порядке и всегда виден.
- Подписи и правила ввода остаются понятными до ошибки.
- После ошибки пользователь может найти поле, исправить значение и завершить отправку.
Если форма многошаговая, проходите весь маршрут. Проверка только первого экрана не замечает ловушки в календаре, выпадающем списке, окне согласия или подтверждении заказа.
Пройдите форму без мыши
Уберите руку с мыши и перезагрузите страницу. Начните с верхней части интерфейса, чтобы увидеть фактический вход в порядок фокуса.
Шаг 1. Двигайтесь клавишами Tab и Shift+Tab
Нажимайте Tab и вслух называйте текущий элемент: ссылка, поле, чекбокс, кнопка. Затем пройдите часть пути назад с Shift+Tab.
Фиксируйте дефект, если:
- фокус исчезает из видимой области или становится неотличим от обычного состояния;
- порядок скачет между несвязанными блоками;
- элемент пропускается, хотя с ним можно взаимодействовать мышью;
- скрытый элемент получает фокус;
- после закрытия окна фокус не возвращается к понятному месту.
Не оценивайте порядок только по координатам. WCAG допускает разные последовательности, если они сохраняют смысл и работоспособность. Практический критерий: пользователь понимает, где находится, что было до этого и что произойдёт дальше.
Шаг 2. Выполните каждое действие
На кнопках и ссылках используйте Enter; для чекбоксов и стандартных кнопок проверьте Space. У выпадающих списков и диалогов проверьте ожидаемые клавиши браузера и компонента, включая стрелки и Esc, если интерфейс обещает закрытие.
Особое внимание — элементам, собранным поверх обычных div и span. Внешне они могут выглядеть кнопками, но не получать фокус и не реагировать на клавиатуру. HTML Standard показывает формы на нативных label, input, fieldset и button; это полезная отправная точка для разработчика, хотя сама по себе нативная разметка не заменяет проверку готового сценария.
Шаг 3. Вызовите и исправьте ошибку
Отправьте пустое обязательное поле, неверный формат email или другое значение, которое форма действительно проверяет. Убедитесь, что сообщение описывает ошибку текстом и относится к конкретному полю.
Красной рамки недостаточно: пользователь должен понять, что произошло. Сообщение «Есть ошибки» тоже слабое, если не помогает найти их. Полезный результат выглядит так: фокус переходит к первой проблеме либо к сводке ошибок, поле явно названо, сообщение можно прочитать, а после исправления форма отправляется без потери остальных данных.
Один проход проверяет путь пользователя; соответствие всем требованиям WCAG требует более широкой оценки.
Таблица приёмки
| Наблюдение | Почему это мешает | Критерий исправления |
|---|---|---|
| Кнопка работает только мышью | Клавиатурный пользователь не завершает сценарий | Действие вызывается с клавиатуры и даёт тот же результат |
| Контур фокуса удалён стилями | Не видно, какой элемент активен | Фокус различим на каждом интерактивном элементе |
| Tab прыгает из контактов в согласие и обратно | Теряется связь между полем и следующим действием | Последовательность сохраняет смысл формы |
| Подсказка спрятана в placeholder | Текст исчезает после ввода и не служит устойчивой подписью | Назначение поля видно рядом или доступно программно |
| Ошибка обозначена только цветом | Причина и поле могут остаться неизвестными | Есть текст с названием поля и описанием проблемы |
| Диалог закрылся, а фокус ушёл в начало страницы | Пользователь теряет место | Фокус возвращается к кнопке вызова или другому логичному элементу |
Placeholder можно оставить примером значения, но не единственным названием поля. Для групп чекбоксов и радиокнопок проверьте общий вопрос и подпись каждого варианта. В спецификации HTML для таких групп используются fieldset и legend; конкретную связь подписи с контролом разработчик проверяет в разметке и с программой чтения с экрана.
Как передать дефект команде
Фраза «форма недоступна» не помогает воспроизвести проблему. Для каждой ошибки запишите:
- URL и ширину окна;
- браузер и операционную систему;
- точную последовательность клавиш;
- элемент, на котором ожидался результат;
- фактическое поведение;
- критерий повторной проверки.
Учебный пример: «На странице заявки после поля “Телефон” нажать Tab. Ожидание: фокус виден на чекбоксе согласия. Факт: фокус переходит на скрытую ссылку и не виден. После исправления Tab должен переводить фокус на следующий видимый интерактивный элемент, а Shift+Tab — возвращать его назад».
Скриншот показывает внешний вид, но не последовательность клавиш. Для скачущего фокуса приложите короткую запись экрана и текстовый сценарий: видео без шагов трудно повторить.
Что проверить после исправления
Повторите весь путь, а не только изменённую кнопку. Исправление tabindex, структуры DOM или поведения диалога может изменить соседние элементы. Пройдите вперёд и назад, снова вызовите ошибку и завершите отправку.
Затем проверьте форму на узкой ширине и при увеличении масштаба: видимый контур не должен скрываться под закреплённой панелью, а сообщение об ошибке — уходить за экран. Отдельно нужна проверка с программой чтения с экрана и другими вспомогательными технологиями; этот материал не подменяет её.
Если форма навязывает согласие, прячет отказ или меняет смысл действия, продолжите проверку по материалу «Тёмные паттерны в интерфейсах». А SEO-аудит WiseLab поможет проверить публичные технические сигналы страницы, но работу формы с клавиатуры нужно принимать вручную.
Для сайта в Беларуси и международного проекта сценарий одинаков: клавиатурная проверка выполняется в браузере и не зависит от доступности внешнего сервиса. Результат приёмки — не оценка «удобно», а воспроизводимый путь от первого поля до подтверждения без мыши.
Источники
Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.
Что думаете?
Загружаем комментарии…