WCAG 3.3.4 Недопущення помилок (юридичних, фінансових, під час уведення даних)

Критерій успіху 3.3.4 захищає людей від дорогих помилок, яких вони не можуть скасувати. Людина з порушенням читання може переставити цифри в кількості, людина з порушенням моторики — натиснути не ту кнопку, а користувач програми зчитування з екрана — не помітити, що вибрано не той розмір. Коли результат — оплачене замовлення чи видалений акаунт, наслідки цілком реальні. Це рівень AA, і в EN 301 549 він є пунктом 9.3.3.4 (в Україні — ДСТУ EN 301 549:2022).

Що вимагає критерій

Критерій застосовується до вебсторінок, які:

• створюють для користувача юридичні зобов'язання чи фінансові операції (оформлення замовлення, прийняття договору, оплата);
• змінюють чи видаляють дані, якими керує користувач, у системах зберігання даних (дані акаунта, адреси, збережені дані);
• або надсилають відповіді користувача в тесті.

Для таких сторінок має виконуватися щонайменше одна умова:

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

Критерій спрямований на серйозні помилки. Він не вимагає підтвердження для кожного збереження чи зміни.

Типові помилки в інтернет-магазині

Кожен із цих випадків є порушенням лише тоді, коли не запропоновано жодного з трьох варіантів, — наприклад, коли замовлення ще й не можна скасувати:

• кнопки «Купити зараз» чи покупки в один клік, які одразу оформлюють оплачене замовлення без кроку перевірки й без можливості скасувати;
• оформлення замовлення, де останній крок не показує товари, кількість, адресу і суму перед оплатою;
• підсумок замовлення, який не можна редагувати, — щоб змінити адресу, доводиться починати спочатку;
• «Видалити акаунт» чи «Видалити всі збережені адреси», що виконується одразу без підтвердження чи скасування;
• оформлення підписки, яке зобов'язує до регулярних платежів, не показавши умов перед підтвердженням.

Як перевірити

Автоматично: у нашого сканера немає правила для цього критерію. Він не оформлює замовлень і не видаляє даних, тож потрібна ручна перевірка.

Вручну: пройдіть процес покупки з тестовим товаром і зупиніться перед оплатою. Перевірте, чи можете ви побачити й змінити все — товари, кількість, адресу доставки, спосіб доставки, суму — перед останньою кнопкою. Потім перевірте особистий кабінет: видаліть адресу чи акаунт і подивіться, чи є підтвердження, перевірка чи скасування. Запишіть, які варіанти скасування пропонують після замовлення.

Як виправити

• Додайте крок перевірки або зробіть так, щоб останній крок оформлення показував усі деталі замовлення з посиланнями «Змінити».
• Використовуйте чітку фінальну кнопку на кшталт «Оформити й оплатити», окрему від «Продовжити».
• Просіть підтвердження перед видаленням акаунтів чи даних або пропонуйте можливість відновлення.
• Перевіряйте введене (адресу, картку, кількість) і давайте користувачам виправити це до оформлення замовлення.

Пов'язані критерії

• 3.3.1 Виявлення помилок — помилки ідентифікують текстом.
• 3.3.3 Підказування в разі помилок — користувачам кажуть, як виправити помилки.
• 3.3.7 Повторне введення даних — не змушуйте користувачів повторно вводити дані в тому самому процесі.

Часті запитання

Чи потрібна кожному оформленню замовлення сторінка перевірки?

Ні. 3.3.4 вимагає щонайменше одного з трьох варіантів: надсилання можна скасувати, дані перевіряються і користувач може їх виправити, або є спосіб переглянути й підтвердити, перш ніж завершити. Крок перевірки — один із поширених способів.

Чи стосується 3.3.4 видалення акаунта чи адреси?

Так. Сторінки, що змінюють чи видаляють дані, якими керує користувач, у системах зберігання даних, охоплено, тож видалення акаунта, збереженої адреси чи списку обраного має бути скасовним, перевіреним чи підтвердженим.

Чи вимагає 3.3.4 діалогу підтвердження для кожного збереження?

Ні. W3C пояснює, що йдеться про запобігання серйозним помилкам, які важко виправити, як-от масова втрата даних, а не про підтвердження кожної зміни.