ACCESSIBILITY.md: Erişilebilirlik Beyanını Depoda Tutmak

Erişilebilirlik bilgisi çoğu projede şuraya buraya dağılır: issue kayıtlarına, katkı rehberine, denetim raporlarına, ekibin kafasındaki birikime, kullanıcılarla yapılan yazışmalara. Bu bilginin öngörülebilir bir adresi olmayınca bir engelle karşılaşan kişi onu aramak zorunda kalıyor, katkıcılar ve proje sahipliği değiştikçe bakımcılar da bağlamı kaybediyor. GitHub artık depo genel bakış sayfalarında ACCESSIBILITY.md dosyasını tanıyor; projenin erişilebilirlik hedefleri, katkıcı beklentileri, desteklenen ortamlar, bilinen kısıtlar ve engel bildirim süreci böylece tek ve kalıcı bir yerde toplanabiliyor.

GitHub erişilebilirlik beyanlarını nasıl görünür kılıyor?

GitHub, ACCESSIBILITY.md dosyasını şu konumlarda tanıyor:

• Deponun kök dizini
• .github/ dizini
• docs/ dizini

Beyan, kuruluşun .github/ deposundan da devralınabiliyor. Aynı erişilebilirlik politikasını çok sayıda depoda tek tek tekrarlamak istemeyen kuruluşlar için pratik bir yol bu.

Public depolarda bakımcılar beyanı Insights > Community Standards ekranından, kısa bir başlangıç şablonu üzerinden ekleyebiliyor ya da önerebiliyor. GitHub’ın topluluk sağlığı dosyaları (community health files) zaten projenin nasıl işlediğini anlatmak için kullanılıyordu:

• Katkı rehberleri, değişikliklerin nasıl önerileceğini açıklar.
• Davranış kuralları, katılıma dair beklentileri belirler.
• Güvenlik politikaları, zafiyetlerin nasıl bildirileceğini anlatır.

ACCESSIBILITY.md‘nin tanınmasıyla erişilebilirlik bilgisi de bu rehberlerin yanında kendine ait bir yer buluyor. Yeni oluşturulan depolarda varsayılan olarak bir accessibility issue etiketi de geliyor. Beyan bir engelin nasıl bildirileceğini ve sonrasında ne beklenebileceğini anlatıyor, etiket ise ortaya çıkan işin bakımcılar tarafından düzenlenip izlenmesini kolaylaştırıyor.

Beyanlar proje pratiğini somutlaştırıyor

GitHub CLI’ın erişilebilirlik beyanı ayarları, bilinen engelleri ve geçici çözümleri belgeliyor. Tablo biçimindeki çıktının ekran okuyucuyla takip edilmesi neden zor olabilir, önce bunu açıklıyor; sonra onun yerine pull request numaralarıyla başlıklarını satır satır yazdıran bir komut veriyor. Beyan ayrıca prompt veya çıktı üzerinde değişiklik yapan katkıcılardan sonucu ilgili erişilebilirlik ayarları etkinken göstermelerini istiyor. CLI’ı kullanan geliştirici elinde somut bir geçici çözümle kalıyor, CLI’a katkı veren geliştirici ise değişikliğinden ne beklendiğini net bir ölçütle görüyor.

GitHub Annotation Toolkit’in beyanı ise Figma kütüphanesine ilişkin bir sınırlamayı belgeliyor: açıklamalar (annotation) ilişkileri görsel olarak aktarmak için canvas üzerindeki konumu, bağlantı çizgilerini ve eşleşen numaraları kullanıyor. Tek tek canvas nesnelerine erişebilmek, bu ilişkilerin ne anlama geldiğini mutlaka iletmiyor.

Beyan burada işbirlikçilere somut bir alternatif öneriyor: açıklanan her öğeyi, amaçlanan semantiğini ve davranışını, varsa sıralamasını tanımlayan yapılandırılmış bir metin açıklaması sağlamak. Tasarım devri (design handoff) hazırlayan ya da alan geliştirici için bu, görsel açıklamalara hangi bilginin eşlik etmesi gerektiğini netleştiriyor.

Aynı dosya erişilebilirlik engellerinin nasıl bildirileceğini de açıklıyor, kütüphanenin yalnızca klavye ya da ekran okuyucu testinden geçmediğini de açıkça söylüyor. Okuyucunun eline hem pratik yönlendirme geçiyor hem de projenin neyi doğruladığına dair net bir sınır. Bu bilginin depo genel bakışında görünür olması, projenin diğer belgeleriyle birlikte bulunmasını kolaylaştırıyor.

Projenin sürdürebileceği kadarını belgeleyin

