WCAG 3.3.1 Виявлення помилок
Оновлено 14 жовтня 2026 · 3 хв читання
- Рівень
- A · WCAG 2.0
- EN 301 549
- 9.3.3.1
- Що перевіряє тестер
- Ручна перевірка: автоматичний інструмент не може надійно перевірити цей критерій.
- Офіційний текст
- Understanding 3.3.1 Error Identification (W3C, англійською)
Критерій успіху 3.3.1 потрібен для того, щоб люди помічали, що форму не прийнято, і знали, яке поле неправильне. Незрячі користувачі не бачать червоної рамки, люди з порушеннями кольоросприйняття можуть її не помітити, а люди з когнітивними порушеннями можуть не зрозуміти іконку. У магазині це часто різниця між завершеним оформленням замовлення і покинутим кошиком. Це рівень A, і в EN 301 549 він є пунктом 9.3.3.1 (в Україні — ДСТУ EN 301 549:2022).
Що вимагає критерій
Якщо помилку введення виявлено автоматично, то:
- елемент із помилкою ідентифіковано, і
- помилку описано користувачеві текстом.
Помилка введення — це надана користувачем інформація, яку не прийнято. Сюди входить пропущена обов'язкова інформація та інформація поза потрібним форматом чи значеннями. WCAG не приписує, як показувати помилки. Підказку, як виправити помилку, окремо регулює 3.3.3 «Підказування в разі помилок».
Типові помилки в інтернет-магазині
- неправильне поле позначено лише червоною рамкою чи червоною іконкою, без тексту;
- оформлення замовлення перезавантажується після «Оформити замовлення» без повідомлення або лише з загальним «Щось пішло не так»;
- повідомлення з'являється вгорі сторінки, але не каже, якого поля воно стосується;
- помилки картки з платіжного віджета показано зображенням або вони зникають за кілька секунд;
- текст помилки є візуально, але не пов'язаний із полем, тож користувач програми зчитування з екрана на цьому полі його не чує.
Як перевірити
Автоматично: у нашого сканера немає правила для цього критерію. Автоматичне сканування не надсилає ваші форми з неправильними даними, тож потрібна ручна перевірка.
Вручну: для кожної важливої форми — реєстрація, вхід, розсилка, контакти, оформлення замовлення, адресна книга — надішліть її з порожніми обов'язковими полями, а потім із неправильними форматами (email без @, короткий індекс, минула дата закінчення дії картки). Переконайтеся, що кожну помилку показано текстом, вона називає поле чи вказує на нього і її зачитує програма зчитування з екрана, коли ви переходите до поля.
Як виправити
- Показуйте текстове повідомлення біля кожного неправильного поля, наприклад «Адреса email: введіть адресу на кшталт [email protected]».
- Пов'яжіть повідомлення з полем через
aria-describedbyі задайте полюaria-invalid="true". - Для довгих форм додайте вгорі підсумок помилок із посиланнями на поля і переміщуйте до нього фокус після надсилання.
- Тримайте повідомлення видимими, доки помилку не виправлено; не покладайтеся лише на колір чи іконки.
Пов'язані критерії
- 3.3.3 Підказування в разі помилок — скажіть користувачам, як виправити помилку.
- 4.1.3 Повідомлення про статус — озвучуйте помилки, що з'являються без переміщення фокуса.
- 1.4.1 Застосування кольору — колір не може бути єдиним сигналом.
Часті запитання
Чи достатньо червоної рамки, щоб показати помилку у формі?
Ні. WCAG 3.3.1 вимагає описати помилку текстом. Сам колір до того ж порушує 1.4.1 «Застосування кольору». Додайте біля поля повідомлення на кшталт «Введіть поштовий індекс».
Чи стосується 3.3.1 порожніх обов'язкових полів?
Так. Інформація, якої вимагає сторінка, але яку користувач пропустив, вважається помилкою введення, тож порожнє обов'язкове поле треба позначити й описати текстом.
Чи каже WCAG, де мають з'являтися повідомлення про помилки?
Певного способу показу не вимагається. Поширена добра практика — повідомлення біля поля, пов'язане з ним через aria-describedby, а для довгих форм — підсумок угорі форми.