Доступная проверка форм и сообщения об ошибках

Обновлено 14 октября 2026 г. · 6 мин чтения

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

Применимые критерии WCAG

3.3.1 Обнаружение ошибок (A): «элемент с ошибкой определён, а ошибка описана пользователю текстом». W3C добавляет, что цвет можно использовать, но только в дополнение к тексту.
3.3.3 Подсказки по исправлению ошибок (AA): если ошибка обнаружена автоматически и исправление известно, предложите его, если только это не поставит под угрозу безопасность или назначение содержимого. «Email недопустим» удовлетворяет 3.3.1; «Введите адрес в формате [email protected]» удовлетворяет ещё и 3.3.3.
3.3.2 Подписи или инструкции (A): заранее скажите, что требуется и в каком формате.
4.1.3 Сообщения о состоянии (AA): собственный пример W3C — текст «5 ошибок на странице», добавленный в форму без перемещения фокуса, — он должен объявляться. Сообщение, которое получает фокус, — это смена контекста, а не сообщение о состоянии.
3.3.4 Предотвращение ошибок (юридические, финансовые данные) (AA): заказы должны быть обратимыми, проверяемыми или подтверждаемыми, прежде чем станут окончательными.
1.4.1 Использование цвета (A), 1.4.3 Контраст (минимальный) (AA): красный текст на белом всё равно должен достигать 4,5:1.
3.3.7 Избыточный ввод (A): после ошибки не заставляйте пользователей заново вводить данные, которые они уже указали.

Пример кода

<form novalidate>
  <div id="error-summary" tabindex="-1" aria-labelledby="error-summary-title" hidden>
    <h2 id="error-summary-title">2 ошибки в форме</h2>
    <ul>
      <li><a href="#email">Email: введите адрес в формате [email protected]</a></li>
      <li><a href="#postcode">Индекс: введите его в формате 00-950</a></li>
    </ul>
  </div>

  <label for="email">Email</label>
  <input id="email" type="email" autocomplete="email"
         aria-invalid="true" aria-describedby="email-error">
  <p id="email-error" class="error">
    <span aria-hidden="true">⚠</span> Введите адрес в формате [email protected]
  </p>

  <label for="postcode">Индекс <span class="hint" id="postcode-hint">(например, 00-950)</span></label>
  <input id="postcode" autocomplete="postal-code"
         aria-invalid="true" aria-describedby="postcode-hint postcode-error">
  <p id="postcode-error" class="error">Введите индекс в формате 00-950</p>

  <button type="submit">Перейти к оплате</button>
</form>

Как это работает:

Текст рядом с полем. Каждое сообщение — видимый текст, связанный через aria-describedby, поэтому он зачитывается вместе с полем. aria-invalid="true" помечает поле как недопустимое — техника W3C ARIA21 «Использование aria-invalid для обозначения поля с ошибкой».
Сводка ошибок при отправке. Покажите сверху сводку со ссылками на поля и переместите на неё фокус (у неё tabindex="-1", чтобы она могла получить фокус) либо переместите фокус на первое недопустимое поле. Если вы не перемещаете фокус, объявите ошибки через живую область (live region) — техника W3C ARIA19 «Использование ARIA role=alert или живых областей для обозначения ошибок». Не делайте и то и другое, иначе сообщение прочитается дважды.
Встроенная проверка во время ввода должна быть мягкой: проверяйте, когда пользователь покидает поле, а не на каждое нажатие клавиши, и убирайте ошибку, как только она исправлена.
Сохраняйте данные. После неудачной отправки сохраните всё, что ввёл пользователь.
Нативная проверка браузера (required, type="email") тоже работает, но её сообщения и оформление зависят от браузера и языка; многие магазины используют novalidate и собственные сообщения на языке страницы.

Работа с клавиатуры и фокус

Действие	Ожидаемый результат
Отправка с ошибками	Фокус перемещается на сводку ошибок (или первое недопустимое поле); экранный диктор её зачитывает
Enter на ссылке в сводке	Фокус перемещается на поле; зачитываются подпись, недопустимое состояние и сообщение
Tab из поля с ошибкой (встроенная проверка)	Сообщение появляется текстом; объявляется через `aria-describedby` при повторном фокусе на поле или как сообщение о состоянии
Исправление поля	`aria-invalid` снимается; сообщение исчезает

Частые ошибки в интернет-магазинах

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

Что находит автоматика и что остаётся для ручной проверки

Автоматическая (правило axe-core)	Что находит
`label`, `select-name`	Поля без подписи
`label-title-only`	Поля, подписанные только через `title` или `aria-describedby` (рекомендация)
`form-field-multiple-labels`	Поля с более чем одной подписью
`autocomplete-valid`	Недопустимые значения `autocomplete` в полях с персональными данными (1.3.5)
`aria-valid-attr-value`	`aria-describedby`, указывающий на несуществующий ID, недопустимые значения `aria-invalid`
`color-contrast`	Текст ошибки с недостаточным контрастом, когда он виден
`frame-title`	Платёжные iframe без заголовка

Все они — карточки в нашей библиотеке правил. Автоматическая проверка видит форму в её начальном состоянии; она её не отправляет. Проверьте вручную: отправьте пустые и неверные значения, убедитесь, что каждая ошибка описана текстом, связана со своим полем, объявляется экранным диктором и читается при масштабе 200 %. С помощью расширения для браузера можно повторно запустить автоматические правила, пока ошибки на экране. Шаги описаны в материале как проверить WCAG.

Запустите бесплатную проверку одной страницы на странице оформления заказа или контактов. Это автоматическая проверка, а не полный аудит.

Частые вопросы

Что WCAG требует для ошибок форм?

3.3.1 «Обнаружение ошибок» (A): поле с ошибкой определено, а ошибка описана текстом. 3.3.3 «Подсказки по исправлению ошибок» (AA): если исправление известно, предложите его. 4.1.3 «Сообщения о состоянии» (AA): сообщения, появляющиеся без перемещения фокуса, объявляются ассистивными технологиями.

Достаточно ли красной рамки, чтобы показать ошибку?

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

Как связать сообщение об ошибке с полем?

Дайте сообщению id и сошлитесь на него из поля через aria-describedby, а на самом поле задайте aria-invalid="true" (техника W3C ARIA21). Тогда экранный диктор зачитает подпись, недопустимое состояние и сообщение.

Должен ли фокус переходить на первую ошибку?

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

Может ли автоматическая проверка проверить ошибки форм?

Она проверяет форму в начальном состоянии: подписи, значения autocomplete, корректные ссылки ARIA и контраст. Формы она не отправляет, поэтому появляются ли ошибки, описаны ли они текстом и объявляются ли, нужно проверять вручную.

Источники

W3C, Understanding 3.3.1 Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html
W3C, Understanding 3.3.3 Error Suggestion: https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html
W3C, Understanding 4.1.3 Status Messages: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html