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 поясняет, что речь идёт о предотвращении серьёзных, трудно исправимых ошибок, например массовой потери данных, а не о подтверждении каждой правки.