В вымышленной ситуации Виктор выбирает занятие и вводит контакт. На следующем шаге той же записи форма снова требует контакт, но не показывает прежний ответ. Виктор набирает его заново и случайно меняет одну цифру. Заявка дошла с другим номером. Сбой здесь начинается не с ошибки проверки номера: интерфейс заставил повторить уже выполненную работу.
Один процесс — два одинаковых вопроса
WCAG 3.3.7 Redundant Entry рассматривает информацию, которую нужно повторно вводить в том же процессе. Она должна подставляться автоматически либо быть доступной для выбора. Среди исключений — необходимый повторный ввод, обеспечение безопасности и данные, которые больше не действительны. Само название шага «подтверждение» не объясняет, зачем заново набирать контакт.
Виктору не нужно вспоминать, как он записал номер на предыдущем экране. В тестовой версии ему показывают прежний контакт с возможностью использовать его и исправить при необходимости. Он замечает опечатку до отправки, вместо того чтобы создавать вторую. Это вымышленная проверка интерфейса, а не измеренный рост конверсии или реальная запись клиента EVOTREN.
Подсказка браузера не заменяет данные предыдущего шага
Разработчик сначала говорит, что браузер обычно предлагает сохранённый номер. W3C поясняет, что автозаполнение браузера само по себе не считается достаточным решением этого критерия: нужные прежние сведения должен предоставлять сайт либо не спрашивать их снова. У Виктора в браузере может быть чужой или устаревший контакт. Такой список не доказывает, что процедура сохранила именно его ответ с первого шага.
Для теста используют выдуманный контакт без настоящей отправки. Проходят шаги подряд, меняют значение на первом экране и смотрят, что появится на следующем. Если там остаётся прежняя версия, простое заполненное поле ещё не означает корректный перенос. Отдельно проверяют возможность исправления: подстановка не должна превращать случайную опечатку в неизменяемый ответ.
Возвращение завтра — другой вопрос
Критерий не обязывает хранить сведения между сеансами. Поэтому из удобного переноса номера внутри записи нельзя сделать вывод «сайт обязан узнавать Виктора завтра на любом устройстве». И переход на другой домен сам по себе не завершает процесс: W3C допускает многошаговую процедуру через разные домены. Границу проверяют по реальному действию пользователя, а не только по адресной строке.
Тренер передаёт разработчику точную цепочку экранов и повторяемое поле. Если выясняется, что прежние данные перестали быть действительными или повтор нужен для безопасности, причину рассматривают отдельно. Не следует отменять проверки пароля ради сокращения кликов или выводить клиентские контакты на общую страницу. Уменьшение ввода не даёт разрешения раскрывать данные.
Не путать сохранение ответа с объяснением ошибки
Если перенесённый контакт не соответствует правилам формы, ему всё равно нужно понятное сообщение. В статье об ошибке в форме записи разобрана причина отказа и связь с полем. Это другая задача: сохранение уже введённого не делает неверный номер правильным, а красная рамка не оправдывает стирание всех остальных ответов.
В завершённой тестовой цепочке Виктор использует тот же контакт без повторного набора, видит его перед отправкой и может поправить. Получение заявки и подтверждение самого занятия проверяют отдельно. Если добавится новый шаг, цепочку проходят снова: лишний запрос контакта легко появляется при соединении двух ранее самостоятельных форм.