Toeganklikheid: GitHub omskep terugvoer in insluiting met deurlopende KI

Revolusionering van Toeganklikheid: GitHub se Deurlopende KI-Benadering

Vir jare het GitHub 'n algemene dog kritieke uitdaging ondervind: die effektiewe bestuur van toeganklikheidsterugvoer. Anders as tipiese produkkwessies, is toeganklikheidsbekommernisse deurdringend, en sny dit dikwels oor verskeie spanne en stelsels. 'n Enkele verslag van 'n skermlesergebruiker kan navigasie, verifikasie en instellings raak, wat tradisionele gesegmenteerde terugvoervloeiprosesse ondoeltreffend maak. Dit het gelei tot verspreide verslae, onopgeloste foute en die frustrasie van gebruikers wie se kwessies in 'n mitiese "fase twee" gebly het wat selde gerealiseer het.

Met die erkenning van die behoefte aan 'n fundamentele verskuiwing, het GitHub 'n reis onderneem om terugvoer te sentraliseer, gestandaardiseerde sjablone te skep, en 'n beduidende agterstand uit te wis. Eers nadat hierdie robuuste grondslag gevestig is, het die vraag ontstaan: Hoe kan KI hierdie proses verder transformeer? Die antwoord lê in 'n innoverende interne vloeiproses, aangedryf deur GitHub Actions, GitHub Copilot, en GitHub Models, ontwerp om elke stukkie gebruikers terugvoer deurlopend te omskep in 'n nagespoorde, geprioritiseerde en uitvoerbare kwessie. Hierdie benadering verseker dat KI menslike oordeel verbeter, herhalende take stroomlyn en kundiges toelaat om te fokus op die lewering van insluitende sagteware.

Deurlopende KI: 'n Lewende Stelsel vir Insluiting

GitHub se "Deurlopende KI vir toeganklikheid" is meer as net 'n hulpmiddel; dit is 'n lewende metodologie wat outomatisering, kunsmatige intelligensie en menslike kundigheid integreer om insluiting direk in die wese van sagteware-ontwikkeling in te bed. Hierdie filosofie ondersteun GitHub se verbintenis tot die 2025 Global Accessibility Awareness Day (GAAD) belofte, met die doel om toeganklikheid oor die oopbron-ekosisteem te versterk deur gebruikers terugvoer effektief te lei en te vertaal in betekenisvolle platformverbeterings.

Die kernbesef was dat die mees impakvolle deurbrake spruit uit die luister na regte mense, tog bied luister op skaal beduidende uitdagings. Om dit te oorkom, het GitHub 'n terugvoervloeiproses gebou wat as 'n dinamiese enjin funksioneer eerder as 'n statiese kaartjiestelsel. Deur sy eie produkte te benut, verhelder, struktureer en spoor GitHub gebruikers- en kliënte terugvoer na, en omskep dit in implementering-gereed oplossings.

Voordat GitHub in tegnologiese oplossings gedelf het, het dit 'n mens-eerste ontwerpbenaadeling aangeneem, en sleutelpersoonlikhede geïdentifiseer wat die stelsel moes dien:

Kwessie-indienders: Gemeenskapsbestuurders, ondersteuningsagente en verkoopsverteenwoordigers wat leiding benodig om kwessies effektief aan te meld, selfs sonder diep toeganklikheidskundigheid.
Toeganklikheid- en diensspanne: Ingenieurs en ontwerpers wat gestruktureerde, uitvoerbare data benodig—soos reproduseerbare stappe, WCAG-kartering en ernstigheids tellings—om kwessies doeltreffend op te los.
Program- en produkbestuurders: Leierskap wat duidelike insig in knelpunte, tendense en vordering benodig om strategiese hulpbrontoewysingsbesluite te neem.

Hierdie fundamentele begrip het GitHub in staat gestel om 'n stelsel te ontwerp wat terugvoer as data behandel wat deur 'n goed gedefinieerde pyplyn vloei, wat in staat is om met hul behoeftes te ontwikkel.

Outomatisering van die Toeganklikheidsterugvoer Pyplyn

GitHub het sy nuwe argitektuur rondom 'n gebeurtenisgedrewe patroon gekonstrueer, waar elke stap 'n GitHub Action aktiveer om daaropvolgende aksies te orkestreer, wat konsekwente hantering van terugvoer verseker, ongeag die oorsprong daarvan. Alhoewel dit aanvanklik handmatig in middel-2024 gebou is, kan so 'n stelsel nou aansienlik vinniger ontwikkel word met behulp van instrumente soos Agentiese Werkvloei, wat die skep van GitHub Actions deur natuurlike taal moontlik maak.

Die vloeiproses reageer op sleutelgebeurtenisse: die skep van 'n kwessie inisieer GitHub Copilot-analise via die GitHub Models API, statusveranderinge aktiveer span oorhandiging, en kwessie-oplossing lei tot opvolging met die oorspronklike indiener. Die outomatisering dek die algemene pad, maar mense kan enige Action handmatig aktiveer of herhaal, wat toesig en buigsaamheid handhaaf.

Die Sewe-Stap Terugvoervloeiproses:

