Erişilebilirlik: GitHub, Sürekli Yapay Zeka ile Geri Bildirimi Kapsayıcılığa Dönüştürüyor

Erişilebilirliği Kökten Değiştirmek: GitHub'ın Sürekli Yapay Zeka Yaklaşımı

Yıllardır GitHub, yaygın ancak kritik bir zorlukla karşı karşıyaydı: erişilebilirlik geri bildirimlerini etkili bir şekilde yönetmek. Tipik ürün sorunlarının aksine, erişilebilirlik endişeleri yaygındır ve genellikle birden çok ekip ve sistemi kapsar. Bir ekran okuyucu kullanıcısından gelen tek bir rapor, gezinme, kimlik doğrulama ve ayarlara dokunabilir, bu da geleneksel izole geri bildirim süreçlerini etkisiz hale getirir. Bu durum, dağınık raporlara, çözülmemiş hatalara ve sorunları nadiren gerçekleşen efsanevi "ikinci aşamada" kalan kullanıcıların hayal kırıklığına yol açtı.

Temel bir değişime duyulan ihtiyacı fark eden GitHub, geri bildirimleri merkezileştirmek, standartlaştırılmış şablonlar oluşturmak ve önemli bir birikmiş iş yükünü temizlemek için bir yolculuğa çıktı. Bu sağlam temeli kurduktan sonra şu soru ortaya çıktı: Yapay zeka bu süreci daha da nasıl dönüştürebilir? Cevap, GitHub Actions, GitHub Copilot ve GitHub Modelleri tarafından desteklenen, her bir kullanıcı geri bildirimini sürekli olarak izlenen, önceliklendirilen ve eyleme dönüştürülebilir bir soruna dönüştürmek üzere tasarlanmış yenilikçi bir dahili iş akışında yatıyor. Bu yaklaşım, yapay zekanın insan muhakemesini geliştirmesini, tekrarlayan görevleri düzene sokmasını ve uzmanların kapsayıcı yazılım sunmaya odaklanmasını sağlar.

Sürekli Yapay Zeka: Kapsayıcılık için Yaşayan Bir Sistem

GitHub'ın "erişilebilirlik için Sürekli Yapay Zeka"sı sadece bir araçtan daha fazlasıdır; otomasyonu, yapay zekayı ve insan uzmanlığını entegre ederek kapsayıcılığı doğrudan yazılım geliştirme dokusuna yerleştiren yaşayan bir metodolojidir. Bu felsefe, GitHub'ın 2025 Küresel Erişilebilirlik Farkındalık Günü (GAAD) taahhüdünün temelini oluşturur ve kullanıcı geri bildirimlerini anlamlı platform iyileştirmelerine etkili bir şekilde yönlendirerek ve çevirerek açık kaynak ekosisteminde erişilebilirliği güçlendirmeyi hedefler.

Temel farkındalık, en etkili atılımların gerçek insanları dinlemekten kaynaklanmasıydı, ancak büyük ölçekte dinlemek önemli zorluklar sunar. Bunun üstesinden gelmek için GitHub, statik bir biletleme sistemi yerine dinamik bir motor gibi çalışan bir geri bildirim iş akışı oluşturdu. Kendi ürünlerini kullanarak GitHub, kullanıcı ve müşteri geri bildirimlerini açıklığa kavuşturur, yapılandırır ve izler, bunları uygulamaya hazır çözümlere dönüştürür.

Teknolojik çözümlere dalmadan önce GitHub, sistemin hizmet vermesi gereken temel kişileri belirleyerek insan odaklı bir tasarım yaklaşımı benimsedi:

Sorun gönderenler: Derin erişilebilirlik uzmanlığına sahip olmasalar bile sorunları etkili bir şekilde raporlamak için rehberliğe ihtiyaç duyan topluluk yöneticileri, destek temsilcileri ve satış temsilcileri.
Erişilebilirlik ve servis ekipleri: Sorunları verimli bir şekilde çözmek için tekrarlanabilir adımlar, WCAG eşlemesi ve ciddiyet puanları gibi yapılandırılmış, eyleme dönüştürülebilir verilere ihtiyaç duyan mühendisler ve tasarımcılar.
Program ve ürün yöneticileri: Stratejik kaynak tahsisi kararları almak için sorun noktaları, eğilimler ve ilerleme hakkında net görünürlüğe ihtiyaç duyan liderlik.

