Повторный ввод данных с нейросетью разбирают по карте одного процесса: где человек уже сообщил сведения, где они понадобились снова и как сайт может предоставить прежнее значение. ИИ поручают подготовить реестр таких переходов и вопросы владельцу. Затем редактор сверяет каждую строку с исходными условиями, а специалист проверяет работающую форму. Ответ модели не подтверждает, что данные действительно сохранились.
Какой результат нужен от упражнения?
Представьте условную заявку на внутренний практикум. На первом шаге участник вводит учебное имя и адрес для материалов. На втором выбирает занятие. На третьем форма снова просит имя и тот же адрес. Подписи понятны, ошибок пока нет, но человек вынужден повторить уже выполненную работу.
Полезное действие этого материала — составить спецификацию повторного использования сведений в одном процессе. Это вымышленная учебная форма, а не описание сервиса AURMIND или клиента. Мы не публикуем результаты её испытаний и не заявляем рост конверсии. Для задания достаточно искусственных данных; реальные заявки сотрудников в чат передавать не нужно.
В пояснении W3C к Redundant Entry речь идёт о сведениях, которые человек уже ввёл или получил и которые снова требуются в том же процессе. Они должны быть заполнены автоматически либо доступны для выбора. У правила есть исключения: существенность повторного ввода, безопасность содержимого и утрата действительности прежних сведений.
Факт. Критерий 3.3.7 относится к повторному вводу в одном процессе. Он не добавляет требования хранить сведения между сеансами. Пояснение W3C отдельно проводит эту границу.
В нашей работе важно сохранить обе части: убрать необоснованный повтор и не превратить это в обещание бессрочного хранения. Полный аудит доступности, правовые основания обработки и способ защиты данных остаются отдельными задачами специалистов.
Расскажите, чему хотите научить команду. Обсудим задачи и формат обучения.
Сначала обозначьте начало и конец процесса
Задайте рамку до запроса к нейросети. В нашем примере процесс начинается с открытия новой учебной заявки и заканчивается её подтверждением. Все три шага относятся к этой заявке. Пароли, платежи, загрузка документов и возвращение после завершения сеанса в упражнение не входят.
Владелец согласовал такие условия:
- На первом шаге участник вводит имя для обращения и учебный адрес электронной почты.
- На втором выбирает одно занятие из предложенного списка. Эти сведения ещё не вводились.
- На третьем проверяет имя, адрес и занятие перед отдельным подтверждением. Имя и адрес остаются действительными на протяжении упражнения.
- Участник может вернуться к первому шагу и исправить адрес. При повторном переходе на проверку нужен исправленный адрес.
- Новая заявка после завершения текущей считается отдельным случаем. Хранение между сеансами и перенос в чужую заявку не согласованы.
Это условия задания, а не универсальные требования WCAG к любому продукту. Если в реальном процессе нужны другие сведения, сначала опишите их происхождение и назначение. Одинаково названные поля могут относиться к разным людям: адрес участника и адрес организатора нельзя автоматически считать одним значением.
Не начинайте с команды «убери все повторы».
Сначала выясните, какие данные действительно повторяются. Текст подписи помогает определить назначение, но сам по себе не доказывает тождество сведений. Если с названиями есть трудности, используйте отдельное упражнение о подписях полей. Здесь мы сравниваем происхождение и использование значений между шагами.
Как составить реестр повторного ввода?
Сохраните техническое имя, шаг получения, шаг повторного использования и ожидаемое поведение. Для нашего условного процесса получается небольшая таблица.
| Сведения | Где получены | Где нужны снова | Решение по учебным условиям |
|---|---|---|---|
| Имя участника | Первый шаг | Проверка на третьем | Показать ранее введённое имя без нового набора |
| Адрес для материалов | Первый шаг | Проверка на третьем | Показать актуальный адрес из этой заявки |
| Занятие | Второй шаг | Проверка на третьем | Показать выбранное занятие |
| Исправленный адрес | Возврат на первый шаг | Повторное открытие третьего | Заменить прежний адрес исправленным |
| Сведения другой заявки | В текущем процессе не получены | Не предусмотрены | Не подставлять; правило переноса не задано |
Последняя строка обозначает ограничение задания. Она не означает, что сведения другой заявки нужно вывести участнику как вариант. В нашем примере такой механизм не проектируется.
Попросите владельца подтвердить реестр. Если происхождение поля неизвестно, оставьте вопрос, а не готовую подстановку. Нейросеть не должна угадывать, что «контакт» означает один и тот же адрес на всех экранах.
Маленькая таблица полезнее большой карты без связей.
Для каждого повторения должно быть видно исходное значение и место назначения. В учебной записи можно использовать «Учебный участник» и адрес на зарезервированном домене example.org. Это условные значения для воспроизведения, а не данные сотрудника.
Что передать нейросети?
Дайте модели согласованные условия и реестр, не заполненную рабочую базу. Укажите, какой результат нужен: редакторская спецификация и список пробелов, а не код хранения или автоматическая настройка формы.
Предлагаемый запрос:
Разбери три шага условной учебной заявки. Составь таблицу: сведения, где получены, где снова нужны, способ предоставить прежнее значение, основание в условиях, вопрос владельцу. Не смешивай текущую заявку с другой. Не придумывай сроки хранения, личные данные, исключения безопасности и результаты тестирования. На третьем шаге требуется только проверить данные; отдельное подтверждение сохраняется. После исправления адреса на первом шаге должен использоваться исправленный адрес. Если условие неизвестно, оставь вопрос. Не создавай HTML и не утверждай соответствие всей формы WCAG.
Первый ответ сравните с исходником построчно. «Загрузим адрес из профиля» добавляет источник, которого в задании нет. «Храним сведения месяц» придумывает срок. «Автоматически отправим заявку после выбора занятия» убирает согласованное подтверждение. Такие строки нельзя принимать только потому, что они звучат удобно.
Попросите модель отдельно перечислить, что она не смогла определить. Например, поведение при закрытии вкладки в задании не согласовано. Правильный результат этой строки — вопрос владельцу о границах сеанса и восстановлении, а не обещание «ничего не потеряется».
Мнение. Для учебного разбора я предлагаю оставить первую версию таблицы рядом с исправленной. По ним видно, удержал ли сотрудник границы процесса и заметил ли выдуманный источник значения. Число вариантов ответа само по себе навыка проверки не показывает.
Автозаполнение и выбор: в чём различие?
Техника G221 показывает несколько способов предоставить сведения предыдущего шага. Среди примеров есть флажок для переноса адреса, автоматическое заполнение по предыдущим ответам и выбор созданной ранее записи со связанными данными. Это документированные варианты, а не единственный обязательный интерфейс.
Для нашего упражнения на третьем шаге достаточно показать ранее введённые сведения для проверки: новый набор не требуется. Если владелец вместо этого оставляет редактируемые поля, в спецификации нужно описать, как прежнее значение в них появляется. Нельзя считать пустое поле решением только потому, что где-то в браузере мог сохраниться адрес.
Пояснение W3C прямо говорит: функция автозаполнения браузера сама по себе не считается достаточной для Redundant Entry. Сведения должен предоставить сайт либо он должен избежать повторного запроса. Это отличается от отдельных требований к аутентификации, которые здесь не разбираются.
Не переносите это утверждение на пароли.
Пункт о повторном вводе не отменяет правила доступной аутентификации и не предписывает показывать секреты. Если в проекте появляется вход в учётную запись, выделите его в отдельную задачу специалисту по безопасности и доступности.
Вариант «доступно для выбора» также требует конкретики. В пояснении допускаются выбор и заполнение поля, копирование текста с текущей страницы и флажок переноса. Данные для такого выбора должны находиться на той же странице. В идеале они видны сразу и связаны с нужным вводом; возможен и раскрываемый блок.
Для владельца спецификации фразы «есть в системе» недостаточно. Где именно пользователь увидит значение? Как перенесёт его в нужное место? Откуда станет ясно, что это сведения текущей заявки? Ответы фиксируют до технической реализации.
Когда повторный ввод требует отдельного решения?
Исключения нельзя назначать по желанию модели. В критерии названы три основания: повторный ввод существенен, сведения необходимы для безопасности содержимого либо прежнее значение больше не действительно. Пример существенности в пояснении — игра на память, смысл которой исчезнет, если показать прошлые ответы.
В нашей учебной заявке таких оснований не задано. Поэтому модель не может объяснить пустое поле фразой «ради безопасности попросим ввести адрес заново». В реальном продукте обоснование и способ реализации проверяют ответственные специалисты. Редактор сохраняет вопрос, когда доказательств нет.
Различайте изменение значения и утрату его действительности. В нашем задании участник исправляет адрес на первом шаге. Ожидание для третьего шага известно: показать исправленный адрес. Это не повод стереть остальные сведения и попросить начать всё заново.
Если система считает прежние данные недействительными, попросите указать основание и затронутые поля. Владелец должен решить этот случай до подготовки готового поведения. Нельзя дописать произвольное правило «всё устаревает через десять минут», чтобы закрыть пробел спецификации.
Ещё одна граница — защита данных. Пояснение W3C предупреждает, что даже временное хранение при автозаполнении требует внимания к защите сведений; неудачная реализация может раскрыть персональные данные. Сам критерий не устанавливает специальных требований или исключений по приватности. Из него нельзя вывести разрешение хранить любой набор данных любым способом.
В упражнении используйте искусственные значения. Выбор хранилища, срока и условий удаления реальной информации передайте ответственным специалистам. Не просите нейросеть выдавать правовое заключение по одной таблице полей.
Как проверить возврат и исправление?
Руководство W3C по многошаговым формам рекомендует по возможности давать переход к завершённым шагам для просмотра. При таком переходе уже введённые на текущем шаге данные следует сохранять. Для нашей заявки это полезная проверка границы: возврат ради исправления адреса не должен незаметно уничтожить выбранное занятие.
Здесь это также явно закреплено учебным заданием. Мы проверяем конкретный согласованный сценарий, а не утверждаем, что один переход доказывает доступность всей формы.
Подготовьте стенд с искусственными значениями и выполните отдельные прогоны:
| Сценарий | Действия | Ожидание по заданию |
|---|---|---|
| Обычный проход | Ввести имя и адрес, выбрать занятие, открыть проверку | Все три значения показаны без повторного набора |
| Исправление | С проверки вернуться на первый шаг, изменить адрес, снова открыть проверку | Показан исправленный адрес; имя и занятие сохранены |
| Отдельное подтверждение | Открыть третий шаг, пока не нажимая подтверждение | Заявка ещё не подтверждена |
| Другая заявка | Завершить текущий процесс и открыть новую учебную заявку | Нельзя считать перенос прежних сведений согласованным; требуется отдельное решение владельца |
Последняя строка — проверка границы задания, а не готовое требование очищать или сохранять всё без разбора. Если новая заявка в реальном продукте использует профиль, её правила нужно описать отдельно. В текущем упражнении такой источник не утверждён.
В журнале укажите адрес и версию стенда, браузер, сценарий, исходные значения, ожидаемый результат и фактическое наблюдение. Не запускали проверку — оставьте наблюдение пустым и пометьте «не проверено». Текст, который модель предсказала по макету, нельзя записывать как результат испытания.
Скриншот одного шага подтверждает лишь видимую часть состояния. Для проверки исправления сохраните последовательность до изменения и после него. Если занятие пропало, запишите дефект именно этого перехода: красивый экран проверки не устраняет потерю значения.
Ошибки ввода рассматривайте отдельно. Способ объяснить неверный адрес разобран в материале о сообщениях об ошибках формы. Здесь главный вопрос другой: остались ли доступными уже полученные сведения и не заставляет ли форма набирать их снова без основания.
Что сдаёт сотрудник после разбора?
Комплект состоит из исходных условий, реестра повторных значений, первой версии ответа модели, принятой спецификации и журнала фактических проверок. Неизвестные случаи остаются вопросами с ответственным за решение. В спецификации нет придуманных сроков, источников данных и исключений.
Для контрольного задания предложите три дефекта: адрес берётся из неописанного профиля, исправление теряется на третьем шаге, выбор занятия автоматически подтверждает заявку. Первый меняет источник значения, второй нарушает актуальность, третий убирает отдельное действие участника. Пусть сотрудник назовёт исходное условие, с которым расходится каждая строка.
Работу принимают по связям и наблюдениям.
Если модель подготовила корректный реестр, редакторская часть может быть закончена. Техническая остаётся открытой до проверки работающего процесса. После исправления дефекта повторите затронутый сценарий; не переносите старое наблюдение на новую версию формы.
Такое упражнение можно включить в корпоративное обучение ИИ для редакторов и владельцев учебных сервисов. Для обсуждения программы достаточно описать роли и условный процесс; реальные заполненные заявки не требуются.
Частые вопросы
Нужно ли сохранять сведения между сеансами?
Критерий Redundant Entry сам по себе не добавляет такого требования. В статье разбирается повторное использование внутри одной заявки. Восстановление после закрытия сеанса, сроки хранения и защита данных требуют отдельного описания.
Считается ли предложение браузера готовым решением?
Нет, для этого критерия одной функции автозаполнения браузера недостаточно. Сайт должен предоставить ранее полученные сведения либо не спрашивать их повторно. Проверяют фактическое поведение процесса, а не наличие подсказки в одном браузере.
Можно ли попросить ИИ сразу написать код?
В этом упражнении нужен проверяемый реестр и согласованная спецификация. Техническую реализацию поручают специалисту после решения вопросов об источниках, границах процесса и защите данных. Сгенерированный код не заменяет испытания и сам по себе не доказывает соответствие WCAG.
Источники
- W3C: Understanding Redundant Entry — правило одного процесса, варианты предоставления значений, исключения и границы хранения.
- W3C: G221 — примеры повторного использования сведений и процедура проверки техники.
- W3C: Multi-page Forms — переход к завершённым шагам с сохранением уже введённых данных.
