Доступність: GitHub перетворює відгуки на інклюзію за допомогою безперервного ШІ

Революціонізація доступності: підхід GitHub з безперервним ШІ

Протягом багатьох років GitHub стикався з поширеною, але критичною проблемою: ефективним управлінням зворотним зв’язком щодо доступності. На відміну від типових проблем з продуктами, проблеми доступності є всепроникними, часто стосуються багатьох команд і систем. Єдиний звіт від користувача програми для читання з екрана може стосуватися навігації, автентифікації та налаштувань, що робить традиційні ізольовані процеси зворотного зв’язку неефективними. Це призводило до розрізнених звітів, невирішених помилок і розчарування користувачів, чиї проблеми залишалися в міфічній "другій фазі", яка рідко матеріалізувалася.

Усвідомлюючи необхідність фундаментальних змін, GitHub розпочав шлях до централізації зворотного зв’язку, створення стандартизованих шаблонів та очищення значного беклогу. Лише після створення цієї міцної основи виникло питання: як ШІ може ще більше трансформувати цей процес? Відповідь полягає в інноваційному внутрішньому робочому процесі, що працює на базі GitHub Actions, GitHub Copilot та GitHub Models, розробленому для безперервного перетворення кожного фрагмента відгуку користувача на відстежуване, пріоритизоване та дієве завдання. Цей підхід гарантує, що ШІ покращує людське судження, оптимізуючи повторювані завдання та дозволяючи експертам зосередитися на створенні інклюзивного програмного забезпечення.

Безперервний ШІ: жива система для інклюзії

"Безперервний ШІ для доступності" від GitHub – це більше, ніж просто інструмент; це жива методологія, яка інтегрує автоматизацію, штучний інтелект та людський досвід, щоб вбудувати інклюзію безпосередньо в основу розробки програмного забезпечення. Ця філософія підкріплює зобов’язання GitHub щодо Глобального дня обізнаності про доступність (GAAD) 2025 року, спрямованого на посилення доступності в екосистемі відкритого вихідного коду шляхом ефективного спрямування та перетворення зворотного зв’язку користувачів у значущі покращення платформи.

Ключовим усвідомленням було те, що найвагоміші прориви походять від слухання реальних людей, але слухання в масштабі створює значні труднощі. Щоб подолати це, GitHub створив робочий процес зворотного зв’язку, який функціонує як динамічний механізм, а не як статична система квитків. Використовуючи власні продукти, GitHub уточнює, структурує та відстежує відгуки користувачів і клієнтів, перетворюючи їх на готові до впровадження рішення.

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

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

Це базове розуміння дозволило GitHub розробити систему, яка розглядає зворотний зв’язок як дані, що проходять через чітко визначений конвеєр, здатний розвиватися відповідно до їхніх потреб.

Автоматизація конвеєра зворотного зв’язку щодо доступності

GitHub побудував свою нову архітектуру навколо керованої подіями моделі, де кожен крок запускає GitHub Action для організації подальших дій, забезпечуючи послідовну обробку зворотного зв’язку незалежно від його походження. Хоча спочатку така система була створена вручну в середині 2024 року, тепер її можна розробити значно швидше за допомогою таких інструментів, як Агентні робочі процеси, які дозволяють створювати 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. Використовуючи ШІ для обробки повторюваних та інтенсивних щодо даних аспектів управління зворотним зв’язком, вони перетворили хаотичний, часто застійний процес на безперервний, проактивний двигун для інклюзії. Це означає, що кожен відгук щодо доступності тепер надійно відстежується, пріоритизується та вживаються відповідні дії, виходячи за рамки обіцянок "другої фази", щоб забезпечити негайні, відчутні покращення для всіх користувачів. Кінцева мета полягає не в тому, щоб замінити людське судження, а в тому, щоб розширити його можливості, вивільнивши цінний час та досвід для зосередження на стратегічних виправленнях та створенні справді доступного програмного забезпечення.