Inname: Terugvoer vloei van verskeie bronne soos die GitHub-toeganklikheidsbesprekingsforum (wat 90% van verslae uitmaak), ondersteuningskaartjies, sosiale media, en e-pos. Alle terugvoer word binne vyf werksdae erken. Vir uitvoerbare items, skep 'n spanlid handmatig 'n naspoor-kwessie deur 'n pasgemaakte toeganklikheidsterugvoer sjabloon te gebruik, wat noodsaaklike konteks vasvang. Hierdie skeppingsgebeurtenis aktiveer 'n GitHub Action om GitHub Copilot te betrek en die kwessie by 'n gesentraliseerde projekbord te voeg.
Copilot-analise: 'n GitHub Action roep die GitHub Models API om die nuutgeskepte kwessie te ontleed.
Indiener-oorsig: Die aanvanklike indiener hersien Copilot se analise, bevestig die akkuraatheid daarvan of maak aanpassings.
Toeganklikheidspan-oorsig: Die gespesialiseerde toeganklikheidspan voer 'n dieper oorsig uit en strategieseer oplossings.
Skakeloudits: Relevante oudits of eksterne hulpbronne word geskakel vir konteks en nakoming.
Sluit Lus: Sodra dit aangespreek is, word die kwessie formeel gesluit, en die oorspronklike gebruiker of kliënt word ingelig.
Verbetering: Terugvoer oor die stelsel se prestasie, insluitend Copilot se analise, lig deurlopende opdaterings en verfynings in.

Hierdie deurlopende vloei verseker sigbaarheid, struktuur en uitvoerbaarheid by elke stadium van die terugvoersleutel.

GitHub Copilot se Intelligente Toeganklikheidstriage

In die hart van hierdie geoutomatiseerde stelsel is GitHub Copilot se intelligente analise. Wanneer 'n naspoor-kwessie geskep word, roep 'n GitHub Action-werkvloei programmaties die GitHub Models API om die verslag te ontleed. GitHub het 'n strategiese keuse gemaak om gestoorde aanwysings (pasgemaakte instruksies) te gebruik in plaas van model-fyninstelling. Dit stel enige spanlid in staat om die KI se gedrag via 'n eenvoudige pull request op te dateer, wat die behoefte aan komplekse heropleidingspyplyne of gespesialiseerde masjienleerkennis uitskakel. Wanneer toeganklikheidstandaarde ontwikkel, werk die span markdown- en instruksielêers op, en die KI se gedrag pas aan met die volgende loop.

GitHub Copilot is gekonfigureer met pasgemaakte instruksies wat deur hul toeganklikheidskundiges ontwikkel is. Hierdie instruksies dien twee kritieke rolle:

Triage-analise: Klassifikasie van kwessies volgens WCAG-oortreding, ernstigheid (sev1-sev4), en geaffekteerde gebruikersgroep.
Toeganklikheidsafrigting: Begeleiding van spanne in die skryf en hersiening van toeganklike kode.

Die instruksielêers verwys na GitHub se toeganklikheidsbeleide, komponentbiblioteek, en interne dokumentasie, wat Copilot 'n omvattende begrip gee van hoe om WCAG-sukseskriteria te interpreteer en toe te pas.

Die outomatisering ontvou in twee sleutelstappe:

Eerste Aksie: By die skep van 'n kwessie, ontleed Copilot die verslag, en vul outomaties ongeveer 80% van die kwessie se metadata aan. Dit sluit meer as 40 datapunte in soos kwessietipe, gebruikerssegment, oorspronklike bron, geaffekteerde komponente, en 'n opsomming van die gebruiker se ervaring. Copilot plaas dan 'n kommentaar op die kwessie wat 'n probleemopsomming, voorgestelde WCAG-kriteria, ernstigheidsvlak, geaffekteerde gebruikersgroepe, aanbevole spantoewysing, en 'n kontrolelys vir verifikasie bevat.
Tweede Aksie: Hierdie daaropvolgende Aksie ontleed Copilot se kommentaar, pas etikette toe gebaseer op die toegewysde ernstigheid, werk die kwessie se status op die projekbord op, en wys dit aan die indiener toe vir hersiening.

Kruisaal, as Copilot se analise onakkuraat is, kan enigiemand dit vlag deur 'n kwessie te open wat die verskil beskryf, wat direk in GitHub se deurlopende verbeteringsproses vir die KI in gevoer word.

Menslike Toesig en Iteratiewe Toeganklikheidsverbeterings

Die vloeiproses beklemtoon menslike toesig en samewerking. Na Copilot se geoutomatiseerde analise, laat die "indiener-oorsig" fase (stap 3) die menslike indiener toe om die KI se bevindinge te verifieer. Hierdie mens-in-die-lus benadering verseker akkuraatheid en laat handmatige regstellings of vlae toe vir Copilot se deurlopende verbeteringsproses. Die daaropvolgende stappe—Toeganklikheidspan-oorsig, Skakeloudits, en Sluit Lus—integreer menslike kundigheid verder, wat verseker dat komplekse probleme deur spesialiste aangespreek word en dat gebruikers tydige, effektiewe oplossings ontvang.

Hierdie dinamiese stelsel verteenwoordig 'n beduidende verskuiwing vir GitHub. Deur KI te benut om die herhalende en data-intensiewe aspekte van terugvoerbestuur te hanteer, het hulle 'n chaotiese, dikwels stagnerende proses omskep in 'n deurlopende, proaktiewe enjin vir insluiting. Dit beteken dat elke stukkie toeganklikheidsterugvoer nou betroubaar nagespoor, geprioritiseer en opgetree word, wat verder gaan as beloftes van "fase twee" om onmiddellike, tasbare verbeterings vir alle gebruikers te lewer. Die uiteindelike doel is nie om menslike oordeel te vervang nie, maar om dit te bemagtig, waardevolle tyd en kundigheid vry te stel om te fokus op strategiese regstellings en 'n werklik toeganklike sagteware-ervaring te bevorder.

Oorspronklike bron

https://github.blog/ai-and-ml/github-copilot/continuous-ai-for-accessibility-how-github-transforms-feedback-into-inclusion/

Gereelde Vrae

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.

Bly op hoogte

Kry die nuutste KI-nuus in jou inkassie.

Deel