Пристапност: 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, промените на статусот активираат префрлање на тимот, а решавањето проблем поттикнува следење со првичниот подносител. Автоматизацијата ја опфаќа заедничката патека, но луѓето можат рачно да активираат или рестартираат која било Action, одржувајќи надзор и флексибилност.

Работeн тек за повратни информации во седум чекори:

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 направи стратешки избор да користи зачувани барања (прилагодени инструкции) наместо фино подесување на моделот. Ова овозможува секој член на тимот да го ажурира однесувањето на ВИ преку едноставно барање за спојување, елиминирајќи ја потребата за сложени цевководи за преквалификација или специјализирано знаење за машинско учење. Кога стандардите за пристапност еволуираат, тимот ги ажурира датотеките со markdown и инструкции, а однесувањето на ВИ се прилагодува со следното извршување.

GitHub Copilot е конфигуриран со прилагодени инструкции развиени од нивните експерти за пристапност. Овие инструкции служат за две клучни улоги:

• Тријажна анализа: Класифицирање проблеми по прекршување на WCAG, сериозност (sev1-sev4) и засегната корисничка група.
• Тренирање за пристапност: Водење на тимови во пишување и прегледување достапен код.

Датотеките со инструкции се однесуваат на политиките за пристапност на GitHub, библиотеката на компоненти и внатрешната документација, обезбедувајќи му на Copilot сеопфатно разбирање за тоа како да ги толкува и применува критериумите за успех на WCAG.

Автоматизацијата се одвива во два клучни чекори:

1. Прва акција: При креирањето на проблем, Copilot го анализира извештајот, автоматски пополнувајќи приближно 80% од метаподатоците на проблемот. Ова вклучува над 40 точки на податоци како што се тип на проблем, сегмент на корисник, оригинален извор, засегнати компоненти и резиме на корисничкото искуство. Copilot потоа објавува коментар за проблемот кој содржи резиме на проблемот, предложени критериуми на WCAG, ниво на сериозност, засегнати кориснички групи, препорачана тимска задача и листа за проверка за верификација.
2. Втора акција: Оваа последователна Action го анализира коментарот на Copilot, применува етикети врз основа на доделената сериозност, го ажурира статусот на проблемот на проектната табла и му го доделува на подносителот за преглед.

Клучно, ако анализата на Copilot е неточна, секој може да ја означи со отворање проблем што ја опишува неусогласеноста, директно хранејќи го процесот на континуирано подобрување на GitHub за ВИ.

Човечки надзор и итеративни подобрувања на пристапноста

Работeн тек ја нагласува човечкиот надзор и соработката. По автоматизираната анализа на Copilot, фазата „преглед на подносителот“ (чекор 3) му овозможува на човечкиот подносител да ги потврди наодите на ВИ. Овој пристап со човек во процесот обезбедува точност и овозможува рачни корекции или ознаки за процесот на континуирано подобрување на Copilot. Последователните чекори – Преглед од тим за пристапност, Поврзување ревизии и Затворање на циклусот – дополнително ја интегрираат човечката експертиза, осигурувајќи дека сложените проблеми се решаваат од специјалисти и дека корисниците добиваат навремени, ефективни решенија.

Овој динамичен систем претставува значајна промена за GitHub. Со користење на ВИ за справување со повторливите и интензивни аспекти на управувањето со повратни информации, тие го трансформираа хаотичниот, честопати стагнирачки процес во континуиран, проактивен мотор за инклузија. Ова значи дека секој дел од повратните информации за пристапност сега сигурно се следи, приоритизира и се дејствува врз него, надминувајќи ги ветувањата за „фаза два“ за да испорача моментални, опипливи подобрувања за сите корисници. Крајната цел не е да се замени човечката проценка, туку да се зајакне, ослободувајќи драгоцено време и експертиза за да се фокусира на стратешки поправки и да се поттикне навистина достапно софтверско искуство.