Code Velocity
Narzędzia dla deweloperów

Dostępność: GitHub przekształca opinie w inkluzywność dzięki ciągłej sztucznej inteligencji

·7 min czytania·GitHub·Źródło oryginalne
Udostępnij
Schemat blokowy ilustrujący proces zbierania opinii o dostępności w GitHubie z wykorzystaniem ciągłej sztucznej inteligencji.

Rewolucjonizowanie Dostępności: Podejście GitHub z Ciągłą Sztuczną Inteligencją

Przez lata GitHub mierzył się z powszechnym, lecz krytycznym wyzwaniem: efektywnym zarządzaniem opiniami dotyczącymi dostępności. W przeciwieństwie do typowych problemów produktowych, kwestie dostępności są wszechobecne, często przekraczając granice wielu zespołów i systemów. Pojedynczy raport od użytkownika czytnika ekranu mógł dotyczyć nawigacji, uwierzytelniania i ustawień, co sprawiało, że tradycyjne, odizolowane procesy zbierania opinii były nieskuteczne. Prowadziło to do rozproszonych raportów, nierozwiązanych błędów i frustracji użytkowników, których problemy wlokły się w mitycznej "fazie drugiej", która rzadko się materializowała.

Uznając potrzebę fundamentalnej zmiany, GitHub podjął się zadania centralizacji opinii, stworzenia ustandaryzowanych szablonów i uporządkowania znacznego zaległości. Dopiero po zbudowaniu tych solidnych podstaw pojawiło się pytanie: jak sztuczna inteligencja mogłaby jeszcze bardziej przekształcić ten proces? Odpowiedź leży w innowacyjnym wewnętrznym przepływie pracy, napędzanym przez GitHub Actions, GitHub Copilot i GitHub Models, zaprojektowanym do ciągłego przekształcania każdej opinii użytkownika w śledzone, priorytetyzowane i możliwe do działania zgłoszenie. To podejście zapewnia, że sztuczna inteligencja wzmacnia ludzką ocenę, usprawniając powtarzalne zadania i pozwalając ekspertom skupić się na dostarczaniu inkluzywnego oprogramowania.

Ciągła Sztuczna Inteligencja: Żywy System dla Inkluzywności

'Ciągła Sztuczna Inteligencja dla dostępności' GitHub to więcej niż tylko narzędzie; to żywa metodologia, która integruje automatyzację, sztuczną inteligencję i ludzką ekspertyzę, aby wbudować inkluzywność bezpośrednio w strukturę rozwoju oprogramowania. Filozofia ta wspiera zobowiązanie GitHub do obchodów Światowego Dnia Świadomości Dostępności (GAAD) w 2025 roku, mające na celu wzmocnienie dostępności w całym ekosystemie open source poprzez skuteczne kierowanie i przekształcanie opinii użytkowników w znaczące ulepszenia platformy.

Kluczowym spostrzeżeniem było to, że najbardziej wpływowe przełomy wynikają ze słuchania prawdziwych ludzi, jednak słuchanie na dużą skalę stanowi poważne wyzwanie. Aby to przezwyciężyć, GitHub zbudował proces zbierania opinii, który działa jako dynamiczny silnik, a nie statyczny system biletowy. Wykorzystując własne produkty, GitHub wyjaśnia, strukturyzuje i śledzi opinie użytkowników i klientów, przekształcając je w gotowe do wdrożenia rozwiązania.

Zanim zagłębił się w rozwiązania technologiczne, GitHub przyjął podejście projektowania zorientowane na ludzi, identyfikując kluczowe osoby, którym system miał służyć:

  • Zgłaszający problemy: Menedżerowie społeczności, agenci wsparcia i przedstawiciele handlowi, którzy potrzebują wskazówek, aby skutecznie zgłaszać problemy, nawet bez głębokiej wiedzy na temat dostępności.
  • Zespoły ds. dostępności i serwisu: Inżynierowie i projektanci wymagający ustrukturyzowanych, możliwych do działania danych – takich jak możliwe do odtworzenia kroki, mapowanie WCAG i oceny ważności – aby efektywnie rozwiązywać problemy.
  • Menedżerowie programów i produktów: Kierownictwo potrzebujące jasnego wglądu w problemy, trendy i postępy, aby podejmować strategiczne decyzje dotyczące alokacji zasobów.

