GitHub рассказал о пилотном проекте экспериментального агента по цифровой доступности, который использует большие языковые модели (LLM) и агентный подход для поиска и устранения барьеров в интерфейсах сервиса.
По данным компании, агент решает две ключевые задачи и автоматически проверяет изменения, затрагивающие фронтенд-код. На данный момент им рассмотрено 3 535 pull request’ов, при этом в 68% случаев замечания были успешно устранены. Наиболее частые проблемы сгруппированы по пяти основным типам, которые создают препятствия для людей, использующих ассистивные технологии.
GitHub подчёркивает, что не пытается «решить доступность» силами одного инструмента, а усиливает работу команд разработки. Агента рассматривают как дополнение к существующим процессам, а не как универсальное решение. Чёткое определение зоны ответственности позволило быстрее запустить эксперимент и получить поддержку внутри компании.
Контекст проекта задают регуляторные изменения. Европейский акт о доступности уже действует, а к апрелю 2027 года раздел II американского закона ADA закрепит WCAG 2.1 AA как юридический критерий готовности. LLM-агенты могут анализировать дерево доступности и автоматически находить часть проблем, поэтому отсутствие системной работы по ручному выявлению и исправлению нарушений ставит организации в уязвимое положение.
В GitHub давно действует отлаженная система регистрации и проверки исправлений по вопросам доступности. Все проблемы собираются в одном репозитории и оформляются по единым правилам. Эта структурированная база стала основным корпусом данных, на который опирается агент. Ему явно указали искать связи между зафиксированными ранее случаями и текущими изменениями кода и текстов.
В компании отмечают, что при генерации кода LLM склонны воспроизводить ошибочные паттерны, так как обучались на многолетнем наследии недоступного кода. Чтобы компенсировать это, GitHub инвестировал в ручное описание и исправление инцидентов, а затем подключил накопленные данные к агенту как эталон для рекомендаций.
Отдельно подчёркивается, что доступность затрагивает сразу несколько ролей: разработку, дизайн, копирайтинг и другие компетенции, связанные с интерфейсами. Из-за высокой зависимости от контекста агенту требуется много токенов, что приводит к росту стоимости, времени отклика и рискам ошибок. Поэтому GitHub уделил особое внимание структуре и архитектуре агента.
Изначально система была монолитной, но быстро упёрлась в ограничения такого подхода. Затем её перевели на архитектуру с подагентами. Вместо множества специализированных подагентов, работающих параллельно, GitHub использует два отдельных подагента, каждый со своей задачей. Они изолированы друг от друга и выдают стандартизированный ответ по шаблону, который затем обрабатывает родительский оркеструющий агент.
Работа подагентов организована в виде чёткой последовательности фаз и шагов с привязкой к нужным ресурсам и набору навыков. Такая линейная схема отражает тот путь, по которому эксперт по доступности проводит аудит, исправление и отчётность вручную. Все операции опираются на шаблоны-схемы, чтобы удерживать агента в заданных рамках и снизить расход токенов, количество «галлюцинаций» и лишних изменений кода.
GitHub подробно прорабатывает ограничения агента. Так как он не является прямым аналогом ручной экспертизы, важно избежать ситуаций, когда пользователи без достаточных знаний по доступности безусловно доверят его выводу. Для этого в систему встроены механизмы отказа от автоматических правок.
Агент использует небольшой shell-скрипт для анализа кода, с которым ему предстоит работать. Скрипт применяет набор эвристик и вычисляет показатель сложности. Если значение превышает заданный порог, агенту запрещается вносить изменения. Вместо этого он предлагает разработчику обратиться к команде по доступности за консультацией.
Дополнительно агенту запрещено генерировать код для шаблонов, которые команда считает высокорисковыми с точки зрения доступности. В их числе drag-and-drop, всплывающие уведомления, редакторы форматированного текста, древовидные представления и таблицы-решётки с данными. Эти компоненты требуют глубокой проработки и пока выходят за рамки возможностей LLM по корректной поддержке ассистивных технологий.
Чтобы не допустить обхода этих ограничений, в инструкции добавлены правила против попыток «обойти систему». По словам команды, LLM «стремятся что-то сгенерировать любой ценой», и для GitHub Copilot это обычно означает код. Поэтому пришлось явно запретить «обходные пути», когда модель пытается выполнить запрещённые действия опосредованно.
GitHub увязывает эффективность агента с рамками стандартов. Из 55 критериев успеха уровней A и AA WCAG только 35 можно отследить детерминированными автоматическими проверками, то есть примерно 36% критериев не поддаются полному автоматическому выявлению. LLM-агенты уже помогают сократить этот разрыв, но не устраняют потребность в ручной работе на этапах дизайна и прототипирования, где и рождается значительная часть проблем.
Это понимание заложено и в логике эскалации. Члены команды по доступности могут подключаться к работе с дизайнерами, чтобы заранее предложить альтернативы и решения, позволяющие достичь бизнес-целей без ущерба для доступности. Такой подход помогает избежать дорогостоящих переделок на поздних стадиях разработки.
Выход агента в продуктив сопровождается постоянной валидацией. GitHub регулярно вручную проверяет результаты его работы и собирает отклики ревьюеров из pull request’ов. Эти сигналы помогают понять, где агенту нужны уточнённые инструкции, дополнительные ресурсы или новые навыки.
Компания подчёркивает, что проект продолжается. Агент по доступности развивается и дорабатывается с целью сделать GitHub максимально доступной и инклюзивной платформой для разработчиков. В планах — возможная открытая публикация агента в будущем, как часть обязательств GitHub по поддержке доступности в экосистеме открытого ПО. Пока же команда делится накопленным опытом, чтобы другие могли использовать эти наработки в собственных инициативах по доступности.
Источник: блог GitHub.
