Видимый фокус с нейросетью проверяют через подготовленную карту состояний: человек доходит до элемента с клавиатуры и отмечает, видны ли сам элемент и признак фокуса. ИИ может составить заготовку протокола по описанию страницы. Заполнять наблюдения и объявлять проверку успешной до работы на стенде ему нельзя.
Это упражнение для команды, которая готовит учебные страницы и передаёт замечания разработчику. В результате останется карточка конкретного перекрытия или пропавшего индикатора, а не общее заключение «сайт доступен».
Почему правильный порядок переходов не решает задачу?
Представьте условную страницу практикума. Проверяющий нажимает Tab, и клавиатурный фокус попадает на ссылку «Скачать задание». Последовательность верна, но ссылка оказывается под закреплённой шапкой. Человек не видит, что сейчас можно открыть. Добавление ещё одной строки в правильный маршрут не объяснит эту проблему.
У проверки порядка фокуса другой результат: последовательность переходов должна сохранять смысл и возможность действий. Здесь мы считаем маршрут уже согласованным и исследуем видимость в момент остановки. Если элемент вообще не достигается, это отдельное замечание о навигации; его нельзя автоматически записать как перекрытие.
В пояснении W3C Focus Visible требование связано с возможностью видеть индикатор клавиатурного фокуса. Оно допускает режим, в котором индикатор показывается при работе с клавиатуры, и не требует, чтобы любое нажатие мыши выглядело точно так же. Важен способ управления, который мы действительно проверяем.
Факт. Пояснение W3C также указывает, что видимый индикатор не должен исчезать по таймеру, пока клавиатурный фокус остаётся на элементе.
Все элементы, состояния и дефекты ниже вымышлены. Это редакционный способ обучения работе с ИИ, а не отчёт об аудите AURMIND или клиента. Документы W3C обосновывают технические различия; они не подтверждают эффективность нашего промпта или конкретной модели.
Не меняйте стили рабочего сайта по ответу нейросети.
Для начала нужен разрешённый учебный стенд и человек, который отвечает за техническую проверку. Упражнение не охватывает все критерии WCAG, все устройства и все возможные компоненты.
Расскажите, чему хотите научить команду. Обсудим задачи и формат обучения.
Разделите индикатор и элемент под ним
Есть два разных вопроса. Первый: можно ли визуально определить, какой элемент получил фокус? Второй: не скрыт ли сам сфокусированный элемент содержимым, которое добавил автор страницы? Их полезно записывать раздельно, даже если причиной обоих наблюдений оказалась одна панель.
Focus Not Obscured (Minimum) требует, чтобы компонент при получении клавиатурного фокуса не был полностью скрыт авторским содержимым. Пояснение называет среди возможных перекрытий закреплённые шапки, нижние панели и немодальные диалоги. При этом минимальный критерий допускает частичное перекрытие: нельзя подменять его более строгим правилом «каждая часть всегда полностью видна».
Стремиться к полностью видимому элементу разумно, но обозначьте это как выбранную цель команды. В документе полное отсутствие перекрытия относится к отдельному усиленному критерию.
Проверяется именно компонент. Внешняя рамка вокруг кнопки не заменяет видимость самой кнопки при оценке минимального требования о перекрытии. И наоборот: видимая кнопка без различимого состояния фокуса не закрывает первый вопрос.
| Наблюдение в условном упражнении | Что записать | Какой вывод пока не делать |
|---|---|---|
| Кнопка видна, признак фокуса не найден | Элемент и состояние, отсутствие различимого индикатора | Что причина обязательно в одной CSS-команде |
| Ссылка целиком за закреплённой шапкой | Полное перекрытие компонента, шапка, положение страницы | Что достаточно нарисовать внешнюю рамку |
| Нижняя панель закрывает часть кнопки | Какая часть видна и какая закрыта | Что частичное перекрытие автоматически нарушает минимум |
| Элемент виден и признак фокуса различим | Наблюдение для этой версии и состояния | Что все другие состояния тоже проверены |

