Выделите текст, чтобы комментировать.
Клиент открыл чат, чтобы перенести доставку. Ассистент ответил правильно, нашёл заказ и предложил свободное время. Но выбрать его человек не смог: маленькие кнопки не реагировали на клавиатуру. В отчёте остался незавершённый диалог. Команда решила, что клиент передумал.
Это условная ситуация, но она показывает слепое пятно автоматизации. Обычно ИИ проверяют на точность ответа, скорость и знание продукта. Способность человека пройти весь путь от вопроса до результата остаётся за пределами проверки. Между тем полезный ответ может оказаться недоступным из-за одной кнопки, исчезнувшего сообщения или обязательного звонка.
У корпоративного ИИ две стороны качества: что он делает и как человек получает результат. В этой статье разберём вторую. Предлагаю проверять доступность на конкретной операции, например переносе записи, запросе документа или исправлении заявки. Такой подход помогает небольшому бизнесу поставить задачу подрядчику, а ИТ-команде — найти ошибки, которые не видны в тестах языковой модели.
Начните с маршрута пользователя
Доступность легко сузить до размера шрифта. Увеличить буквы полезно, но это не поможет человеку, который не видит уведомление об ошибке или не может остановить голосового помощника. Рабочая единица проверки — законченная задача со всеми переходами между экранами и каналами.
Возьмём условную компанию, которая ремонтирует технику. Клиент хочет изменить время приезда мастера. Ему нужно открыть чат, подтвердить заказ, узнать доступные интервалы, выбрать новый и получить подтверждение. Запишите эти действия отдельно. Рядом укажите, как их выполнит человек без мыши, без звука, при сильном увеличении экрана и с программой экранного доступа.
Не следует приписывать одной группе пользователей одинаковые привычки. Один незрячий человек работает на компьютере, другой пользуется телефоном. Человек со сниженным слухом может предпочитать текст, но это ничего не говорит о его зрении или моторике. Настройки и альтернативные способы взаимодействия лучше привязывать к потребности, которую пользователь выбирает сам.
Для первого прохода достаточно одной операции. Иначе команда составит длинный перечень пожеланий и не доведёт ни один путь до конца. У проверки должно быть наблюдаемое завершение: новый интервал сохранён, подтверждение доступно, прежняя запись больше не активна.
Дайте возможность управлять чатом без мыши
Проверку можно начать с простого действия: убрать мышь со стола. Попробуйте открыть виджет, перейти в поле сообщения, отправить вопрос, прочитать ответ, открыть источник и вернуться к переписке. Кнопки выбора, прикрепления файла и связи с сотрудником тоже входят в маршрут.
В критерии WCAG 2.1.1 предусмотрена работа функциональности через клавиатурный интерфейс, за исключением действий, которым по природе нужна траектория движения. Обычный выбор времени или отправка сообщения к таким исключениям не относятся. Для разработчика это проверяемое требование к интерфейсу, а не просьба сделать его удобнее по ощущениям.
Следите за фокусом — указанием того, какой элемент сейчас получает нажатия клавиш. После отправки сообщения он не должен неожиданно перескакивать в конец страницы. После закрытия окна выбора времени человеку нужно понимать, где он оказался. Если виджет перехватывает клавишу Tab и не выпускает пользователя обратно на сайт, выйти из разговора может быть сложнее, чем начать его.
Названия элементов тоже имеют значение. Три кнопки, которые программа экранного доступа произносит как «кнопка, кнопка, кнопка», не дают выбора. Подписи должны описывать действие: «Отправить сообщение», «Прикрепить файл», «Остановить ответ». Это особенно полезно там, где дизайнер оставил только пиктограмму.
Управляйте потоком ответа
Посимвольная генерация выглядит живо. Но при неудачной реализации программа экранного доступа может многократно перечитывать изменяющийся текст. Человек слышит начало предложения несколько раз, теряет предыдущий ответ и ждёт, когда интерфейс перестанет его перебивать.
Разделите события ожидания, появления содержания и завершения. Пользователю достаточно узнать, что запрос принят и ответ готовится. Дальше ему нужен управляемый доступ к тексту: чтение завершённых фрагментов или целого ответа, возможность остановить озвучивание и вернуться к нужному месту. Конкретный вариант следует проверять на используемых устройствах и программах экранного доступа.
W3C отдельно объясняет, что сообщения о статусе должны быть доступны вспомогательным технологиям без обязательного перевода фокуса. Там же отмечен риск чрезмерно разговорчивых уведомлений. Из этого не следует, что весь поток ИИ нужно объявлять срочным сообщением. Для чата разумно отдельно проектировать уведомление «ответ готов» и навигацию по самому ответу.
Предусмотрите ситуацию, когда генерация оборвалась. Надпись «Готово» не должна появляться только потому, что соединение закрылось. Если часть ответа отсутствует, сообщите об этом и дайте безопасный способ повторить запрос. Человек не обязан угадывать завершённость инструкции по последнему знаку препинания.
Сохраняйте выбор между текстом и голосом
Голосовой интерфейс помогает, когда трудно печатать. Он же создаёт препятствие, если человек не слышит ответ, находится в шумном помещении или не может говорить. Поэтому голосовой ИИ полезно проектировать вместе с текстовым способом решить ту же задачу.
Речь не о полном дублировании всего интерфейса. Важно сохранить одинаковый результат. Если по телефону можно перенести запись, текстовый канал не должен ограничиваться обещанием обратного звонка. В противном случае формально альтернатива есть, но она снова приводит к недоступному действию.
Для голосового сценария проверьте паузы. Люди говорят с разной скоростью; пауза не всегда означает, что реплика закончена. Дайте возможность повторить фразу, исправить распознанное и запросить текстовое подтверждение. Если человек говорит «нет, я имел в виду следующий четверг», система должна показать, какую дату она приняла после исправления.
Не просите пользователя доказывать причину выбора канала. Кнопки «Продолжить текстом» достаточно. Аналогично настройка крупного текста не требует вопроса о диагнозе. Компания получает необходимую для обслуживания настройку, а человек сохраняет контроль над тем, какие сведения о себе сообщать.
Пишите ответы для действия
Даже технически доступный чат может оказаться тяжёлым для чтения. Например, в ответ на вопрос о переносе записи он выдаёт шесть абзацев условий, а единственный подходящий интервал прячет в середине. Пользователь вынужден удерживать в памяти слишком много деталей.
Начинайте с информации, которая нужна на текущем шаге. В нашем примере: «Есть четверг с 14 до 16 часов. Перенести на это время?» Условия, влияющие на выбор, должны находиться рядом. Если перенос платный, размер платы нельзя прятать за ссылкой «Подробнее» после подтверждения.
Сокращение текста не должно менять смысл. Удобный приём для команды — сравнить короткий ответ с источником по трём вопросам: что пользователь может сделать, сколько это стоит и какие ограничения действуют. Если короткая версия потеряла хотя бы одно существенное условие, её нужно исправить независимо от того, насколько легко она читается.
Объясняйте ошибку через следующий шаг. Сообщение «Некорректные данные» заставляет заново перебирать весь ввод. «В номере заказа должно быть восемь цифр; вы ввели семь» позволяет исправить конкретное место. При этом не следует автоматически удалять остальной текст, который человек уже набрал.
Проверьте кнопки и увеличение экрана
У интерфейса чата обычно мало места. Поэтому второстепенные действия превращаются в маленькие значки, а панель ввода перекрывает сообщения. На большом мониторе это может не мешать. При увеличении текста или на телефоне часть пути становится недоступной.
В WCAG 2.2 критерий минимального размера цели 2.5.8 задаёт размер 24 на 24 CSS-пикселя либо выполнение предусмотренных исключений, в том числе условий расстояния между целями. Это минимальный технический ориентир, а не гарантия удобства. Для часто используемых действий стоит закладывать более просторные области нажатия и проверять их с пользователями.
Откройте чат при увеличенном масштабе. Можно ли прочитать название кнопки целиком? Осталось ли доступным поле ввода? Не закрыла ли клавиатура подтверждение? Появилась ли горизонтальная прокрутка внутри сообщения с таблицей? Иногда достаточно заменить широкую таблицу последовательностью коротких пунктов, чтобы человек мог прочитать ответ без постоянного движения в стороны.
Важное состояние передавайте словами. Оранжевая рамка сама по себе не объясняет, что заявка ещё не отправлена. Вместе с визуальным сигналом нужен понятный текст. Так интерфейс остаётся читаемым при разных настройках отображения и не заставляет запоминать значение каждого цвета.
Не потеряйте человека на авторизации
Корпоративный помощник часто требует входа: он работает с документами, заказами или кадровыми данными. Поэтому проверка доступности начинается до первого вопроса ИИ. Если пользователь не может пройти авторизацию, качество остальных ответов уже не имеет значения.
В разъяснении WCAG 3.3.8 о доступной аутентификации рассматриваются, в частности, поддержка менеджеров паролей и возможность вставить код. Запрет вставки усложняет вход для людей, которым трудно запоминать или вручную переписывать последовательности символов. Обсудите с командой безопасности способ сохранить защиту, не создавая лишних препятствий при вводе.
Проверьте истечение сессии посреди разговора. Что произойдёт с длинным сообщением, если человеку потребовалось больше времени? Можно ли войти повторно и продолжить задачу? Какие сведения допустимо сохранить на устройстве, а какие нужно удалить? Здесь нужны согласованные решения разработчика и ответственного за данные.
Не ослабляйте проверку личности только потому, что выбран альтернативный интерфейс. Доступность означает возможность выполнить предусмотренную проверку подходящим способом. Это особенно важно для операций, которые открывают доступ к конфиденциальным документам или меняют сведения о заказе.
Исправление должно быть полноценным сценарием
ИИ может неверно распознать адрес, перепутать дату или не понять короткую фразу. Поэтому доступность включает возможность остановить действие и исправить информацию. Человеку нужен явный путь назад, который не требует начинать разговор с нуля.
Перед существенным изменением покажите итог: что именно будет сделано и с какими параметрами. Для переноса записи это дата, время и адрес. Кнопки «Подтвердить» и «Изменить время» понятнее одинаковых «Да» и «Нет», особенно если пользователь возвращается к сообщению после паузы.
После исправления сообщите, какое значение действует сейчас. Старый вариант может оставаться в истории, но не должен выглядеть равнозначным новому. Если действие уже выполнено, объясните, доступна ли отмена и кто может помочь. Обещание «Я всё исправил» допустимо только после подтверждения результата системой, где хранится запись.
Передача сотруднику также требует проверки. Пользователь должен суметь вызвать человека доступным способом, узнать время ожидания и продолжить в подходящем канале. Сотруднику полезно передать содержание задачи и сделанные шаги. Предположения модели о здоровье или способностях клиента в такое резюме включать не нужно.
Проведите небольшой тест с реальными задачами
Автоматическая проверка интерфейса полезна для обнаружения части ошибок разметки. Однако она не ответит, понял ли человек, что запись перенесена, и смог ли исправить неверную дату. W3C рекомендует вовлекать пользователей в оценку доступности вместе с проверкой требований, учитывая разнообразие опыта и вспомогательных технологий.
Для первого цикла подготовьте несколько задач без подсказок о расположении кнопок. Например: перенести запись, найти подтверждение, исправить адрес и связаться с сотрудником после неудачной попытки. Используйте тестовые данные, чтобы участник не совершил реальную нежелательную операцию.
Наблюдайте за точкой затруднения. Формулировка «не смог выбрать время с клавиатуры, фокус не попадает в список» полезнее оценки «чат неудобный». Фиксируйте устройство, браузер и вспомогательную технологию: решение, работающее в одной комбинации, может требовать проверки в другой.
Не превращайте небольшое тестирование в статистическое доказательство доступности для всех. Его задача — найти конкретные препятствия и исправить их. Участников стоит приглашать с разными способами работы, заранее объяснять задачу и оплачивать их время. После изменений повторно проверяйте именно те маршруты, на которых возникли затруднения.
Закрепите доступность в поддержке продукта
Одного исправленного виджета недостаточно. Новая кнопка согласования, другой способ авторизации или обновление потоковой генерации могут снова сломать маршрут. Добавьте проверку ключевой операции в приёмку изменений и назначьте человека, который отвечает за её завершение.
Полезно считать успешность по наблюдаемому результату и способу взаимодействия, когда такие технические сведения действительно нужны и допустимы к сбору. Не пытайтесь вывести наличие инвалидности из поведения пользователя. Если человек несколько раз нажал одну кнопку, это повод исследовать интерфейс, а не присваивать ему характеристику.
Для начала выберите один частый запрос и пройдите его без мыши и звука, с увеличенным текстом и программой экранного доступа. Запишите первое место, где результат стал недостижим. Исправьте его и повторите проверку. Так требование доступности превращается в конкретную работу над продуктом: человек получает возможность закончить дело на своих условиях.
