Revolutionerar tillgänglighet: GitHubs kontinuerliga AI-strategi
I åratal stod GitHub inför en vanlig men kritisk utmaning: att effektivt hantera tillgänglighetsfeedback. Till skillnad från typiska produktproblem är tillgänglighetsfrågor genomgripande och sträcker sig ofta över flera team och system. En enda rapport från en skärmläsaranvändare kan beröra navigering, autentisering och inställningar, vilket gör traditionella, siloade feedbackprocesser ineffektiva. Detta ledde till spridda rapporter, olösta buggar och frustration hos användare vars problem dröjde kvar i en mytisk 'fas två' som sällan materialiserades.
GitHub insåg behovet av en grundläggande förändring och påbörjade en resa för att centralisera feedback, skapa standardiserade mallar och rensa en betydande eftersläpning. Först efter att denna robusta grund etablerats uppstod frågan: Hur kunde AI ytterligare omvandla denna process? Svaret ligger i ett innovativt internt arbetsflöde, drivet av GitHub Actions, GitHub Copilot och GitHub Models, utformat för att kontinuerligt omvandla varje del av användarfeedback till ett spårat, prioriterat och handlingsbart ärende. Denna strategi säkerställer att AI förbättrar mänskligt omdöme, effektiviserar repetitiva uppgifter och låter experter fokusera på att leverera inkluderande programvara.
Kontinuerlig AI: Ett levande system för inkludering
GitHubs 'kontinuerliga AI för tillgänglighet' är mer än bara ett verktyg; det är en levande metodik som integrerar automatisering, artificiell intelligens och mänsklig expertis för att bädda in inkludering direkt i programvaruutvecklingens vävnad. Denna filosofi ligger till grund för GitHubs åtagande i löftet för Global Accessibility Awareness Day (GAAD) 2025, med syftet att stärka tillgängligheten i hela open source-ekosystemet genom att effektivt dirigera och översätta användarfeedback till meningsfulla plattformförbättringar.
Kärnan i insikten var att de mest betydande genombrotten kommer från att lyssna på riktiga människor, men att lyssna i stor skala innebär betydande utmaningar. För att övervinna detta byggde GitHub ett feedback-arbetsflöde som fungerar som en dynamisk motor snarare än ett statiskt ärendehanteringssystem. Genom att utnyttja sina egna produkter förtydligar, strukturerar och spårar GitHub användar- och kundfeedback och omvandlar den till implementeringsklara lösningar.
Innan GitHub dök in i tekniska lösningar antog de en 'människan först'-designstrategi och identifierade nyckelpersoner som systemet behövde tjäna:
- Ärendeinsändare: Community managers, supportagenter och säljare som behöver vägledning för att rapportera problem effektivt, även utan djup expertis inom tillgänglighet.
- Tillgänglighets- och serviceteam: Ingenjörer och designers som behöver strukturerad, handlingsbar data – såsom reproducerbara steg, WCAG-mappning och allvarlighetsgrader – för att effektivt lösa problem.
- Program- och produktchefer: Ledning som behöver tydlig insikt i problemområden, trender och framsteg för att fatta strategiska beslut om resursallokering.
Denna grundläggande förståelse gjorde det möjligt för GitHub att designa ett system som behandlar feedback som data som flödar genom en väldefinierad pipeline, kapabel att utvecklas med deras behov.
Automatiserar feedbackpipelinen för tillgänglighet
GitHub konstruerade sin nya arkitektur kring ett händelsedrivet mönster, där varje steg utlöser en GitHub Action för att orkestrera efterföljande åtgärder, vilket säkerställer konsekvent hantering av feedback oavsett dess ursprung. Även om det ursprungligen byggdes manuellt i mitten av 2024, kan ett sådant system nu utvecklas betydligt snabbare med verktyg som Agentic Workflows, som möjliggör skapande av GitHub Actions genom naturligt språk.
Arbetsflödet svarar på nyckelhändelser: skapandet av ett ärende initierar GitHub Copilot-analys via GitHub Models API, statusändringar utlöser teamöverlämningar, och ärendeupplösning föranleder uppföljning med den ursprungliga inlämnaren. Automatiseringen täcker den vanliga sökvägen, men människor kan manuellt utlösa eller köra om vilken Action som helst, vilket bibehåller tillsyn och flexibilitet.
Arbetsflödet för feedback i sju steg:
-
Intag: Feedback flödar från olika källor som GitHubs diskussionsforum för tillgänglighet (som står för 90% av rapporterna), supportärenden, sociala medier och e-post. All feedback bekräftas inom fem arbetsdagar. För åtgärdbara punkter skapar en teammedlem manuellt ett spårningsärende med hjälp av en anpassad mall för tillgänglighetsfeedback, som fångar upp viktig kontext. Denna skapelsehändelse utlöser en GitHub Action för att engagera GitHub Copilot och lägga till ärendet på en centraliserad projekttavla.
-
Copilot-analys: En GitHub Action anropar GitHub Models API för att analysera det nyskapade ärendet.
-
Inlämnarens granskning: Den ursprungliga inlämnaren granskar Copilots analys, bekräftar dess noggrannhet eller gör justeringar.
-
Tillgänglighetsteamets granskning: Det specialiserade tillgänglighetsteamet genomför en djupare granskning och lägger upp strategier för lösningar.
-
Länka revisioner: Relevanta revisioner eller externa resurser länkas för kontext och efterlevnad.
-
Stäng slinga: När ärendet har åtgärdats stängs det formellt, och den ursprungliga användaren eller kunden informeras.
-
Förbättring: Feedback om systemets prestanda, inklusive Copilots analys, informerar om kontinuerliga uppdateringar och förfiningar.
Detta kontinuerliga flöde säkerställer synlighet, struktur och handlingsbarhet i varje steg av feedbackens livscykel.
GitHub Copilots intelligenta tillgänglighetssortering
I hjärtat av detta automatiserade system finns GitHub Copilots intelligenta analys. När ett spårningsärende skapas, anropar ett GitHub Action-arbetsflöde programmatiskt GitHub Models API för att analysera rapporten. GitHub gjorde ett strategiskt val att använda lagrade prompter (anpassade instruktioner) istället för finjustering av modellen. Detta gör att varje teammedlem kan uppdatera AI:ns beteende via en enkel pull request, vilket eliminerar behovet av komplexa omskolningspipelines eller specialiserad maskininlärningskunskap. När tillgänglighetsstandarder utvecklas, uppdaterar teamet markdown- och instruktionsfiler, och AI:ns beteende anpassar sig med nästa körning.
GitHub Copilot är konfigurerad med anpassade instruktioner utvecklade av deras ämnesexperter inom tillgänglighet. Dessa instruktioner fyller två kritiska roller:
- Sorteringsanalys: Klassificering av ärenden efter WCAG-överträdelse, allvarlighetsgrad (sev1-sev4) och berörd användargrupp.
- Tillgänglighetsvägledning: Att vägleda team i att skriva och granska tillgänglig kod.
Instruktionsfilerna hänvisar till GitHubs tillgänglighetspolicyer, komponentbibliotek och intern dokumentation, vilket ger Copilot en omfattande förståelse för hur WCAG:s framgångskriterier ska tolkas och tillämpas.
Automatiseringen utvecklas i två nyckelsteg:
- Första åtgärden: Vid skapandet av ett ärende analyserar Copilot rapporten och fyller automatiskt i cirka 80% av ärendets metadata. Detta inkluderar över 40 datapunkter såsom ärendetyp, användarsegment, originalkälla, berörda komponenter och en sammanfattning av användarens upplevelse. Copilot postar sedan en kommentar på ärendet som innehåller en problemsammanfattning, föreslagna WCAG-kriterier, allvarlighetsgrad, påverkade användargrupper, rekommenderad teamtilldelning och en checklista för verifiering.
- Andra åtgärden: Denna efterföljande åtgärd parsar Copilots kommentar, tillämpar etiketter baserade på den tilldelade allvarlighetsgraden, uppdaterar ärendets status på projekttavlan och tilldelar det till inlämnaren för granskning.
Avgörande är att om Copilots analys är felaktig kan vem som helst flagga det genom att öppna ett ärende som beskriver avvikelsen, vilket direkt matar in i GitHubs kontinuerliga förbättringsprocess för AI:n.
Mänsklig tillsyn och iterativa tillgänglighetsförbättringar
Arbetsflödet betonar mänsklig tillsyn och samarbete. Efter Copilots automatiserade analys tillåter 'inlämnarens granskning'-fasen (steg 3) den mänskliga inlämnaren att verifiera AI:ns fynd. Detta 'människan i loopen'-tillvägagångssätt säkerställer noggrannhet och möjliggör manuella korrigeringar eller flaggningar för Copilots kontinuerliga förbättringsprocess. De efterföljande stegen – Tillgänglighetsteamets granskning, Länka revisioner och Stäng slinga – integrerar ytterligare mänsklig expertis, vilket säkerställer att komplexa problem hanteras av specialister och att användare får snabba och effektiva lösningar.
Detta dynamiska system representerar en betydande förändring för GitHub. Genom att utnyttja AI för att hantera de repetitiva och dataintensiva aspekterna av feedbackhantering har de förvandlat en kaotisk, ofta stagnerande process till en kontinuerlig, proaktiv motor för inkludering. Detta innebär att varje del av tillgänglighetsfeedback nu spåras, prioriteras och åtgärdas på ett tillförlitligt sätt, och går bortom löften om 'fas två' för att leverera omedelbara, påtagliga förbättringar för alla användare. Det slutliga målet är inte att ersätta mänskligt omdöme utan att stärka det, frigöra värdefull tid och expertis för att fokusera på strategiska korrigeringar och främja en verkligt tillgänglig programvarupplevelse.
Vanliga frågor
What challenges did GitHub face with accessibility feedback before implementing its Continuous AI system?
What defines 'Continuous AI for accessibility' and how does it enhance traditional accessibility efforts?
How does GitHub Copilot specifically contribute to the efficiency and effectiveness of the accessibility feedback workflow?
What are GitHub's 'custom instructions' for Copilot, and why were they chosen over model fine-tuning for this system?
How does GitHub ensure that human judgment and oversight remain central to the accessibility process despite the extensive use of AI automation?
Who are the primary beneficiaries of GitHub's enhanced accessibility feedback system, and how does it cater to their specific needs?
How does GitHub integrate user feedback from external sources into its internal accessibility process, ensuring consistency and actionability?
Håll dig uppdaterad
Få de senaste AI-nyheterna i din inkorg.
