Незрячий автор навыка аудита доступности убрал ложные срабатывания ИИ-агента

Задача знакома всем, кто доверяет нейросети проверку сайта или кода: агент находит «ошибки», которых нет, и предлагает правки, которые ломают соседние страницы. Ниже порядок проверок, который убирает ложные находки. Его можно забрать в свой промпт.

Accessibility Auditor Skill это навык (skill), то есть набор инструкций для ИИ-агента. ИИ-агент здесь означает программу на основе нейросети, которая сама выполняет цепочку действий, а не только отвечает на вопрос. Навык проверяет доступность интерфейсов по исходному коду и обследует сайты. Доступность означает, что интерфейсом могут пользоваться и люди с нарушениями зрения, в том числе со скринридером (программой, которая читает вслух происходящее на экране).

В ранних версиях агент объявлял проблемой отсутствие атрибута в одном файле, хотя нужное поведение уже обеспечивала библиотека. Ещё он предлагал правку, не проверив, где ещё используется общий компонент. Разбор автора «Как я дорабатывал навык аудита доступности: библиотеки, общие компоненты и ложные срабатывания» показывает, откуда взялось каждое правило.

Что понадобится для доработки аудита?

• ИИ-агент с доступом к репозиторию проекта.
• Исходный код компонентов и сведения о версии используемой библиотеки.
• Автотесты, например Playwright (инструмент, который сам нажимает кнопки в браузере и проверяет результат).
• Скринридер для финальной проверки в работающем приложении.

Пошаговая инструкция: от места использования к реализации

1. Запретите агенту выносить вердикт по одному файлу. Сначала он смотрит реализацию компонента, библиотеку и общие обёртки. Общий компонент похож на типовую дверь в многоэтажке: поменяете её в одной квартире, и это затронет все.
2. Заставьте проследить цепочку. Агент должен выяснить, какой элемент получает фокус и откуда берётся его доступное имя (то, что произносит скринридер). Ещё он проверяет, где создаются подпись, подсказка и ошибка, как передаются их идентификаторы и сохраняет ли компонент атрибуты от вызывающего кода.
3. Проверяйте, что файл вообще работает. В репозитории остаются старые компоненты с похожими названиями, и правка в них на живой интерфейс не повлияет.
4. Учитывайте уже заданные объявления. Роли status и alert сами определяют, как озвучиваются изменения. Для обычной подсказки не ставьте режим assertive или роль alert, потому что они прерывают текущую речь.
5. Проверяйте потребителей общего интерфейса. Новое свойство не должно попадать в компоненты, которые его не понимают.
6. Предпочитайте публичный API компонента, то есть его официальный «вход». Если приходится лезть во внутреннюю разметку библиотеки, добавьте регрессионный тест (автопроверку, что после обновлений ничего не сломалось).
7. Требуйте честный отчёт: агент указывает, что выполнил сам. Анализ кода, тесты и проверка скринридером подтверждают разное.

Пример промпта по этим правилам:

``` Прежде чем объявить проблему доступности, проверь реализацию компонента, библиотеку установленной версии и общие обёртки. Убедись, что файл участвует в рабочем сценарии. Не добавляй атрибуты, которые уже создаёт библиотека. Для обычной подсказки не используй assertive и роль alert. В отчёте отдельно укажи: что проверено по коду, что тестами, что требует проверки скринридером. :::

Что делать с этим прямо сейчас, по ролям

Автору Дзена: если ведёте сайт или канал с формами подписки, не принимайте отчёт нейросети на веру. Спросите, проверила ли она библиотеку, а не один файл.

Маркетологу: ложная находка в аудите стоит денег, потому что разработчик тратит время на правку, которая ничего не меняет. Требуйте от подрядчика отчёт с разделением «проверено по коду, тестами, скринридером».

Предпринимателю из РФ и СНГ: правила оформлены как текст инструкций, их можно вставить в промпт любого ИИ-ассистента. Из доступных в РФ вариантов это YandexGPT и GigaChat. Насколько хорошо они разберут код ваших компонентов, источник не проверял.