GitHub рассказал, как использует искусственный интеллект, чтобы системно обрабатывать обратную связь по доступности и быстрее устранять барьеры для пользователей с ограниченными возможностями. Новый внутренний процесс автоматизирует разбор обращений и помогает командам фокусироваться на исправлениях, а не на ручной сортировке сообщений.
Раньше жалобы по доступности оказывались разбросаны по разным бэклогам, часто оставались без владельца и ответа. Многие запросы месяцами не переходили в реальные правки, а обещанные улучшения откладывались на неопределённое «второй этап».
Команда централизовала все обращения, ввела шаблоны задач и провела разбор накопленного бэклога. На этой базе GitHub построил новый процесс, в котором GitHub Actions, GitHub Copilot и GitHub Models превращают каждый отзыв пользователя в отслеживаемую задачу с приоритетом, статусом и ответственными.
Целью было не заменить специалистов, а снять с них рутину. AI автоматически анализирует обращения, заполняет метаданные и предлагает классификацию, а люди принимают ключевые решения, проверяют выводы и разрабатывают исправления.
Такой подход GitHub описывает как «непрерывный AI для доступности» — не разовую проверку и не отдельный продукт, а методику, которая постоянно встраивает требования доступности в обычный цикл разработки. Эта философия связана с поддержкой компанией инициативы Global Accessibility Awareness Day (GAAD) 2025 и обещанием усилить доступность в экосистеме открытого кода.
Основной источник обращений — публичный раздел обсуждений по доступности на GitHub, где сейчас концентрируется около 90% всей обратной связи. Там пользователи подтверждают проблемы, добавляют контекст и делятся обходными решениями, что делает отчёты богаче и полезнее классических тикетов поддержки.
Любой отчёт, требующий действий, превращается в задачу по шаблону accessibility feedback issue. Шаблон фиксирует, что именно сообщил пользователь, откуда пришёл сигнал и какие компоненты задействованы, чтобы информация не терялась между приёмом и дальнейшей обработкой.
Создание такой задачи запускает GitHub Action, который обращается к GitHub Copilot через GitHub Models API. Второй Action автоматически добавляет задачу на проектный борт, где видны статусы, тенденции и новые потребности.
GitHub использует сохранённые инструкции вместо дообучения моделей. Поведение AI настраивается через markdown-файлы и файлы инструкций, которые обновляются pull request-ами. Для изменения логики не нужны пайплайны обучения и специальные знания в машинном обучении.
Инструкции для Copilot составлены экспертами по доступности. Они включают внутренние политики, библиотеку компонентов и документацию по применению критериев WCAG. В результате Copilot решает две задачи: проводит первичный разбор обращения (тип нарушения WCAG, серьёзность, затронутые группы пользователей) и выступает помощником по доступности для команд разработки.
Автоматизация устроена в два шага. Сначала Action, срабатывающий при создании issue, запускает анализ. GitHub Copilot автоматически заполняет около 80% метаданных — более 40 параметров: тип проблемы, сегмент пользователя, источник, затронутые компоненты и контекст. Остальное дополняет сотрудник.
Затем Copilot публикует в комментарии чек-лист и вывод анализа. Следующий Action разбирает этот комментарий, ставит метки по уровню серьёзности, обновляет статус задачи на проектном борту и назначает её автору для подтверждения. Любой сотрудник может оспорить анализ Copilot, создав отдельную задачу с описанием ошибки — это встроенный механизм улучшения.
Перед тем как использовать рекомендации AI, проходят два уровня проверки. Сначала автор задачи пытается воспроизвести проблему по чек-листу из комментария Copilot. Инструкция написана простым языком, содержит пошаговые действия и ссылки на инструменты, так что с ней справляются даже сотрудники без глубоких знаний по доступности.
Если проблему удалось воспроизвести, автор помечает задачу как проверенную, что запускает следующий Action. Если воспроизвести не удалось, пользователь получает запрос на дополнительные детали, после чего анализ Copilot можно перезапустить вручную или через изменение метки.
После отметки «проверено» задача попадает на отдельный борт accessibility first responder. Это сигнал для профильной команды, куда входят инженеры, дизайнеры, внутренние «чемпионы» по доступности, подрядчики по тестированию и менеджеры.
Команда по доступности сверяет оценку Copilot: серьёзность, соответствие критериям WCAG и категориальные метки. В спорных случаях приоритет всегда за человеком. Все правки фиксируются и используются для корректировки инструкций, чтобы повышать точность в будущем.
После валидации команда выбирает подход к решению и помечает задачу как прошедшую триеж. Action возвращает задачу автору, который информирует пользователя, что именно будет сделано и в какие ориентировочные сроки.
Далее каждое обращение связывается с системой формальных аудитов по доступности. Около 75–80% внешних жалоб совпадает с уже известными внутренними findings. В этих случаях задача связывается с существующим аудиторским issue и помечается как выявленная пользователем, что помогает ранжировать по реальному влиянию.
Если сигнал выявляет новую проблему, создаётся новая аудит-задача, которая связывается с исходным обращением. Так вся экосистема обратной связи и аудитов остаётся связанной.
Ключевой момент — коммуникация с пользователем. После выбора плана решения автор контакта объясняет, что будет меняться. После выката исправления он снова обращается к пользователю и просит подтвердить результат, а в случае обсуждений на доске доступности публикует обновление публично.
Если пользователь подтверждает, что барьер устранён, задача закрывается. Если проблема остаётся, цикл возвращается к команде по доступности. Задачи не закрываются без подтверждения от человека, который сообщил о проблеме.
Замыкание цикла происходит и на уровне качества работы AI. В каждом комментарии Copilot есть ссылка на создание задачи для разбора неточностей. Такие обращения перерабатываются в pull request-ы к файлам инструкций и промптов.
Отдельный GitHub Action еженедельно сканирует внутренний репозиторий руководств по доступности и автоматически вносит новые рекомендации в кастомные инструкции для Copilot. Это поддерживает синхронизацию AI с текущими стандартами.
Компания делает ставку не на безошибочность, а на постоянное улучшение. Ежеквартально команда анализирует метрики точности, время решения, частоту повторяющихся сбоев по WCAG и динамику объёма обратной связи. Эти данные попадают в регулярные отчёты и дают руководству картину прогресса и проблемных зон.
За год ситуация изменилась радикально. Раньше почти половина обращений по доступности оставалась нерешённой более 300 дней. Сейчас такой «долгий» бэклог устранён, а процесс мониторится через автоматические еженедельные и квартальные отчёты GitHub Actions.
В одном из кейсов пользователь по имени Джеймс сообщил, что интерфейс GitHub Copilot CLI недоступен для скринридеров: декоративное оформление мешало чтению, а интерактивные элементы было сложно обойти. После создания задачи Copilot за считанные минуты сопоставил описание с техническими деталями, добавил ссылки на внутреннюю документацию и шаги для воспроизведения.
На этом фоне стало ясно, что команда ранее уже выпустила обновления CLI с режимом для скринридеров, о котором Джеймс не знал. Сотрудник оперативно ответил, указав на параметр –screen-reader. Пользователь подтвердил, что эта опция сильно улучшила работу, и ситуация разрулилась за часы, а не месяцы.
GitHub подчёркивает, что главный эффект даёт не только скорость, а именно ощущаемое пользователями улучшение. По словам компании, истории, в которых люди получают реальные рабочие решения вместо формальных ответов, показывают ценность вложений в фундамент: аннотации в дизайне, сканеры кода, внутренние «чемпионы» по доступности и тестирование с участием людей с инвалидностью. AI здесь усиливает уже выстроенные практики, а не заменяет их.
Компания отмечает, что продолжает развивать систему, но уже сейчас любой владелец репозитория — от крупного корпоративного проекта до любительской open source-библиотеки — может внедрить подобный подход. Достаточно создать шаблон задачи для обращений по доступности, добавить файл .github/copilot-instructions.md со своими стандартами и поручить AI первичный разбор и оформление, чтобы команде было проще сосредоточиться на написании более инклюзивного кода.
GitHub призывает пользователей делиться проблемами доступности, с которыми они сталкиваются на платформе. Компания утверждает, что теперь такие сигналы не теряются в бэклоге, а проходят по прозрачному, автоматизированному и подотчётному маршруту до полного решения.
Источник: блог GitHub.