Схема разделяет признак фокуса и видимость компонента. Ответ «да» на один вопрос не заменяет ответ на другой. Все сведения изображения повторены в таблице; по иллюстрации не измеряют реальную страницу.
Контраст самого индикатора относится к отдельному техническому разбору. Пояснение Focus Visible связывает такие признаки с требованиями к нетекстовому контрасту. Порог для обычного текста из упражнения о цветовых парах нельзя без объяснения переносить на любую рамку. В этой тренировке мы не рассчитываем контраст рамок и не выдаём визуальное впечатление за измерение.
Что передать нейросети до составления карты?
Владелец учебного стенда задаёт исходник. Для нашей тренировки это страница с программой занятия, ссылкой «Скачать задание» и кнопкой «Отправить вопрос». Вверху закреплена шапка. Внизу есть автоматически показанная информационная панель, которую пользователь не открывал сам. Панель можно закрыть предусмотренной кнопкой; конкретное управление согласуют на стенде.
Шапка остаётся закреплённой при прокрутке. Информационная панель имеет два заранее определённых состояния: показана и закрыта. Маршрут к ссылке и кнопке известен проверяющему. Исходник не сообщает, что именно происходит с прокруткой при получении фокуса: это надо наблюдать, а не дописывать от имени системы.
Названия страницы и элементов — учебные. Не отправляйте в неподходящий сервис внутренние адреса, данные участников, содержимое заявок или рабочие снимки с личной информацией. Для составления карты достаточно описания разрешённого макета. Правила выбора инструмента задаёт организация.
Предлагаемое поручение:
По этому описанию подготовь карту проверки видимости клавиатурного фокуса. Для каждой строки укажи элемент, начальное состояние шапки и нижней панели, способ достижения элемента, два отдельных вопроса о видимости индикатора и компонента. Фактические наблюдения оставь «не проверено». Не выдумывай результат прокрутки, размеры панелей, CSS и выполненные испытания. Для неизвестного способа достижения задай вопрос. Раздели наблюдение, возможную причину и предложение специалисту. Не объявляй частичное перекрытие нарушением минимального критерия и не считай внешнюю рамку частью компонента.
Этот промпт — предложенная редакцией заготовка, а не проверенный универсальный тест.
Полученный ответ сначала сверяют с исходником. Модель может превратить информационную панель в модальный диалог и запретить переходы на основную страницу. Тогда она поменяла условия упражнения. Верните описание автору ответа: наша панель не объявлена модальной и появляется автоматически. Выбор нового устройства интерфейса не относится к подготовке протокола.
Мнение. Для первого занятия я предлагаю оставить всего два целевых элемента и два состояния панели. Так участник сможет объяснить происхождение каждой строки. Это педагогический выбор редакции, не ограничение стандарта.
Как выглядит заготовка без выдуманных результатов?
Сначала проверяют ссылку при закрытой нижней панели, затем кнопку в том же состоянии. После восстановления исходной версии повторяют обе строки с показанной панелью. Закреплённая шапка присутствует в каждом сценарии. Это четыре самостоятельные проверки, для каждой требуется воспроизводимый способ начала.
| Цель | Нижняя панель | Что фиксировать при получении фокуса | Фактический результат до теста |
|---|---|---|---|
| Скачать задание | Закрыта | Индикатор; видимость ссылки относительно шапки | Не проверено |
| Отправить вопрос | Закрыта | Индикатор; видимость кнопки относительно шапки | Не проверено |
| Скачать задание | Показана автоматически | Индикатор; видимость ссылки относительно обоих блоков | Не проверено |
| Отправить вопрос | Показана автоматически | Индикатор; видимость кнопки относительно обоих блоков | Не проверено |
Способ достижения записывает проверяющий по согласованному маршруту. Таблица не утверждает, что ссылка расположена в определённом месте экрана, и не обещает, что браузер сам выведет кнопку из-под панели. Если ширина окна меняется, это новое условие: сохраните фактические размеры и не смешивайте результаты разных состояний в одной ячейке.
Прокрутка тоже часть записи.
Укажите, откуда начали движение, какие действия выполнили и где остановилась страница. Не прокручивайте её мышью ради красивого итогового снимка перед фиксацией исходного наблюдения. Такой снимок уже может показывать другое состояние. Если дополнительная прокрутка нужна для разбора, запишите её отдельным действием и сохраните оба результата.
Для этого упражнения не требуется подбирать точное количество нажатий по скриншоту. Нужен маршрут, который другой участник сможет повторить на той же версии. Если исходная точка недостижима или фокус потерян, остановите соответствующую строку и опишите неопределённость.

