Сообщения о статусе с нейросетью готовят по событиям приложения: что началось, что завершилось и какой результат подтверждён. Итог учебного задания — спецификация уведомлений и протокол их проверки на стенде. ИИ предлагает формулировки, а человек сверяет состояние системы и фактическое объявление сообщения программой экранного доступа.
Какую задачу решает уведомление без перевода фокуса?
Участник ищет памятку в учебном каталоге. Он нажал «Найти», продолжает работать в поле поиска, а под ним уже написано «Ничего не найдено». Человек, который видит страницу, замечает результат. Пользователь программы экранного доступа может не узнать о нём, если обновление не передано подходящим программным способом.
В пояснении W3C к Status Messages критерий относится к изменениям содержимого, сообщающим об успехе, результате действия, ожидании, ходе процесса или наличии ошибки без изменения контекста. Такие сообщения должны определяться программно через роль или свойства, чтобы вспомогательная технология могла представить их без получения фокуса.
Факт. Список найденных документов сам по себе не является сообщением о статусе по этому определению. Краткая фраза о результате поиска — другой объект. Если открылась новая страница или диалог получил фокус, границы проверки тоже меняются.
Здесь мы разбираем только ожидание, завершение и отсутствие результатов в пределах текущей страницы. Ошибки ввода рассматриваются в отдельном задании по сообщениям формы. Текущая задача — сообщить о результате асинхронной операции человеку, который остаётся на своём месте взаимодействия.
Ниже предложено авторское упражнение по работе с ИИ. Документы W3C не оценивают этот промпт или программу обучения. Все состояния каталога вымышлены; это не аудит AURMIND или клиентского продукта, не обещание соответствия всего сайта WCAG.
Расскажите, чему хотите научить команду. Обсудим задачи и формат обучения.
Зафиксируйте события до запроса к модели
Для упражнения зададим условный каталог памяток. После нажатия «Найти» запрос выполняется без перезагрузки. Фокус остаётся на кнопке поиска. При завершении система либо возвращает три документа, либо подтверждает отсутствие результатов.
Число три — заданные данные одного сценария, а не статистика реального каталога.
Тайм-аут и потерю соединения не включаем в готовые тексты: их обработку владелец задачи ещё не согласовал. Не превращайте отсутствие ответа в «Ничего не найдено».
| Событие в учебном каталоге | Подтверждённое состояние | Видимый текст | Что проверить при объявлении |
|---|---|---|---|
| Начало запроса | Поиск выполняется | Ищем памятки | Понятно, какая операция идёт |
| Ответ с тремя документами | Поиск завершён, есть три результата | Найдено памяток: 3 | Объявлен результат вместе с предметом счёта |
| Ответ с пустым списком | Поиск завершён, результатов нет | Памятки не найдены | Пустой результат отличим от ожидания |
| Ответ ещё не получен | Результат неизвестен | Готовая фраза не утверждена | Нужен вопрос владельцу о сценарии сбоя |
Последняя строка обозначает пробел в спецификации. Это не предложение показать пользователю служебную фразу «Готовая фраза не утверждена».
До решения владельца сценарий остаётся незавершённым.
Схема отделяет три согласованных события от состояния, для которого пока нет решения. Её содержание повторено в таблице. Изображение помогает обсудить границу, но не заменяет проверку работающей страницы.
Подготовьте и исходные ограничения: разрешённый стенд, версия каталога, доступный набор условных данных, ответственный за техническую реализацию.
Сотруднику, который редактирует текст, не требуется доступ к реальным поисковым журналам. Для тренировки достаточно согласованного макета событий.
Как поручить ИИ подготовку спецификации?
Полезное действие запроса — получить таблицу, которую можно сверить с событиями, а не набор эффектных уведомлений. Передайте исходные правила и попросите сохранить различие между ожиданием, пустым ответом и неизвестным результатом.
Пример поручения:
Подготовь спецификацию уведомлений условного каталога по таблице событий. Для каждой строки укажи основание, видимый текст, смысл сообщения для программы экранного доступа и вопрос владельцу, если данных недостаточно. Не добавляй сроки, проценты готовности, автоматический повтор, число результатов или гарантии. Фокус остаётся на кнопке «Найти». Не создавай HTML и не утверждай, что проверил страницу. Неизвестный ответ не называй пустым результатом. Технический способ объявления оставь специалисту.
После ответа проверьте таблицу построчно. «Почти готово, осталось несколько секунд» не следует из состояния «Поиск выполняется». «Попробуйте другой запрос» может оказаться разумным редакционным дополнением, но в данном исходнике такого следующего действия нет. Сначала согласуйте его с владельцем.
Число результатов тоже приходит из данных.
Если модель написала «Найдено 10 памяток», верните строку на исправление: в сценарии задано три.
Не исправляйте условие задним числом, чтобы ответ выглядел удачным. При реальной реализации число должно соответствовать фактическому результату, а не текстовому шаблону упражнения.
Мнение. Для разбора навыка я предлагаю сохранять первую версию ответа и короткую запись каждого исправления. По ним видно, где сотрудник удержал исходные условия, а где принял выдуманное дополнение. Количество вариантов текста не показывает качество проверки.
Чем различаются текущее состояние и журнал событий?
В технике ARIA22 описан role="status" для уведомления об обновлении состояния. У роли неявное значение aria-live="polite" и значение aria-atomic="true". При этом документ советует явно задавать aria-atomic="true", когда требуется объявлять содержимое целиком: в некоторых окружениях поведение по умолчанию отличается.
Это способ реализации, который выбирает и проверяет специалист. Редактор не подтверждает доступность, найдя слово status в ответе модели.
Для нашего каталога важно услышать «Найдено памяток: 3», а не оторванное «3». В спецификации запишите смысл объявления целиком; точная речевая форма зависит от реализации и используемой вспомогательной технологии. Проверяющий сохраняет фактически услышанное и окружение проверки.
Другой документ, ARIA23, описывает role="log" для последовательного добавления информации в историю или журнал. У этой роли неявное aria-live="polite", но aria-atomic="false".
Это отличается от объявления всего контейнера состояния.
Не назначайте журнал только потому, что операция имеет несколько этапов. В нашем задании видимый текст заменяется текущим результатом; сохраняемая история не предусмотрена. Если владелец решит вести журнал обработки файлов, потребуется другая спецификация: какие записи добавляются, в каком порядке и как называется область истории. Такая работа не выполняется механической заменой status на log.
Обе техники — документированные варианты, а не обязательный рецепт для любого компонента. Их наличие не освобождает от проверки конкретного окружения.
Составьте протокол фактического объявления
Передайте принятую таблицу специалисту. Для реализации по ARIA22 он проверяет, что контейнер с нужной ролью существует до появления сообщения, само обновление попадает внутрь него, а необходимый контекст включён в объявляемую область. Эти пункты перечислены в процедуре проверки техники.
Затем выполните каждый согласованный сценарий на стенде с программой экранного доступа. Запишите браузер, вспомогательную технологию и их версии, адрес и версию страницы. Если проверку не проводили, поле наблюдения остаётся пустым, а статус работы — «не проверено».
| Сценарий | Подготовка | Ожидание по нашему заданию | Наблюдение |
|---|---|---|---|
| Ожидание поиска | Стенд удерживает ответ после запуска | Сообщено, что идёт поиск памяток; фокус на кнопке | Заполнить после проверки |
| Три результата | Стенд возвращает заданные три документа | Сообщён предмет и число результатов; фокус на кнопке | Заполнить после проверки |
| Пустой результат | Стенд возвращает пустой список | Сообщено об отсутствии памяток; фокус на кнопке | Заполнить после проверки |
Строки — отдельные сценарии. Для каждого восстановите исходное состояние и зафиксируйте способ подготовки. Если ответ приходит мгновенно и состояние ожидания не удаётся воспроизвести, попросите разработчика подготовить управляемый тестовый случай.
Не записывайте предполагаемое объявление как услышанное.
Проверка фокуса здесь отвечает одному вопросу: не переместился ли он при уведомлении вопреки заданной спецификации? Полный маршрут переходов разбирает упражнение о порядке фокуса. Понятное объявление не доказывает, что вся клавиатурная навигация работает правильно.
Разделяйте три записи: что видно, что объявлено и где находится фокус. Скриншот подтверждает лишь часть наблюдений. Ответ ИИ по скриншоту не заменяет запуск сценария со вспомогательной технологией.
Что делать с повторными и исчезающими сообщениями?
В пояснении Status Messages отдельно рассматривается удаление текста ожидания. Зрячий человек может понять, что операция завершилась, когда исчезает «Загрузка». Для человека, который не видит экран, одного исчезновения может быть недостаточно. В нашем задании ожидание заменяется подтверждённым итогом, который тоже проверяют при объявлении.
Не добавляйте «Успешно» по таймеру.
Проверьте переход между ожиданием и результатом на том же сценарии. Если итог не поступил, это не успех. Верните незавершённый случай владельцу, сохранив фактические наблюдения. Редактор уведомлений не определяет безопасность повторной операции и не придумывает её результат.
Частые обновления требуют отдельного внимания: документ W3C предупреждает о риске чрезмерно разговорчивого интерфейса. В упражнении не нужно объявлять каждое изменение счётчика или регулярно повторять «Ищем памятки». Частоту обратной связи для реального процесса согласуют и проверяют с пользователями; универсального интервала здесь нет.
Если разработчик предлагает срочное прерывающее объявление, попросите основание. Рутинный результат поиска не становится чрезвычайным событием из-за желания «точно привлечь внимание».
Выбор механизма и приоритета передают специалисту вместе с описанием значимости события.
Как принять работу сотрудника?
Участник сдаёт исходные условия, ответ модели, принятую спецификацию и отдельный журнал испытаний. В таблице уведомлений каждый текст связан с подтверждённым событием. Неизвестные состояния вынесены в вопросы, а технические предположения не выданы за наблюдения.
Для разбора предложите три дефекта: обещание «через секунду», число без названия предмета и подмену отсутствующего ответа пустым результатом. Попросите найти основание каждой правки. Первое обещание не подтверждено исходником; во втором сообщении потерян контекст; в третьем заявлено состояние, которого система не установила.
Работу с текстом можно завершить раньше технических испытаний, но весь комплект остаётся непринятым, пока требуемые проверки не выполнены. Найденный дефект исправляют в соответствующей части и повторно проверяют зависимые сценарии. Новая формулировка может изменить объявление; перенос контейнера — его программную доступность.
Это упражнение показывает, умеет ли сотрудник использовать ИИ для подготовки проверяемой спецификации. Оно не доказывает качество любой модели, рост конверсии или соответствие продукта всем требованиям доступности.
Такое задание можно включить в корпоративное обучение ИИ для редакторов и владельцев учебных сервисов. Для обсуждения программы опишите процесс и роли проверяющих; реальные журналы пользователей и закрытые данные передавать не требуется.
Частые вопросы
Нужно ли озвучивать весь список найденных документов?
В нашем задании проверяют краткий итог поиска с названием предмета и числом. Сам список — отдельное содержимое. Его доступность и навигацию по результатам проверяют в другом объёме работ.
Можно ли считать уведомление проверенным по снимку экрана?
Нет. Снимок показывает видимый текст. Для принятия упражнения нужен протокол фактического объявления со вспомогательной технологией и проверка того, где остался фокус.
Почему нельзя заменить неизвестный результат сообщением об отсутствии памяток?
Пустой результат — подтверждённый ответ системы, а неизвестный исход означает, что такого ответа пока нет. В нашем макете правило для сбоя не согласовано: сотрудник должен передать вопрос владельцу, сохранив различие состояний.
Источники
- W3C: Understanding Status Messages — границы определения, контекст сообщения, удаление ожидания и риск избыточных объявлений.
- W3C: ARIA22 — роль status, целостное объявление и процедура проверки контейнера.
- W3C: ARIA23 — последовательные обновления журнала и различие параметров объявления.
