Code Velocity
Utvecklarverktyg

Tillgänglighet: GitHub förvandlar feedback till inkludering med kontinuerlig AI

·7 min läsning·GitHub·Originalkälla
Dela
Flödesschema som illustrerar GitHubs kontinuerliga AI-arbetsflöde för tillgänglighetsfeedback.

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:

  1. 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.

  2. Copilot-analys: En GitHub Action anropar GitHub Models API för att analysera det nyskapade ärendet.

  3. Inlämnarens granskning: Den ursprungliga inlämnaren granskar Copilots analys, bekräftar dess noggrannhet eller gör justeringar.

  4. Tillgänglighetsteamets granskning: Det specialiserade tillgänglighetsteamet genomför en djupare granskning och lägger upp strategier för lösningar.

  5. Länka revisioner: Relevanta revisioner eller externa resurser länkas för kontext och efterlevnad.

  6. Stäng slinga: När ärendet har åtgärdats stängs det formellt, och den ursprungliga användaren eller kunden informeras.

  7. 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:

  1. 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.
  2. 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?
Prior to the new system, GitHub struggled with a decentralized and inconsistent approach to accessibility feedback. Issues were often scattered across various backlogs, lacked clear ownership, and improvements were frequently postponed. This disorganization led to a lack of follow-through, leaving users with unaddressed concerns and creating a barrier to truly inclusive software development. The cross-cutting nature of accessibility issues, touching multiple teams, exacerbated these coordination challenges, making it difficult to establish a single point of responsibility or a coherent workflow for resolution.
What defines 'Continuous AI for accessibility' and how does it enhance traditional accessibility efforts?
Continuous AI for accessibility is a dynamic methodology that integrates automation, artificial intelligence, and human expertise into the software development lifecycle. Unlike static audits or one-time fixes, it's a living system designed to continuously process and act on user feedback. It goes beyond simple code scanners by actively listening to real people and using AI, particularly GitHub Copilot and GitHub Actions, to clarify, structure, and prioritize that feedback. This ensures that inclusion is woven into the very fabric of development, transforming scattered reports into implementation-ready solutions and fostering ongoing improvement.
How does GitHub Copilot specifically contribute to the efficiency and effectiveness of the accessibility feedback workflow?
GitHub Copilot plays a crucial role by providing intelligent triage and analysis of accessibility reports. Upon issue creation, Copilot, guided by custom instructions from accessibility subject matter experts, programmatically analyzes the report. It automatically populates approximately 80% of an issue's metadata, including WCAG violation classifications, severity levels, affected user groups, and recommended team assignments. This automated analysis significantly reduces manual effort, standardizes issue categorization, and provides immediate, actionable insights, allowing human teams to focus on problem-solving rather-than repetitive data entry and initial assessment.
What are GitHub's 'custom instructions' for Copilot, and why were they chosen over model fine-tuning for this system?
GitHub utilizes 'custom instructions' for Copilot, developed by their accessibility subject matter experts, to guide its behavior for triage analysis and accessibility coaching. These instructions are stored prompts that point to GitHub’s accessibility policies, component library, and internal documentation, detailing how WCAG success criteria are interpreted and applied. This approach was chosen over model fine-tuning because it allows for rapid iteration and team-wide updates. Any team member can update the AI's behavior by modifying markdown and instruction files via a pull request, eliminating the need for complex retraining pipelines or specialized ML knowledge, ensuring the AI's behavior evolves as standards do.
How does GitHub ensure that human judgment and oversight remain central to the accessibility process despite the extensive use of AI automation?
GitHub deliberately designed its system so that AI automates repetitive tasks while humans retain critical judgment and oversight. For example, after GitHub Copilot's initial analysis, a 'submitter review' step ensures a human verifies Copilot's findings. If Copilot's analysis is incorrect, humans can flag it, providing direct feedback for continuous improvement of the AI. Furthermore, every GitHub Action in the workflow can be manually triggered or re-run, ensuring that humans can intervene at any point. The goal is to offload mundane work to AI, empowering humans to focus on complex problem-solving, collaboration, and making informed decisions about software fixes.
Who are the primary beneficiaries of GitHub's enhanced accessibility feedback system, and how does it cater to their specific needs?
The system serves three primary groups. Issue submitters (community managers, support agents, sales reps) benefit from a guided system that standardizes feedback collection and educates them on accessibility concepts. Accessibility and service teams (engineers, designers) receive structured, actionable data including reproducible steps, WCAG mapping, and clear ownership, streamlining their remediation efforts. Program and product managers gain visibility into pain points, trends, and progress, enabling strategic resource allocation. Ultimately, the biggest beneficiaries are the users and customers with disabilities whose feedback is now consistently tracked, prioritized, and acted upon, leading to a more inclusive GitHub experience.
How does GitHub integrate user feedback from external sources into its internal accessibility process, ensuring consistency and actionability?
GitHub acknowledges that accessibility feedback can originate from diverse external sources, including support tickets, social media, email, and direct outreach, with the GitHub accessibility discussion board being a primary channel. Regardless of the source, every piece of feedback is acknowledged within five business days. When external feedback requires action, a team member manually creates an internal tracking issue using a custom accessibility feedback template. This template standardizes the collected information, preventing data loss. This new issue then triggers an automated GitHub Action, engaging GitHub Copilot for analysis and adding it to a centralized project board, ensuring consistent processing and action regardless of its origin.

Håll dig uppdaterad

Få de senaste AI-nyheterna i din inkorg.

Dela