Tilgjengelighet: GitHub forvandler tilbakemeldinger til inkludering med kontinuerlig AI

Revolusjonerer tilgjengelighet: GitHubs kontinuerlige AI-tilnærming

I årevis sto GitHub overfor en vanlig, men kritisk utfordring: effektivt å håndtere tilbakemeldinger om tilgjengelighet. I motsetning til typiske produktproblemer er tilgjengelighetsbekymringer gjennomgripende, og krysser ofte flere team og systemer. En enkelt rapport fra en skjermleserbruker kan berøre navigasjon, autentisering og innstillinger, noe som gjør tradisjonelle silo-baserte tilbakemeldingsprosesser ineffektive. Dette førte til spredte rapporter, uløste feil, og frustrasjon hos brukere hvis problemer hang i en mytisk "fase to" som sjelden materialiserte seg.

I erkjennelse av behovet for et grunnleggende skifte, la GitHub ut på en reise for å sentralisere tilbakemeldinger, opprette standardiserte maler og rydde opp i et betydelig etterslep. Først etter å ha etablert dette robuste grunnlaget oppsto spørsmålet: Hvordan kunne AI transformere denne prosessen ytterligere? Svaret ligger i en innovativ intern arbeidsflyt, drevet av GitHub Actions, GitHub Copilot og GitHub Models, designet for kontinuerlig å transformere hver bit av brukertilbakemelding til en sporet, prioritert og handlingsrettet sak. Denne tilnærmingen sikrer at AI forbedrer menneskelig dømmekraft, strømlinjeformer repeterende oppgaver og lar eksperter fokusere på å levere inkluderende programvare.

Kontinuerlig AI: Et levende system for inkludering

GitHubs 'Kontinuerlig AI for tilgjengelighet' er mer enn bare et verktøy; det er en levende metodikk som integrerer automatisering, kunstig intelligens og menneskelig ekspertise for å forankre inkludering direkte i programvareutviklingens struktur. Denne filosofien underbygger GitHubs forpliktelse til løftet til Global Accessibility Awareness Day (GAAD) i 2025, med mål om å styrke tilgjengeligheten på tvers av åpen kildekode-økosystemet ved effektivt å rute og oversette brukertilbakemeldinger til meningsfulle plattformforbedringer.

Kjernerealiteten var at de mest virkningsfulle gjennombruddene stammer fra å lytte til virkelige mennesker, men å lytte i stor skala byr på betydelige utfordringer. For å overvinne dette bygget GitHub en tilbakemeldingsflyt som fungerer som en dynamisk motor i stedet for et statisk billettsystem. Ved å utnytte sine egne produkter klargjør, strukturerer og sporer GitHub bruker- og kundetilbakemeldinger, og konverterer dem til implementeringsklare løsninger.

Før GitHub dykket ned i teknologiske løsninger, tok de i bruk en menneske-først-design-tilnærming, og identifiserte nøkkelpersoner som systemet måtte betjene:

• Saksinnsendere: Fellesskapsledere, støtteagenter og salgsrepresentanter som trenger veiledning for å rapportere problemer effektivt, selv uten dyp tilgjengelighetsekspertise.
• Tilgjengelighets- og serviceteam: Ingeniører og designere som krever strukturerte, handlingsrettede data – som reproduserbare trinn, WCAG-kartlegging og alvorlighetsgrader – for å effektivt løse problemer.
• Program- og produktsjefer: Lederskap som trenger klar innsikt i problempunkter, trender og fremdrift for å ta strategiske beslutninger om ressursallokering.

Denne grunnleggende forståelsen gjorde at GitHub kunne designe et system som behandler tilbakemeldinger som data som flyter gjennom en veldefinert pipeline, i stand til å utvikle seg med deres behov.

Automatisering av tilbakemeldings-pipelinen for tilgjengelighet

GitHub konstruerte sin nye arkitektur rundt et hendelsesdrevet mønster, der hvert trinn utløser en GitHub Action for å orkestrere påfølgende handlinger, noe som sikrer konsekvent håndtering av tilbakemeldinger uavhengig av deres opprinnelse. Mens et slikt system opprinnelig ble bygget manuelt midt i 2024, kan det nå utvikles betydelig raskere ved hjelp av verktøy som Agentic Workflows, som tillater opprettelse av GitHub Actions gjennom naturlig språk.

Arbeidsflyten reagerer på nøkkelhendelser: saksopprettelse initierer GitHub Copilot-analyse via GitHub Models API, statusendringer utløser teamoverleveringer, og saksløsning utløser oppfølging med den opprinnelige innsenderen. Automatiseringen dekker den vanlige veien, men mennesker kan manuelt utløse eller kjøre enhver Action på nytt, noe som opprettholder tilsyn og fleksibilitet.

Arbeidsflyten for tilbakemeldinger i syv trinn:

1. Inntak: Tilbakemeldinger strømmer inn fra ulike kilder som GitHubs diskusjonsforum for tilgjengelighet (som står for 90 % av rapportene), støttebilletter, sosiale medier og e-post. Alle tilbakemeldinger bekreftes innen fem virkedager. For handlingsrettede elementer oppretter et teammedlem manuelt en sporingssak ved hjelp av en egendefinert mal for tilbakemelding om tilgjengelighet, som fanger opp viktig kontekst. Denne opprettelseshendelsen utløser en GitHub Action for å engasjere GitHub Copilot og legge saken til et sentralisert prosjektstyre.

