Ligipääsetavus: GitHub muudab tagasiside kaasamiseks pideva tehisintellekti abil

Ligipääsetavuse revolutsioon: GitHubi pideva tehisintellekti lähenemine

Aastaid seisis GitHub silmitsi tavapärase, kuid kriitilise väljakutsega: ligipääsetavuse tagasiside tõhusa haldamisega. Erinevalt tüüpilistest tooteprobleemidest on ligipääsetavusega seotud mured laialt levinud, ulatudes sageli üle mitme meeskonna ja süsteemi. Ekraanilugeja kasutaja üksainus aruanne võis puudutada navigeerimist, autentimist ja seadeid, muutes traditsioonilised eraldiseisvad tagasisideprotsessid ebaefektiivseks. See viis hajutatud aruannete, lahendamata vigade ja kasutajate pettumuseni, kelle probleemid viibisid müütilises "teises faasis", mis harva realiseerus.

Tunnistades vajadust põhimõttelise muutuse järele, asus GitHub teele tagasiside tsentraliseerimiseks, standardiseeritud mallide loomiseks ja olulise tööde mahajäämuse likvideerimiseks. Alles pärast selle tugeva aluse loomist tekkis küsimus: kuidas saaks tehisintellekt seda protsessi veelgi muuta? Vastus peitub uuenduslikus sisemises töövoos, mida toetavad GitHub Actions, GitHub Copilot ja GitHub Models, ning mis on loodud selleks, et pidevalt muuta iga kasutaja tagasiside jälgitavaks, prioriseeritud ja teostatavaks probleemiks. See lähenemine tagab, et tehisintellekt täiustab inimlikku otsustusvõimet, lihtsustab korduvaid ülesandeid ja võimaldab ekspertidel keskenduda kaasava tarkvara pakkumisele.

Pidev tehisintellekt: Elav süsteem kaasamiseks

GitHubi "Pidev tehisintellekt ligipääsetavuse heaks" on rohkem kui lihtsalt tööriist; see on elav metoodika, mis integreerib automatiseerimise, tehisintellekti ja inimliku asjatundlikkuse, et põimida kaasamine otse tarkvaraarenduse kangasse. See filosoofia toetab GitHubi pühendumust 2025. aasta ülemaailmsele ligipääsetavuse teadlikkuse päeva (GAAD) lubadusele, mille eesmärk on tugevdada ligipääsetavust avatud lähtekoodiga ökosüsteemis, suunates ja tõlkides tõhusalt kasutaja tagasiside olulisteks platvormiparandusteks.

Peamine arusaam oli, et kõige mõjusamad läbimurded tulenevad reaalsete inimeste kuulamisest, kuid suuremahuline kuulamine esitab märkimisväärseid väljakutseid. Selle ületamiseks ehitas GitHub tagasiside töövoo, mis toimib dünaamilise mootorina, mitte staatilise piletisüsteemina. Kasutades oma tooteid, GitHub selgitab, struktureerib ja jälgib kasutajate ja klientide tagasisidet, muutes selle juurutamisvalmis lahendusteks.

Enne tehnoloogiliste lahenduste juurde asumist võttis GitHub kasutusele inimesekeskse disainilähenemise, määratledes peamised persoonad, keda süsteem teenindama pidi:

Probleemi esitajad: Kogukonnajuhid, tugiagendid ja müügiesindajad, kes vajavad juhendamist probleemide tõhusaks aruandluseks, isegi ilma sügavate ligipääsetavuse teadmisteta.
Ligipääsetavuse ja teenindusmeeskonnad: Insenerid ja disainerid, kes vajavad struktureeritud, teostatavaid andmeid – näiteks reprodutseeritavaid samme, WCAG-i kaardistamist ja tõsiduse skoore – probleemide tõhusaks lahendamiseks.
Programmi- ja tootejuhid: Juhtkond, kes vajab selget ülevaadet valupunktidest, trendidest ja edusammudest, et teha strateegilisi ressursside jaotamise otsuseid.

