Pieejamība: GitHub pārveido atsauksmes iekļaušanā ar nepārtrauktu AI

Pieejamības revolucionizēšana: GitHub nepārtrauktās AI pieeja

Gadiem ilgi GitHub saskārās ar izplatītu, taču kritisku izaicinājumu: efektīvu pieejamības atsauksmju pārvaldību. Atšķirībā no tipiskām produktu problēmām, pieejamības jautājumi ir visaptveroši, bieži aptverot vairākas komandas un sistēmas. Viens ziņojums no ekrāna lasītāja lietotāja varētu ietekmēt navigāciju, autentifikāciju un iestatījumus, padarot tradicionālos, nodalītos atsauksmju procesus neefektīvus. Tas noveda pie izkaisītiem ziņojumiem, neatrisinātām kļūdām un lietotāju vilšanās, kuru problēmas ieilga mītiskajā "otrajā fāzē", kas reti kad materializējās.

Atzīstot nepieciešamību pēc fundamentālas pārmaiņas, GitHub uzsāka ceļu, lai centralizētu atsauksmes, izveidotu standartizētas veidnes un sakārtotu ievērojamu uzdevumu sarakstu. Tikai pēc šī stabilā pamata izveidošanas radās jautājums: kā AI varētu vēl vairāk pārveidot šo procesu? Atbilde slēpjas inovatīvā iekšējā darbplūsmā, ko nodrošina GitHub Actions, GitHub Copilot un GitHub Models, kas paredzēta nepārtrauktai katras lietotāja atsauksmes pārvēršanai par izsekojamu, prioritizētu un rīcībspējīgu problēmu. Šī pieeja nodrošina, ka AI uzlabo cilvēka spriedumu, racionalizējot atkārtotus uzdevumus un ļaujot ekspertiem koncentrēties uz iekļaujošas programmatūras piegādi.

Nepārtraukta AI: Dzīva sistēma iekļaušanai

GitHub "Nepārtrauktā AI pieejamībai" ir vairāk nekā tikai rīks; tā ir dzīva metodoloģija, kas integrē automatizāciju, mākslīgo intelektu un cilvēka zināšanas, lai iekļaušanu tieši ieaustu programmatūras izstrādes pamatā. Šī filozofija ir pamatā GitHub apņemšanās pildīt 2025. gada Vispasaules pieejamības izpratnes dienas (GAAD) solījumu, kura mērķis ir stiprināt pieejamību visā atvērtā koda ekosistēmā, efektīvi novirzot un pārvēršot lietotāju atsauksmes par nozīmīgiem platformas uzlabojumiem.

Galvenā atziņa bija tāda, ka visiedarbīgākie sasniegumi rodas, klausoties reālus cilvēkus, tomēr klausīšanās plašā mērogā rada ievērojamas problēmas. Lai to pārvarētu, GitHub izveidoja atsauksmju darbplūsmu, kas darbojas kā dinamisks dzinējs, nevis statiska biļešu sistēma. Izmantojot savus produktus, GitHub precizē, strukturē un izseko lietotāju un klientu atsauksmes, pārvēršot tās par ieviešanai gataviem risinājumiem.

Pirms iedziļināšanās tehnoloģiskajos risinājumos, GitHub pieņēma uz cilvēku orientētu dizaina pieeju, identificējot galvenās personas, kurām sistēmai bija jākalpo:

Problēmu iesniedzēji: Kopienas pārvaldnieki, atbalsta aģenti un pārdošanas pārstāvji, kuriem nepieciešami norādījumi, lai efektīvi ziņotu par problēmām, pat bez dziļām zināšanām par pieejamību.
Pieejamības un pakalpojumu komandas: Inženieri un dizaineri, kuriem nepieciešami strukturēti, rīcībspējīgi dati – piemēram, reproducējami soļi, WCAG kartēšana un smaguma pakāpes rādītāji –, lai efektīvi atrisinātu problēmas.
Programmu un produktu vadītāji: Vadība, kurai nepieciešams skaidrs ieskats problemātiskajās jomās, tendencēs un progresā, lai pieņemtu stratēģiskus lēmumus par resursu sadalījumu.

