Как подписать поля формы: метки, подсказки и сообщения об ошибках

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

Что должно получиться

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

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

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

Из чего это складывается

Сначала проверьте, нужно ли само поле

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

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

Как это сделать по шагам

1. Опишите действие посетителя. Сформулируйте, что должно произойти после заполнения. Сопоставьте с этой задачей каждое поле и уберите лишние требования через согласование с владельцем процесса.
2. Соберите фактические условия. Уточните обязательность, принимаемый формат и ограничения. Если система принимает несколько вариантов, не сужайте их текстом без причины.
3. Напишите короткие подписи. Назовите нужные данные понятными человеку словами. Не заменяйте подпись общим призывом и не заставляйте угадывать смысл по иконке.
4. Добавьте необходимые подсказки. Объясните необычный формат, назначение сведений и возможность пропуска. Разместите пояснение рядом с соответствующим полем.
5. Подготовьте сообщения об ошибках. Для каждой реальной проверки укажите, какое значение не подходит и что можно сделать. Отделите ошибку ввода от сбоя обработки.
6. Проверьте состояния. Просмотрите пустое и заполненное поле, фокус, ошибку, узкий экран и увеличение текста. Назначение должно оставаться понятным, когда пример внутри исчез.
7. Проверьте техническую связь. Убедитесь вместе с разработчиком, что подпись связана с нужным управлением, а подсказка и ошибка доступны вспомогательным технологиям.
8. Пройдите форму с человеком. Попросите объяснить, что вводить и как исправить тестовую ошибку. Записывайте непонимание, уточняйте текст и повторяйте тот же сценарий.

Как написать подпись

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

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

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

Свяжите подпись с управлением

Визуально расположить текст рядом с полем недостаточно. Для обычного HTML-поля разработчик может связать label и input через совпадающие for и id. Такая связь помогает браузеру и вспомогательным технологиям понять, к какому управлению относится название.

Условный пример пары элементов:

<label for='contact-email'>Email для ответа</label> <input id='contact-email' type='email' name='email'>

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

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

Чем подсказка отличается от примера

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

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

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

Подсказки не должны повторять очевидное

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

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

Как обозначить обязательность

Сообщите до отправки, какие поля нельзя пропустить. Если используется условный знак, объясните его значение. Один красный цвет без текста может быть непонятен, а различие только по цвету не обеспечивает доступность.

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

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

Как написать сообщение об ошибке

Начните с конкретного препятствия и доступного исправления. Вместо общего «неверно» объясните, что требуется: заполнить обязательное поле, проверить адрес или выбрать подходящий вариант. Не обвиняйте человека и не выводите внутреннее исключение программы как инструкцию.

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

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

Сохраняйте связь и возможность исправления

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

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

Частые ошибки

• Оставить только placeholder. После заполнения назначение поля перестаёт быть видно.
• Расположить подпись у чужого поля. Внешняя близость и техническая связь должны указывать на одно управление.
• Скопировать ограничения из другой формы. Текст обязан совпадать с реальными условиями текущего действия.
• Показывать одну ошибку на все случаи. Пропущенное значение, неверный формат и сбой обработки требуют разных объяснений.
• Писать только цветом. Цвет помогает заметить состояние, а текст объясняет его.
• Проверять лишь пустой макет. Заполненная форма и сообщения после ошибки могут занимать совсем другое место.

Как проверить

• По подписи понятно, какие данные нужны.
• Назначение поля остаётся понятным после ввода.
• Требования и возможность пропуска указаны заранее.
• Подсказки отвечают реальной неоднозначности и не противоречат обработке.
• Сообщение объясняет конкретную проблему и следующий шаг.
• Подписи, подсказки и ошибки связаны с нужным полем.
• Текст читается на узком экране и после увеличения.
• В тестовом сценарии человек может найти ошибку, исправить её и продолжить действие.

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

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

Для вложений отдельно проверьте загрузку файла: тип, размер и ошибки.

Вопросы и ответы

Можно ли оставить название только внутри пустого поля?

Не используйте исчезающий пример как единственную подпись. После ввода человеку всё ещё нужно понимать назначение значения. Предусмотрите доступное название и понятное визуальное обозначение поля.

Нужна ли подсказка у каждого поля?

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

Достаточно ли красной рамки для ошибки?

Рамка может привлечь внимание, но не объясняет причину. Добавьте понятное сообщение и связь с полем. Человек должен узнать, что требуется изменить, даже если не различает цветовую отметку.

Кто должен подтверждать ограничения?

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

Нужно ли показывать технический код ошибки?

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

Почему подпись выглядит правильно, а проверка доступности находит проблему?

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

Как принять работу над текстами формы?

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