To podstawowe zrozumienie pozwoliło GitHubowi zaprojektować system, który traktuje opinie jako dane przepływające przez dobrze zdefiniowany potok, zdolny do ewoluowania wraz z ich potrzebami.

Automatyzacja Procesu Zbierania Opinii o Dostępności

GitHub zbudował swoją nową architekturę wokół wzorca opartego na zdarzeniach, gdzie każdy krok uruchamia GitHub Action w celu orkiestracji kolejnych działań, zapewniając spójne przetwarzanie opinii niezależnie od ich pochodzenia. Chociaż początkowo system ten był budowany ręcznie w połowie 2024 roku, obecnie można go opracować znacznie szybciej, używając narzędzi takich jak Przepływy Agentowe, które umożliwiają tworzenie GitHub Actions za pomocą języka naturalnego.

Przepływ pracy reaguje na kluczowe zdarzenia: utworzenie zgłoszenia inicjuje analizę GitHub Copilot za pośrednictwem API GitHub Models, zmiany statusu uruchamiają przekazywanie zadań zespołowi, a rozwiązanie zgłoszenia skłania do kontaktu z pierwotnym zgłaszającym. Automatyzacja obejmuje typową ścieżkę, ale ludzie mogą ręcznie uruchomić lub ponownie uruchomić dowolną Akcję, zachowując nadzór i elastyczność.

Siedmioetapowy Proces Zbierania Opinii:

  1. Przyjęcie: Opinie napływają z różnych źródeł, takich jak forum dyskusyjne GitHub dotyczące dostępności (które stanowi 90% raportów), zgłoszenia wsparcia, media społecznościowe i poczta elektroniczna. Wszystkie opinie są potwierdzane w ciągu pięciu dni roboczych. W przypadku elementów wymagających działania, członek zespołu ręcznie tworzy zgłoszenie śledzenia, używając niestandardowego szablonu opinii dotyczących dostępności, który przechwytuje niezbędny kontekst. To zdarzenie utworzenia uruchamia GitHub Action, aby zaangażować GitHub Copilot i dodać zgłoszenie do scentralizowanej tablicy projektowej.

  2. Analiza Copilota: Akcja GitHub Action wywołuje API GitHub Models w celu analizy nowo utworzonego zgłoszenia.

  3. Przegląd przez zgłaszającego: Pierwotny zgłaszający przegląda analizę Copilota, potwierdzając jej dokładność lub wprowadzając poprawki.

  4. Przegląd przez Zespół ds. Dostępności: Wyspecjalizowany zespół ds. dostępności przeprowadza głębszy przegląd i opracowuje strategię rozwiązań.

  5. Łączenie Audytów: Odpowiednie audyty lub zasoby zewnętrzne są łączone w celu kontekstu i zgodności.

  6. Zamknięcie Obiegu: Po rozwiązaniu, zgłoszenie jest formalnie zamykane, a pierwotny użytkownik lub klient jest informowany.

  7. Udoskonalenie: Opinie na temat wydajności systemu, w tym analizy Copilota, stanowią podstawę ciągłych aktualizacji i udoskonaleń.

Ten ciągły przepływ zapewnia widoczność, strukturę i możliwość podjęcia działań na każdym etapie cyklu życia opinii.

Inteligentne Sortowanie Dostępności przez GitHub Copilot

W sercu tego zautomatyzowanego systemu znajduje się inteligentna analiza GitHub Copilot. Gdy tworzone jest zgłoszenie śledzenia, przepływ pracy GitHub Action programowo wywołuje API GitHub Models w celu analizy raportu. GitHub podjął strategiczną decyzję o użyciu przechowywanych podpowiedzi (niestandardowych instrukcji) zamiast dostrajania modelu. Pozwala to każdemu członkowi zespołu na aktualizację zachowania sztucznej inteligencji za pomocą prostego żądania pull, eliminując potrzebę złożonych potoków ponownego szkolenia lub specjalistycznej wiedzy z zakresu uczenia maszynowego. Gdy standardy dostępności ewoluują, zespół aktualizuje pliki markdown i instrukcji, a zachowanie sztucznej inteligencji dostosowuje się przy kolejnym uruchomieniu.

