GitHub, erişilebilirlik bildirimi dosyalarına görünürlük kazandırdı

GitHub erişilebilirlik bildirimi için yeni bir yer açıldı

GitHub erişilebilirlik bildirimi yaklaşımı, projelerde erişilebilirlikle ilgili dağınık bilgileri daha öngörülebilir bir noktada toplama hedefi taşıyor. GitHub, ACCESSIBILITY.md adlı dosyaları artık depo genel bakış sayfalarında görünür kılıyor. Böylece bir projenin erişilebilirlik hedefleri, katkı sunanlardan beklentileri, desteklenen ortamları, bilinen sınırlamaları ve engel bildirme yöntemi tek bir dosyada açıklanabiliyor.

Şirketin açıklamasına göre erişilebilirlik çalışmasına dair bilgiler çoğu zaman hata takip sistemlerinde, katkı rehberlerinde, denetim raporlarında, ekip bilgisinde ya da kullanıcılarla yapılan görüşmelerde kalıyor. Bu bilginin sabit bir adresi olmadığında, bir engelle karşılaşan kişilerin ilgili ayrıntıyı araması gerekiyor; projeye katkı verenler veya proje sahipliği değiştikçe de bağlam kaybolabiliyor. ACCESSIBILITY.md, bu dağınıklığa karşı kalıcı bir referans noktası olarak konumlanıyor.

Dosya nerede bulunabilir?

GitHub, ACCESSIBILITY.md dosyasını deponun kök dizininde, .github dizininde veya docs dizininde tanıyor. Bir depo, kuruluşun .github deposunda yer alan bildirimi de devralabiliyor. Bu seçenek, özellikle aynı kuruluş altındaki projelerde ortak bir erişilebilirlik çerçevesinin kullanılmasına imkân verebilir; ancak her proje kendi sınırlamalarını ve uygulamalarını ayrıca belgeleyebilir.

Açık depolarda bakım sorumluları, Insights > Community Standards bölümünden kısa bir başlangıç belgesi ekleyebiliyor veya önerebiliyor. GitHub bu düzenlemeyi, projelerin çalışma biçimini açıklayan mevcut topluluk sağlığı dosyalarının yanına yerleştiriyor. Katkı rehberleri değişiklik önerme yolunu, davranış kuralları katılım beklentilerini, güvenlik politikaları ise zafiyet bildirimini açıklar. ACCESSIBILITY.md’nin tanınmasıyla erişilebilirlik bilgisi de bu dokümantasyon setinde kendine ait bir alan kazanıyor.

Neden önemli: Bilgi, kullanıcı deneyiminin parçasıdır

Bu değişikliğin önemi, yalnızca yeni bir dosya adının desteklenmesinde değil, erişilebilirlik konusundaki bilginin projeyi kullananlar için daha kolay bulunabilir hâle gelmesinde yatıyor. Bir engelle karşılaşan kişi açısından, projenin hangi ortamları desteklediğini, hangi sorunların bilindiğini ve nasıl bildirim yapılacağını öğrenmek pratik bir ihtiyaç. Katkı sunanlar açısından ise değişiklik yaparken hangi erişilebilirlik beklentilerinin geçerli olduğunu görmek, proje içindeki kararların daha açık biçimde paylaşılmasını sağlayabilir.

GitHub ayrıca yeni depolara varsayılan olarak bir erişilebilirlik sorun etiketi ekliyor. Bildirimde, bir engelin nasıl raporlanacağının ve ardından ne beklenebileceğinin anlatılması; etikette ise ortaya çıkan işin düzenlenip izlenmesi amaçlanıyor. Bu iki unsur birlikte, erişilebilirlik sorunlarını yalnızca genel bir niyet beyanı değil, takip edilebilir proje işi olarak ele alma çerçevesi sunuyor.

GitHub CLI örneği: Sorunu ve geçici çözümü birlikte açıklamak

GitHub’ın verdiği örneklerden biri GitHub CLI’ın erişilebilirlik bildirimi. Bu belgede ayarlar, bilinen engeller ve geçici çözümler yer alıyor. Örneğin tablo çıktısının ekran okuyucuyla takip edilmesinin zor olabileceği belirtiliyor. Buna karşılık, çekme isteği numaralarını ve başlıklarını her satırda bir tane olacak biçimde yazdıran bir komut sunuluyor.

Belge yalnızca kullanıcıya yönelik bir çözüm aktarmıyor. İstemcideki istemleri veya çıktıları değiştiren katkıcıların, sonuçları ilgili erişilebilirlik ayarları etkin durumdayken göstermesi da isteniyor. Bu örnek, bildirimin iki ayrı gruba nasıl somut yön verebileceğini gösteriyor: Aracı kullanan kişi için alternatif bir kullanım yolu, araca katkı sunan kişi için ise değişiklik sırasında dikkate alınacak bir beklenti sağlanıyor.

Tasarım araçlarında görsel ilişkinin sınırı

GitHub Annotation Toolkit’in bildirimi ise Figma kitaplığındaki bir sınırlamayı belgeliyor. Açıklamaya göre ek açıklamalar, öğeler arasındaki ilişkiyi görsel olarak tuval üzerindeki konum, bağlantı çizgileri ve eşleşen numaralarla aktarıyor. Buna karşılık tekil tuval nesnelerine erişim, bu ilişkilerin ne olduğunu her zaman iletmeyebiliyor.

Bildirim, işbirliği yapanlara görsel ek açıklamalara eşlik edecek yapılandırılmış bir metin açıklaması sağlama önerisi veriyor. Bu açıklamanın her ek açıklamalı öğeyi, amaçlanan anlamını ve davranışını, ayrıca gerekli sıralama bilgisini tanımlaması isteniyor. Dosya aynı zamanda kitaplığın yalnızca klavyeyle veya ekran okuyucuyla test edilmediğini açıkça söylüyor. Bu ifade, doğrulanmış olanla henüz doğrulanmamış olan arasındaki sınırı kullanıcılar ve tasarım teslimiyle çalışan geliştiriciler için görünür kılıyor.

Tek bir şablon yerine güncel ve sürdürülebilir bilgi

GitHub, ACCESSIBILITY.md için tek ve zorunlu bir biçim dayatmıyor. Küçük bir kitaplığın, komut satırı aracının, dokümantasyon sitesinin ve büyük bir web uygulamasının kullanıcıları, riskleri ve bakım kapasitesi farklı olabilir. Bu nedenle şirketin önerisi, projenin güncel tutabileceği doğru bilgilerle başlamak yönünde.

Bu yaklaşım, erişilebilirlik bildiriminin kapsamlı görünmek uğruna eskiyen ya da doğrulanmamış vaatlerle dolmaması gerektiğine işaret ediyor. Projenin hedeflerini, bilinen engellerini, kullanılabilen geçici yolları ve bildirim sürecini açıkça yazmak; hem kullanıcıların neyle karşılaşabileceğini anlamasına hem de bakım sorumlularının bilgiyi proje değiştikçe korumasına yardımcı olabilir. GitHub’ın bu dosyayı depo görünümüne taşıması, erişilebilirlik bilgisini kenarda kalan bir not olmaktan çıkarıp açık kaynak projelerinin kamusal çalışma düzeninin bir parçası hâline getiriyor.