Три части схемы — состояние, цель и наблюдение. До тестирования заполнены только первые две; в третьей стоит «не проверено». Схема не показывает выполненный нами тест.
Что человек проверяет на стенде?
Откройте согласованную версию и запишите браузер, операционную систему, размер области просмотра, масштаб и существенные настройки клавиатурного управления. Настройки нужны для повторения условий, а не для заявления об охвате всех браузеров. Для каждой строки восстановите согласованное состояние панели и дойдите до цели с клавиатуры.
Техника W3C G149 описывает использование компонентов, которые при получении фокуса выделяет пользовательский агент. В её процедуре для каждого фокусируемого компонента устанавливают фокус и проверяют наличие выделения. Это один из способов выполнения требования, а не обязанность использовать только стандартную пунктирную рамку.
На стенде сотрудник сначала определяет текущую цель и видимый признак фокуса. Затем отдельно отмечает, виден ли сам компонент и какие блоки его перекрывают. Оставаясь на элементе, проверяющий наблюдает, сохраняется ли индикатор. Произвольный «достаточный» таймер в секундах в этой статье не задаётся.
Если индикатор не удалось найти, так и напишите.
Не угадывайте текущую цель только по ожидаемой последовательности. Попросите технического специалиста помочь установить, где фактически оказался фокус. До подтверждения нельзя уверенно писать «кнопка получила фокус, но рамки нет»: возможно, фокус ушёл в другое место. В журнале должны различаться отсутствие видимого признака и неподтверждённая цель.
Не активируйте кнопку отправки на рабочей форме ради проверки её состояния. Для нашего упражнения используют безопасный стенд с согласованными действиями. Нажатие Tab до кнопки и отправка данных — разные операции.
Когда элемент перекрыт полностью, сохраните весь контекст окна и перекрывающий блок. Обрезка одной кнопки не покажет, откуда пришла панель и почему она находится поверх. Снимок сопровождает последовательность действий, но не заменяет её. Если поведение меняется во времени, полезно приложить разрешённую запись экрана с пояснением момента получения фокуса.
Как не ошибиться с частичным перекрытием и окнами?
Нашу автоматически показанную панель не следует путать с содержимым, которое открыл сам пользователь. В Focus Not Obscured (Minimum) есть специальное примечание: для пользовательского раскрытия возможность показать сфокусированный компонент без продвижения фокуса влияет на оценку. Пояснение отдельно оговаривает, что этот разбор не переносится на заранее размещённые автором блоки или автоматически появляющиеся предупреждения.
Поэтому не закрывайте замечание об автоматически показанной панели фразой «до кнопки закрытия можно дойти ещё несколькими Tab». Для точной оценки специалисту нужны происхождение панели и поведение при получении фокуса. В нашем исходнике панель появляется автоматически, а исходное наблюдение фиксируется до дополнительных действий.
Для пользовательского раскрытия передайте вопрос отдельно: кто открыл блок, каким действием его можно убрать, остаётся ли фокус на прежней цели? Не выдумывайте, что Escape обязательно закрывает любой компонент. В рабочей проверке описывают фактическое управление конкретного блока.
С модальными диалогами начинается другой сценарий.
В этой тренировке мы не проектируем модальное окно, не предписываем перенос фокуса и не предлагаем превратить каждую панель в диалог. Если реальная страница содержит такой компонент, согласуйте отдельную проверку с техническим специалистом. Упрощённую карту двух элементов нельзя выдавать за полноценную проверку его поведения.
При частичном перекрытии опишите видимую область без преждевременного вердикта. Например, в вымышленном наблюдении нижняя часть кнопки закрыта панелью, но её подпись и верхний край видны. Минимальный критерий о полном скрытии нельзя объявить нарушенным только из этого факта. При этом индикатор может оказаться неразличимым — первый вопрос остаётся самостоятельным. Команда вправе поставить задачу убрать и частичное перекрытие, обозначив свою цель явно.
Как передать дефект и проверить исправление?
Плохая запись: «ИИ нашёл проблему с фокусом». Она не позволяет установить, что наблюдал человек. Полезнее карточка: «Учебный стенд, версия А. Панель показана автоматически. После согласованного перехода на кнопку “Отправить вопрос” специалист подтвердил фокус на ней. Компонент целиком закрыт нижней панелью; индикатор не найден. Прилагаются условия окна и последовательность действий».
Это образец записи, а не результат проведённого аудита.
В реальном журнале должны стоять фактическая версия, условия, проверяющий и подтверждение цели. Для причины оставьте отдельное поле «не установлена». Ответ «исправить z-index» ещё не доказательство причины: решение выбирает разработчик после воспроизведения, учитывая работу страницы и другие состояния.
Не удаляйте закреплённые блоки из спецификации задним числом, чтобы закрыть замечание.
Если команда согласовала другое поведение панели, сохраните изменение требования и новую версию. Затем повторите исходный сценарий и назовите наблюдение после правки. Статус «код изменён» не равен «проверено»: элемент мог остаться перекрытым в другом размере окна или индикатор мог перестать быть видимым.
Для принятия учебной работы попросите участника передать исходное описание, фактический ответ ИИ, исправленную карту, журнал наблюдений и список непроверенных состояний. Коллега должен воспроизвести хотя бы одно замечание по этой записи. Не засчитывайте формулировку модели «нарушений нет» вместо протокола.
На корпоративном обучении ИИ такую задачу можно обсуждать на разрешённом макете: сотрудник готовит проверку, человек выполняет её, технический специалист разбирает причину. Для первого разговора опишите, кто выпускает учебные страницы и кто принимает их техническое качество. Передавать реальные заявки участников для этого не нужно.
Частые вопросы
Достаточно ли правильного маршрута Tab?
Нет. В этом упражнении последовательность уже согласована. При каждой остановке отдельно проверяют видимость индикатора и самого компонента. Правильная цель может оказаться за закреплённой шапкой.
Любое перекрытие означает нарушение минимального критерия?
Нет. В пояснении W3C минимум относится к полному скрытию компонента авторским содержимым. Частичное перекрытие и видимость индикатора описывают отдельно; более строгую цель команды нельзя молча выдавать за минимальное требование.
Можно ли принять ответ нейросети без открытия стенда?
Можно принять только заготовку сценариев, если она верно отражает исходник. Фактическая проверка остаётся невыполненной. Скриншот или уверенный текст модели не подтверждают клавиатурное поведение страницы.
Источники
- W3C: Focus Visible — видимый индикатор, режим клавиатурного управления и отсутствие временного исчезновения.
- W3C: Focus Not Obscured (Minimum) — видимость компонента, полное и частичное перекрытие, примечания о пользовательских раскрытиях.
- W3C: G149 — выделение компонентов средствами пользовательского агента и процедура проверки.