See alusarusaam võimaldas GitHubil disainida süsteemi, mis käsitleb tagasisidet kui andmeid, mis voolavad läbi hästi määratletud torustiku, mis on võimeline arenema koos nende vajadustega.

Ligipääsetavuse tagasiside torustiku automatiseerimine

GitHub ehitas oma uue arhitektuuri ümber sündmuspõhisele mustrile, kus iga samm käivitab GitHub Actioni järgnevate tegevuste orkestreerimiseks, tagades tagasiside järjepideva käsitlemise sõltumata selle päritolust. Kuigi algselt ehitati see käsitsi 2024. aasta keskel, saab sellist süsteemi nüüd oluliselt kiiremini arendada, kasutades tööriistu nagu Agentic Workflows, mis võimaldavad luua GitHub Actionsi loomuliku keele abil.

Töövoog reageerib võtmesündmustele: probleemi loomine algatab GitHub Copiloti analüüsi GitHub Models API kaudu, olekumuutused käivitavad meeskonnapõhise edastuse ja probleemi lahendamine kutsub esile järelkontakti algse esitajaga. Automatiseerimine hõlmab tavapäraseid teekondi, kuid inimesed saavad käsitsi käivitada või uuesti käivitada mis tahes Actioni, säilitades järelevalve ja paindlikkuse.

Seitsmeastmeline tagasiside töövoog:

Sissevõtt: Tagasiside voolab erinevatest allikatest, nagu GitHubi ligipääsetavuse arutelulaud (mis moodustab 90% aruannetest), tugipiletid, sotsiaalmeedia ja e-post. Kogu tagasiside laekumist kinnitatakse viie tööpäeva jooksul. Teostatavate punktide puhul loob meeskonnaliige käsitsi jälgimisprobleemi, kasutades kohandatud ligipääsetavuse tagasiside malli, mis haarab olulise konteksti. See loomissündmus käivitab GitHub Actioni, et kaasata GitHub Copilot ja lisada probleem tsentraliseeritud projekti tahvlile.
Copiloti analüüs: GitHub Action kutsub GitHub Models API-t, et analüüsida äsja loodud probleemi.
Esitaja ülevaatus: Algne esitaja vaatab Copiloti analüüsi üle, kinnitades selle täpsust või tehes kohandusi.
Ligipääsetavuse meeskonna ülevaatus: Spetsialiseeritud ligipääsetavuse meeskond viib läbi sügavama ülevaatuse ja strateegiseerib lahendusi.
Auditite linkimine: Asjakohased auditid või välised ressursid lingitakse konteksti ja vastavuse tagamiseks.
Ringi sulgemine: Kui probleem on lahendatud, suletakse see ametlikult ja algset kasutajat või klienti teavitatakse.
Täiustamine: Tagasiside süsteemi toimivuse kohta, sealhulgas Copiloti analüüsi kohta, annab teavet pidevateks uuendusteks ja täpsustusteks.

See pidev voog tagab nähtavuse, struktuuri ja teostatavuse igas tagasiside elutsükli etapis.

GitHub Copiloti intelligentne ligipääsetavuse sorteerimine

Selle automatiseeritud süsteemi keskmes on GitHub Copiloti intelligentne analüüs. Kui jälgimisprobleem luuakse, kutsub GitHub Actioni töövoog programmiliste vahenditega GitHub Models API-t aruannet analüüsima. GitHub tegi strateegilise valiku kasutada salvestatud viipasid (kohandatud juhiseid) mudeli peenhäälestamise asemel. See võimaldab igal meeskonna liikmel uuendada tehisintellekti käitumist lihtsa pull-requesti kaudu, välistades vajaduse keerukate ümberõppe pipeline'ide või spetsiaalsete masinõppe teadmiste järele. Kui ligipääsetavuse standardid arenevad, uuendab meeskond markdown- ja juhistefaile ning tehisintellekti käitumine kohandub järgmise käivitamisega.

