Доступность: GitHub превращает обратную связь в инклюзивность с помощью непрерывного ИИ

Революция в доступности: Подход GitHub с непрерывным ИИ

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

Признавая необходимость фундаментальных изменений, GitHub начал путь к централизации обратной связи, созданию стандартизированных шаблонов и устранению значительного отставания. Только после создания этой прочной основы возник вопрос: Как ИИ может еще больше трансформировать этот процесс? Ответ кроется в инновационном внутреннем рабочем процессе, основанном на GitHub Actions, GitHub Copilot и GitHub Models, который предназначен для постоянного превращения каждой части пользовательской обратной связи в отслеживаемую, приоритетную и действенную задачу. Этот подход гарантирует, что ИИ улучшает человеческое суждение, оптимизируя повторяющиеся задачи и позволяя экспертам сосредоточиться на создании инклюзивного программного обеспечения.

Непрерывный ИИ: Живая система для инклюзивности

'Непрерывный ИИ для доступности' от GitHub — это больше, чем просто инструмент; это живая методология, которая интегрирует автоматизацию, искусственный интеллект и человеческий опыт для внедрения инклюзивности непосредственно в ткань разработки программного обеспечения. Эта философия лежит в основе обязательства GitHub по Дню всемирной осведомленности о доступности (GAAD) 2025 года, направленного на укрепление доступности во всей экосистеме открытого исходного кода путем эффективной маршрутизации и преобразования обратной связи от пользователей в значимые улучшения платформы.

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

Прежде чем приступить к технологическим решениям, GitHub применил подход проектирования, ориентированный на человека, определив ключевые персоны, которым система должна была служить:

• Отправители задач: Менеджеры сообщества, агенты поддержки и торговые представители, которым требуется руководство для эффективного сообщения о проблемах, даже без глубоких знаний в области доступности.
• Команды по доступности и обслуживанию: Инженеры и дизайнеры, которым требуются структурированные, действенные данные — такие как воспроизводимые шаги, сопоставление WCAG и оценки серьезности — для эффективного решения проблем.
• Менеджеры программ и продуктов: Руководство, нуждающееся в четком понимании болевых точек, тенденций и прогресса для принятия стратегических решений по распределению ресурсов.

Это фундаментальное понимание позволило GitHub разработать систему, которая рассматривает обратную связь как данные, проходящие через хорошо определенный конвейер, способный развиваться в соответствии с их потребностями.

Автоматизация конвейера обратной связи по доступности

GitHub построил свою новую архитектуру на основе событийно-ориентированной модели, где каждый шаг запускает GitHub Action для координации последующих действий, обеспечивая последовательную обработку обратной связи независимо от ее происхождения. Хотя изначально такая система была построена вручную в середине 2024 года, теперь ее можно разработать значительно быстрее, используя такие инструменты, как Agentic Workflows, которые позволяют создавать GitHub Actions с помощью естественного языка.

Рабочий процесс реагирует на ключевые события: создание задачи инициирует анализ GitHub Copilot через GitHub Models API, изменения статуса вызывают передачу задачи команде, а разрешение задачи инициирует последующее взаимодействие с первоначальным отправителем. Автоматизация охватывает общий путь, но люди могут вручную запускать или перезапускать любое действие, сохраняя надзор и гибкость.

Семиступенчатый рабочий процесс обратной связи:

1. Сбор: Обратная связь поступает из различных источников, таких как дискуссионная доска GitHub по доступности (на которую приходится 90% отчетов), тикеты поддержки, социационные сети и электронная почта. Вся обратная связь подтверждается в течение пяти рабочих дней. Для действенных элементов член команды вручную создает задачу отслеживания, используя пользовательский шаблон обратной связи по доступности, который фиксирует необходимый контекст. Это событие создания запускает GitHub Action для привлечения GitHub Copilot и добавления задачи на централизованную доску проектов.

2. Анализ Copilot: GitHub Action вызывает GitHub Models API для анализа вновь созданной задачи.

3. Проверка отправителем: Первоначальный отправитель просматривает анализ Copilot, подтверждая его точность или внося коррективы.

4. Проверка командой по доступности: Специализированная команда по доступности проводит более глубокий обзор и разрабатывает стратегию решений.

