Авторський аналіз і практичні рекомендації. Приклади умовні; платного замовника немає.
Відповідь рухається, інтерфейс має бути стабільним
Текст з’являється частинами. Сторінка прокручується, кнопка зупинки зміщується, а екранний читач знову починає озвучення. Модель може виконувати корисну роботу, проте інтерфейс заважає за нею стежити. Тут потрібне чітке розділення відповідальності: зміст відповіді, статус процесу й елементи керування мають різні завдання.
Це авторська методика перевірки потокових AI-інтерфейсів, а не повідомлення про запуск моделі чи сертифікація доступності. Приклади умовні. Рекомендації потрібно перевіряти з технологіями й сценаріями, якими користується твоя аудиторія.
Що встановлює стандарт
Пояснення W3C до критерію WCAG 2.2 4.1.3 говорить про програмне визначення повідомлень стану, щоб допоміжні технології могли оголошувати їх без перенесення фокуса. Короткий статус процесу відрізняється від змістовного результату завдання. Наш висновок для дизайну: відповідь і повідомлення про її готовність мають бути різними елементами.
Усю відповідь не потрібно перетворювати на термінове сповіщення. Окрема зона може повідомити про початок і завершення генерації, залишивши текст для самостійного читання. Джерело визначає принцип доступності, але не універсальну реалізацію потокового інтерфейсу.
Спочатку опиши стани
Зафіксуй стани готовності, генерації, зупинки, завершення та помилки. Для кожного потрібні зрозуміла назва й наступна дія. Виріши, чи зберігається часткова відповідь після зупинки та чи замінює її повторна спроба. Ці рішення мають передувати вибору анімації або градієнта.
Умовний дослідницький помічник під час генерації показує стабільну кнопку зупинки й позначає незавершеність тексту. Після зупинки він залишає чернетку та пропонує продовжити або почати знову. Помилка пояснює, що збережено, а завершення прибирає невизначеність без стрибка сторінки.
Оголошуй переходи, а не кожен фрагмент
Почни з окремої зони статусу та перевір ненав’язливе озвучення початку й завершення. Не додавай до цього каналу кожен фрагмент відповіді. Позначка прогресу має описувати відомий системі факт, а не вигадані кроки міркування чи відсоток без надійної основи.
Поведінку оголошень обирай за результатами спостережень. Різні браузери й екранні читачі по-різному ставлять повідомлення в чергу. Перевір коротку й довгу відповіді та обрив з’єднання. Спокійний вигляд не доводить, що озвучення також спокійне.
Збережи доступ до керування
Кнопка зупинки має залишатися доступною з клавіатури, поки текст росте. Її доступна назва повинна пояснювати дію. Не прибирай сфокусований елемент без продуманого наступного місця фокуса. Людині не потрібно починати навігацію заново після власної команди.
Окремо визнач правила прокручування. Якщо читач повернувся до попереднього абзацу, новий текст не має щоразу тягнути його вниз. Дай зрозумілий шлях до останнього фрагмента. Перевір збільшення масштабу й вузький екран, де відповідь швидко витісняє керування за межі видимої області.
Часткова відповідь — окремий стан
Перерваний текст може містити корисні думки й незавершені твердження. Познач його як чернетку. Копіювання та експорт мають зберігати розуміння цього статусу. Зупинка генерації не означає скасування зовнішньої дії, яка вже відбулася.
Відновлення тексту відрізняється від відновлення після відправленого листа чи зміненої бази даних. Інтерфейс має пояснювати, що залишилося локальним, що збережено й що підтвердив сторонній сервіс. Зникнення індикатора саме по собі не доводить доставку повідомлення.
Перевір увесь шлях
Пройди сценарій клавіатурою: надішли запит, перевір прогрес, зупини, прочитай чернетку, повтори й відновися після помилки. Повтори зі збільшенням масштабу та екранним читачем. Запиши втрату фокуса, зайві оголошення й зміни тексту під час читання.
Фіксуй конкретні умови перевірки та невирішені випадки. Один успішний сценарій не сертифікує весь продукт. Перетвори знайдену проблему на спостережувану умову приймання, наприклад збереження фокуса після зупинки. Повторюй сценарій після змін моделі чи бібліотеки компонентів.
Зроби це частиною релізу
Практичний результат — короткий опис станів для дизайну, розробки й QA. Він пов’язує видимий статус, озвучення, дію клавіатурою та відновлення. Такий контракт може залишатися стабільним навіть після заміни моделі.
Перед запуском запитай: чи може людина стежити за роботою у власному темпі? Якщо для цього потрібно бачити кожну анімацію або ловити останній фрагмент, спочатку спростіть взаємодію. Зрозумілі межі й стабільне керування корисні кожному читачеві.
Джерела та метод
Перевірено 2 листопада 2026 року. Рекомендації редакції слід перевірити у власному продукті. W3C: Understanding SC 4.1.3
Пов’язаний матеріал: Сайт уже працює. А форма звернення?