Клієнт бачить «Невірні дані», але не знає, яке поле виправити. Власник бачить незавершену заявку, але не знає, чи людину зупинили ціна, незрозумілий формат дати або недоступна кнопка. ШІ може допомогти переписати текст форми. Однак гарна чернетка не перевіряє, чи форму можна пройти клавіатурою або скринрідером.
Цей матеріал — для невеликого готелю, сервісної майстерні чи іншого бізнесу, який приймає запити через сайт. Результат роботи — погоджені тексти полів і сценарії перевірки для підрядника. Це редакційний робочий процес, не сертифікація доступності та не обіцянка більшої кількості заявок.
Спочатку зафіксуйте, що форма справді робить
Не починайте із запиту «зроби форму дружньою». Випишіть її призначення одним реченням: наприклад, «надіслати запит щодо ремонту, не забронювати підтверджений час». Потім звірте з відповідальним за послугу кожне поле та правило перевірки.
Для робочого реєстру використайте такі колонки:
| Поле реєстру | Що записати |
|---|---|
| Код поля | Стабільний ідентифікатор, наприклад request-date |
| Навіщо запитуємо | Яка дія потребує цієї інформації |
| Обов’язковість | Погоджене правило, а не припущення ШІ |
| Прийнятні дані | Реальний формат і обмеження системи |
| Тексти | Назва поля, підказка, окремі повідомлення про помилки |
| Після надсилання | Фактичний результат і погоджений наступний крок |
| Власник і версія | Хто підтверджує правило та коли його перевірено |
Якщо команда не може пояснити потребу в полі, спочатку перегляньте процес. ШІ не повинен додавати дату народження, адресу чи обов’язковий телефон лише тому, що такі поля трапляються в інших формах. Для редагування текстів використовуйте вигадані приклади, а не експорт справжніх заявок.
Розділіть назву, підказку та помилку
Назва відповідає на питання «що сюди ввести», підказка уточнює потрібний формат до введення, помилка пояснює конкретну проблему після перевірки. Не просіть модель вмістити всі три функції в один декоративний рядок.
W3C WAI рекомендує пов’язувати назви з елементами форми. Видимий текст поруч із полем і його програмний зв’язок із цим полем — не одне й те саме. Для звичайних HTML-полів підрядник зазвичай використовує елемент label і відповідний ідентифікатор.
Настанови WAI щодо інструкцій пояснюють, що текст усередині порожнього поля — placeholder — не замінює назву. Він зникає під час введення. Обов’язковість і потрібні формати мають бути зрозумілими; інструкції також потрібно зробити доступними допоміжним технологіям.
Практичне завдання для ШІ тут вузьке: запропонувати формулювання за вже погодженими правилами, не змінювати правила та не створювати код без окремої перевірки.
Приклад: запит до майстерні, а не готове бронювання
Нижче — вигаданий приклад, не тест реального сайту. Припустімо, майстерня приймає запит через форму з обов’язковими полями «Електронна пошта для відповіді», «Тип послуги» та «Бажана дата». Телефон необов’язковий. Система приймає дату у форматі день.місяць.рік, а час візиту підтверджує працівник окремо.
Для порожнього поля дати чернетка може бути такою: «Вкажіть бажану дату». Для запису у неправильному форматі: «Вкажіть бажану дату у форматі день.місяць.рік». Це різні ситуації; універсальне «Щось пішло не так» не пояснює потрібної дії.
Кнопка «Надіслати запит» точніша за «Забронювати», якщо бронювання не відбувається. Після підтвердженого приймання системою можна показати: «Запит отримано. Дату й час візиту ще не підтверджено». Не додавайте «відповімо за 15 хвилин», якщо бізнес не погодив і не забезпечує такого строку.
Якщо сервіс недоступний, це не помилка дати клієнта. GOV.UK Design System відрізняє проблеми введених даних від проблем послуги, які користувач не може виправити. Для нашого прикладу команда має окремо погодити повідомлення про збій і перевірений альтернативний спосіб звернення. Не повідомляйте, що запит отримано, коли система цього не підтвердила.
Дайте ШІ обмежене завдання
Можна використати такий редакційний шаблон:
Підготуй українські тексти форми лише за наданим реєстром полів. Для кожного коду поверни назву, коротку підказку, повідомлення для порожнього обов’язкового поля та для кожного підтвердженого правила перевірки. Не додавай полів, вимог, строків відповіді, способів зв’язку або обіцянки бронювання. Відділи помилки введення від збою сервісу. Якщо правило не визначене, напиши «Потрібне рішення відповідального». Окремо запропонуй текст кнопки й повідомлення після фактично підтвердженого приймання. Нічого не публікуй.
Попросіть також перелік розбіжностей: наприклад, підказка називає телефон необов’язковим, але система без нього не пропускає. Це питання для власника процесу, а не привід доручити моделі самостійно обрати правило. Загальний принцип докладніше описаний у матеріалі про запит як робочий бриф.
Перевірте мову — потім реалізацію
За порадами WAI щодо текстів, короткі речення, зрозумілі слова та пояснення незнайомих скорочень допомагають зробити зміст яснішим. Скорочуйте бюрократичне формулювання, але не вилучайте важливу умову. Якщо є українська й англійська форми, перевіряйте однаковість правил, а не лише граматику перекладу.
WAI рекомендує повідомляти про результат надсилання і давати зрозумілий шлях виправлення помилок. Підряднику передайте не просто файл із текстом, а перевірні сценарії:
- Порожнє обов’язкове поле отримує відповідне повідомлення.
- Запис неправильного формату викликає саме погоджену помилку.
- Необов’язкове поле можна залишити порожнім.
- Успішне надсилання й збій показують різні, правдиві результати.
- Клієнт може знайти проблемне поле й виправити його.
Пройдіть форму як задачу клієнта
На тестовій версії попросіть відповідального пройти всю послідовність клавіатурою, без миші: дістатися полів, зробити вибір, надіслати, знайти помилку та виправити її. Перевірте видимий фокус, логічний порядок переходів і відсутність місця, з якого неможливо вийти. Зі збільшеним текстом переконайтеся, що назви й повідомлення не перекривають поля. Це початкові перевірки, не повний аудит; WAI прямо обмежує висновки Easy Checks.
Для скринрідера залучіть людину, яка вміє ним користуватися. Перевірте, що вона отримує назву, підказку, стан поля та результат дії. WAI радить поєднувати участь користувачів з перевіркою стандартів: успіх однієї людини не доводить доступності для всіх.
Збережіть версію форми, сценарій, пристрій, браузер, допоміжну технологію, спостереження й відповідального за виправлення. Невиконаний тест позначайте «не перевірено», а не «пройдено». ШІ може впорядкувати цей журнал, але не підмінити спостереження.
Висновок: почніть з однієї форми й погодженого реєстру її правил. ШІ готує варіанти тексту; людина підтверджує зміст, підрядник перевіряє реалізацію, користувачі допомагають знайти бар’єри. Доступність не виникає від самого переписування.
Автор: Надалі. Підготовлено за допомогою ШІ. Першоджерела перевірено 28 жовтня 2026 року. Надалі не тестувала описану вигадану форму. Обкладинка — ШІ-ілюстрація умовних бланків, не зображення перевіреної форми.