5. Связывание аудитов: Соответствующие аудиты или внешние ресурсы привязываются для контекста и соответствия требованиям.

6. Завершение цикла: После решения проблема официально закрывается, и первоначальный пользователь или клиент информируется об этом.

7. Улучшение: Обратная связь о производительности системы, включая анализ Copilot, служит основой для постоянных обновлений и доработок.

Этот непрерывный поток обеспечивает прозрачность, структурированность и действенность на каждом этапе жизненного цикла обратной связи.

Интеллектуальная сортировка доступности с помощью GitHub Copilot

В основе этой автоматизированной системы лежит интеллектуальный анализ GitHub Copilot. Когда создается задача отслеживания, рабочий процесс GitHub Action программно вызывает GitHub Models API для анализа отчета. GitHub сделал стратегический выбор в пользу использования сохраненных промптов (пользовательских инструкций) вместо тонкой настройки модели. Это позволяет любому члену команды обновлять поведение ИИ с помощью простого pull request, устраняя необходимость в сложных конвейерах переобучения или специализированных знаниях в области машинного обучения. Когда стандарты доступности развиваются, команда обновляет файлы markdown и инструкций, и поведение ИИ адаптируется при следующем запуске.

GitHub Copilot настроен с помощью пользовательских инструкций, разработанных их экспертами по доступности. Эти инструкции выполняют две критически важные роли:

• Анализ сортировки: Классификация задач по нарушению WCAG, серьезности (sev1-sev4) и затронутой группе пользователей.
• Обучение доступности: Руководство команд по написанию и проверке доступного кода.

Файлы инструкций ссылаются на политики доступности GitHub, библиотеку компонентов и внутреннюю документацию, предоставляя Copilot всестороннее понимание того, как интерпретировать и применять критерии успеха WCAG.

Автоматизация разворачивается в два ключевых шага:

1. Первое действие: При создании задачи Copilot анализирует отчет, автоматически заполняя примерно 80% метаданных задачи. Это включает более 40 точек данных, таких как тип задачи, сегмент пользователя, исходный источник, затронутые компоненты и резюме опыта пользователя. Затем Copilot публикует комментарий к задаче, содержащий краткое описание проблемы, предложенные критерии WCAG, уровень серьезности, затронутые группы пользователей, рекомендованное назначение команды и контрольный список для проверки.
2. Второе действие: Это последующее действие анализирует комментарий Copilot, применяет метки на основе назначенной серьезности, обновляет статус задачи на доске проектов и назначает ее отправителю для проверки.

Что особенно важно, если анализ Copilot неточен, любой может отметить это, открыв задачу с описанием расхождения, напрямую способствуя процессу непрерывного улучшения ИИ в GitHub.

Человеческий надзор и итеративные улучшения доступности

Рабочий процесс подчеркивает человеческий надзор и сотрудничество. После автоматического анализа Copilot, фаза 'проверки отправителем' (шаг 3) позволяет человеку-отправителю проверить выводы ИИ. Этот подход 'человек в контуре' обеспечивает точность и позволяет вносить ручные исправления или отмечать проблемы для процесса непрерывного улучшения Copilot. Последующие шаги — Проверка командой по доступности, Связывание аудитов и Завершение цикла — далее интегрируют человеческий опыт, гарантируя, что сложные проблемы решаются специалистами, а пользователи получают своевременные и эффективные решения.

Эта динамичная система представляет собой значительный сдвиг для GitHub. Используя ИИ для обработки повторяющихся и ресурсоемких аспектов управления обратной связью, они превратили хаотичный, часто застойный процесс в непрерывный, проактивный механизм для инклюзивности. Это означает, что каждая часть обратной связи по доступности теперь надежно отслеживается, приоритизируется и обрабатывается, выходя за рамки обещаний 'второй фазы' для обеспечения немедленных, ощутимых улучшений для всех пользователей. Конечная цель состоит не в том, чтобы заменить человеческое суждение, а в том, чтобы расширить его возможности, освободив ценное время и опыт для сосредоточения на стратегических исправлениях и содействия созданию по-настоящему доступного программного обеспечения.