Формы, которые заполняют: поля, ошибки, маски, автозаполнение

Меньше полей — меньше потерь

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

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

Если полей много объективно — например, в анкете или оформлении страховки, — форму разбивают на шаги с понятным прогрессом. Каждый шаг должен быть логически цельным: «Контакты», «Доставка», «Оплата». При этом введённые данные должны сохраняться при переходе назад — потеря заполненного шага — одна из самых раздражающих ошибок. Критерий WCAG 2.2 3.3.7 «Redundant Entry» прямо требует не заставлять человека повторно вводить то, что он уже сообщил в рамках процесса.

Подписи, плейсхолдеры и подсказки

У каждого поля должна быть видимая подпись, связанная с ним через <label for>. Плейсхолдер вместо подписи — один из самых живучих антипаттернов: текст исчезает при начале ввода, и человек, отвлёкшийся на секунду, уже не помнит, что вводит. Плейсхолдер обычно имеет низкий контраст, а скринридеры обрабатывают его непоследовательно.

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

Формат и требования объясняйте до ввода, а не после ошибки. «Пароль от 8 символов» под полем пароля экономит пользователю попытку. Такую подсказку связывают с полем через aria-describedby, чтобы её зачитывал скринридер.

Обязательные и необязательные поля нужно различать явно. Если обязательных большинство, удобнее помечать необязательные словом «необязательно» в подписи, чем расставлять звёздочки по всей форме. Звёздочка без пояснения — условность, которую понимают не все.

• Видимая подпись над полем, связанная через label.
• Плейсхолдер — только пример формата, не замена подписи.
• Требования к вводу — до ввода, через aria-describedby.
• Необязательные поля помечены словом.

Правильный тип поля и клавиатура

На мобильных устройствах тип поля определяет, какую клавиатуру увидит пользователь. type="email" показывает клавиатуру с символом @, type="tel" — цифровую панель, type="url" — клавиатуру с точкой и слэшем. Это мелочь, которая заметно снижает число ошибок и раздражение.

Для числовых данных, которые не являются числами в математическом смысле — номер карты, код из СМС, индекс, номер договора, — лучше использовать type="text" с inputmode="numeric". Поле type="number" предназначено для количеств: оно добавляет стрелки, может менять значение при прокрутке колесом мыши и отбрасывает ведущие нули.

Для дат выбор неочевиден. Нативный type="date" хорошо работает на мобильных, но выглядит по-разному в разных браузерах. Для даты рождения часто удобнее три отдельных поля или одно текстовое с маской: листать календарь на несколько десятилетий назад неудобно. Для бронирований и диапазонов, наоборот, календарь полезен, потому что пользователь видит дни недели.

Ошибки: когда и как показывать

Момент показа ошибки сильно влияет на ощущения. Валидация на каждое нажатие клавиши выглядит агрессивно: человек ещё не дописал email, а поле уже красное. Валидация только при отправке заставляет искать ошибки по всей форме. Практичный компромисс — проверять поле при потере фокуса (blur), а после того как ошибка показана, снимать её сразу при исправлении, не дожидаясь ухода из поля.

Текст ошибки должен говорить, что не так и как исправить. «Неверный формат» не помогает; «Введите email в формате name@example.com» — помогает. Ошибку располагают рядом с полем, обычно под ним, и не полагаются только на цвет: красная рамка без текста и иконки не видна людям с нарушениями цветовосприятия. WCAG 3.3.1 «Error Identification» требует описывать ошибку текстом.

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

Отдельная категория — ошибки, о которых знает только сервер: email уже зарегистрирован, промокод истёк, адрес не обслуживается. Их нужно показывать в том же месте и в том же стиле, что и клиентские, а не всплывающим окном с кодом ответа.

Маски ввода: помощь или помеха

Маска форматирует ввод на лету: телефон превращается в +7 (999) 123-45-67, номер карты разбивается на группы по четыре цифры. Хорошая маска снижает число ошибок и помогает человеку проверить введённое глазами. Плохая — ломает вставку из буфера, двигает курсор в конец при правке середины и не даёт ввести номер в привычном формате.

Правила для масок простые. Маска должна принимать вставку в любом разумном формате: с восьмёркой, с плюсом, со скобками, с пробелами — и нормализовать её. Правка в середине не должна сбрасывать курсор. Удаление символа-разделителя не должно блокировать стирание. И маска не должна запрещать ввод вариантов, которые вы не предусмотрели, если они валидны — например, международные номера, если продукт работает не только в одной стране.

Для полей с очень вариативным форматом — имя, адрес, email — маски вредны. Строгие правила вроде «только кириллица» или «имя не короче трёх букв» отсекают реальных людей с короткими, двойными или иностранными именами. Здесь лучше мягкая проверка на очевидные ошибки и доверие к пользователю.

• Принимать вставку в любом разумном формате и нормализовать.
• Не сбрасывать курсор при правке в середине.
• Не блокировать удаление разделителей.
• Не ставить маски на имена, адреса и email.

Автозаполнение: бесплатное ускорение

Браузеры и менеджеры паролей умеют подставлять имя, телефон, адрес, данные карты и одноразовые коды. Чтобы это работало, полям нужен правильный атрибут autocomplete из стандартного списка HTML: name, given-name, family-name, email, tel, street-address, postal-code, cc-number, cc-exp, one-time-code, new-password, current-password.

Это не только удобство, но и требование доступности: критерий WCAG 1.3.5 «Identify Input Purpose» уровня AA предполагает программное указание назначения полей с данными о пользователе. Для людей с моторными и когнитивными нарушениями автозаполнение может быть разницей между заполненной и брошенной формой.

Типичные ошибки: autocomplete="off" на всей форме «для безопасности», запрет вставки в поле пароля, нестандартные имена полей, которые сбивают эвристики браузера. Запрет вставки пароля мешает менеджерам паролей и подталкивает к простым паролям; WCAG 2.2 3.3.8 «Accessible Authentication» прямо называет поддержку вставки и менеджеров паролей способом соответствия.

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

Редакция Флагштока

Пишем об UX/UI-дизайне: исследования, интерфейсы, дизайн-системы и доступность.