Усі поля можуть пройти перевірку, а повідомлення все одно міститиме помилку. Адреса написана правильно, але це адреса старого офісу; у заявці обрано не ту послугу. Етап перегляду допомагає оцінити зміст відповідей, а не лише допустимість їхнього формату. Він корисний тоді, коли людина справді бачить важливе та може його виправити.
1. Співвіднесіть перевірку з наслідками
Не варто додавати окремий екран підтвердження до кожної короткої підписки. Спочатку з’ясуйте, до чого призведе помилка й чи можна реально скасувати дію. Критерій WCAG 2.2 3.3.4 стосується юридичних зобов’язань, фінансових операцій, відповідних змін або видалення збережених даних під контролем користувача та надсилання відповідей на тести. У цих межах передбачено альтернативи: можливість скасування, перевірка з можливістю виправлення або перегляд, підтвердження й виправлення перед завершенням. Однакова сторінка перевірки для всіх форм не вимагається.
Для докладної заявки на проєкт підсумок може бути доречним дизайнерським рішенням і поза цим критерієм. Проте він має допомагати, а не просто додавати ще одну зупинку.
2. Покажіть те, що людина має оцінити
Об’єднайте відповіді у зрозумілі групи: контакти, потрібні роботи, вкладення. Замість внутрішніх кодів показуйте людські назви. Збережіть важливі переноси рядків у повідомленні. Відрізняйте порожнє необов’язкове поле від свідомої відповіді «немає». Якщо дія передбачає оплату чи зобов’язання, поясніть істотні умови до остаточного підтвердження, а не лише в квитанції.
Підсумок не виправить двозначного запитання. Починайте з полів зі зрозумілим призначенням, а під час перегляду використовуйте ті самі назви. Не повторюйте конфіденційні секрети лише заради зовнішньої повноти.
3. Зробіть виправлення коротким і безпечним
Біля кожної групи дайте конкретне посилання: «Редагувати контакти» зрозуміліше за кілька однакових «Змінити». Повертайте людину до потрібних полів, не очищаючи решту. Після редагування заново формуйте підсумок із поточних відповідей, щоб на екрані не залишилася стара адреса.
Редагування не повинно випадково запускати надсилання. Перевірте доступність переходів із клавіатури та зрозуміле розташування фокуса. Якщо нове значення не пройшло валідацію, поясніть проблему біля поля й збережіть правильні відповіді. Докладніше про цей етап — у матеріалі про повідомлення про помилки, що допомагають.
4. Чесно назвіть остаточну дію
Кнопка «Далі» не має непомітно надсилати зобов’язувальну заявку. Назвіть реальну дію, наприклад «Надіслати запит», і візуально відокремте її від редагування. У багатокроковому процесі позначте поточний етап і повторіть важливі інструкції. WAI радить логічні кроки та зрозумілий прогрес, а не поділ короткої форми лише заради індикатора.
Після натискання розрізняйте надсилання та підтверджений успіх. Якщо результат невідомий, не повідомляйте про успішне отримання й не спонукайте до повторення без пояснення ризику дублювання.
5. Перевірте шлях виправлення
Пройдіть форму з довгим повідомленням, порожніми необов’язковими полями та заміненим вкладенням. Спробуйте вузький екран, збільшений текст і клавіатуру. Розуміння не повинно залежати від кольору або маленької піктограми олівця.
- Чи видно, що саме буде надіслано?
- Чи можна виправити важливу відповідь без початку спочатку?
- Чи з’являється виправлене значення в підсумку?
- Чи відрізняється надсилання від переходу далі?
- Чи відповідає повідомлення результату?
Корисна перевірка — не декоративне «Ви впевнені?», а можливість помітити й усунути помилку до того, як вона матиме наслідки.