Как научить ИИ-аудитора доступности не находить несуществующие ошибки

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

Одна из типичных ситуаций — агент видит, что у поля формы нет атрибута aria-describedby, который связывает его с подсказкой или сообщением об ошибке, и предлагает добавить этот атрибут. Однако нужную связь уже может создавать библиотека. Если этого не проверить, исправление окажется лишним. Хуже того, изменение общего компонента способно затронуть сразу несколько форм.

Поэтому автор изменил порядок работы агента. Теперь тот должен выяснить, какой элемент получает фокус, откуда берётся его доступное имя, как устроены подписи и сообщения об ошибках, какие атрибуты передаёт библиотека установленной версии. Важно также убедиться, что найденный файл вообще используется в работающем интерфейсе, а не остался от старой реализации. Отсутствие атрибута в коде ещё не означает ошибку доступности.

Новые правила появлялись после работы над реальными проектами. Например, в RTL, в PR №1603, агент дорабатывал сообщения авторизации и загрузки. Оказалось, что роли status и alert уже определяют, как скринридер сообщает об изменениях. Если добавить лишние атрибуты, пользователь может услышать одно сообщение дважды или столкнуться с тем, что обычная подсказка прерывает текущую речь.

В предложенном исправлении индикатор загрузки скрыли от скринридера, оставив озвучиваемый текст Loading RTL... внутри области статуса. Так декоративный элемент не дублировал сообщение. В инструкции закрепили правило: сначала проверять существующую семантику, а уже потом добавлять атрибуты. Сам PR закрыли без слияния, поэтому этот пример показывает предложенное решение, а не подтверждённый результат в работающем приложении.

В проекте Vets-Who-Code обнаружилась другая проблема. Агент добавил свойство feedbackId для связи текстового поля с сообщением обратной связи, но распространил его на общий интерфейс. В итоге свойство стало доступно компонентам, которые не умели его обрабатывать. При доработке свойства текстовых полей отделили от общего интерфейса, а для Input и Textarea добавили проверки пользовательских идентификаторов.

После этого автор потребовал от агента проверять всех потребителей общего интерфейса. В частности, нужно убедиться, что новый атрибут не попадёт в HTML там, где его не поддерживают, а связь поля с ошибкой сохранится как при автоматически созданном идентификаторе, так и при значении, заданном разработчиком. При исправлении нельзя терять и другие подсказки, уже связанные с полем через aria-describedby.

Ещё один урок появился в suitenumerique/docs. Исправление выбора формата экспорта опиралось на внутреннюю разметку Cunningham Select. Но библиотека может обновиться, и такое решение перестанет работать. Теперь агенту предписано по возможности использовать публичный API компонента. Если приходится обращаться к внутренним элементам, нужно добавить регрессионный тест. В этом случае проверки атрибутов aria-hidden и tabindex включили в Playwright-тест, хотя полный сквозной прогон тогда не выполняли.

Есть и принятое исправление. В Nextcloud iOS агент обнаружил, что VoiceOver может выделить папку в окне выбора места сохранения файла, но не произнести её название. Он добавил доступное имя из названия папки и дополнительных сведений, уже показанных на экране, исключил пустые значения и обозначил строку как кнопку. PR №4111 приняли 28 мая 2026 года. Правда, проверили только исходный код: собрать приложение и протестировать его с VoiceOver на устройстве не удалось из-за отсутствия Xcode.

Автор также пробовал поручать агенту поиск проблем в открытых репозиториях и подготовку исправлений. Позже он перешёл к сбору кандидатов в течение недели, чтобы выбирать проекты с несколькими связанными проблемами и заранее проверять, не исправил ли их кто-то другой. Этот опыт помогал пополнять инструкции, хотя сам поиск проектов и расписание подготовки PR оставались отдельными заданиями.

В результате получился набор правил, который учитывает не только отдельные атрибуты, но и устройство компонентов, поведение библиотек и последствия изменений. При этом снижение числа ложных находок никто не измерял. Автор не заявляет о доказанном росте точности: он показывает конкретные ошибки и то, как менял инструкции после них. Главный вывод — ИИ-аудитор должен чётко разделять то, что он предполагает по исходному коду, что подтвердили автоматические тесты и что действительно проверили в работающем интерфейсе со скринридером.