Сообщения об ошибках формы: как объяснить, что исправить
Красная рамка не объясняет, что делать дальше. Разбираем рабочую карточку ошибок и сценарии приёмки для формы обращения — без изменения реальных форм и отправки тестовых заявок.
Сначала определите, что действительно произошло
В форме могут возникнуть разные ситуации: обязательное поле пусто, значение не соответствует принятому формату или запрос не удалось отправить. Одинаковое «Ошибка» скрывает разницу и заставляет посетителя повторять действия наугад.
Представим вымышленную компанию, которая принимает запросы на аренду небольшого выставочного стенда. В форме есть имя, электронная почта, дата события и описание задачи. Это учебная модель, а не кейс Salestudia или отчёт о поведении настоящих клиентов.
Для каждого сообщения сначала запишите условие появления. Не обещайте, что адрес электронной почты существует, только потому что он прошёл проверку формата. И не сообщайте «заявка принята», если у интерфейса нет подтверждения успешной передачи. Текст должен соответствовать известному состоянию, а не удобной догадке.
Подготовьте словарь состояний до красивого текста
Соберите названия полей, обязательность, действующие ограничения и источник каждого ограничения. Иногда проблема находится не в формулировке, а в необоснованном правиле: например, поле требует телефон, хотя обращение можно обработать по электронной почте.
| Состояние | Что известно | Что согласовать |
|---|---|---|
| Пустое обязательное поле | Название поля и правило обязательности | Почему без него нельзя продолжить |
| Неподходящий формат | Какая запись поддерживается | Понятный пример и допустимые варианты |
| Недоступная дата | Источник данных о доступности | Не выдавать техническое ограничение за занятость |
| Сбой отправки | Есть ли подтверждение передачи | Правдивый следующий шаг без обещания приёма |
Не меняйте такие правила самостоятельно в рамках редакторской задачи. Вынесите вопрос владельцу процесса и разработчику. В черновике отдельно помечайте согласованные требования и предположения, чтобы временный пример не превратился в действующую проверку.
Назовите поле и конкретное действие
Вместо «Неверные данные» подготовьте короткую фразу, которая связывает проблему с полем. Например, в учебной форме: «Укажите электронную почту для ответа» при пустом обязательном поле. Это не то же самое, что сообщение о неподходящем формате уже введённого адреса.
W3C рекомендует в уведомлении указывать связанное поле, кратко объяснять ошибку и подсказывать способ исправления. Для списка ошибок полезны переходы к соответствующим полям. Эти принципы помогают готовить текст, но сама доступность зависит и от реализации интерфейса.
Для неподходящей даты в нашем примере можно написать: «Проверьте дату события: используйте формат ДД.ММ.ГГГГ». Такая фраза допустима только при действительно согласованном формате. Не добавляйте предупреждение о недоступности даты, если система проверила лишь способ записи.
Отделите помощь от обвинения
Сообщение должно описывать состояние, а не оценивать человека. «Поле пока не заполнено» и конкретная просьба полезнее фразы «Вы снова ошиблись». Избегайте внутреннего жаргона вроде «validation failed», если он ничего не объясняет аудитории.
Не превращайте ошибку в рекламное объявление или шутку. Посетитель уже решает затруднение; длинный продающий абзац мешает понять следующий шаг. Если нужен более подробный пример, отделите его от основной короткой инструкции.
Проверьте формулировки на всех языках, которые действительно поддерживает сайт. Перевод названия поля должен совпадать с видимой подписью. Нельзя обещать русскоязычный ответ только потому, что интерфейс переведён: язык обслуживания является отдельным подтверждаемым условием.
Рассмотрите место и момент сообщения
Текст рядом с полем и общая сводка выполняют разные задачи. Первый помогает понять конкретную правку, вторая — заметить, что продолжение остановилось и сколько вопросов осталось. W3C также рассматривает программную связь сообщения с полем и уведомление вспомогательных технологий о динамических изменениях.
Эти технические решения проверяет специалист в конкретной форме. Хорошая редактура не подтверждает, что сообщение будет объявлено программой чтения с экрана. Не ограничивайте приёмку снимком красной рамки: нужен работающий сценарий.
Отдельно согласуйте момент проверки. Незавершённый ввод ещё не всегда означает ошибку, которую стоит немедленно показывать. В учебном сценарии сравните поведение при входе в пустое поле, во время набора, при переходе к следующему полю и при попытке продолжить.
Составьте несколько воспроизводимых проверок
Используйте вымышленные данные и согласованный тестовый контур. Реальные обращения, подписки, платежи и бронирования не создают ради проверки редакторского текста. Если безопасная отправка не согласована, обозначьте границу и не называйте весь процесс проверенным.
| Действие | Что проверить | Чего не утверждать заранее |
|---|---|---|
| Оставить обязательное поле пустым | Указано правильное поле и следующий шаг | Что сообщение уже доступно всем технологиям |
| Исправить один из двух вопросов | Состояние обновилось без ложного успеха всей формы | Что остальные поля автоматически приняты |
| Вернуться к предыдущему полю | Понятно, что ещё требует внимания | Что один удачный проход покрывает все состояния |
| Получить сетевой сбой в тестовой среде | Нет ложного подтверждения отправки | Что письмо обязательно доставлено |
Для каждого сценария запишите исходное состояние, действие, ожидаемый текст и наблюдение. Пример ниже — задание на будущую проверку, а не результат проведённого теста.
Передайте разработчику не только готовые фразы
Рабочий пакет включает карту состояний, утверждённые тексты, условия появления, примеры и список открытых вопросов. Укажите, кто согласует требования к данным, кто внедряет поведение и кто принимает результат. Иначе красивый документ может остаться отдельно от реального интерфейса.
После исправления повторите тот же сценарий. Сохраните старое наблюдение и новый результат отдельно: «текст обновлён» не равнозначно «проблема решена». Если сбой не воспроизводится, уточните среду и последовательность действий, а не закрывайте вопрос по предположению.
Не добавляйте в журнал реальные пароли, платёжные реквизиты или чужие обращения. Для описания текстовой ошибки обычно достаточно адреса тестовой страницы, названия поля и обезличенного примера. Этот материал не задаёт правила хранения пользовательских данных.
Что получится на выходе
Результат этой работы — согласованный словарь сообщений и проверяемые сценарии, а не обещание роста конверсии или полного соответствия стандартам. Отдельно остаются техническая доставка формы, защита от спама и полноценная оценка доступности.
Salestudia — агентство цифрового маркетинга из Idstein, работающее с бизнесом по всей Германии. При подготовке сайта важно согласовывать не только страницы услуг, но и моменты, когда посетитель должен исправить или повторить действие. Объём разработки и проверки определяется по конкретной задаче.
Обложка создана ИИ: бумажные карточки условно показывают поле и подсказку, а не настоящий клиентский интерфейс. Материал W3C прочитан 1 ноября 2026 года; примеры компании, формулировки и таблицы разработаны для этой статьи.
Официальные и профильные ссылки
Эти материалы дают контекст для данных, правил и рекомендаций на странице.
- W3C WAI — User Notification Источник проверен: 01.11.2026
Часто спрашивают
Ответы уточняют объём работ, роли, зависимости и способ оценки результата.
Красной рамки достаточно?
Она может выделить поле, но не объясняет причину и способ исправления. Нужны понятный текст и проверка того, как сообщение работает в реальном интерфейсе.
Проверка формата почты подтверждает доставку?
Нет. Допустимая запись, существование адреса, успешная передача запроса и доставка сообщения — разные состояния.
Нужно менять действующую форму сразу после подготовки текста?
Нет. Сначала согласуйте правила, состояния и технический объём. Внедрение и проверка выполняются отдельно в разрешённом контуре.
Удобнее написать напрямую?
Коротко укажите компанию, рынок и задачу — так разговор будет предметнее.