Bu temel anlayış, GitHub'ın geri bildirimleri, ihtiyaçlarına göre gelişebilen, iyi tanımlanmış bir boru hattından akan veriler olarak ele alan bir sistem tasarlamasını sağladı.

Erişilebilirlik Geri Bildirim Boru Hattını Otomatikleştirmek

GitHub, yeni mimarisini, her adımın sonraki eylemleri düzenlemek için bir GitHub Action'ı tetiklediği, kökeni ne olursa olsun geri bildirimin tutarlı bir şekilde ele alınmasını sağlayan, olay odaklı bir model etrafında inşa etti. İlk olarak 2024 ortalarında manuel olarak inşa edilmiş olsa da, böyle bir sistem artık doğal dil aracılığıyla GitHub Actions oluşturmaya olanak tanıyan Ajan İş Akışları gibi araçlar kullanılarak önemli ölçüde daha hızlı geliştirilebilir.

İş akışı temel olaylara yanıt verir: sorun oluşturma GitHub Models API aracılığıyla GitHub Copilot analizini başlatır, durum değişiklikleri ekip devirlerini tetikler ve sorun çözümü orijinal gönderenle takip edilmesini sağlar. Otomasyon ortak yolu kapsar, ancak insanlar herhangi bir Action'ı manuel olarak tetikleyebilir veya yeniden çalıştırabilir, böylece denetim ve esneklik korunur.

Yedi Adımlı Geri Bildirim İş Akışı:

