Валидация Html-формы: как настроить проверку данных и показать ошибки пользователю

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

Контрольные точки надежной проверки формы

• Задайте базовые ограничения средствами HTML: тип поля, обязательность и допустимый формат.
• Используйте браузерный API валидации, чтобы не дублировать правила в JavaScript без необходимости.
• Объясняйте, что именно исправить, рядом с полем и в доступной для вспомогательных технологий форме.
• Проверяйте данные на сервере независимо от результата в браузере.
• Протестируйте пустые значения, неверный формат, граничную длину и отключённый JavaScript.

Какие проверки можно задать средствами HTML

HTML-ограничения подходят для стандартных полей: электронной почты, обязательного имени, числа или текста заданной длины. Они помогают пользователю обнаружить ошибку до отправки и работают без отдельного JavaScript-кода.

Пример базовой формы:

  Электронная почта
  

  Сообщение
  

  

Атрибуты required, minlength, maxlength, min, max и pattern позволяют задать типовые правила. Указывайте для каждого поля связанную подпись через , а не полагайтесь только на текст-подсказку внутри поля.

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

Как подключить JavaScript-валидацию без дублирования правил

Для проверки HTML-формы на JavaScript обычно достаточно самой формы, браузерного API Constraint Validation и небольшого обработчика отправки. Если проект уже использует библиотеку или фреймворк, подключайте проверку в соответствии с его архитектурой, не создавая параллельные источники правил.

• У HTML-полей должны быть корректные атрибуты required, type, minlength и другие подходящие ограничения.
• JavaScript должен читать результат через checkValidity() или validity, а не повторять те же регулярные выражения и правила вручную.
• Для пользовательского сообщения можно использовать setCustomValidity(); после исправления значения его нужно сбрасывать пустой строкой.
• Если отправка зависит от сети или ответа сервера, обработчик должен корректно показывать состояние ожидания и ошибку отправки.

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

Где и как показывать ошибки, чтобы пользователь понял, что исправить

Перед настройкой учитывайте риски и ограничения:

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

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

  Электронная почта
  
  <p id="email-error" aria-live="polite"></p>

  Сообщение
  
  <p id="message-error" aria-live="polite"></p>

  

1. Оставьте правила в HTML

   Задайте ограничения прямо на полях, например required и type="email". Атрибут novalidate отключает автоматические браузерные всплывающие сообщения при отправке, но не отключает проверку через API.

2. Подготовьте место для каждого сообщения

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

3. Проверьте форму при отправке

   Вызовите checkValidity() у формы. Если проверка не пройдена, отмените отправку, найдите невалидные поля, выведите соответствующие подсказки и переведите фокус на первое поле с ошибкой.
4. Обновляйте сообщение после исправления

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

Пример обработчика:

const form = document.querySelector("#contact-form");

function messageFor(input) {
  if (input.validity.valueMissing) {
    return "Заполните это поле.";
  }

  if (input.validity.typeMismatch) {
    return "Введите адрес электронной почты в правильном формате.";
  }

  if (input.validity.tooShort) {
    return `Введите не менее ${input.minLength} символов.`;
  }

  return "Проверьте введённые данные.";
}

function updateError(input) {
  const error = document.getElementById(`${input.id}-error`);
  const invalid = !input.validity.valid;

  input.setAttribute("aria-invalid", String(invalid));
  error.textContent = invalid ? messageFor(input) : "";
}

form.addEventListener("submit", (event) => {
  const fields = [...form.querySelectorAll("input, textarea, select")];

  fields.forEach(updateError);

  if (!form.checkValidity()) {
    event.preventDefault();
    fields.find((field) => !field.validity.valid)?.focus();
  }
});

form.addEventListener("input", (event) => {
  if (event.target.matches("input, textarea, select")) {
    updateError(event.target);
  }
});

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

Как связать сообщения об ошибках с полями и сохранить доступность

Проверьте готовую форму по списку:

• У каждого поля есть видимая подпись, однозначно объясняющая, какие данные нужны.
• Сообщение расположено рядом с соответствующим полем и содержит конкретный способ исправления.
• Поле связано с сообщением через aria-describedby.
• При ошибке для поля устанавливается aria-invalid="true", а после исправления состояние сбрасывается.
• Пользователь может заполнить форму и отправить её с клавиатуры.
• Фокус после неудачной отправки перемещается к первому полю с ошибкой.
• Сообщение об ошибке доступно программам чтения с экрана и не передаётся только цветом.
• Ошибка не стирает уже введённые пользователем данные.

Не перемещайте фокус при каждом нажатии клавиши: это мешает вводу. Для проверки при наборе достаточно обновлять текст и состояние поля; перенос фокуса уместен после неудачной отправки.

Почему браузерной проверки недостаточно и что перепроверять на сервере

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

• Считать результат браузера доказательством корректности. Сервер повторно проверяет обязательность, тип, формат, длину и допустимые значения.
• Полагаться только на type="email". Проверка формата не подтверждает существование адреса или право владения им.
• Принимать произвольные значения из списка. Сервер проверяет, что переданный идентификатор действительно разрешён и доступен пользователю.
• Не ограничивать размер и состав данных. Задайте серверные пределы и отклоняйте неожиданные значения.
• Использовать введённый текст как команду или разметку. При работе с базой применяйте безопасные параметры запросов, а при выводе данных - подходящее экранирование.
• Считать скрытое поле защитой. Любые данные, отправленные браузером, могут быть изменены; проверяйте права и контекст операции на сервере.
• Не обрабатывать серверные ошибки в интерфейсе. Возвращайте понятное сообщение без раскрытия внутренних деталей и сохраняйте заполненные поля, когда это безопасно.

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

Подберите способ тестирования по назначению формы:

• Ручная проверка в браузере. Подходит для оценки текста ошибок, порядка перехода клавишей Tab, фокуса и поведения на узком экране.
• Автоматизированные тесты интерфейса. Уместны для повторяющихся сценариев: пустое обязательное поле, неверный формат, слишком короткое значение и успешная отправка.
• Проверка серверного обработчика отдельно. Отправьте запрос с некорректными данными напрямую, чтобы убедиться, что сервер не полагается на браузерную валидацию.
• Проверка доступности вспомогательными средствами. Пройдите форму клавиатурой и проверьте, что имя поля, его состояние и текст ошибки доступны при чтении страницы.

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

Практические нюансы проверки HTML-форм

Когда достаточно встроенной проверки браузера?

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

Зачем нужен атрибут novalidate?

Он отключает автоматический показ стандартных сообщений браузера при отправке формы, если интерфейс показывает собственные ошибки. Методы checkValidity() и состояние validity продолжают работать.

Как избежать повторения правил в JavaScript?

Задайте базовые ограничения HTML-атрибутами и используйте браузерный API для чтения результата. Дополнительный JavaScript добавляйте только для правил, которые нельзя выразить стандартными атрибутами.

Когда очищать сообщение об ошибке?

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

Можно ли считать поле электронной почты корректным, если браузер его принял?

Нет. Браузер проверяет формат, но не подтверждает существование адреса и владение им; для этого нужна отдельная серверная логика, если подтверждение требуется сценарием.

Что делать, если сервер обнаружил ошибку после клиентской проверки?

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

Как проверить, что валидацию нельзя обойти?

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