GitHub Copilot jest skonfigurowany z niestandardowymi instrukcjami opracowanymi przez ekspertów ds. dostępności. Instrukcje te pełnią dwie kluczowe role:

  • Analiza Sortowania: Klasyfikowanie problemów według naruszeń WCAG, ważności (sev1-sev4) i grupy dotkniętych użytkowników.
  • Mentoring Dostępności: Prowadzenie zespołów w pisaniu i recenzowaniu dostępnego kodu.

Pliki instrukcji odwołują się do zasad dostępności GitHub, biblioteki komponentów i wewnętrznej dokumentacji, zapewniając Copilotowi kompleksowe zrozumienie, jak interpretować i stosować kryteria sukcesu WCAG.

Automatyzacja przebiega w dwóch kluczowych krokach:

  1. Pierwsza Akcja: Po utworzeniu zgłoszenia, Copilot analizuje raport, automatycznie wypełniając około 80% metadanych zgłoszenia. Obejmuje to ponad 40 punktów danych, takich jak typ problemu, segment użytkownika, oryginalne źródło, dotknięte komponenty i podsumowanie doświadczenia użytkownika. Copilot następnie zamieszcza komentarz do zgłoszenia, zawierający podsumowanie problemu, sugerowane kryteria WCAG, poziom ważności, dotknięte grupy użytkowników, zalecane przypisanie zespołu i listę kontrolną do weryfikacji.
  2. Druga Akcja: Ta kolejna Akcja analizuje komentarz Copilota, stosuje etykiety na podstawie przypisanej ważności, aktualizuje status zgłoszenia na tablicy projektowej i przypisuje je do zgłaszającego w celu przeglądu.

Co kluczowe, jeśli analiza Copilota jest niedokładna, każdy może to zgłosić, otwierając zgłoszenie opisujące niezgodność, bezpośrednio zasilając proces ciągłego doskonalenia sztucznej inteligencji GitHub.

Nadzór Człowieka i Iteracyjne Ulepszenia Dostępności

Przepływ pracy kładzie nacisk na nadzór człowieka i współpracę. Po zautomatyzowanej analizie Copilota, faza 'przeglądu przez zgłaszającego' (krok 3) pozwala człowiekowi zgłaszającemu zweryfikować ustalenia sztucznej inteligencji. To podejście 'człowiek w pętli' zapewnia dokładność i pozwala na ręczne korekty lub zgłoszenia do procesu ciągłego doskonalenia Copilota. Kolejne kroki – Przegląd Zespołu ds. Dostępności, Łączenie Audytów i Zamknięcie Obiegu – dalej integrują ludzką ekspertyzę, zapewniając, że złożone problemy są rozwiązywane przez specjalistów, a użytkownicy otrzymują terminowe i skuteczne rozwiązania.

Ten dynamiczny system stanowi znaczącą zmianę dla GitHub. Wykorzystując sztuczną inteligencję do obsługi powtarzalnych i intensywnych pod względem danych aspektów zarządzania opiniami, przekształcili chaotyczny, często zastoinowy proces w ciągły, proaktywny silnik inkluzywności. Oznacza to, że każda opinia dotycząca dostępności jest teraz niezawodnie śledzona, priorytetyzowana i brana pod uwagę, wykraczając poza obietnice 'fazy drugiej', aby dostarczyć natychmiastowe, namacalne ulepszenia dla wszystkich użytkowników. Ostatecznym celem nie jest zastąpienie ludzkiej oceny, ale jej wzmocnienie, uwalniając cenny czas i ekspertyzę, aby skupić się na strategicznych poprawkach i wspierać prawdziwie dostępne doświadczenie z oprogramowaniem.

Często zadawane pytania

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.

Bądź na bieżąco

Otrzymuj najnowsze wiadomości o AI na swoją skrzynkę.

Udostępnij