Şahsen, Avrupa’da erişilebilirlik meselesi artık “güzel olur” kategorisinden çıktı. Resmen zorunlu. 2025 yazına girerken bu konu birçok ekipte masaya sertçe düştü ve ben de editör koltuğunda ilk kez bu kadar yoğun “a11y” konuşulduğunu fark ettim — açıkçası 2024 sonbaharıydı o dönem, hani bazı teknik başlıklar vardır ya, herkes önemli der ama kimse elini taşın altına koymaz… işte erişilebilirlik tam olarak öyleydi, uzun süredir. Şimdi o dönem kapandı.
İşin aslı şu: Avrupa’daki çerçeve tek bir standarttan ibaret değil, ülkeye göre değişen uygulamalar var. Fransa tarafında RGAA 4.1 bayağı net ve detaylı bir referans sunuyor. WCAG’ye yaslanıyor ama aynı şey değil — daha fazla kriter, daha sıkı test yöntemi. Sahada “tamam mı devam mı?” dedirten bir yapı var ortada (ki bu çoğu kişinin gözünden kaçıyor)
Kısa bir not düşeyim buraya.
Geçen yıl Şubat 2025’te Paris merkezli küçük bir SaaS ekibiyle yaptığım görüşmede bunu çok net gördüm. Ekip, Axe ve Lighthouse raporlarına güvenip rahatlamıştı. Sonra resmi denetim checklist’i gelince yüzleri düştü (en azından benim deneyimim böyle). Çünkü araçlar WCAG dili konuşuyordu, denetçi ise RGAA istiyordu. Aradaki boşluk da küçük değildi.
WCAG başka, RGAA başka: Kağıt üstünde benzer, pratikte ayrı dünya
Bakın şimdi, dışarıdan bakınca “ikisi de erişilebilirlik standardı işte” deyip geçmek kolay. Ama RGAA’nın olayı biraz daha sert. Neden önemli bu? WCAG size neye ulaşmanız gerektiğini söylerken, RGAA çoğu zaman nasıl test edeceğinizi de tarif ediyor — bu fark küçük görünür ama audit tarafında geceyi gündüze çevirir, inanın.
İtiraf edeyim, RGAA 4.1’de 106 kriter var. Bu sayı tek başına bile insanı durup düşünduruyor. Yalnızca görsel kontrast veya form etiketleri gibi klasik başlıklar yok; dil bildirimi, HTML doğruluğu, gezinme tutarlılığı, başlık hiyerarşisi gibi detaylar da işin içine giriyor, kısacası standart “gözle kontrol edilir” seviyesinde değil, bayağı sistemli davranmak gerekiyor.
Ben buna ilk kez 2023’te Lyon’daki bir kamu projesinde denk geldim. Geliştiriciler Axe raporunu temizleyince her şey bitti sanmıştı. Ama gerçek denetimde menü yapısı ve sayfa şablonları yüzünden tekrar tekrar aynı hatalar çıktı. Yani tek sayfayı düzeltmek yetmiyor. Yapıyı düzeltmek gerekiyor.
Evet, doğru duydunuz.
Garip gelecek ama, E tabi burada en kritik mesele şu: RGAA’yı manuel yürütmek mümkün ama pahalı ve yavaş. Bilhassa kurumsal ölçekte yüzlerce sayfa varsa ekipler CSV çöplüğünün içinde boğuluyor, bu da otomasyonun değerini sadece hız meselesinin ötesine taşıyor — asıl kıymet nerede toplu etki yaratacağını göstermekte. ₹12 LPA Alan Yeni Mezunun Gerçek Beceri Paketi: Ne Öğrenmişti? yazımızda bu konuya da değinmiştik.
%62 otomasyon neden önemli?
Heyecanlanmayın hemen. Rakam güzel görünüyor, evet, ama asıl kıymet oran değil etki alanı. Toplam 106 kriterin 66’sı otomatik test edilebiliyorsa, denetimin ciddi bir kısmını makineye bırakıp insan enerjisini gerçekten zor olan kısımlara saklayabiliyorsunuz — bu fark düşündüğünüzden büyük.
Mesela görüntülerde alternatif metin eksikliği ya da formlarda label kaybı gibi sorunlar otomasyona oldukça uygun. Buna karşılık video altyazısı veya sesli içerikte bağlamsal değerlendirme hâlâ insan gözü istiyor. Araç sizi kurtarır. Ama tamamen kurtarmaz. Neden önemli bu? Burada hayal kırıklığı yaşamak istemeyenler bunu peşinen kabul etmeli. Bu konuyla ilgili Sam Altman’ın Sözleri: Kriz, Başarı ve Yapay Zekâda Fren Meselesi yazımıza da göz atmanızı tavsiye ederim.
| Kategori | Otomasyon Oranı | Pratik Yorum |
|---|---|---|
| Zorunlu öğeler | %90 | En hızlı kazanım burada |
| Navigasyon | %73 | Şablon bazlı hatalar yakalanır |
| Yapısal öğeler | %75 | Başlık ve liste düzeni önemli |
| Renkler | %67 | Tasarım sistemi varsa iş kolaylaşır |
| Formlar | %54 | Karmaşık akışlarda manuel kontrol gerekir |
| Görseller | %56 | Pek çok hata tekrar eder durumda olur |
| Medyalar | %23 | Neredeyse yarı yarıya insan kararı ister |
Lafı gevelemeden söyleyeyim: en yüksek geri dönüş zorunlu öğelerde geliyor (yanlış duymadınız). Çünkü bunlar her sayfada karşınıza çıkıyor — bir şirket logosunun olduğu header’da dil etiketi eksikse ya da neredeyse tüm site boyunca title boşsa, bunun etkisi tekil değil sistemik oluyor, ve bunu genelde faturayı ödeyene kadar kimse fark etmiyor.
Araçların kör noktası: Rapor var, çözüm yoksa ne işe yarar?
Şunu fark ettim: Axe-core gibi motorlar teknik olarak iş görüyor, buna lafım yok. Ama ham çıktıyı olduğu gibi vermek çoğu — kendi adıma konuşayım — ekip için yeterli olmuyor. Bir satırda “287 görselde alt metin yok” yazması başka şeydir; bunun hangi komponentten geldiğini söylemesi bambaşka şeydir. Kod Kapsama Araçları: 2026’da En İyiler ve Gerçekler yazımızda bu konuya da değinmiştik.
Editör masasında bunu görünce aklıma hep aynı örnek geliyor: mutfakta 500 tane kirli tabak görmekle bulaşık makinesinin hangi rafta tıkandığını bilmek arasında fark var (yanlış duymadınız). İlki moral bozar. İkincisi işi çözer. İşte pattern detection tam olarak bunu yapıyor.
Patern tespiti neden kritik?
Vallahi, Sistem aynı CSS seçiciye sahip tekrar eden ihlalleri eşleştirince şunu diyebiliyor: “Sorun ürün kartında.” Bu cümle çok basit duruyor ama pratikte saatler kazandırıyor, hatta bazen günlerce sürecek düzeltmeyi tek PR’a indiriyor — bunu ilk gördüğümde gerçekten şaşırdım açıkçası.
{
"image-alt": {
"rgaaCriteria": ["1.1", "1.2"],
"theme": "Images",
"testMethod": "automatic"
}
}Bunu kendi projelerimde de gördüm; özellikle tasarım sistemi kullanan startup’larda bir komponenti düzeltmek onlarca sayfayı toparlıyor. Kurumsalda ise işler biraz daha ağır ilerliyor çünkü onay zinciri uzuyor,. Sonuç yine aynı yere çıkıyor: doğru yerden müdahale ederseniz etkisi katlanıyor.
Neden çok sayfalı tarama şart?
Ana sayfayı temizlemek çoğu zaman göz boyar sadece. Gerçek denetim için giriş ekranları, iletişim formu, içerik sayfası (yanlış duymadınız). Farklı şablonların hepsi görülmeli — çünkü sorun çoğu zaman tekil sayfada değil şablonun ta kendisinde gizlenir.
- Ana sayfa ile yetinmeyin.
- Kritik kullanıcı akışlarını dahil edin.
- Aynı bileşenin farklı varyantlarını test edin.
- Taslak yerine canlı DOM üzerinden karar verin.
- Sadece hata bulmayın; tekrar eden kalıbı bulun. — ciddi fark yaratıyor
Küçük startup ile enterprise arasında fark ne?
Bence, Küçük bir startup için en mantıklı yaklaşım önce hızlı kazanımları toplamak olurdu: eksik lang etiketi, yanlış title yapısı, kontrast sorunu… Bunlar az maliyetle büyük etki verir ve ekip motivasyonunu düşürmez, hatta tersine. Ben Mart 2025’te Berlin’de çalışan iki kişilik bir ürün ekibinde bunu gördüm; üç saatlik çalışma sonunda ana sorunların yarısı kapanmıştı. Ciddi fark var. Yapay Zekâ İş Arama Ajanı: Dedalus ile Yeni Katman yazımızda da bu konuya değinmiştik. WhatsApp’ta Kendi Yerel Yapay Zekânı Kurmak: Node.js ve Ollama yazımızda da bu konuya değinmiştik.
Vallahi, Enterprise tarafında ise mesele teknik olmaktan çok operasyonel hale geliyor. Denetim raporu çıkarıyorsunuz ama devreye — ki bu tartışılır — girmesi için tasarım ekibi, frontend ekibi. Hukuk/compliance tarafının aynı masaya oturması gerekiyor — açık konuşayım, bazen koddan daha zor olan bu koordinasyon oluyor, inanın (inanın bana)
Düşük bütçede nasıl ilerlenir?
Eğer kaynak azsa önce otomasyona uygun kriterleri toplayın ve onları sprint planına dağıtın. Form etiketleri, sayfa başlıkları ve heading sırası iyi başlangıç noktalarıdır — hem uygulanması kolaydır hem de hemen hissedilir sonuç verir. Başka bir şeyle başlamayın.
Büyük organizasyonda ne değişir?
Büyük yapılarda raporu üretmek kadar raporu yaşatmak da önemli. Yani CI/CD hattına gömmek gerekir ki yeni hata tekrar içeri sızmasın — yoksa her release sonrası yeniden temizlik yapmak zorunda kalırsınız, bu da hem yorucu hem moral bozucu. Ben bunu 2024 sonunda Amsterdam merkezli bir fintech toplantısında dinledim; ekip haftalık tarama olmadan ilerleyemediklerini söylüyordu, oldukça dürüst bir itiraftı.
Dikkat edilmesi gerekenler ve pratik ipuçları
Bence bu işte en büyük tuzak araç fetişi yapmak. Rapor üreten aracı kurup “tamamdır” demek çok kolay ama yanıltıcı. Araç size sinyal verir, karar vermez. Kararı veren ekip olmak zorunda. Bu kadar.
Neyse uzatmayalım… Eğer böyle bir sistemi kuruyorsanız şu noktalara bakın: (yanlış duymadınız)
- Tarama kapsamını tek sayfa ile sınırlamayın;
- Aynı hatanın kaç yerde tekrar ettiğini ölçün; — ciddi fark yaratıyor
- Düzeltmeleri komponent seviyesinde yapın;
- Tasarımdan kodlamaya kadar ortak dil kurun;
- Metrikleri sprint hedeflerine bağlayın;
- Mümkünse her release öncesi otomatik kontrol çalıştırın;
- Medyalar için manuel incelemeyi ayrı tutun. (bence en önemlisi)
Açık konuşayım, burada beni en çok etkileyen şeylerden biri geri bildirim döngüsünün kısalığı oldu. Geçen ay İstanbul’da görüştüğüm bir ajans, pattern detection sayesinde rapor süresini ciddi biçimde kısaltmıştı —. Artık tek tek dosya okumak yerine çözüm kümesini görüyordu. Fark buydu işte.
“Erişilebilirlik denetimi sadece hata listesi değildir; doğru kurulursa ürün geliştirme sürecinin hızlandırıcısı olur.”
Sıkça Sorulan Sorular
FAQ bölümü nedir?
Bazıları sorgu mu anlamadı?…
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.
