Доступный вход с нейросетью разбирают по всему пути в существующий аккаунт. На каждом шаге нужно выяснить, требуется ли запомнить, перепечатать или решить что-либо, и какой механизм помогает пройти этот шаг. ИИ собирает наблюдения в протокол; работающий вход проверяет человек на согласованном стенде.
Что получится после упражнения?
Представьте учебный кабинет: участник вводит адрес и пароль, затем код подтверждения. Внешне всё выглядит привычно. Но если пароль можно вставить, а код приходится перепечатывать по одной цифре, удобный первый экран ещё не описывает весь путь.
Это вымышленный пример для обучения редакторов и владельцев учебных сервисов. Мы не проверяли кабинет AURMIND или систему клиента. Результат упражнения — карта шагов аутентификации с основаниями, вопросами и пустой графой фактических наблюдений. Она помогает передать специалисту конкретный дефект вместо пожелания «упростить вход».
Не передавайте нейросети настоящие пароли и коды.
Для разбора хватит искусственных обозначений полей, согласованных условий и обезличенного описания поведения. Реальный вход тестируют с разрешённой тестовой учётной записью. Защита аккаунта, выбор факторов и настройки безопасности остаются задачами ответственных специалистов.
В пояснении W3C к Accessible Authentication (Minimum) речь идёт о входе уже существующих пользователей. Создание имени пользователя и первоначальное открытие аккаунта не входят в фокус этого критерия. Поэтому в упражнении не нужно незаметно подменять вход регистрацией новой учебной заявки.
Расскажите, чему хотите научить команду. Обсудим задачи и формат обучения.
Какие требования нужно прочитать до запроса к ИИ?
Критерий 3.3.8 уровня AA не требует одного определённого способа входа. Он ограничивает обязательные проверки когнитивных функций — например, запоминание пароля или решение задачи — и перечисляет основания, при которых такой шаг допустим: альтернативный способ, помогающий механизм, распознавание объектов или распознавание предоставленного пользователем нетекстового содержимого.
У последних двух оснований есть важная граница. Они являются исключениями минимального критерия; из этого не следует, что распознавание изображений удобно каждому человеку. W3C отдельно указывает, что эти исключения отсутствуют в усиленном критерии 3.3.9 уровня AAA. Здесь разбирается минимальный уровень, без заявления о соответствии всего сервиса.
Не сокращайте это до фразы «пароли запрещены». Правильно размеченные поля и работающие механизмы помощи позволяют использовать парольный вход. Проверка должна установить, может ли человек воспользоваться этим механизмом в конкретной реализации, а не только найти знакомую надпись на экране.
Какие условия собрать у владельца кабинета?
Попросите перечислить экраны и переходы. Что появляется после успешного пароля? Бывает ли дополнительная проверка после ошибки? Предусмотрен ли другой путь для того же аккаунта? Неизвестное поведение оставляйте вопросом, а не дописывайте удобный вариант за владельца.
Для нашего условного стенда согласованы такие условия:
- Аккаунт уже существует; начальная регистрация не рассматривается.
- На первом шаге есть поля адреса и текущего пароля. Задание предусматривает вставку и заполнение менеджером паролей.
- Второй шаг принимает одноразовый учебный код. Поле должно принять код целиком при вставке; отдельного решения головоломки в условиях нет.
- После принятия кода открывается кабинет. Одного появления страницы с надписью «Добро пожаловать» недостаточно: проверяющий должен установить, что вошёл в разрешённый тестовый аккаунт.
- В отдельном варианте стенда предусмотрена ссылка входа по электронной почте. Это другая ветвь для сравнения; она не добавляется молча к парольному пути.
Это ожидания учебного задания, а не результаты испытания и не универсальная спецификация безопасности. Период действия кода, число попыток и срок действия ссылки здесь не назначены. Их нельзя вывести из требования доступности или придумать в ответе модели.
Не смешивайте механизм входа с анкетными данными. В упражнении о повторном вводе сведений речь идёт о переносе уже полученных значений между шагами заявки. Для пароля и кода в этой статье рассматривают иной результат: возможность пройти аутентификацию без обязательного перепечатывания или запоминания.
Как составить запрос к нейросети?
Передайте все условия, короткие выдержки первоисточников и желаемый формат ответа. Самих секретов в запросе быть не должно. Для кода используйте обозначение «учебный код целиком»; его действующее значение модели не нужно.
Предлагаемый запрос:
По условиям учебного кабинета ниже составь карту входа в существующий аккаунт. Для каждого шага запиши исходное состояние, требуемое действие пользователя, возможную когнитивную нагрузку, согласованный механизм помощи, способ фактической проверки и открытый вопрос. Отдели парольный путь с кодом от варианта со ссылкой по почте. Не придумывай сроки действия, настройки безопасности и результаты испытаний. Не делай вывод о соответствии всего сервиса WCAG. Графу фактического наблюдения оставь пустой. Если условия не дают ответа, напиши «требует уточнения». Сопоставь каждое нормативное объяснение с указанным первоисточником; предложения по организации упражнения пометь отдельно.
После запроса вставьте исходные условия целиком. Иначе модель может убрать второй фактор ради простоты или назвать любой код «необходимым исключением безопасности». Ни того ни другого в задании не согласовано. Ответ с такими добавлениями возвращают на уточнение.
Как выглядит карта парольного пути?
В таблице описаны ожидаемые проверки по нашему заданию. Фактические результаты появятся после работы на стенде. Слова «вставка предусмотрена» в спецификации ещё не означают «вставка работает».
| Шаг | Ожидание по условиям | Что проверить на стенде | Что нельзя заключать заранее |
|---|---|---|---|
| Адрес и пароль | Доступны вставка и заполнение менеджером | Поля принимают данные согласованными способами; вход продолжается | Разметка сама гарантирует поддержку любого менеджера |
| Код подтверждения | Код вставляется целиком | Вставить весь учебный код и проверить полный результат в поле | Несколько отдельных ячеек обязательно принимают весь код |
| Завершение входа | Открывается разрешённый тестовый аккаунт | Подтвердить состояние входа без публикации секретов | Видимый приветственный текст доказывает аутентификацию |
| Дополнительная проверка | Поведение пока не описано | Получить условия появления и способ прохождения | Ненаблюдавшаяся CAPTCHA отсутствует во всех случаях |
Последняя строка намеренно остаётся открытой. W3C поясняет, что дополнительные проверки могут появляться лишь в отдельных ситуациях, например после повторных ошибок. Если такой шаг используется, он тоже попадает в разбор критерия. Не нужно провоцировать блокировку рабочего аккаунта: безопасный способ воспроизведения согласуют со специалистом на стенде.
Проверяйте ответ модели по строкам.
Если она объявила «второй фактор не нужен», найдите условие, которое разрешало бы его убрать. Его нет. Если она заполнила фактическое наблюдение фразой «всё работает», попросите указать сохранённый результат испытания. В этом упражнении его пока тоже нет. Такие ошибки меняют статус работы, а не просто ухудшают стиль текста.
Почему важно проверить вставку кода целиком?
Пояснение W3C рассматривает ситуацию, когда одноразовый код разделён на несколько полей, а вставка заполняет только первую цифру. Внешне интерфейс может выглядеть готовым к вводу, но человек всё равно вынужден переписывать оставшиеся символы.
Для систем с кодами W3C требует учитывать возможность вставки и автозаполнения. При оценке веб-содержимого предполагается, что код уже доступен в буфере обмена пользователя; бесшовная передача между двумя устройствами выходит за рамки этой оценки. Из этого нельзя делать инструкцию пересылать действующие коды по произвольным каналам.
В нашем протоколе сначала проверяют содержимое поля после одной вставки. Затем — возможность продолжить согласованный вход. Если в поле оказался один символ вместо целого кода, запишите наблюдение именно так. Не заменяйте его общей оценкой «неудобно» и не просите ИИ восстановить недостающие цифры.
Наблюдение связывают с версией стенда, браузером, способом заполнения и конкретным шагом. Не записывайте в отчёт сам пароль или действующий код. Формат безопасных доказательств заранее согласуют ответственные за тестирование; здесь нужен след выполнения сценария, а не коллекция секретов.
Что даёт разметка полей, а что требует испытания?
Техника H100 показывает пример полей электронной почты и пароля с подписями и атрибутами автозаполнения. В её примере используются autocomplete="email" и autocomplete="current-password". Техника также требует не блокировать заполнение средствами пользователя и вставку.
Это не основание обещать поддержку любого сочетания браузера и менеджера. Для учебного отчёта разделите проверку разметки и проверку поведения. Специалист может увидеть корректные подписи в коде, а затем обнаружить обработчик, который препятствует вставке. Одно наблюдение не отменяет другое.
В процедуре H100 отдельно проверяются подходящее доступное имя каждого поля аутентификации и возможность вставки. Общая работа с подписями разобрана в материале о названиях полей формы. Здесь она нужна как часть конкретного пути входа, а не как замена проверки пароля и следующего шага.
Не начинайте с генерации готового обработчика входа. Сначала установите, что должно происходить и какие сведения пока отсутствуют. Сгенерированный код требует технической проверки безопасности и испытаний; редакторская карта не выполняет эти проверки за разработчика.
Как отдельно разобрать вход по ссылке из письма?
Техника G218 описывает вариант: пользователь вводит адрес, получает письмо, выбирает ссылку и возвращается на сайт уже вошедшим. Проверка по этой технике включает получение письма, открытие сайта по ссылке и подтверждение входа в аккаунт.
Это последовательность, а не утверждение, что любой отправленный email решает задачу.
Письмо может прийти, но ссылка вести на обычную главную страницу без входа.
Поэтому в нашей альтернативной ветви каждое из трёх наблюдений записывают отдельно. Открытый сайт ещё не означает открытый аккаунт.
Безопасность механизма не является фокусом G218. Документ упоминает ограниченный по времени токен, но не задаёт универсальную длительность. Владелец сервиса и специалист по безопасности должны согласовать реализацию; модель не назначает минуты по собственному усмотрению.
Для уровня AAA процедура G218 дополнительно проверяет отсутствие теста распознавания объектов. Не переносите это дополнительное условие на минимальный критерий как будто у него нет исключений. И наоборот, наличие исключения AA не доказывает, что любой вариант с картинками пройдёт проверку: нужно прочитать точные условия и весь путь.
Как принять учебную работу сотрудника?
Попросите сдать исходные условия, первую карту модели, исправленную версию и журнал реальных наблюдений либо явную отметку «не проверено». Для каждого дефекта должно быть понятно, какой шаг затронут и с каким ожиданием расходится реализация.
Для контроля предложите три ошибки: модель убрала код подтверждения, приняла вставку одной цифры за вставку целого кода и объявила письмо доказательством входа. Пусть сотрудник найдёт основание для исправления каждой строки. Сверять нужно смысл перехода, а не количество пунктов в ответе.
После изменения реализации повторяют затронутые сценарии. Старое наблюдение относится к прежней версии; его нельзя переносить на обновлённый путь входа автоматически. Итог этого упражнения — проверяемые вопросы и наблюдения для специалистов, без сертификата безопасности или обещания полной доступности кабинета.
Такой разбор можно включить в корпоративное обучение ИИ для редакторов и владельцев учебных продуктов. Для обсуждения программы достаточно описать роли и искусственный сценарий; доступы к рабочим аккаунтам не нужны.
Частые вопросы
Нужно ли отказываться от паролей?
Нет, из критерия 3.3.8 такой вывод не следует. В нём предусмотрены механизмы помощи, включая поддержку менеджеров паролей и вставки. Проверяют согласованный путь и фактическое поведение каждого шага.
Можно ли объявить вход доступным по одному скриншоту?
Скриншот показывает видимое состояние. Он не подтверждает вставку, работу автозаполнения и успешный переход в нужный аккаунт. Для этих утверждений нужны отдельные наблюдения на разрешённом стенде.
Относится ли упражнение к регистрации новой заявки?
Нет. Здесь разбирается аутентификация существующего пользователя. Перенос сведений между шагами заявки, ошибки полей и продление времени — отдельные задачи с другими результатами проверки.
Источники
- W3C: Understanding Accessible Authentication (Minimum) — область критерия, механизмы помощи, код подтверждения и исключения.
- W3C: H100 — пример разметки полей и процедура проверки вставки.
- W3C: G218 — вход по ссылке из письма и границы этой техники.
