Порядок фокуса с нейросетью проверяют в два этапа: по согласованному описанию страницы составляют ожидаемый маршрут, затем человек проходит его с клавиатуры и записывает фактические переходы. ИИ здесь помогает подготовить сценарии. Его ответ «всё доступно» не подтверждает работу страницы.
Ниже — упражнение для команды, которая выпускает учебные материалы и передаёт технические замечания разработчику.
Что именно мы проверяем?
Откройте условную страницу практикума без мыши. Ссылка «Программа» получает фокус, затем он оказывается в поле вопроса, а кнопка «Материалы» остаётся позади. Внешне всё аккуратно, но непонятно, можно ли открыть памятку. Чтобы описать проблему, недостаточно написать «навигация неудобная».
Нужны исходное состояние, нажатая клавиша, ожидаемый переход и наблюдение.
Фокус — текущая точка взаимодействия при управлении с клавиатуры. В этом упражнении нас интересует последовательность переходов между элементами. Мы не переписываем названия полей, тексты ссылок или сообщения об ошибках. Для них есть отдельные задания: проверка назначения ссылок и подписи полей формы.
Пояснение W3C Focus Order разбирает требование сохранять смысл и работоспособность при последовательной навигации. Оно не требует единственного порядка для любой страницы. Если несколько последовательностей сохраняют смысл и позволяют работать, допустимы разные варианты; буквальное совпадение с визуальной раскладкой требуется не во всех случаях.
Факт. Красивый маршрут сверху вниз сам по себе не доказывает соответствие критерию. Важна связь переходов со смыслом и действиями на странице.
Далее предложен редакционный способ подготовки учебного задания с ИИ. Документы W3C объясняют доступность, но не оценивают нашу модель, промпт или программу обучения. Все элементы и дефекты примера вымышлены; это не результат аудита сайта AURMIND или клиента.
Полезный результат упражнения — журнал переходов, по которому специалист сможет воспроизвести конкретную проблему.
Полный аудит WCAG, разработка сложных компонентов и подтверждение соответствия всего сайта остаются отдельными задачами.
Расскажите, чему хотите научить команду. Обсудим задачи и формат обучения.
Подготовьте исходник с двумя состояниями
Не начинайте с просьбы «проверь доступность скриншота». На изображении можно увидеть подписи и расположение, но нельзя выполнить переходы. Для нашей тренировки владелец страницы заранее задаёт простую спецификацию. В рабочем случае он согласует её с разработчиком и указывает тестовый адрес и версию.
Условная страница содержит следующие элементы в основном содержимом:
- обычную ссылку «Программа», которая открывает страницу с темами;
- простую кнопку «Материалы», раскрывающую немодальный блок непосредственно после себя;
- ссылку «Скачать памятку» внутри этого блока;
- текстовое поле «Вопрос ведущему», расположенное после блока.
В начале блок закрыт, его ссылка скрыта и в последовательность обхода не включена. После активации кнопки блок открывается, ссылка становится доступной для следующего перехода. Сам фокус по нашей спецификации остаётся на кнопке. Повторная активация закрывает блок. Это согласованные условия конкретного учебного примера, а не универсальная модель всех раскрывающихся компонентов.
Для простых элементов этой тренировки согласуем Tab как переход вперёд, Shift+Tab как переход назад, а Enter — как активацию кнопки «Материалы». В реальном компоненте проверяют его фактические способы управления и принятые платформой соглашения. Не распространяйте эту таблицу на дерево, вкладки или редактор: внутри составного компонента могут использоваться другие клавиши.
Мы проверяем только названный участок. Шапка, меню браузера, нижняя часть страницы и другие переходы существуют за границами примера и в его таблице не перечислены. Перед первым шагом проверяющий фиксирует, как он дошёл до ссылки «Программа» с клавиатуры. Если это пока не удаётся, исходное состояние не достигнуто и первый сценарий нельзя пометить выполненным.
| Состояние перед действием | Фокус перед действием | Действие в упражнении | Ожидаемый результат по спецификации |
|---|---|---|---|
| Блок закрыт | Программа | Tab | Фокус на кнопке «Материалы» |
| Блок закрыт | Материалы | Tab | Фокус в поле «Вопрос ведущему» |
| Блок закрыт | Вопрос ведущему | Shift+Tab | Фокус на кнопке «Материалы» |
| Блок закрыт | Материалы | Enter | Блок открыт; фокус остаётся на кнопке |
| Блок открыт | Материалы | Tab | Фокус на ссылке «Скачать памятку» |
| Блок открыт | Скачать памятку | Tab | Фокус в поле «Вопрос ведущему» |
| Блок открыт | Вопрос ведущему | Shift+Tab | Фокус на ссылке «Скачать памятку» |
| Блок открыт | Материалы | Enter | Блок закрыт; фокус остаётся на кнопке |
Строки — самостоятельные сценарии с заданным начальным состоянием. Не читайте таблицу как один непрерывный протокол: для некоторых строк нужно сначала восстановить нужное состояние и дойти до исходного элемента. Способ подготовки тоже записывают.
Иначе последняя строка могла бы незаметно выполняться из поля вопроса вместо кнопки.
Схема показывает три части того же примера. При закрытом блоке путь вперёд идёт от «Программы» через «Материалы» к вопросу, обратный — в противоположном направлении. При открытом блоке между кнопкой и вопросом появляется ссылка на памятку. Все сведения изображения повторены в таблице и тексте.
Как поручить нейросети подготовку сценариев?
Передайте спецификацию, состояния и границы участка. Для обучения достаточно вымышленной страницы. Рабочую разметку, внутренние адреса и сведения о пользователях используйте только в разрешённом инструменте по правилам организации. Для этого упражнения не нужны пароли, заполненные заявки или журнал действий реальных сотрудников.
Предлагаемое поручение:
По спецификации условной страницы составь сценарии клавиатурной проверки. Для каждого укажи начальное состояние блока, элемент с фокусом, действие, ожидаемый переход и основание в исходнике. Отдельно перечисли вопросы, на которые спецификация не отвечает. Не заполняй фактический результат и не утверждай, что выполнил тест. Не добавляй новые элементы, клавиши, автоматический перенос фокуса или правила закрытия. Сохрани названия «Программа», «Материалы», «Скачать памятку», «Вопрос ведущему». Не предлагай правку HTML до наблюдения и разбора причины специалистом.
Сначала сравните ответ с исходником.
Если модель добавила модальное окно, она изменила предмет проверки. Если предложила закрывать наш блок по Escape, найдите такое условие в спецификации. Его нет. Нужен вопрос владельцу о желаемом поведении, а не выдуманная строка приёмки.
Особенно внимательно прочитайте колонки «ожидается» и «наблюдалось». Фраза «фокус корректно возвращается» в фактической колонке недопустима, если никто ещё не открыл стенд. Замените её статусом «не проверено» и поручите действие проверяющему.
Подготовка сценария не должна превращаться в поддельную квитанцию тестирования.
Мнение. Для первого разбора я предлагаю небольшой участок с одним меняющимся состоянием. Так проще выяснить, из какого правила получилась каждая строка. Это выбор редакции для учебной работы, а не ограничение стандарта на размер проверки.
Не просите пять вариантов одного маршрута ради объёма.
Полезнее найти пропущенное состояние: например, модель проверила только открытый блок и забыла закрытый. Во втором случае скрытая ссылка не должна появляться в ожидаемом пути именно по условиям нашего упражнения.
Пройдите маршрут и запишите наблюдение
Работайте на согласованном стенде, где разрешены такие действия. Укажите версию страницы, браузер, операционную систему и существенные настройки клавиатурного управления. Если участник не может определить исходную точку, попросите специалиста помочь воспроизводимо начать сценарий. Не маскируйте этот пробел общим «проверка пройдена».
Сначала выполните переход вперёд при закрытом блоке. Записывайте каждый шаг, а не только итоговую точку. Затем восстановите исходное состояние и проверьте обратный переход. Откройте блок предусмотренной клавишей и повторите строки для открытого состояния. При активации ссылки вы можете уйти со страницы; это отдельное действие, которое не нужно смешивать с простым попаданием фокуса на неё.
Для записи подойдёт карточка:
Страница и версия: условный стенд практикума, версия проверки указана проверяющим. Состояние: блок открыт. Исходная точка: кнопка «Материалы». Действие: Tab. Ожидание по спецификации: ссылка «Скачать памятку». Наблюдение: поле «Вопрос ведущему». Статус: расхождение; причина пока не установлена.
Это учебный пример записи дефекта, а не выполненный нами тест.
В реальном журнале нужны фактические значения и имя проверяющего. Видеозапись может дополнить последовательность действий; один неподвижный скриншот не показывает весь маршрут. Если фокус визуально не удаётся найти, так и запишите наблюдение и передайте его специалисту.
Не угадывайте элемент по расположению страницы.
На схеме приведена та же карточка: блок открыт, после кнопки ожидается памятка, но в условном наблюдении достигнуто поле вопроса. Пока это расхождение, а не установленная техническая причина. Нельзя сделать вывод «не хватает tabindex» только по такому описанию.
Отдельное пояснение W3C Keyboard касается управления функциональностью через клавиатурный интерфейс без требования определённого времени отдельных нажатий. В нём есть исключение для функций, зависящих от пути движения, а не только конечных точек. Наш простой участок со ссылками, кнопкой и полем не является примером свободного рисования.
Не сводите всё клавиатурное управление к подсчёту остановок Tab.
В пояснении Keyboard допускается клавиатурный способ выполнить то же или сопоставимое действие, даже если конкретный видимый контрол не получает фокус. А внутри составного компонента перемещение может идти стрелками. Не объявляйте любой такой случай дефектом по нашей упрощённой таблице. Его разбирают по назначению компонента и согласованному сценарию.
Как отличить странный порядок от клавиатурной ловушки?
Неожиданный переход и невозможность покинуть компонент — разные наблюдения. В первом случае человек может продолжить маршрут, хотя последовательность мешает понять страницу. Во втором нужно выяснить, существует ли способ выйти с клавиатуры и известен ли он пользователю. Нескольких нажатий Tab недостаточно для вывода о всех возможных способах выхода.
W3C No Keyboard Trap разбирает требование: если клавиатурой можно перевести фокус в компонент, из него должен быть доступен клавиатурный выход. Когда способ отличается от обычных клавиш или других стандартных способов выхода, пользователя информируют, как это сделать.
Модальный диалог — важная оговорка. Временное удержание переходов внутри него может быть уместно, если пользователь знает, как выйти из компонента с клавиатуры. Не принимайте решение «ловушка» только потому, что Tab не перешёл к фону открытого окна. В нашем примере модального окна вообще нет: раскрытый блок остаётся частью обычного участка страницы.
Если при проверке реального компонента вы не нашли выход, сохраните последовательность действий, состояние и доступные инструкции. Не просите модель придумать секретную комбинацию клавиш. Передайте наблюдение специалисту, который проверит реализацию, предусмотренные способы управления и объяснение для пользователя.
Для нашего блока достаточно конкретного вопроса: после открытой памятки можно ли продолжить путь к вопросу и вернуться назад согласно спецификации? Для редактора текста или встроенного приложения нужен свой набор действий. Эта статья не задаёт его автоматически и не сертифицирует чужие компоненты.
Что передать разработчику после проверки?
Передавайте воспроизводимое расхождение с основанием. «Нужно улучшить доступность» не указывает ни элемент, ни действие. «В открытом блоке после кнопки Tab переводит фокус к вопросу, ссылка памятки на этом проходе не достигнута» уже позволяет начать разбор. Добавьте версию, окружение и способ восстановления исходного состояния.
Разработчик устанавливает причину.
Она может относиться к реализации, к неполной спецификации или к настройкам проверки; без данных выбирать её нельзя. Если модель советует пронумеровать все элементы положительными значениями tabindex, не вносите изменение вслепую. Пояснение Focus Order отдельно рассматривает риск порядка, нарушающего смысл и работоспособность. Исправление проверяют как поведение, а не как наличие нового атрибута.
После согласованной правки повторите исходный сценарий и связанные переходы назад и вперёд. Если изменили открытие блока, снова проверьте оба состояния. В журнале сохраняют старое наблюдение и новую проверку с версиями; прежний дефект не превращают задним числом в успешную запись.
Схема разделяет три результата. ИИ предложил сценарии по описанию, проверяющий записал реальные действия и непроверенные случаи, специалист разобрал причину и проверил исправление. Одна успешно выполненная строка не означает, что вся страница соответствует WCAG. Объём заключения должен совпадать с объёмом работы.
Для командного разбора выдайте сотруднику спецификацию и ответ с двумя намеренными подменами: придуманным модальным окном и заранее заполненным «тест пройден». Попросите показать, что подтверждено исходником, что осталось гипотезой, а что требует действий на стенде. Затем предложите учебную карточку расхождения без готового технического решения.
Принять упражнение можно, когда сценарии сохраняют согласованные состояния, фактические результаты отделены от ожиданий и замечание воспроизводимо. Если стенд ещё не проверен, результат называется планом проверки. В этом нет недостатка — важно не выдать его за завершённую техническую приёмку.
Такое задание можно обсудить в рамках программы корпоративного обучения работе с ИИ: опишите, кто готовит учебные страницы, кто проверяет их с клавиатуры и кто исправляет реализацию. Для выбора учебной задачи не нужны учётные записи сотрудников или доступ к рабочему сервису.
Частые вопросы
Может ли ИИ проверить порядок по скриншоту?
По изображению можно обсудить видимую компоновку и сформулировать вопросы. Выполненные переходы оно не подтверждает. Для фактического результата нужен тест на странице с записанными состояниями и действиями.
Любой порядок, отличный от расположения на экране, ошибочен?
Нет. Focus Order допускает разные логичные последовательности, сохраняющие смысл и работоспособность. Для конкретного замечания объясните, какое отношение или действие нарушено, а не просто сравнивайте координаты элементов.
Нужно ли сделать каждый текст отдельной остановкой Tab?
Из рассматриваемого требования это не следует. Критерий Focus Order оценивает порядок получающих фокус компонентов, а не предписывает включить каждый абзац в обход. Решение о реализации принимают по назначению содержимого и проверяют технически.
Если Tab ходит по кругу внутри диалога, это всегда ловушка?
Нет. Для модального диалога нужно проверить предусмотренный клавиатурный выход и понятность способа выхода. Временное ограничение фокуса внутри открытого диалога само по себе не доказывает нарушение.
Можно ли принять страницу по составленной таблице?
Таблица подтверждает подготовку сценариев. Приёмка реализации требует фактических действий и результатов. Здесь разобран ограниченный участок; полного вывода о доступности страницы или всего сайта он не даёт.
Источники
- W3C: Focus Order — смысл последовательного обхода, допустимость разных логичных порядков и примеры динамических компонентов.
- W3C: Keyboard — управление функциональностью клавиатурным интерфейсом и границы требования.
- W3C: No Keyboard Trap — выход из компонентов и оговорки о модальных диалогах.