ACCESSIBILITY.md için tek bir sabit biçim yok. 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 kullanıcıları da riskleri de bakım kapasitesi de aynı değil. Doğru olan ve projenin güncel tutabileceği bilgiyle başlamak gerekiyor. Kaynakta önerilen başlıklar şunlar:

• Öncelikler ve hedefler: Erişilebilirliğin proje için neden önemli olduğunu ve hangi kullanıcı deneyimlerine odaklanıldığını açıklayın.
• Katkıcı beklentileri: Değişiklikler için beklenen erişilebilirlik kontrollerini, kanıtları veya inceleme pratiklerini tanımlayın; hem insan katkıcılar hem de kodlama ajanları (coding agents) için talimat verin.
• Engel bildirimi: Doğrudan ve erişilebilir bir bildirim yolu sunun. Engellilik beyanı, ekran görüntüsü veya kayıt zorunlu tutulmamalı.
• Yanıt süreci: Bakımcıların erişilebilirlik sorunlarını nasıl teyit ettiğini, triyaj ettiğini, izlediğini ve ilettiğini açıklayın. Proje önem düzeyleri kullanıyorsa, bunların triyaj sırasında bakımcılar tarafından atanmasına veya doğrulanmasına izin verin.
• Desteklenen ortamlar: Desteklenen veya test edilmiş platformları, tarayıcıları, giriş yöntemlerini ve yardımcı teknolojileri listeleyin.
• Bilinen kısıtlar: Engelleri etkilenen deneyim üzerinden tarif edin, varsa geçici çözümleri ekleyin ve izlenen düzeltme işine bağlantı verin.
• Sahiplik ve bakım: Beyanı ve ilgili pratikleri güncel tutmaktan sorumlu ekibi, rolü veya bakımcıyı adlandırın.
• Geri bildirim ve iyileştirme: Kullanıcıların ve katkıcıların beyanda ya da projenin erişilebilirlik pratiklerinde değişiklik önerme yolunu açıklayın.

Bir proje hedef olarak bir Web Content Accessibility Guidelines (WCAG) sürümü ve seviyesi belirtebilir, ama hedef belirtmek doğrulanmış uygunluk anlamına gelmiyor. Uygunluk iddiası bir değerlendirme gerektirir; o değerlendirmenin kapsamı, tarihi, yöntemi ve değerlendiricisi de tanımlanmalıdır.

En işe yarar beyanlar neye benziyor?

En faydalı erişilebilirlik beyanları, bir şey zaten ters gittikten sonra o sayfaya ulaşan kişiye hizmet eder. Sade dil, hedefini açıklayan bağlantı metinleri ve net bir bildirim yolu, burada hukuki ya da standart ağırlıklı ifadelerden daha çok işe yarıyor.

İyi bir bildirim yönergesi ilgili bağlamı davet eder: etkilenen görev, sayfa, gözlemlenen davranış, tarayıcı, işletim sistemi, yardımcı teknoloji. Ekran görüntüsünü ve kaydı isteğe bağlı bırakır, kimseden engelliliğini kanıtlamasını istemez.

Beyanın koyduğu beklentiler de bakımcıların tutarlı biçimde karşılayabileceği beklentiler olmalı. Bildirimin alındığının teyidi, durum güncellemeleri, mevcut geçici çözümler, öngörülen süreler ve düzeltmeyi bildiren kişinin doğrulayabilmesi için bir fırsat, bunların hepsi buraya girebilir.

Bir örnekle başlayıp uyarlayın

Open Source Accessibility Toolkit ayrıntılı ve herkese açık bir örnek sunuyor. GitHub’ın Community Standards akışı ise daha kısa bir başlangıç dosyası veriyor; içindeki yönlendirmeleri projeler kendi bilgileriyle değiştiriyor. Amaç, dosyayı yayımlamadan önce kusursuz bir politika üretmek değil. Doğru bilgiyle başlayın, boşlukları açıkça adlandırın, projenin erişilebilirlik pratikleri olgunlaştıkça beyanı güncelleyin.

Erişilebilirlik beyanı eklemek, bu alandaki çalışmayı kullanıcılar, katkıcılar ve bakımcılar için daha keşfedilebilir kılıyor. Pratik açık kaynak projelerinde yaygınlaştıkça erişilebilirlik de toplulukların planlama, geliştirme, bildirim ve iyileştirme biçiminin bir parçası haline geliyor.

Kaynaklar ve İleri Okuma

• github.blog

• Accessibility statements now have a home on GitHub — The GitHub Blog (Jan Maarten)
• GitHub Docs: Deponuza erişilebilirlik sayfası ekleme
• GitHub CLI erişilebilirlik beyanı (ACCESSIBILITY.md)
• GitHub Annotation Toolkit erişilebilirlik beyanı
• Open Source Accessibility Toolkit örnek beyanı