Контактную форму нельзя заполнить с клавиатуры: практическая проверка доступности

Проверяйте доступность контактной формы, проходя весь путь заявки без мыши: доберитесь до полей, введите данные, исправьте ошибку и получите понятный результат отправки. Если фокус исчезает или сообщение об ошибке не указывает поле для исправления, форму нельзя принять только потому, что она отправляется мышью.

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

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

Определите начало и завершение проверки формы

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

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

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

Руководство W3C WAI по формам охватывает подписи, инструкции, валидацию и уведомления пользователя. Основы доступности форм. Эти части нужно оценивать вместе: технически достижимое поле всё ещё может быть непонятным.

Можно ли выполнить все действия с клавиатуры

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

Критерий WCAG о клавиатуре относится к использованию функциональности через клавиатурный интерфейс с точно определёнными исключениями. Объяснение Keyboard. Кнопке или выбору в контактной форме обычно нет оснований быть доступными только по клику мыши. Разработчику нужно устранить причину, а не добавить совет «используйте мышь».

Запишите первое место, где продолжение невозможно. Например, фокус достигает поля даты, но календарь нельзя закрыть или выбрать дату. В сообщении о дефекте нужны нажатые клавиши и наблюдаемый результат. «Форма недоступна» — слишком широкая задача для точного исправления.

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

Видимый фокус показывает, где произойдёт действие

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

В тесте отличайте невидимый фокус от неправильного порядка. В первом случае элемент может быть достигнут, но индикатор не виден. Во втором фокус может перескакивать между несвязанными местами. Запись экрана с последовательностью клавиш помогает разработчику понять, что исправлять.

Проверьте форму также при открытом сообщении об ошибке, закреплённом заголовке или панели уведомлений внизу. Индикатор фокуса может существовать, но активное поле — быть перекрыто. Не оценивайте только исходный пустой экран формы.

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

Подпись должна быть связана с полем

Видимый текст над полем ввода не всегда означает техническую связь. W3C рекомендует идентифицировать элемент с помощью корректно связанной подписи. В стандартной HTML-форме это часто делают через label и идентичность поля. Руководство по подписям полей.

Текст placeholder исчезает при вводе и не заменяет полноценную подпись. Пользователь должен по-прежнему понимать, что вводится в поле. Пояснение о формате или обязательности должно быть доступно у соответствующего поля. Одного цвета или визуального расположения недостаточно.

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

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

Сообщение об ошибке должно помогать вернуться к задаче

После неподходящего ввода пользователь должен знать, что не принято и что исправить. Руководство W3C по уведомлениям объясняет сообщения об ошибках и успешном результате. User Notifications. Одна красная рамка не передаёт всю нужную информацию.

В практическом тесте используйте одно ошибочное поле. Проверьте, называет ли сообщение проблему и можно ли добраться до исправления клавиатурой. Если используется сводка ошибок, проверьте её ссылки. Если фокус переводится в ошибочное поле, убедитесь, что контекст не теряется. Одно решение не становится автоматически обязательным для всех форм: оно должно работать в конкретном пути.

Сохраняйте правильно введённые данные там, где это безопасно. Если после одной ошибки исчезает всё описание или статус вложения, человеку приходится начинать заново. Для чувствительных полей возможны особые ограничения, поэтому поведение нужно определить осознанно и ясно объяснить.

Технический сбой отправки нужно отличать от неправильного ввода. «Проверьте форму» не помогает, если сервер не отвечает. Пользователю нужны понятный статус и следующее действие без необходимости вслепую многократно отправлять одну заявку.

Шаги ручного теста и ожидаемый результат

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

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

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

Чего не доказывает автоматическая проверка

Инструмент может найти технические проблемы и помочь повторять отдельные проверки. Но сам по себе он не подтверждает, что подпись понятна человеку, порядок логичен, а восстановление после ошибки практически выполнимо. Пустой список ошибок нужно читать вместе с областью проверки.

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

Приоритет исправления определяйте по возможности завершить ключевое действие. Полностью недостижимая кнопка отправки или застревание в меню — прямое препятствие. Косметические различия оценивайте отдельно, не теряя критический путь заявки.

Приёмка исправления и дальнейшая поддержка

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

Команде нужен небольшой воспроизводимый тест, а не только общее требование в проекте. Свяжите его с путём заявки, чтобы разработчик, редактор и заказчик понимали, что считается готовым. Отличайте фактический результат от ещё не проверенных сочетаний сред.

Достаточно добавить атрибуты ARIA?

Нет. Атрибуты должны соответствовать реальному элементу и его поведению. Стандартный семантический элемент часто подходит как начало, но работу клавиатуры и уведомления всё равно нужно проверить.

После ошибки фокус всегда должен переходить к первому полю?

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

Этот тест подтверждает соответствие всего сайта?

Нет. Он охватывает выбранный путь и проверенные среды. Для полной оценки нужны более широкий охват и соответствующие требования.

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