Šī fundamentālā izpratne ļāva GitHub izveidot sistēmu, kas atsauksmes apstrādā kā datus, kuri plūst pa labi definētu konveijeru, kas spēj attīstīties atbilstoši viņu vajadzībām.

Pieejamības atsauksmju konveijera automatizācija

GitHub izveidoja savu jauno arhitektūru ap uz notikumiem balstītu modeli, kurā katrs solis iedarbina GitHub Action, lai orķestrētu turpmākās darbības, nodrošinot konsekventu atsauksmju apstrādi neatkarīgi no to izcelsmes. Lai gan sākotnēji tas tika manuāli izveidots 2024. gada vidū, šādu sistēmu tagad var izstrādāt ievērojami ātrāk, izmantojot tādus rīkus kā Agentic Workflows, kas ļauj izveidot GitHub Actions, izmantojot dabisko valodu.

Darbplūsma reaģē uz galvenajiem notikumiem: problēmas izveide iedarbina GitHub Copilot analīzi, izmantojot GitHub Models API, statusa izmaiņas iedarbina komandas nodošanu, un problēmas atrisināšana iedarbina atbildes saziņu ar sākotnējo iesniedzēju. Automatizācija aptver ierasto ceļu, taču cilvēki var manuāli iedarbināt vai atkārtoti palaist jebkuru Action, saglabājot uzraudzību un elastību.

Septiņu soļu atsauksmju darbplūsma:

Iesaukums: Atsauksmes plūst no dažādiem avotiem, piemēram, GitHub pieejamības diskusiju foruma (kas veido 90% ziņojumu), atbalsta biļetēm, sociālajiem medijiem un e-pastu. Visas atsauksmes tiek apstiprinātas piecu darba dienu laikā. Rīcībspējīgiem jautājumiem komandas dalībnieks manuāli izveido izsekošanas problēmu, izmantojot pielāgotu pieejamības atsauksmju veidni, kas apkopo būtisku kontekstu. Šis izveides notikums iedarbina GitHub Action, lai iesaistītu GitHub Copilot un pievienotu problēmu centralizētam projekta panelim.
Copilot analīze: GitHub Action izsauc GitHub Models API, lai analizētu jaunizveidoto problēmu.
Iesniedzēja pārskatīšana: Sākotnējais iesniedzējs pārskata Copilot analīzi, apstiprinot tās precizitāti vai veicot pielāgojumus.
Pieejamības komandas pārskatīšana: Specializētā pieejamības komanda veic padziļinātu pārskatīšanu un izstrādā risinājumus.
Auditēšanas saites: Atbilstošās auditēšanas vai ārējie resursi tiek saistīti kontekstam un atbilstībai.
Cikla noslēgšana: Kad problēma ir atrisināta, tā tiek oficiāli slēgta, un sākotnējais lietotājs vai klients tiek informēts.
Uzlabošana: Atsauksmes par sistēmas veiktspēju, tostarp Copilot analīzi, sniedz informāciju nepārtrauktiem atjauninājumiem un uzlabojumiem.

Šī nepārtrauktā plūsma nodrošina pārredzamību, struktūru un rīcībspēju katrā atsauksmju dzīves cikla posmā.

GitHub Copilot inteliģentā pieejamības šķirošana

Šīs automatizētās sistēmas pamatā ir GitHub Copilot inteliģentā analīze. Kad tiek izveidota izsekošanas problēma, GitHub Action darbplūsma programmatiski izsauc GitHub Models API, lai analizētu ziņojumu. GitHub stratēģiski izvēlējās izmantot saglabātas uzvednes (pielāgotas instrukcijas), nevis modeļa precizēšanu. Tas ļauj jebkuram komandas dalībniekam atjaunināt AI uzvedību, izmantojot vienkāršu pull pieprasījumu, tādējādi novēršot vajadzību pēc sarežģītām pārapmācības konveijerām vai specializētām mašīnmācīšanās zināšanām. Kad pieejamības standarti attīstās, komanda atjaunina markdown un instrukciju failus, un AI uzvedība pielāgojas ar nākamo palaišanu.

