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.
Şahsen, İşin ilginci şu: GitHub burada yalnızca “biz içerde düzen kurduk” demiyor. Bir adım ileri gidip topluluğa açılıyor. Açık kaynak dünyasında bu bence can alıcı bir kırılma noktası (ben de ilk duyduğumda şaşırmıştım). Çünkü açık kaynakta erişilebilirlik sorunu tek bir şirketin çözebileceği kadar dar değil; tam tersine, ortak dil, ortak pratik. Biraz da cesaret istiyor. Hani bazen bir projeye bakarsınız, kod güzel ama ekran okuyucuyla kullanmak işkence olur — işte tam o noktada mesele teknik olmaktan çıkıp insanı hâle geliyor.
2019’da Ankara’da bir kurumsal müşteriyle çalışırken benzer bir durum yaşamıştık. Uygulama dışarıdan gayet modern görünüyordu ama klavye gezintisi zayıftı, kontrast sorunluydu, formlar etiket taşımıyordu. İlk denetimde birkaç saat içinde on tane temel problem çıktı (evet, doğru duydunuz). Geliştirici ekip şaşırmıştı; çünkü kimse kötü niyetli değildi, sadece kontrol listesi yoktu. Açık konuşayım, erişilebilirlik çoğu zaman “fark etmediğimiz eksiklerin toplamı” oluyor.
GitHub’ın stratejisi neden önemli?
Bu yazıda beni en çok çeken şeylerden biri, stratejinin yalnızca iç operasyonlara dönük olmaması. İlk beş yılda içerideki borcu kapatmak mantıklıydı; önce temeli sağlamlaştırırsınız, sonra dışarıya açılırsınız. Az önce X dedim ama aslında Y daha doğru olabilir: burada asıl başarı ölçüsü teknik iyileştirme değil, davranış değişikliği (şaşırtıcı ama gerçek). Yanı ekipler artık erişilebilirliği “ekstra iş” gibi değil, normal iş gibi görüyorsa asıl dönüşüm başlamış demektir.
Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de bu teknolojinin benimsenmesi biraz farklı ilerliyor. Büyük kurumlar genelde güvenlik ve uyumluluk tarafına hızlı giriyor ama erişilebilirlik konusu ya tasarım ekibine bırakılıyor ya da test aşamasında hatırlanıyor. Küçük ekiplerde işe durum başka; herkes her şeyi yaptığı için hız var ama disiplin eksik kalabiliyor. Enterprise tarafta süreç kurmanız gerekiyor, startup tarafında işe sade ama net kurallar koymanız lazım. İkisinde de ortak nokta şu: erken başlarsanız çok ucuz çözülecek şeyler aylar sonra faturalandırılıyor.
Erişilebilirlik lüks değil; ürün kalitesinin sessiz ölçüsü. Kullanamayan biri varsa ürününüz eksiktir.
Açık kaynakta erişilebilirliği ölçeklemek kolay mı?
Kısa cevap: Hayır. Uzun cevap: yine hayır ama yapılabilir! Bakın, açık kaynak dünyasında bakımcı sayısı sınırlı olabiliyor, belgeler eski kalabiliyor ve öncelikler çok hızlı değişiyor. GitHub’ın open source accessibility tarafında yaptığı hamlelerin değeri burada ortaya çıkıyor; sadece kendi ürününü düzeltmekten bahsetmiyorlar, ekosistemi toparlamaya çalışıyorlar.
Bunu geçen yıl İstanbul’daki bir gönüllü topluluk etkinliğinde çok net gördüm. Birkaç bağımsız geliştiriciyle konuşurken hepsi aynı şeyi söylüyordu: “İyi niyet var ama rehber yok.” Mesela ekran okuyucu desteği için gerekli küçük dokunuşları bilen azdı; aria etiketleri vardı ama mantığı oturmamıştı; renk kontrastı gözle görülür şekilde yetersizdi (inanın bana). Neden önemli bu? Yanı mesele teknoloji yokluğu değil, pratik bilgisizlikti.
Bi saniye — GitHub’ın Open Source Assistive Technology Hackathon gibi etkinlikleri burada güzel çalışıyor. Teoriyi bırakıp doğrudan üretime sokuyor insanları. Bu bana AZ-305 hazırlığında yaşadığım bir şeyi hatırlattı: mimariyi ezberleyebilirsiniz ama gerçek senaryoda karar vermeyi bilmiyorsanız sınav kağıt üstünde kalır. Aynı mantık burada da geçerli — rehberi okumak yetmez, eli kirletmek lazım.
Evet, doğru duydunuz.
Pratikte ne işe yarıyor?
Hackathon’larda çıkan sonuçların en güçlü yanı hız değil aslında; ortak dil yaratmalarıdır. Bir proje bakımcısı ile yardımcı teknoloji geliştiren kişi aynı masaya oturunca soyut kavramlar somutlaşıyor. “Bu buton neden odakta kayboluyor?” sorusu ile “bu kullanıcı nasıl işlemi tamamlayacak?” sorusu aynı yere bağlanıyor.
Neyse uzatmayalım, iyi kurgulanmış bir erişilebilirlik girişimi size üç şey kazandırır: daha az hata bildirimi, daha geniş kullanıcı kitlesi ve daha temiz arayüz alışkanlığı. Kötü yanı da var tabi — ilk başta ekip biraz yavaşlıyor hissi oluşuyor. Ama bu geçici bir rahatsızlık; sonrasında kalite oturunca geri dönüş netleşiyor.
Ve işler burada ilginçleşiyor.
| Yaklaşım | Küçük Ekip | Büyük Kurum |
|---|---|---|
| Erişilebilirlik sahibi | Tek kişi veya çapraz rol | Program + tasarım + QA + mühendislik |
| Kontrol yöntemi | Basit checklist | SDA/CI otomasyon + manuel test |
| Maliyet baskısı | Düşük başlangıç bütçesi | Daha yüksek entegrasyon maliyeti |
| Kazanç tipi | Daha hızlı ürün/özgüven | Daha geniş uyumluluk ve risk azaltma |
Tasarım sistemi ile AI araçları birleşince ne oluyor?
Şunu söyleyeyim, Burası bence hikâyenin en ilginç kısmı. Eskiden erişilebilirlik çoğunlukla frontend meselesi gibi görülürdü; şimdi iş tasarım sistemine ve yapay zekâ araçlarına kadar uzanıyor. GitHub’ın yaklaşımı da bunu gösteriyor zaten: bileşen kütüphanesi düzgünse yeni ekran üretirken hata payı azalıyor, AI araçları da daha iyi öneri veriyor. Fena değil yanı… hatta baya işe yarıyor (evet, doğru duydunuz) Daha fazla bilgi için Visual Studio’da Plan Agent: Kodu Yazmadan Önce Durup Düşünmek yazımıza bakabilirsiniz.
Ben 2024’te İzmir’deki bir SaaS müşterisinde benzer bir düzen kurarken şunu fark ettim: tasarım sistemi olan ekipler hız kazanıyor (ciddiyim). Bileşenlerin a11y kuralları eksikse hata aynı hızla çoğalıyor. Menü açılıyor ama focus geri dönmüyor; modal kapanınca kullanıcı nerede kaldığını anlamıyor. Şey gibi düşünün — evde ışığı kapatıp anahtarı yerini unutmak gibi! Arayüz de bazen böyle karanlıkta bırakabiliyor insanı. Daha fazla bilgi için npm’de İmzayı Sıkılaştıran Yeni Dönem: Stage Queue ve Allow Flag’ler yazımıza bakabilirsiniz.
Hmm, bunu nasıl anlatsamdı… Daha fazla bilgi için LLM Cold Start Derdi: Blob Stream ile Hız Kazanmak yazımıza bakabilirsiniz.
Aslında, Yapay zekâ tarafında işe konu daha hassas. Copilot benzeri araçlar kod üretirken erişilebilir isimlendirme. Doğru HTML semantiği önerirse büyük avantaj sağlıyor; fakat yanlış eğitim verilirse hatayı ölçekli hâle getiriyor. Geçen ay Mart 2026’da yaptığımız iç değerlendirmede benzer bir kod örneğinde AI’nın div üstüne div yığdığını gördük; klavye akışı bozulmuştu (en azından benim deneyimim böyle). Yanı AI kurtarıcı olabilir ama denetimsiz olursa hayal kırıklığı da yaratır.
Bence hayatı nokta ne?
Hani, Kritik nokta şu: erişilebilirliği “test sonu kontrolü” olmaktan çıkarıp standart hâline getirmek (yanlış duymadınız). Aksi hâlde her sprint sonunda küçük yangınlar söndürürsünüz. Bu bana Azure IaaS projelerinde güvenlik katmanlarını sonradan eklemeye çalışan ekipleri hatırlatıyor; başta kolay görünür,sonra karmaşa büyür.
- Yeni component tanımlarken klavye odağı var mı diye bakın. (bence en önemlisi)
- Renk kontrastını design token seviyesinde zorunlu tutun.
- ARIA’yı dekor gibi değil, ihtiyaç oldukça kullanın.
- Ekran okuyucu testi için haftalık mini rutin oluşturun.
Türkiye’de şirketler bunu nasıl ele almalı?
Yanı, Açık konuşayım, Türkiye’de birçok kurumda erişilebilirlik hâlâ regülasyon başlığı olarak görülüyor; oysa pazarlama değeri de var,müşteri memnuniyeti de var,hatta destek çağrılarının azalması bile var. En çok da kamuya — kendi adıma konuşayım — çalışan firmalar ile bankacılık tarafında durum biraz daha ciddiye alınıyor çünkü dış denetim baskısı hissediliyor. Ama KOBİ’lerde mesele genelde “bizi etkiler mi?” sorusuna sıkışıyor (evet, doğru duydunuz)
Etkiler. Hem de beklediğinizden fazla. İstanbul’da 2025 başında görüştüğüm orta ölçekli bir e-ticaret firmasının canlı sohbet kayıtlarında en çok gelen şikâyetlerden biri form dolduramayan kullanıcılardan geliyordu. Sorun kodda minicikti:label yoktu,odak sırası bozuktu,bir de ödeme ekranında hata mesajı okunmuyordu. Bazen küçücük eksiklik büyük satış kaçırıyor,işin aslı şu ki… bu tür kaybın faturası görünmez olduğu için kimse sahiplenmiyor.
Kurum içi önerim basit:ilk etapta üç alan belirleyin — ana sayfa,kimlik doğrulama akışı,para/işlem adımları. Çünkü en çok trafik orada olur. Orada sorun varsa etkisi büyüktür. Denemek istiyorsanız ilk iş bu üç yolu haritalayın;gerisi ardından gelir.
Kendi sahadan notlarım ve çıkarımlarım
2023’te Logosoft’ta bir finans müşterisinde çalışırken raporlama ekranlarının neredeyse tamamı mouse odaklıydı. Bir çalışan geçici el sakatlığı nedeniyle klavyeye döndüğünde işler durdu;çok basit görünen bazı işlemler sekmeler arasında dolaşılamadığı için tıkandı. Bu olaydan sonra ekip kısa sürede keyboard-first yaklaşımına geçti. Sonuç? Destek talebi düştü,işlem süresi kısaldı. Açıkçası beklediğim kadar sancılı olmadı. Azure Files’ta Kimlik Duvarı Kalktı: Entra-Only Dönemi yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Azure NetApp Files ile EDA Yükünü Bulutta Taşımak: Neden İşe Yarıyor? yazımıza da göz atmanızı tavsiye ederim.
<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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder