Достъпност: 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 чрез API на GitHub Models, промените в състоянието задействат прехвърляне на екип, а разрешаването на проблем подканва проследяване с първоначалния подател. Автоматизацията обхваща общия път, но хората могат ръчно да задействат или преизпълнят всяко Action, поддържайки надзор и гъвкавост.

Седемстепенният работен поток за обратна връзка:

1. Приемане: Обратната връзка постъпва от различни източници като дискусионния борд за достъпност на GitHub (който отговаря за 90% от докладите), билети за поддръжка, социални медии и имейл. Цялата обратна връзка се потвърждава в рамките на пет работни дни. За елементи, изискващи действие, член на екипа ръчно създава проблем за проследяване, използвайки персонализиран шаблон за обратна връзка за достъпност, който улавя основния контекст. Това събитие за създаване задейства GitHub Action, за да ангажира GitHub Copilot и да добави проблема към централизиран проектен борд.

2. Анализ от Copilot: GitHub Action извиква API на GitHub Models, за да анализира новосъздадения проблем.

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

4. Преглед от екипа по достъпност: Специализираният екип по достъпност извършва по-задълбочен преглед и разработва стратегии за решения.

5. Свързване на одити: Релевантни одити или външни ресурси се свързват за контекст и съответствие.

6. Затваряне на цикъла: След като е разрешен, проблемът се затваря официално и оригиналният потребител или клиент се информира.

7. Подобрение: Обратната връзка за производителността на системата, включително анализа на Copilot, информира непрекъснатите актуализации и подобрения.

Този непрекъснат поток осигурява видимост, структура и приложимост на всеки етап от жизнения цикъл на обратната връзка.

Интелигентно приоритизиране на достъпността от GitHub Copilot

В основата на тази автоматизирана система е интелигентният анализ на GitHub Copilot. Когато се създаде проблем за проследяване, работен поток на GitHub Action програмно извиква API на GitHub Models, за да анализира доклада. 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. Използвайки ИИ за обработка на повтарящите се и интензивни по отношение на данни аспекти на управлението на обратната връзка, те са трансформирали хаотичен, често застоял процес в непрекъснат, проактивен двигател за приобщаване. Това означава, че всяка част от обратната връзка за достъпност вече е надеждно проследявана, приоритизирана и се действа по нея, надхвърляйки обещанията за „фаза две“, за да осигури незабавни, осезаеми подобрения за всички потребители. Крайната цел не е да се замени човешката преценка, а да се овласти, освобождавайки ценно време и експертиза за фокусиране върху стратегически корекции и насърчаване на наистина достъпно софтуерно изживяване.