2. Copilot-analyse: En GitHub Action kaller GitHub Models API for å analysere den nyopprettede saken.

3. Innsenderanmeldelse: Den opprinnelige innsenderen gjennomgår Copilots analyse, bekrefter nøyaktigheten eller gjør justeringer.

4. Tilgjengelighetsteamets gjennomgang: Det spesialiserte tilgjengelighetsteamet utfører en dypere gjennomgang og strategilegger løsninger.

5. Kobling av revisjoner: Relevante revisjoner eller eksterne ressurser kobles for kontekst og etterlevelse.

6. Lukking av sløyfen: Når saken er adressert, lukkes den formelt, og den opprinnelige brukeren eller kunden blir informert.

7. Forbedring: Tilbakemeldinger om systemets ytelse, inkludert Copilots analyse, informerer om kontinuerlige oppdateringer og forbedringer.

Denne kontinuerlige flyten sikrer synlighet, struktur og handlingsdyktighet i alle stadier av tilbakemeldingslivssyklusen.

GitHub Copilots intelligente tilgjengelighetssortering

Kjernen i dette automatiserte systemet er GitHub Copilots intelligente analyse. Når en sporingssak opprettes, kaller en GitHub Action-arbeidsflyt programmatisk GitHub Models API for å analysere rapporten. GitHub tok et strategisk valg om å bruke lagrede prompter (egendefinerte instruksjoner) i stedet for modellfinjustering. Dette gjør at ethvert teammedlem kan oppdatere AI-ens atferd via en enkel pull-forespørsel, noe som eliminerer behovet for komplekse retreningspipeline eller spesialisert maskinlæringskunnskap. Når tilgjengelighetsstandarder utvikler seg, oppdaterer teamet markdown- og instruksjonsfiler, og AI-ens atferd tilpasser seg med neste kjøring.

GitHub Copilot er konfigurert med egendefinerte instruksjoner utviklet av deres tilgjengelighetseksperter. Disse instruksjonene tjener to kritiske roller:

• Sorteringsanalyse: Klassifisering av problemer etter WCAG-brudd, alvorlighetsgrad (sev1-sev4) og berørt brukergruppe.
• Tilgjengelighetscoaching: Veiledning av team i skriving og gjennomgang av tilgjengelig kode.

Instruksjonsfilene refererer til GitHubs tilgjengelighetspolicyer, komponentbibliotek og intern dokumentasjon, og gir Copilot en omfattende forståelse av hvordan WCAG-suksesskriterier skal tolkes og anvendes.

Automatiseringen utfolder seg i to viktige trinn:

1. Første handling: Ved opprettelse av saken analyserer Copilot rapporten, og fyller automatisk ut omtrent 80 % av sakens metadata. Dette inkluderer over 40 datapunkter som sakstype, brukersegment, opprinnelig kilde, berørte komponenter og et sammendrag av brukerens opplevelse. Copilot legger deretter inn en kommentar på saken som inneholder et problemsammendrag, foreslåtte WCAG-kriterier, alvorlighetsgrad, berørte brukergrupper, anbefalt teamtildeling og en sjekkliste for verifisering.
2. Andre handling: Denne påfølgende handlingen tolker Copilots kommentar, bruker etiketter basert på tildelt alvorlighetsgrad, oppdaterer sakens status på prosjektstyret, og tildeler den til innsenderen for gjennomgang.

Avgjørende er at hvis Copilots analyse er unøyaktig, kan hvem som helst flagge det ved å opprette en sak som beskriver avviket, noe som direkte bidrar til GitHubs kontinuerlige forbedringsprosess for AI-en.

Menneskelig tilsyn og iterative tilgjengelighetsforbedringer

Arbeidsflyten legger vekt på menneskelig tilsyn og samarbeid. Etter Copilots automatiserte analyse, tillater 'innsenderanmeldelse'-fasen (trinn 3) at den menneskelige innsenderen verifiserer AI-ens funn. Denne menneske-i-sløyfen-tilnærmingen sikrer nøyaktighet og tillater manuelle korreksjoner eller flagg for Copilots kontinuerlige forbedringsprosess. De påfølgende trinnene – Tilgjengelighetsteamets gjennomgang, Kobling av revisjoner og Lukking av sløyfen – integrerer ytterligere menneskelig ekspertise, og sikrer at komplekse problemer adresseres av spesialister og at brukere mottar rettidige, effektive løsninger.

Dette dynamiske systemet representerer et betydelig skifte for GitHub. Ved å utnytte AI til å håndtere de repeterende og dataintensive aspektene ved tilbakemeldingshåndtering, har de forvandlet en kaotisk, ofte stillestående prosess til en kontinuerlig, proaktiv motor for inkludering. Dette betyr at hver bit av tilbakemelding om tilgjengelighet nå pålitelig spores, prioriteres og handles på, og beveger seg utover løfter om "fase to" for å levere umiddelbare, håndgripelige forbedringer for alle brukere. Det ultimate målet er ikke å erstatte menneskelig dømmekraft, men å styrke den, frigjøre verdifull tid og ekspertise for å fokusere på strategiske fikser og fremme en virkelig tilgjengelig programvareopplevelse.