Saavutettavuus: GitHub muuttaa palautteen inkluusioksi jatkuvan tekoälyn avulla

Saavutettavuuden mullistaminen: GitHubin jatkuva tekoälylähestymistapa

Vuosien ajan GitHub kohtasi yleisen mutta kriittisen haasteen: saavutettavuuspalautteen tehokkaan hallinnan. Toisin kuin tyypilliset tuoteongelmat, saavutettavuusongelmat ovat läpitunkevia, usein ulottuen useisiin tiimeihin ja järjestelmiin. Yksittäinen ruudunlukijan käyttäjän raportti saattoi koskettaa navigointia, todennusta ja asetuksia, tehden perinteisistä siiloutuneista palautejärjestelmistä tehottomia. Tämä johti hajallaan oleviin raportteihin, ratkaisemattomiin virheisiin ja käyttäjien turhautumiseen, joiden ongelmat jäivät kummittelemaan myyttiseen "toiseen vaiheeseen", joka harvoin toteutui.

Tunnistaessaan perustavanlaatuisen muutoksen tarpeen GitHub lähti matkalle keskittämään palautetta, luomaan standardoituja malleja ja purkamaan merkittävää ruuhkaa. Vasta tämän vankan perustan luomisen jälkeen heräsi kysymys: Kuinka tekoäly voisi muuttaa tätä prosessia edelleen? Vastaus piilee innovatiivisessa sisäisessä työnkulussa, joka saa voimansa GitHub Actionsista, GitHub Copilotista ja GitHub Modelsista, ja joka on suunniteltu jatkuvasti muuttamaan jokaisen käyttäjäpalautteen seuratuksi, priorisoiduksi ja toimintakelpoiseksi ongelmaksi. Tämä lähestymistapa varmistaa, että tekoäly parantaa ihmisen harkintaa, virtaviivaistaa toistuvia tehtäviä ja antaa asiantuntijoille mahdollisuuden keskittyä inklusiivisten ohjelmistojen toimittamiseen.

Jatkuva tekoäly: Elävä järjestelmä inkluusiota varten

GitHubin "Jatkuva tekoäly saavutettavuuteen" on enemmän kuin pelkkä työkalu; se on elävä metodologia, joka integroi automaation, tekoälyn ja ihmisen asiantuntemuksen upottaakseen inkluusion suoraan ohjelmistokehityksen ytimeen. Tämä filosofia tukee GitHubin sitoutumista vuoden 2025 Global Accessibility Awareness Day (GAAD) -lupaukseen, jonka tavoitteena on vahvistaa saavutettavuutta avoimen lähdekoodin ekosysteemissä ohjaamalla ja kääntämällä käyttäjäpalautteen tehokkaasti merkityksellisiksi alustaparannuksiksi.

Ydinoivallus oli, että merkityksellisimmät läpimurrot syntyvät todellisten ihmisten kuuntelusta, mutta kuuntelu laajassa mittakaavassa asettaa merkittäviä haasteita. Tämän voittamiseksi GitHub rakensi palautetyönkulun, joka toimii dynaamisena moottorina staattisen tikettijärjestelmän sijaan. Hyödyntämällä omia tuotteitaan GitHub selventää, jäsentää ja seuraa käyttäjä- ja asiakaspalautetta muuttaen sen toteutusvalmiiksi ratkaisuiksi.

Ennen teknologisten ratkaisujen syventämistä GitHub omaksui ihmislähtöisen suunnittelun lähestymistavan, tunnistaen avainhenkilöt, joita järjestelmän piti palvella:

• Ongelmien lähettäjät: Yhteisöpäälliköt, tukihenkilöstö ja myyntiedustajat, jotka tarvitsevat ohjausta ongelmien tehokkaaseen raportointiin, jopa ilman syvällistä saavutettavuusasiantuntemusta.
• Saavutettavuus- ja palvelutiimit: Insinöörit ja suunnittelijat, jotka tarvitsevat jäsenneltyä, toimintakelpoista dataa – kuten toistettavia vaiheita, WCAG-kartoituksia ja vakavuusasteita – ongelmien tehokkaaseen ratkaisemiseen.
• Ohjelma- ja tuotepäälliköt: Johto, joka tarvitsee selkeän näkyvyyden kipupisteisiin, trendeihin ja edistymiseen strategisten resurssien allokointipäätösten tekemiseksi.

