Доступна валідація форм і повідомлення про помилки

Оновлено 14 жовтня 2026 · 6 хв читання

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

Відповідні критерії WCAG

3.3.1 Виявлення помилок (A): «елемент, у якому є помилка, ідентифіковано, а помилку описано користувачеві текстом». W3C додає, що колір можна використовувати, але лише додатково до тексту.
3.3.3 Підказування в разі помилок (AA): якщо помилку виявлено автоматично і відоме виправлення, запропонуйте його, якщо тільки це не поставить під загрозу безпеку чи призначення вмісту. «Адреса електронної пошти недійсна» відповідає 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 protected]</a></li>
      <li><a href="#postcode">Поштовий індекс: введіть його у форматі 01001</a></li>
    </ul>
  </div>

  <label for="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">(наприклад, 01001)</span></label>
  <input id="postcode" autocomplete="postal-code"
         aria-invalid="true" aria-describedby="postcode-hint postcode-error">
  <p id="postcode-error" class="error">Введіть поштовий індекс у форматі 01001</p>

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

Як це працює:

Текст, поруч із полем. Кожне повідомлення — видимий текст, пов'язаний через aria-describedby, тож його читають разом із полем. aria-invalid="true" позначає поле як недійсне — техніка W3C ARIA21 «Using aria-invalid to Indicate An Error Field».
Підсумок помилок після надсилання. Покажіть угорі підсумок із посиланнями на поля й перенесіть на нього фокус (він має tabindex="-1", щоб міг отримувати фокус) або перенесіть фокус на перше недійсне поле. Якщо фокус не переносите, оголосіть помилки через живу область — техніка W3C ARIA19 «Using ARIA role=alert or Live Regions to Identify Errors». Не робіть обох, інакше повідомлення прочитають двічі.
Валідація під час введення має бути м'якою: перевіряйте, коли користувач залишає поле, а не після кожного натискання клавіші, і прибирайте помилку, щойно її виправлено.
Зберігайте дані. Після невдалого надсилання зберігайте все, що ввів користувач.
Нативна валідація браузера (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