Giriş (Intake): Geri bildirim, GitHub erişilebilirlik tartışma panosu (raporların %90'ını oluşturur), destek biletleri, sosyal medya ve e-posta gibi çeşitli kaynaklardan akar. Tüm geri bildirimler beş iş günü içinde onaylanır. Eyleme dönüştürülebilir öğeler için, bir ekip üyesi, temel bağlamı yakalayan özel bir erişilebilirlik geri bildirim şablonu kullanarak manuel olarak bir takip sorunu oluşturur. Bu oluşturma olayı, GitHub Copilot'ı devreye sokmak ve sorunu merkezi bir proje panosuna eklemek için bir GitHub Action'ı tetikler.
Copilot Analizi: Bir GitHub Action, yeni oluşturulan sorunu analiz etmek için GitHub Models API'yi çağırır.
Gönderen İncelemesi: İlk gönderen Copilot'ın analizini inceler, doğruluğunu onaylar veya ayarlamalar yapar.
Erişilebilirlik Ekibi İncelemesi: Uzmanlaşmış erişilebilirlik ekibi daha derin bir inceleme yapar ve çözümler stratejisini belirler.
Denetimleri Bağlama: Bağlam ve uyumluluk için ilgili denetimler veya harici kaynaklar bağlanır.
Döngüyü Kapatma: Ele alındıktan sonra, sorun resmi olarak kapatılır ve orijinal kullanıcı veya müşteri bilgilendirilir.
İyileştirme: Copilot'ın analizi de dahil olmak üzere sistemin performansına ilişkin geri bildirim, sürekli güncellemeleri ve iyileştirmeleri besler.

Bu sürekli akış, geri bildirim yaşam döngüsünün her aşamasında görünürlüğü, yapıyı ve eyleme dönüştürülebilirliği sağlar.

GitHub Copilot'ın Akıllı Erişilebilirlik Tasnifi

Bu otomatik sistemin kalbinde GitHub Copilot'ın akıllı analizi yer almaktadır. Bir takip sorunu oluşturulduğunda, bir GitHub Action iş akışı, raporu analiz etmek için GitHub Models API'yi programlı olarak çağırır. GitHub, model ince ayarı yerine depolanmış istemleri (özel talimatlar) kullanmak stratejik bir tercih yaptı. Bu, herhangi bir ekip üyesinin basit bir çekme isteği aracılığıyla yapay zekanın davranışını güncellemesine olanak tanır, böylece karmaşık yeniden eğitim süreçlerine veya özel makine öğrenimi bilgisine olan ihtiyacı ortadan kaldırır. Erişilebilirlik standartları geliştikçe, ekip markdown ve talimat dosyalarını günceller ve yapay zekanın davranışı bir sonraki çalıştırmada adapte olur.

GitHub Copilot, erişilebilirlik konu uzmanları tarafından geliştirilen özel talimatlarla yapılandırılmıştır. Bu talimatlar iki kritik rol oynar:

Tasnif Analizi: Sorunları WCAG ihlali, ciddiyet (sev1-sev4) ve etkilenen kullanıcı grubuna göre sınıflandırma.
Erişilebilirlik Koçluğu: Ekiplere erişilebilir kod yazma ve inceleme konusunda rehberlik etme.

Talimat dosyaları, GitHub'ın erişilebilirlik politikalarına, bileşen kütüphanesine ve dahili belgelerine atıfta bulunarak Copilot'a WCAG başarı kriterlerinin nasıl yorumlanıp uygulanacağı konusunda kapsamlı bir anlayış sağlar.

Otomasyon iki temel adımda gerçekleşir:

İlk Eylem: Sorun oluşturulduğunda, Copilot raporu analiz eder ve sorunun meta verilerinin yaklaşık %80'ini otomatik olarak doldurur. Bu, sorun türü, kullanıcı segmenti, orijinal kaynak, etkilenen bileşenler ve kullanıcının deneyiminin bir özeti gibi 40'tan fazla veri noktasını içerir. Copilot daha sonra soruna bir problem özeti, önerilen WCAG kriterleri, ciddiyet seviyesi, etkilenen kullanıcı grupları, önerilen ekip ataması ve doğrulama için bir kontrol listesi içeren bir yorum gönderir.
İkinci Eylem: Bu sonraki Eylem, Copilot'ın yorumunu ayrıştırır, atanan ciddiyete göre etiketler uygular, sorunun proje panosundaki durumunu günceller ve inceleme için gönderene atar.

Önemli olarak, Copilot'ın analizi yanlışsa, herkes tutarsızlığı açıklayan bir sorun açarak bunu işaretleyebilir, bu da doğrudan GitHub'ın yapay zeka için sürekli iyileştirme sürecine katkıda bulunur.

İnsan Denetimi ve Tekrarlayan Erişilebilirlik İyileştirmeleri

İş akışı, insan denetimini ve işbirliğini vurgular. Copilot'ın otomatik analizinden sonra, "gönderen incelemesi" aşaması (3. adım), insan göndericinin yapay zekanın bulgularını doğrulamasını sağlar. Bu insan döngüde yaklaşımı, doğruluğu sağlar ve Copilot'ın sürekli iyileştirme süreci için manuel düzeltmelere veya işaretlemelere olanak tanır. Sonraki adımlar – Erişilebilirlik Ekibi İncelemesi, Denetimleri Bağlama ve Döngüyü Kapatma – insan uzmanlığını daha da entegre ederek, karmaşık sorunların uzmanlar tarafından ele alınmasını ve kullanıcıların zamanında, etkili çözümler almasını sağlar.

Bu dinamik sistem, GitHub için önemli bir değişimi temsil etmektedir. Yapay zekayı geri bildirim yönetiminin tekrarlayan ve veri yoğun yönlerini ele almak için kullanarak, kaotik, genellikle durgun bir süreci kapsayıcılık için sürekli, proaktif bir motora dönüştürdüler. Bu, her bir erişilebilirlik geri bildiriminin artık güvenilir bir şekilde izlendiği, önceliklendirildiği ve üzerinde işlem yapıldığı, "ikinci aşama" vaatlerinin ötesine geçerek tüm kullanıcılar için anında, somut iyileştirmeler sağlandığı anlamına gelir. Nihai amaç, insan muhakemesinin yerini almak değil, onu güçlendirmek, stratejik düzeltmelere odaklanmak ve gerçekten erişilebilir bir yazılım deneyimini teşvik etmek için değerli zamanı ve uzmanlığı serbest bırakmaktır.

Orijinal kaynak

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

Sık Sorulan Sorular

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.

Güncel Kalın

En son yapay zeka haberlerini e-postanıza alın.

Paylaş