GitHub Copilot on konfigureeritud kohandatud juhistega, mille on välja töötanud nende ligipääsetavuse valdkonna eksperdid. Need juhised täidavad kahte kriitilist rolli:

Sorteerimisanalüüs: Probleemide klassifitseerimine WCAG rikkumise, tõsiduse (sev1-sev4) ja mõjutatud kasutajarühma järgi.
Ligipääsetavuse juhendamine: Meeskondade juhendamine ligipääsetava koodi kirjutamisel ja ülevaatamisel.

Juhistefailid viitavad GitHubi ligipääsetavuse poliitikatele, komponentide teegile ja sisemisele dokumentatsioonile, pakkudes Copilotile terviklikku arusaama sellest, kuidas tõlgendada ja rakendada WCAG-i edukriteeriumeid.

Automatiseerimine toimub kahes põhietapis:

Esimene tegevus: Probleemi loomisel analüüsib Copilot aruannet, täites automaatselt umbes 80% probleemi metaandmetest. See hõlmab üle 40 andmepunkti, nagu probleemi tüüp, kasutajasegment, algne allikas, mõjutatud komponendid ja kokkuvõte kasutaja kogemusest. Seejärel postitab Copilot probleemi kohta kommentaari, mis sisaldab probleemi kokkuvõtet, soovitatud WCAG kriteeriume, tõsiduse taset, mõjutatud kasutajarühmi, soovitatud meeskonna määramist ja kontrollnimekirja kontrollimiseks.
Teine tegevus: See järgnev Action parssib Copiloti kommentaari, rakendab silte vastavalt määratud tõsidusele, uuendab probleemi olekut projekti tahvlil ja määrab selle esitajale ülevaatamiseks.

Oluline on, et kui Copiloti analüüs on ebatäpne, saab igaüks sellele tähelepanu juhtida, avades lahknevust kirjeldava probleemi, mis annab otsest tagasisidet GitHubi tehisintellekti pideva täiustamise protsessile.

Inimlik järelevalve ja iteratiivsed ligipääsetavuse täiustused

Töövoog rõhutab inimlikku järelevalvet ja koostööd. Pärast Copiloti automatiseeritud analüüsi võimaldab "esitaja ülevaatuse" etapp (3. samm) inimesest esitajal kontrollida tehisintellekti leide. See inimest kaasav lähenemine tagab täpsuse ja võimaldab käsitsi parandusi või märguandeid Copiloti pideva täiustamise protsessiks. Järgmised sammud – Ligipääsetavuse Meeskonna Ülevaatus, Auditite Linkimine ja Ringi Sulgemine – integreerivad veelgi inimlikku asjatundlikkust, tagades, et keerulisi probleeme lahendavad spetsialistid ja et kasutajad saavad õigeaegseid ja tõhusaid lahendusi.

See dünaamiline süsteem kujutab endast GitHubi jaoks olulist nihet. Kasutades tehisintellekti tagasiside haldamise korduvate ja andmemahukate aspektide käsitlemiseks, on nad muutnud kaootilise, sageli seisva protsessi pidevaks, proaktiivseks kaasamise mootoriks. See tähendab, et iga ligipääsetavuse tagasiside osa on nüüd usaldusväärselt jälgitud, prioriseeritud ja sellele reageeritakse, minnes kaugemale "teise faasi" lubadustest, et pakkuda koheseid ja käegakatsutavaid parandusi kõigile kasutajatele. Lõppeesmärk ei ole inimliku otsustusvõime asendamine, vaid selle võimendamine, vabastades väärtuslikku aega ja asjatundlikkust, et keskenduda strateegilistele parandustele ja edendada tõeliselt ligipääsetavat tarkvarakogemust.

Algallikas

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

Korduma kippuvad küsimused

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.

Püsige kursis

Saage värskeimad AI uudised oma postkasti.

Jaga