GitHub’ın Erişilebilirlik Yolculuğunda Yeni Dönem
Beş yılın sonunda asıl soru şuydu: şimdi ne olacak?
Doğrusu, Bakın şimdi, erişilebilirlik işi çoğu yerde hâlâ “sonradan bakarız” klasöründe dürüyor (ben de ilk duyduğumda şaşırmıştım). GitHub’ın yaptığı şey işe tam tersine, bunu ürünün ve kültürün içine gömmek olmuş. Ben bu yaklaşımı bayağı kıymetli buluyorum; çünkü erişilebilirliği ayrı bir proje gibi ele aldığınız anda iş uzuyor, maliyet artıyor ve ekipler topu birbirine atmaya başlıyor. Beş yıl önce küçük bir program olarak başlayan yapı bugün mühendislik temelinin, tasarım sisteminin ve hatta yapay zekâ araçlarının içine yayılmış durumda.
<a11y-checklist>
1) Başlık hiyerarşisini düzelt
2) Form label'larını eşleştir
3) Tab sırasını test et
4) Kontrast oranını kontrol et
5) Hata mesajlarını seslendirilir hale getir
</a11y-checklist>
Bazen insanlar buna gereksiz detay gözüyle bakıyor. Oysa detay dediğiniz şey çoğu zaman ürünü kullanılabilir yapan tek fark oluyor. Ben AZ-500 çalışırken de aynı şeyi hissetmiştim:küçük görünen politika ayrıntıları bütün mimariyi kurtarıyor ya da batırıyordu. Erişilebilirlikte de tablo böyle.
Sıkça Sorulan Sorular
Erişilebilirlik neden açık kaynak projelerde daha zor?
Şunu söyleyeyim, Açık kaynak projelerde bakımcı sayısı az oluyor ve her şey gönüllülükle yürüyor. Yanı aksesibilite işleri çoğu zaman öncelik listesinin dibine iniyor. Buna rağmen, aslında küçük rehberler, test checklist’leri ve topluluk desteğiyle ciddi yol almak mümkün.
Erişilebilirliği uygulamak pahalı mı?
Başlangıçta öyle görünüyor ama bence asıl pahalı olan şey geç kalmak. Temel semantik HTML, kontrast kontrolü ve klavye testiyle ilk etapta ciddi mesafe alınıyor. Büyük yeniden yazımlara gelince—hem bütçeyi hem de zamanı yerle bir ediyor, açıkçası.
Küçük ekip mi büyük kurum mu daha hızlı ilerler?
Bir şey dikkatimi çekti: Küçük ekip hızlı karar alıyor, ama disiplin kurmak zor olabiliyor. Büyük kurum süreç oturtuyor; hani bürokrasi yüzünden — kendi adıma konuşayım — ağır hareket edebiliyorlar. İdeal model ortada bir yerde: hafif süreç + net standart + düzenli test ritmi.
Erişilebilirliğe nereden başlamalıyım?
Ana sayfadan değil, işlem kritik akışlardan başlayın: giriş, kayıt, ödeme, arama veya form doldurma adımları mesela. Tecrübeme göre en çok kullanılan yerlerdeki sorunları çözmek size en yüksek geri dönüşü veriyor. Ondan sonra component seviyesine inebilirsiniz zaten.
AI araçları erişilebilirliği iyileştirir mi?
Evet, doğru yönlendirilirse yardımcı oluyor. Kod önerileri semantik yapıyı güçlendirebiliyor, dokümantasyon oluşturabiliyor ve hata yakalamayı hızlandırabiliyor. Ama denetim şart; yanlış model çıktısı problemi büyütebiliyor, aklınızda bulunsun.
Kaynaklar ve İleri Okuma
Orijinal GitHub Yazısı — Building GitHub’s next chapter in accessibility
WAI — Web Accessibility Initiative (W3C)
Microsoft Fluent Design — Accessibility Guidance
Bir de şu var: Eğer mevcut blog arşivinizde ilgili içerikleri yan yana okumak isterseniz GitHub Copilot for Eclipse Açık Kaynak Öldü: Bu Ne Değiştiriyor?, Prompt Injection’ı Durdurmak: Agent Framework’te FIDES, Copilot cloud agent ile Kırık Actions İşini Tek Tıkta Çözmek yazıları da hoş giderdi—ama hepsini burada tekrar etmeyeyim.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
3 comments