GitHub Copilot ir konfigurēts ar pielāgotām instrukcijām, ko izstrādājuši viņu pieejamības jomas eksperti. Šīm instrukcijām ir divas kritiskas lomas:

Šķirošanas analīze: Problēmu klasificēšana pēc WCAG pārkāpumiem, smaguma pakāpes (sev1-sev4) un ietekmētās lietotāju grupas.
Pieejamības apmācība: Komandu vadīšana pieejama koda rakstīšanā un pārskatīšanā.

Instrukciju faili attiecas uz GitHub pieejamības politikām, komponentu bibliotēku un iekšējo dokumentāciju, nodrošinot Copilotam visaptverošu izpratni par to, kā interpretēt un piemērot WCAG veiksmes kritērijus.

Automatizācija notiek divos galvenajos posmos:

Pirmā darbība: Pēc problēmas izveides Copilot analizē ziņojumu, automātiski aizpildot aptuveni 80% no problēmas metadatiem. Tas ietver vairāk nekā 40 datu punktus, piemēram, problēmas veidu, lietotāju segmentu, sākotnējo avotu, ietekmētās komponentes un lietotāja pieredzes kopsavilkumu. Pēc tam Copilot ievieto komentāru par problēmu, kas satur problēmas kopsavilkumu, ieteiktos WCAG kritērijus, smaguma pakāpi, ietekmētās lietotāju grupas, ieteikto komandas piešķiršanu un pārbaudes sarakstu.
Otrā darbība: Šī turpmākā darbība parsē Copilot komentāru, piemēro birkas, pamatojoties uz piešķirto smaguma pakāpi, atjaunina problēmas statusu projekta panelī un piešķir to iesniedzējam pārskatīšanai.

Svarīgi, ja Copilot analīze ir neprecīza, jebkurš to var atzīmēt, atverot problēmu, aprakstot neatbilstību, tādējādi tieši sniedzot atsauksmes GitHub nepārtrauktajam AI uzlabošanas procesam.

Cilvēka uzraudzība un iteratīvi pieejamības uzlabojumi

Darbplūsmā tiek uzsvērta cilvēka uzraudzība un sadarbība. Pēc Copilot automatizētās analīzes "iesniedzēja pārskatīšanas" fāze (3. solis) ļauj cilvēkam, kurš iesniedza problēmu, pārbaudīt AI secinājumus. Šī cilvēka iesaistīšanās pieeja nodrošina precizitāti un ļauj veikt manuālas korekcijas vai atzīmēt nepilnības Copilot nepārtrauktās uzlabošanas procesam. Turpmākie soļi – Pieejamības komandas pārskatīšana, Auditēšanas saišu pievienošana un Cikla noslēgšana – vēl vairāk integrē cilvēka zināšanas, nodrošinot, ka sarežģītas problēmas risina speciālisti un ka lietotāji saņem savlaicīgus un efektīvus risinājumus.

Šī dinamiskā sistēma ir nozīmīga pārmaiņa GitHub. Izmantojot AI, lai apstrādātu atkārtotos un ar datiem bagātos atsauksmju pārvaldības aspektus, viņi ir pārveidojuši haotisku, bieži stagnējošu procesu par nepārtrauktu, proaktīvu iekļaušanas dzinēju. Tas nozīmē, ka katra pieejamības atsauksme tagad tiek uzticami izsekota, prioritizēta un īstenota, pārsniedzot "otrās fāzes" solījumus, lai nodrošinātu tūlītējus, taustāmus uzlabojumus visiem lietotājiem. Galvenais mērķis nav aizstāt cilvēka spriedumu, bet gan to stiprināt, atbrīvojot vērtīgu laiku un zināšanas, lai koncentrētos uz stratēģiskiem labojumiem un veicinātu patiesi pieejamu programmatūras pieredzi.

Sākotnējais avots

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

Bieži uzdotie jautājumi

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.

Esiet informēti

Saņemiet jaunākās AI ziņas savā e-pastā.

Dalīties