Tämä perustavanlaatuinen ymmärrys antoi GitHubille mahdollisuuden suunnitella järjestelmän, joka käsittelee palautetta dataana, joka virtaa hyvin määritellyn putken läpi ja joka pystyy kehittymään tarpeiden mukana.

Saavutettavuuspalauteputken automatisointi

GitHub rakensi uuden arkkitehtuurinsa tapahtumalähtöisen mallin ympärille, jossa jokainen vaihe laukaisee GitHub Actionin järjestämään seuraavat toiminnot, varmistaen palautteen johdonmukaisen käsittelyn sen alkuperästä riippumatta. Vaikka järjestelmä rakennettiin alun perin manuaalisesti vuoden 2024 puolivälissä, tällainen järjestelmä voidaan nyt kehittää merkittävästi nopeammin käyttämällä työkaluja kuten Agenttiset työnkulut, jotka mahdollistavat GitHub Actionsien luomisen luonnollisella kielellä.

Työnkulku reagoi avaintapahtumiin: ongelman luominen aloittaa GitHub Copilot -analyysin GitHub Models API:n kautta, tilamuutokset laukaisevat tiimin vaihtojen ja ongelman ratkaiseminen kehottaa seuraamaan alkuperäisen lähettäjän kanssa. Automaatio kattaa yleisen polun, mutta ihmiset voivat manuaalisesti käynnistää tai ajaa uudelleen minkä tahansa Actionin, säilyttäen valvonnan ja joustavuuden.

Seitsemänvaiheinen palautetyönkulku:

1. Vastaanotto: Palaute virtaa eri lähteistä, kuten GitHubin saavutettavuuskeskustelufoorumilta (joka kattaa 90 % raporteista), tukipyynnöistä, sosiaalisesta mediasta ja sähköpostista. Kaikki palaute kuitataan viiden arkipäivän kuluessa. Toimintakelpoisten kohteiden osalta tiimin jäsen luo manuaalisesti seurantakysymyksen käyttäen mukautettua saavutettavuuspalautelomaketta, joka tallentaa olennaisen kontekstin. Tämä luomistapahtuma laukaisee GitHub Actionin aktivoimaan GitHub Copilotin ja lisäämään ongelman keskitettyyn projektitauluun.

2. Copilotin analyysi: GitHub Action kutsuu GitHub Models API:a analysoimaan äskettäin luodun ongelman.

3. Lähettäjän tarkistus: Alkuperäinen lähettäjä tarkistaa Copilotin analyysin vahvistaen sen paikkansapitävyyden tai tehden korjauksia.

4. Saavutettavuustiimin tarkistus: Erikoistunut saavutettavuustiimi tekee syvemmän tarkistuksen ja strategisoi ratkaisuja.

5. Linkitä auditoinnit: Asiaankuuluvat auditoinnit tai ulkoiset resurssit linkitetään kontekstin ja vaatimustenmukaisuuden vuoksi.

6. Sulje silmukka: Kun ongelma on käsitelty, se suljetaan virallisesti ja alkuperäiselle käyttäjälle tai asiakkaalle ilmoitetaan.

7. Parannus: Palautetta järjestelmän suorituskyvystä, mukaan lukien Copilotin analyysi, käytetään jatkuviin päivityksiin ja hienosäätöihin.

Tämä jatkuva virta varmistaa näkyvyyden, rakenteen ja toimintakelpoisuuden palautteen elinkaaren jokaisessa vaiheessa.

GitHub Copilotin älykäs saavutettavuuslajittelu

Tämän automatisoidun järjestelmän ytimessä on GitHub Copilotin älykäs analyysi. Kun seurantakysymys luodaan, GitHub Action -työnkulku kutsuu ohjelmallisesti GitHub Models API:a analysoimaan raportin. GitHub teki strategisen valinnan käyttää tallennettuja kehotteita (mukautettuja ohjeita) mallin hienosäädön sijaan. Tämä antaa minkä tahansa tiimin jäsenen päivittää tekoälyn käyttäytymistä yksinkertaisen pull requestin kautta, mikä eliminoi monimutkaisten uudelleenkoulutusputkien tai erikoistuneen koneoppimisosaamisen tarpeen. Kun saavutettavuusstandardit kehittyvät, tiimi päivittää markdown- ja ohjetiedostot, ja tekoälyn käyttäytyminen mukautuu seuraavalla ajokerralla.

