Сообщения об ошибках формы с нейросетью готовят по согласованным правилам ввода: модель предлагает текст, а редактор проверяет, какое поле отклонено, почему и что человек может исправить. Результат упражнения — таблица состояний после отправки и сценарии проверки. Красная рамка и фраза «Что-то пошло не так» не объясняют, как завершить действие.
Что отличает ошибку ввода от сбоя отправки?
Участник условного практикума нажал кнопку, но форма осталась на экране. Имя пустое, формат участия не выбран, а сверху появилось «Ошибка». Какой шаг ему сделать? Ввести имя, выбрать формат, ждать ответа сервера или отправить заявку ещё раз?
Сначала выясните фактическое состояние, затем просите ИИ написать фразу.
В пояснении W3C к Error Identification разобрано требование: когда ошибка ввода выявлена автоматически, ошибочный элемент нужно определить, а ошибку описать текстом. Это относится к пропущенным обязательным данным и значениям вне допустимого формата или набора. Вопрос о подсказке исправления рассматривает отдельный критерий.
Факт. Описание ошибки и подсказка исправления решают разные задачи. В пояснении к Error Suggestion речь идёт об известных способах исправления; предусмотрено исключение, если подсказка ставит под угрозу безопасность или назначение содержимого.
Документ W3C об исправлении ошибок не разрешает модели придумывать правила формы. Из «поле не принято» нельзя вывести ни требование корпоративной почты, ни срок повторной попытки. Основание каждой подсказки берут у владельца процесса.
Ниже — редакционное упражнение по применению ИИ, а не методика W3C для нейросетей. Примеры полностью вымышлены. Они не описывают форму AURMIND или клиента, не подтверждают рост конверсии и не заменяют аудит доступности всей страницы.
Разделите три ситуации. При пустом обязательном поле известно, что именно надо заполнить. При значении вне согласованного списка известны допустимые варианты. При неизвестном результате отправки нельзя утверждать ни приём, ни отказ: текст и следующий шаг согласует владелец процесса с технической командой.
Схема показывает эти три состояния. Они требуют разных оснований, даже если на экране выглядят одинаковой красной плашкой. Не поручайте нейросети угадывать состояние по одному скриншоту: изображение не доказывает, получил ли сервер данные.
Подписи до ввода разбираются в отдельном упражнении по названиям полей. Здесь подписи уже согласованы. Меняется только обратная связь после неудачной попытки.
Расскажите, чему хотите научить команду. Обсудим задачи и формат обучения.
Соберите таблицу условий и допустимых исправлений
Для учебного задания возьмём три поля и явно зададим правила. «Имя» обязательно: требуется имя для обращения, фамилия не нужна. «Формат» обязателен: разрешены только «Онлайн» и «В аудитории». «Вопрос ведущему» необязателен: в упражнении ограничение длины не задано. Реальные пользовательские записи в задании не используются.
Согласуем ещё одно условие: сообщения показываются после попытки отправки. Это выбор для нашего упражнения, а не универсальное требование для всех форм. Не добавляйте проверку на каждом нажатии клавиши только потому, что модель предложила «современный UX».
| Поле или состояние | Проверяемое условие | Текст для учебного примера | Основание |
|---|---|---|---|
| Имя | Значение пустое после отправки | Имя: введите имя для обращения | Обязательное поле; фамилия не требуется |
| Формат | Значение не выбрано | Формат: выберите «Онлайн» или «В аудитории» | Два согласованных варианта |
| Формат | Получено значение вне списка | Формат: выберите «Онлайн» или «В аудитории» | Произвольный вариант недопустим |
| Вопрос ведущему | Значение пустое | Сообщение об ошибке не требуется | Поле необязательное |
| Результат отправки неизвестен | Нет подтверждённого результата | Готовый текст не определён; нужен вопрос владельцу | Нельзя обещать приём или безопасную повторную отправку |
Третья строка пригодится при обсуждении реализации, если в систему может попасть устаревшее или подменённое значение. Она не означает, что обычный пользователь способен напечатать произвольный вариант в закрытом списке. Способ воспроизведения такого состояния определяет специалист на согласованном стенде.
Пустое необязательное поле включено намеренно.
Так команда видит не только причины отказа, но и состояние, которое не должно порождать ошибку по заданным правилам. Если ИИ написал «Заполните вопрос ведущему», найдите основание в исходнике. Его нет.
Исправлять нужно ответ, а не задним числом объявлять вопрос обязательным.
Для каждого правила запишите владельца и версию исходного задания. В небольшой тренировке достаточно даты и имени ответственного в рабочем файле. Эти служебные сведения не переносят в публичные сообщения пользователю. Таблица нужна команде, текст ошибки — человеку, который заполняет форму.
Не смешивайте поле с результатом всей операции. Фраза «Заявка не отправлена» описывает итог, но не объясняет пустое имя. А «Введите имя» не сообщает, что произошло с уже отправленной заявкой.
Когда состояние неизвестно, фиксируйте пробел отдельно от готовых формулировок.
Как поставить задачу нейросети?
Передайте согласованные условия, видимые названия полей и таблицу состояний. Для тренировки хватит условных данных. Рабочие формы, закрытые адреса и журналы заявок используйте только в разрешённом инструменте и по правилам организации. Не копируйте в запрос заполненные анкеты сотрудников.
Предлагаемый текст задания:
Подготовь сообщения после попытки отправки условной формы по правилам ниже. Для каждой строки укажи поле, причину отказа, сообщение, разрешённое исправление и основание в исходнике. Сохрани названия «Имя», «Формат» и «Вопрос ведущему». Не меняй обязательность, варианты выбора и момент показа. Не добавляй лимиты, сроки, требования фамилии или корпоративной почты. Для пустого необязательного вопроса не создавай ошибку. Если результат отправки неизвестен, сформулируй вопрос владельцу, не выдумывай статус и правило повтора. Не создавай HTML и не утверждай, что проверил работающую форму.
Это шаблон поручения, а не обещание поведения любого сервиса. Ответ читают построчно.
Сначала сверьте полноту состояний, затем смысл действия и только после этого сокращайте фразы.
Допустим, модель вернула «Имя: укажите полное имя и фамилию». Фраза звучит вежливо, но меняет правило. В исправлении оставьте имя для обращения. Если владелец действительно хочет фамилию, сначала измените согласованное задание и назначение поля. Редактор не принимает такое решение по вкусу.
Другой ответ: «Формат: выберите удобное время». Он не добавляет персональных данных, однако подменяет предмет выбора. В исходнике нет времени — есть способ участия. Откажитесь от формулировки, даже если она короче исходного варианта.
Мнение. Для первого разбора я предлагаю принимать одну формулировку с явным основанием, а не двадцать синонимов. Так видно, удержал ли сотрудник правила. Это редакционный приём, а не требование стандарта.
Не просите нейросеть «сделать ошибки дружелюбнее» без исходника. В ответе легко обсуждать тон и пропустить изменение действия. Задание «не обвиняй человека» полезно как редакционная установка, но само по себе не определяет допустимый ввод.
Сохраните исходный ответ.
При обсуждении покажите конкретную правку и её основание: «убрали фамилию, потому что требуется только имя для обращения». Такая запись помогает проверить решение без повторной генерации всей статьи или таблицы.
Как проверить причину и подсказку исправления?
Прочитайте сообщение вне макета. Можете ли вы назвать поле и допустимое действие? Для нашей формы «Неверные данные» слишком неопределённо. «Имя: введите имя для обращения» связывает сообщение с полем и объясняет, что требуется в учебном случае пустого значения.
Не объявляйте слово «неверно» запрещённым во всех интерфейсах. Важен смысл сообщения вместе с его местом и окружением. Наш критерий редакционной приёмки конкретен: по строке таблицы понятно, какое условие нарушено и какое исправление разрешено.
На схеме показан один переход: имя обязательно, поле пустое, допустимое исправление — ввести имя для обращения. Требования фамилии или паспорта в цепочке нет. Все сведения изображения повторены в тексте и таблице, поэтому схема не является единственным носителем условия.
Разберите четыре типичных подмены:
- «Обязательное поле» без названия может не объяснить, где исправлять ввод. Проверьте фактическое окружение сообщения.
- «Выберите формат» не перечисляет варианты. В нашем коротком учебном списке их можно назвать прямо; в реальной длинной форме решение согласуют с командой.
- «Слишком длинный вопрос» вводит ограничение, которого нет в задании. Такой текст отклоняют до литературной правки.
- «Попробуйте ещё раз через пять минут» выдумывает срок и безопасность повтора. Для неизвестного результата отправки такого основания нет.
Сама возможность сформулировать подсказку не означает, что её всегда можно раскрыть. Критерий3.3.3 содержит оговорку о безопасности и назначении содержимого. Поэтому не распространяйте учебный шаблон механически на вход в аккаунт, платёж или другую чувствительную операцию. Их сообщения и допустимую детализацию согласуют ответственные специалисты.
В нашем задании нет авторизации, платежей и восстановления пароля. Не добавляйте эти сценарии в ответ ради полноты: они требуют других исходных условий.
Проверка текста заканчивается не фразой «звучит понятно», а конкретной записью: поле совпадает, причина соответствует условию, действие допустимо, неподтверждённых ограничений нет. Если один пункт неизвестен, строка остаётся на согласовании. Удачная формулировка не закрывает отсутствующее правило.
Где показывать сообщение и что проверяет специалист?
Руководство W3C User Notification рассматривает общую обратную связь после отправки и сообщения возле элементов формы. В нём описан список ошибок со ссылками к соответствующим полям; также приведён способ связи поля с сообщением через aria-describedby. Это примеры реализации, а не единственная обязательная компоновка для любого интерфейса.
Для нашего упражнения согласуйте с техническим специалистом два места: краткий общий результат попытки и сообщение у каждого отклонённого поля. В общей части можно назвать число обнаруженных ошибок, но оно должно совпадать с фактическими ошибками. Если список ещё не рассчитан, модель не должна подставлять число по памяти. Для подписей переходов к полям пригодится проверка назначения ссылок: текст должен вести к нужному месту, а переход — работать в реализации.
Текст «Есть ошибки» не заменяет объяснение у поля. И наоборот: человек должен иметь возможность узнать о неудачной попытке, а не искать изменения на длинной странице. Как обеспечить это в конкретном компоненте, определяет специалист и проверяет на реализации.
Одного цвета недостаточно для разбираемого текстового описания: в пояснении W3C цвет и значки рассматриваются как дополнение к нему. В учебной проверке не принимайте только красную рамку. Сохраните точную фразу, место показа и состояние, при котором она появляется.
Редактор может сравнить видимый текст с таблицей. Проверку программной связи, перемещения фокуса, клавиатурной навигации и объявления динамического изменения поручают специалисту. Наличие атрибута в скопированном фрагменте ещё не доказывает, что нужное сообщение будет доступно в работающем компоненте.
Здесь мы не публикуем готовый HTML формы.
Цель — подготовить материал для согласованной реализации и не выдать литературную правку за техническую приёмку. Для самописного компонента, библиотечного поля и серверной страницы способы проверки могут различаться. В квитанции указывают фактический вариант и результат, а не общий ответ модели «доступность учтена».
Проверьте исправление и повторную попытку
Откройте согласованный тестовый стенд с условными данными. Не отправляйте вымышленные заявки в действующую форму организации. Сначала воспроизведите пустое обязательное имя, затем отсутствие формата и отдельно пустой необязательный вопрос. Сравнивайте наблюдаемый результат с каждой строкой таблицы.
При нескольких ошибках проверьте, что общий список и сообщения у полей описывают один набор проблем. Если исправлено только имя, сообщение о нём не должно оставаться как актуальная ошибка в нашем принятом сценарии. Формат при этом ещё может требовать выбора. Точные моменты обновления состояния заранее согласуйте с разработчиком.
Схема разделяет три проверки. Редактор сверяет текст с исходными правилами. Специалист проверяет доступность сообщения в нужном состоянии и навигацию. Затем команда повторяет попытку с исправленным вводом и убеждается, что не осталось устаревшей ошибки.
Ни один из этапов не заменяет остальные.
Сохраняйте результаты по сценариям, а не одной отметкой «проверено». Подойдёт рабочая запись: версия стенда, исходное состояние, действие, ожидаемый текст, наблюдение, проверяющий и нерешённый вопрос. Скриншот дополнит запись о видимом тексте, но не подтвердит программную связь или доставку данных на сервер.
Для состояния «результат неизвестен» заранее запросите техническое объяснение. Если такого сценария на стенде пока нет, отметьте его как непроверенный. Не имитируйте сетевой сбой на рабочем сервисе без согласованного задания и не придумывайте квитанцию успешной отправки.
Успех тоже должен опираться на фактический результат. Наш учебный пример не задаёт выдачу сертификата, срок ответа или отправку письма. Поэтому «Вы зарегистрированы, письмо придёт через минуту» нельзя принять только за бодрый тон. Сначала владелец процесса подтверждает, какой результат система действительно фиксирует и сообщает.
Как принять упражнение у сотрудника?
Выдайте исходные правила и намеренно испорченный ответ модели: обязательная фамилия, ошибка для пустого необязательного вопроса, выбор времени вместо формата и обещание повторить отправку через пять минут. Попросите сотрудника найти основание каждой фразы. Это учебные дефекты, а не реальные ошибки чьего-либо продукта.
Принять работу можно, когда таблица охватывает согласованные состояния, все тексты сохраняют правила, неизвестные статусы вынесены на согласование, а техническая проверка оформлена отдельно. Если специалист ещё не проверил реализацию, результат называется принятой редакционной спецификацией, а не готовой доступной формой.
Для разбора достаточно одной небольшой формы.
Сохраните исходник, ответ ИИ, принятую таблицу и квитанцию проверки стенда. Тогда коллега сможет восстановить, почему появилась конкретная подсказка и какое правило она объясняет. Такой навык полезен команде, которая готовит учебные регистрации и внутренние заявки; он не доказывает эффективность любой модели на любых данных.
Если хотите включить это упражнение в корпоративное обучение ИИ, опишите тип формы и роли сотрудников. Для обсуждения программы не нужны заполненные заявки и персональные данные участников.
Частые вопросы
Можно ли попросить ИИ придумать правила валидации?
В этом упражнении — нет. Он работает с уже согласованными условиями. Когда правила не хватает, результатом должен стать вопрос владельцу, а не новая обязательность или ограничение длины.
Сообщение обязательно должно стоять под полем?
W3C описывает разные способы, включая общий список и сообщения возле элементов. Конкретное решение проверяют в реализации. Важны понятное описание и доступность обратной связи, а не механическое копирование одного макета.
Можно ли подтвердить приём заявки по тексту на экране?
Текст показывает, что интерфейс сообщил пользователю. Сам по себе он не доказывает серверную запись. Владелец процесса и технический специалист определяют, на каком фактическом событии основано подтверждение.
Заменяет ли таблица ошибок аудит WCAG?
Нет. Здесь проверяется один ограниченный учебный результат. Полный объём требований и способы оценки доступности определяют отдельно; приятный текст и наличие нескольких атрибутов такого заключения не дают.
Источники
- W3C: Error Identification — выявленная ошибка, ошибочный элемент и текстовое описание.
- W3C: Error Suggestion — известные подсказки исправления и оговорка о безопасности.
- W3C: User Notification — общая обратная связь, сообщения у полей и примеры связей.
