Как вручную проверить подписи полей и сообщения об ошибках в форме регистрации

Если у вас есть форма регистрации с двумя полями — email и пароль, — ее можно быстро проверить без большого аудита. Для базовой ручной проверки достаточно ответить на пять вопросов: есть ли у каждого поля постоянная видимая подпись, понятна ли инструкция, совпадает ли доступное имя поля с этой подписью, связано ли сообщение об ошибке с конкретным полем и проходит ли сценарий с клавиатуры. Такой подход не заменяет полный аудит на соответствие WCAG, но хорошо находит самые частые поломки интерфейса.

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

Какая информация нужна пользователю поля

У каждого поля есть три разных слоя информации. Подпись говорит, что это за поле: «Email» или «Пароль». Инструкция объясняет правило ввода, если оно неочевидно: например, «Используйте адрес, к которому у вас есть доступ» или «Не менее 8 символов». Сообщение об ошибке сообщает, что именно не так: «Введите email в формате name@example.com». Эти три слоя не заменяют друг друга.

Самая частая ошибка в коротких формах — использовать placeholder как единственную подпись. Пока поле пустое, текст вроде бы виден, но после ввода он исчезает. Пользователь теряет ориентир, а в проверке доступных имен может оказаться, что у поля нет корректного названия. Для email и пароля постоянные подписи должны оставаться видимыми и до ввода, и после него.

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

Подписи и инструкции учебной формы

Для ручной проверки удобнее всего начать с минимального эталона. Ниже — учебный пример разметки для обычной HTML-страницы. В нем подписи постоянные, а инструкции вынесены в отдельный текст, на который поле ссылается через aria-describedby.

<form novalidate>
  <div>
    <label for="reg-email">Email</label>
    <p id="email-hint">Используйте адрес, к которому у вас есть доступ.</p>
    <input
      id="reg-email"
      name="email"
      type="email"
      autocomplete="email"
      aria-describedby="email-hint">
  </div>

  <div>
    <label for="reg-password">Пароль</label>
    <p id="password-hint">Не менее 8 символов.</p>
    <input
      id="reg-password"
      name="password"
      type="password"
      autocomplete="new-password"
      aria-describedby="password-hint">
  </div>

  <button type="submit">Создать аккаунт</button>
</form>

Что здесь важно проверить вручную. Во-первых, подпись связана с полем через пару for и id. Во-вторых, инструкция не спрятана внутрь поля, а существует как отдельный текст рядом. В-третьих, формулировки короткие: подпись называет поле, а инструкция объясняет только то, что реально поможет ввести данные.

После визуальной проверки полезно открыть в браузере панель доступности в DevTools и посмотреть доступное имя поля. Для email вы должны увидеть имя вроде Email, а не пустое значение и не случайный текст из placeholder. Если в дереве доступности поле названо непредсказуемо или вообще без имени, это уже достаточный повод считать проверку не пройденной.

Сообщение об ошибке и связь с полем

Хорошая ошибка отвечает на два вопроса: что произошло и как исправить ввод. Сообщение «Неверные данные» почти бесполезно: непонятно, какой именно фрагмент неверный. Для email лучше работает «Введите email в формате name@example.com», для пароля — «Пароль должен содержать не менее 8 символов». Это не полный набор правил безопасности, а понятная подсказка на уровне интерфейса.

Важно не только показать текст, но и связать его с конкретным полем. В учебной форме это можно сделать так: добавить полю aria-invalid="true" и включить идентификатор ошибки в aria-describedby. Тогда инструкция и ошибка будут относиться именно к этому вводу, а не висеть отдельно сверху страницы.

<label for="reg-email">Email</label>
<p id="email-hint">Используйте адрес, к которому у вас есть доступ.</p>
<input
  id="reg-email"
  name="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-hint email-error">
<p id="email-error">Введите email в формате name@example.com.</p>

Общее сообщение над формой может пригодиться, например «Исправьте ошибки в форме», но оно не должно заменять локальные ошибки у самих полей. Иначе пользователь видит проблему, но вынужден сам угадывать, куда именно перейти. Отдельно проверьте, не передается ли ошибка только цветом рамки: красная обводка без текста помогает не всем.

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

Учебный пример ручной проверки формы регистрации

УЧЕБНЫЙ пример. Возьмем условную форму из двух полей. В первой версии у email есть только placeholder name@example.com, у пароля есть видимая подпись «Пароль», а общая ошибка после отправки выглядит как «Проверьте данные». Локальных ошибок рядом с полями нет.

1. Проверка без ввода. Нажимаем Tab и ставим фокус в email. Видимой постоянной подписи рядом нет — первый сбой найден. Пользователь после ввода потеряет контекст, что это было за поле.
2. Проверка доступного имени. Открываем панель доступности. У email имя либо пустое, либо совпадает с placeholder. Для практической проверки это считаем провалом: у поля нет надежного названия.
3. Проверка ошибки. Вводим ivan@ в email и 123 в пароль, отправляем форму клавишей Enter. Появляется общий текст «Проверьте данные», но неясно, что именно исправлять. У email нет сообщения о формате, у пароля нет сообщения о длине.
4. Проверка клавиатурного возврата. После отправки фокус остается на кнопке. Пользователю приходится самому искать, где ошибка. Для короткой формы это уже достаточный сигнал, что сценарий нуждается в доработке.

Во второй версии формы добавляем постоянную подпись Email, инструкцию к каждому полю и локальные сообщения об ошибках. В состоянии ошибки email получает текст «Введите email в формате name@example.com», пароль — «Пароль должен содержать не менее 8 символов». Поля помечаются как невалидные, а ошибки связываются через aria-describedby.

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

Короткий протокол ручной проверки

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

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

Если хотите разбирать такие задачи глубже, в сохраненном описании каталога курса «UX/UI-дизайнер» Bang Bang Education упомянуты юзабилити-тесты, UX-копирайтинг и цифровая доступность. Для темы форм это полезное сочетание: одни навыки помогают написать понятные подписи и ошибки, другие — проверить сценарий на реальном интерфейсе, а не только на макете.