GitHub Copilot on määritetty mukautetuilla ohjeilla, jotka heidän saavutettavuuden asiantuntijansa ovat kehittäneet. Nämä ohjeet palvelevat kahta kriittistä roolia:

• Lajitteluanalyysi: Ongelmien luokittelu WCAG-rikkomusten, vakavuuden (sev1-sev4) ja vaikutusalueiden mukaan.
• Saavutettavuusvalmennus: Tiimien ohjaaminen saavutettavan koodin kirjoittamisessa ja tarkistamisessa.

Ohjetiedostot viittaavat GitHubin saavutettavuuskäytäntöihin, komponenttikirjastoon ja sisäiseen dokumentaatioon, antaen Copilotille kattavan ymmärryksen siitä, miten WCAG:n menestyskriteerejä tulkitaan ja sovelletaan.

Automaatio etenee kahdessa avainvaiheessa:

1. Ensimmäinen toiminto: Ongelman luonnin yhteydessä Copilot analysoi raportin täyttäen automaattisesti noin 80 % ongelman metatiedoista. Tämä sisältää yli 40 datapistettä, kuten ongelmatyypin, käyttäjäsegmentin, alkuperäisen lähteen, vaikuttavat komponentit ja yhteenvedon käyttäjän kokemuksesta. Copilot julkaisee sitten kommentin ongelmasta, joka sisältää ongelman yhteenvedon, ehdotetut WCAG-kriteerit, vakavuustason, vaikutusalueet, suositellun tiimitehtävän ja tarkistuslistan todentamista varten.
2. Toinen toiminto: Tämä seuraava Action jäsentää Copilotin kommentin, soveltaa tarroja määritetyn vakavuuden perusteella, päivittää ongelman tilan projektitaululla ja määrittää sen lähettäjälle tarkistettavaksi.

Kriittisesti, jos Copilotin analyysi on epätarkka, kuka tahansa voi ilmoittaa siitä avaamalla ongelman, joka kuvaa poikkeaman, syöttäen sen suoraan GitHubin jatkuvaan tekoälyn parannusprosessiin.

Ihmisen valvonta ja iteratiiviset saavutettavuusparannukset

Työnkulku korostaa ihmisen valvontaa ja yhteistyötä. Copilotin automaattisen analyysin jälkeen "lähettäjän tarkistus" -vaihe (vaihe 3) antaa ihmislähettäjälle mahdollisuuden tarkistaa tekoälyn löydökset. Tämä ihmisen osallistumiseen perustuva lähestymistapa varmistaa tarkkuuden ja mahdollistaa manuaaliset korjaukset tai ilmoitukset Copilotin jatkuvaan parannusprosessiin. Seuraavat vaiheet – Saavutettavuustiimin tarkistus, Linkitä auditoinnit ja Sulje silmukka – integroivat edelleen ihmisen asiantuntemuksen, varmistaen, että monimutkaiset ongelmat käsitellään asiantuntijoiden toimesta ja että käyttäjät saavat oikea-aikaisia, tehokkaita ratkaisuja.

Tämä dynaaminen järjestelmä edustaa merkittävää muutosta GitHubille. Hyödyntämällä tekoälyä palautteenhallinnan toistuvien ja dataintensiivisten osien käsittelyyn he ovat muuttaneet kaoottisen, usein pysähtyneen prosessin jatkuvaksi, ennakoivaksi inkluusion moottoriksi. Tämä tarkoittaa, että jokainen saavutettavuuspalaute seurataan nyt luotettavasti, priorisoidaan ja sen pohjalta toimitaan, siirtyen "toisen vaiheen" lupauksista välittömiin, konkreettisiin parannuksiin kaikille käyttäjille. Lopullinen tavoite ei ole korvata ihmisen harkintaa, vaan antaa sille valtaa, vapauttaen arvokasta aikaa ja asiantuntemusta keskittyä strategisiin korjauksiin ja edistää aidosti saavutettavaa ohjelmistokokemusta.