Geçen ay İstanbul’da bir ürün toplantısındaydım — ekrandaki rapor erişilebilirlik skoru 78 gösteriyordu ve odanın havası bir anda o tanıdık “tamamdır, iş bitti” rahatlığına büründü. Ben de içimden kurdum o meşhur cümleyi: dur bir dakika, bu sayı tek başına hiçbir şeyi anlatmıyor.
İşin aslı şu: otomatik araçlar faydalı, bunu söylemiyorum değil. Ama onların verdiği puan çoğu zaman gerçeğin cilalı, rötuşlanmış bir versiyonu gibi duruyor. Lighthouse, axe-core ya da WAVE size hızlı bir kontrol listesi çıkarıyor — evet, tamam, kullanışlı. Fakat bu araçların yakaladığı şeylerle gerçek kullanıcıların yaşadığı engeller arasında ciddi bir mesafe var (bizzat test ettim). Ve o mesafe bazen can sıkıcı derecede büyük oluyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Skor Neden Bu Kadar Aldatıcı?
Şöyle düşünün: karmaşık bir konuyu tek rakama sıkıştırıyorsunuz. İnsan beyni buna kanıyor doğal olarak — 80 görünce iyi hissettiriyor, 90 görünce “az kaldı” diyorsunuz. Ama ekran okuyucu kullanan biri formu tamamlayamıyorsa, klavyeyle menüde dolaşamıyorsa ya da renk kontrastı yüzünden metni zar zor okuyorsa… o skor biraz makyajlı kalıyor işte.
Benzer şeyi 2023’te kendi yan projemde bizzat yaşadım; küçük bir SaaS arayüzü test ediyordum. Otomatik tarama bana gayet tatlı bir tablo gösterdi, neredeyse “aferin” diyecektim. Sonra gerçek kullanım senaryosuna geçtim — sadece klavyeyle gezince üç hayati butonun ulaşılmaz olduğunu fark ettim. Araç “iyi gidiyorsun” diyordu ama kullanıcı tarafında işler bayağı yamuktu.
Automated testing araçlarını yazım denetleyicisi gibi düşünmek lazım aslında. Yazım hatasını bulur, virgül eksikliğini işaret eder… ama cümlenin komple saçma olup olmadığını anlamaz. Erişilebilirlikte de durum birebir aynı: eksik alt metni görür, yanlış etiketlenmiş form alanını bulur, düşük kontrastı işaret eder. Fakat sayfada mantık akışı bozuk mu, odak sırası tamamen dağınık mı, yardım metni gerçekten anlaşılır bir dilde mi yazılmış — bunları çoğu zaman kaçırır, geçer.
Otomatik skorlar yol gösterir; ama yolculuğun kendisini yaşamazlar.
Sayıyla Ölçülen Şey Her Zaman Gerçek Değil
Bilmem anlatabiliyor muyum, Açık konuşayım: yüzde hesabı burada tehlikeli bir oyuncak oluyor. Bir ekip %70 gördüğünde bunu “neredeyse tamam” diye yorumlayabiliyor — halbuki erişilebilirlik dünyasında kalan o %30, bazen en kritik bariyerlere denk geliyor tam olarak. Ödeme adımı çalışmıyor olabilir. Modal pencerede odak kayboluyor olabilir (en azından benim deneyimim böyle). Ya da hata mesajları ekran okuyucuya hiç iletilmiyordur.
Ne yalan söyleyeyim, Bir de şu var, bunu özellikle söylemek istiyorum: bazı ekipler zamanla aracı memnun etmek için çalışmaya başlıyor. Yani kullanıcının gerçek sorununu çözmek yerine rapordaki kırmızı satırı yeşile boyuyorlar. Etiketi doğru yere taşımak güzel, evet. Ama yalnızca skor artsın diye yapılan kozmetik değişikliklerin pek kıymeti yok. Hatta bazen ters teper — ekip “erişilebilirliği hallettik” sanır ve mesele kapanır.
Kısa bir not düşeyim buraya. Multi-Turn Prompt Injection: ML’siz Tespit Taktikleri yazımızda bu konuya da değinmiştik.
Geçen sene Ankara’da görüştüğüm bir tasarım lideri bana şunu demişti: “Lighthouse bize iyi not verdi.” Güzel tabii. Sonra canlı demo yaptık bir düşüneyim… ve yalnızca Tab tuşuyla ilerleyince sipariş akışının tam ortasında tıkandık kaldık — resmen klasik. İşte orada, o an, skorun değil deneyimin önemli olduğu çok net ortaya çıktı.
| Automated skor | Tahmini yakalanan sorun oranı | Kaba okuma |
|---|---|---|
| %30 | %17 civarı | Daha yolun başı |
| %50 | %28-29 civarı | Temel açıklar var |
| %70 | %40 civarı | Kulağa iyi geliyor ama değil |
| %90+ | %51 civarı | Cilalı görünürlük yanılsaması |
| %100 | %57 üst sınır iddiası bile olsa… | Yanılgının zirvesi |
Neyse, bu sayıları çok uzatmayalım. Asıl mesele şu: yüzde yüksekse yönetici masasında yatırım baskısı azalıyor,. Insanlar eksiklerin büyüklüğünü görmüyor. Güven duygusu bazen gerçeğin önüne geçiyor — ve bu tehlikeli. Bu konuyla ilgili AI Reasoning Sistemleri: Zihin Teorisi Gerçekten Geldi mi? yazımıza da göz atmanızı tavsiye ederim.
Kullanıcı Görmeden Erişilebilirlik Tam Sayılmaz
Erişilebilirlik işi laboratuvarda bitmiyor. Aslında çoğu zaman asıl iş tam da laboratuvardan sonra başlıyor diyebilirim. Gerçek kullanıcı testi yapmadan elde edilen sonuçlar biraz steril kalıyor — temiz görünüyor ama hayatın kirini, karmaşasını, öngörülemeyen o anları taşımıyor.
Küçük startup ile kurumsal yapı aynı değil
Küçük bir startup’ta hız baskısı var; ekip iki haftada yeni özellik çıkarmak, müşteri kazanmak istiyor. Erişilebilirlik “sonra hallederiz” listesine düşüyor. Oysa daha en baştan birkaç temel alışkanlık oturtulsa, ileride oluşacak ciddi teknik borçtan kurtulunurdu — bu kadar basit aslında. Apple’ın MacBook Neo çıkmazı: İnce çizgi kalınlaştı yazımızda bu konuya da değinmiştik.
Enterprise tarafta ise bambaşka türden bir problem çıkıyor: süreç fazlasıyla var ama sahiplenme az olabiliyor. Herkesin onayı lazım, herkesin fikri var… fakat kimse gerçek kullanıcıyla oturup test etmiyor (ben de ilk duyduğumda şaşırmıştım). Açık konuşayım, bu ikisi arasında seçmek zorunda kalsam yine küçük takımın çevikliğini tercih ederim — erken müdahale çoğu zaman daha ucuz çünkü (şaşırtıcı ama gerçek) Zephyr Events: Küçük Paket, Büyük Yarış Durumu Dersi yazımızda da bu konuya değinmiştik. WebAssembly 3.0 ve .NET: 2026’da Web Uygulamalarının Yeni Ritmi yazımızda da bu konuya değinmiştik.
Araçların güçlü olduğu yer neresi?
Otomasyon çöpe atılacak bir şey değil — tam tersine, oldukça değerli bir ilk savunma hattı gibi çalışıyor. Eksik label’ları yakalar, ARIA hatalarını gösterir, kontrast sorunlarını haber verir. Yüzlerce sayfayı dakikalar içinde tarar. Bilhassa büyük sitelerde manuel kontrolde gözden kaçacak bariz problemleri süzmek için birebir.
Bu yüzden araç + insan testi birlikte yürümeli.
Bilhassa de formlar, menüler ve ödeme akışlarında canlı test şart.
Aksi halde rapor yeşil görünür… kullanıcı hâlâ kapıda bekliyor olur.
Peki Ne Yapmalı? Skora Değil Sürece Bakın
Bence pratik yaklaşım şu olmalı: otomatik taramayı başlangıç filtresi olarak kullanın, sonra mutlaka elle test edin. Mümkünse gerçek engelli kullanıcılarla doğrulayın. Bir rapor sizi yönlendirsin ama karar vermesin. Bu ayrımı bir kez kurduğunuzda işler çok daha sağlıklı ilerliyor — bunu deneyimleyerek gördüm.
- Axe veya Lighthouse ile temel teknik hataları bulun.
- Sadece fareyle değil klavyeyle de gezin.
- Ekran okuyucu testi yapın; NVDA ya da VoiceOver işinizi görür.
- Tasarımlarda renk kontrastını göz kararıyla bırakmayın.
- Error mesajlarını kısa ve anlaşılır yazın.
Daha açık söyleyeyim, bilmem anlatabiliyor muyum, Evet, listenin sonunda ufak tefek kırıklıklar çıkacak — bu normal, hatta beklenen. Mesele kusursuz olmak değil; sistematik biçimde, tutarlı şekilde iyileştirmek.
Metrikleri nasıl okumalı?
Ekip içinde tek sayı yerine birkaç sinyal birlikte kullanmak daha dürüst bir tablo veriyor bence. Teknik bulgu sayısı ayrı tutulsun, manuel testte geçen senaryolar ayrı izlensin, gerçek kullanıcı geri bildirimi ayrı bir sütun olsun. Böyle bakınca yönetim katmanına da çok daha sağlam bir hikâye anlatabiliyorsunuz.
Lighthouse skoru = başlangıç sinyali
Gerçek erişilebilirlik = teknik + tasarım + içerik + insan testi
Eğer sadece ilk satırı izliyorsanız,
hikâyenin yarısını kaçırıyorsunuz demektir.
# not really code — just a mental model
}Neden Liderler Yanlış Yorumluyor?
Kötü niyetten değil bu çoğu zaman — bunu netleştirelim. Sorun daha basit: tek sayı yönetmesi kolaydır. Toplantıda bir yüzde göstermek, onlarca detayı sıralamaktan çok daha rahat satılıyor. Ama kolay satılan şey her zaman (belki yanılıyorum ama) doğru olan şey değildir. Bunu yıllardır görüyorum, hâlâ şaşırıyorum.
Bence, Geçen mart ayında editör masasına gelen bir örnekte ürün sahibi neredeyse gururla “%82’ye çıktık” dedi. Ben de sordum: “Tamam, güzel… peki checkout’u sadece klavyeyle bitirebilen kaç kişi var?” O an sessizlik oldu. Sessizlik bazen cevaptan daha güçlüdür.
Birkaç net risk noktası:
- Yönetim yanlış güven hissine kapılıyor.
- Bütçe erken kesilebiliyor.
- Ekip performansı skora indirgeniyor.
- Kullanıcı deneyimi ikinci plana düşüyor.
Bir aracın yeşil ışığı, gerçeğin yeşil olduğu anlamına gelmez.
Bir aracın yeşil ışığı, gerçeğin yeşil olduğu anlamına gelmez.
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.
