GitHub artık ACCESSIBILITY.md dosyalarını depo genel bakış sayfalarında görüntülüyor

GitHub, erişilebilirlik beyanlarını standart bir proje dosyası haline getiriyor

GitHub artık ACCESSIBILITY.md dosyalarını yerleşik olarak öne çıkarıyor ve open source bakımcılarına, projelerinin erişilebilirliği nasıl ele aldığını yayınlamaları için yerleşik bir konum sunuyor. GitHub Blog'da yer alan bilgiye göre dosya eklendiğinde depo genel bakış sayfalarında görünüyor; böylece bir projeye gelen herkes, issue kayıtlarını veya sohbet geçmişlerini karıştırmadan projenin erişilebilirlik duruşunu bulabiliyor.

GitHub'ın açıkladığı motivasyon parçalanmışlık: erişilebilirlik bilgileri genellikle issue takip sistemleri, katkı rehberleri, denetim raporları ve bireysel bakımcıların aklına dağılmış durumda. Öngörülebilir bir konumu olmadığında bir engelle karşılaşan kullanıcılar cevap aramak zorunda kalıyor ve projeler, katkıda bulunanlar ile sahiplik zamanla değiştikçe bu bağlamı kaybediyor.

Dosya nerede tanınıyor

GitHub Blog'da açıklandığı üzere ACCESSIBILITY.md, depo kök dizinine, .github/ dizinine veya docs/ dizinine yerleştirildiğinde tanınıyor. Depolar ayrıca kuruluşlarının .github/ deposundaki bir beyanı devralabiliyor; böylece kendi dosyası olmayan bir proje yine de kuruluş rehberini gösteriyor. Herkese açık depoların bakımcıları, Insights > Community Standards panelinden kısa bir başlangıç şablonu sunan bu panel aracılığıyla bir beyan ekleyebiliyor veya öneriyor.

Dosya, bir projenin nasıl işlediğini birlikte açıklayan katkı rehberleri, davranış kuralları ve güvenlik politikalarının yanı sıra GitHub'ın mevcut topluluk sağlığı dosyalarına katılıyor. Yeni depolar ayrıca varsayılan olarak bir erişilebilirlik issue etiketi içeriyor; bakımcılar bu etiketi gelen engel bildirimlerini düzenlemek ve takip etmek için kullanabiliyor.

GitHub'ın kendi ekipleri dosyayı nasıl kullanıyor

GitHub'ın kendi iki projesi, bir beyanın neler içerebileceğini örnekliyor. GitHub CLI'nın erişilebilirlik beyanı, desteklediği ayarları, bilinen engelleri ve geçici çözümleri belgeliyor. Örneğin, tablo biçimindeki çıktının ekran okuyucuyla takip edilmesinin zor olduğunu açıklıyor ve bunun yerine pull request numaralarını ve başlıklarını satır başına bir tane olacak şekilde yazdıran bir komut öneriyor. Ayrıca prompt veya çıktı değiştiren katkıda bulunanlardan, ilgili erişilebilirlik ayarları etkinleştirilmiş halde sonuçları göstermelerini istiyor.

GitHub Annotation Toolkit'in beyanı, Figma kütüphanesinin bir sınırlılığını ele alıyor: ek açıklamalar ilişkileri kanvas konumu, bağlantı çizgileri ve eşleşen numaralar üzerinden aktarıyor ve tek tek kanvas nesnelerine erişmek bu ilişkileri mutlaka iletmeyebiliyor. Beyan, iş birlikçilerden her bir ek açıklamalı öğeyi, amaçlanan semantiğini ve davranışını ve varsa ilgili sıralamayı tanımlayan yapılandırılmış bir metin açıklaması sunmalarını istiyor. Ayrıca kütüphanenin yalnızca klavye veya ekran okuyucu testinden geçmediğini açıkça belirtiyor; böylece okuyucular neyin doğrulanıp neyin doğrulanmadığını tam olarak biliyor.

GitHub dosyada neler bulunmasını öneriyor

Zorunlu bir format yok; GitHub, küçük bir kütüphanenin, bir komut satırı aracının, bir dokümantasyon sitesinin ve büyük bir web uygulamasının farklı kullanıcılara, risklere ve bakım kapasitesine sahip olduğunu belirtiyor. Önerilen başlangıç noktası, projenin gerçekten güncel tutabileceği doğru bilgi.

Önerilen bölümler şunlar: erişilebilirliğin proje için neden önemli olduğu ve hangi deneyimlere öncelik verildiği; katkıda bulunanlardan beklenen kontroller, kanıtlar veya inceleme uygulamaları; hem insan katılımcılar hem de kodlama agent'ları için talimatlar dahil; doğrudan ve erişilebilir bir bildirim yolu; bakımcıların bildirimleri nasıl onayladığı, önceliklendirdiği ve hakkında iletişim kurduğu; desteklenen platformlar, tarayıcılar, giriş yöntemleri ve yardımcı teknolojiler; geçici çözümler ve takip issue'larına bağlantılarla açıklanan bilinen sınırlılıklar; beyanın sahibinin ve bakımcısının kim olduğu; ve iyileştirme önerme yöntemi.

GitHub'ın bildirim rehberi ayrıntılı: etkilenen görev, gözlemlenen davranış, tarayıcı, işletim sistemi ve yardımcı teknoloji gibi bağlamı isteyin; ancak ekran görüntülerini ve kayıtları isteğe bağlı tutun ve kimseden engelini açıklamasını asla zorunlu kılmayın. Blog ayrıca, hedef olarak bir Web Content Accessibility Guidelines sürümü ve seviyesi belirtmenin bir uygunluk beyanı olmadığına dikkat çekiyor; uygunluk beyanı kapsam, tarih, yöntem ve değerlendireni belirten bir değerlendirme gerektiriyor. Daha kapsamlı bir referans isteyen projeler Open Source Accessibility Toolkit'in herkese açık örneğini uyarlayabilir.

Neden önemli

Bu, erişilebilirliği geçici ve çoğu zaman görünmez bir kaygıdan, belgelenmiş ve keşfedilebilir bir proje hijyeni parçasına taşıyor; davranış kuralları ve güvenlik politikaları da GitHub onlara standart dosya adları verdiğinde aynı normalleşme yolunu izlemişti. Engelli kullanıcılar için neyin çalışıp neyin çalışmadığını ve sorunları nasıl bildireceklerini öğrenebilecekleri öngörülebilir bir yer yaratıyor. Bakımcılar için ise erişilebilirlik bağlamını katkıda bulunan değişimlerine rağmen koruyor ve beklentileri baştan netleştiriyor; bu, otomatik agent'lar tarafından yazılan kodun artan payı için de geçerli. Daha geniş iddia kültürel: bir ACCESSIBILITY.md eklemek bir README eklemek kadar rutinleşirse, erişilebilirlik open source projelerinde sonradan akla gelen bir konu olmaktan çıkıp planlamanın ve geliştirmenin bir parçası haline geliyor.