Erişilebilirlik Denetimi Nedir? Web Sitenizin WCAG’ye Uygun Olup Olmadığı Nasıl Kontrol Edilir

En son WebAIM Million raporuna göre, bir milyon ana sayfa genelinde 56 milyon farklı erişilebilirlik hatası tespit edildi — sayfa başına ortalama 56 hata. Bu, web sitelerinin ezici çoğunluğunun her gün engelli kullanıcıları aktif olarak yüzüstü bıraktığı anlamına geliyor. Bir web sitesi sahibi, geliştirici veya uyumluluk yöneticisi olarak sitenizin WCAG ile uyumlu olup olmadığını merak ediyorsanız, yanıt neredeyse kesin olarak düzgün bir erişilebilirlik denetimi yürütmeyi içerir. Asıl soru şu: Bu gerçekte ne anlama geliyor ve bunu doğru şekilde nasıl yaparsınız?

Erişilebilirlik Denetimlerinin Neden Vazgeçilmez Hale Geldiği

Web erişilebilirliği artık iyi niyetler alanını çoktan geride bıraktı. Artık giderek artan sayıda yargı alanında yasal bir zorunluluk ve uyumsuzluğun sonuçları somut ve ölçülebilir. 2024 yılında yalnızca Amerika Birleşik Devletleri'nde 4.000'den fazla web erişilebilirliği davası açıldı ve bu eğilim artmaya devam ediyor. ABD’de mahkemeler, halka açık işletmelerin web sitelerinin ADA Title III kapsamında erişilebilir olması gerektiğine tutarlı şekilde hükmetti. Bu arada, Avrupa Erişilebilirlik Yasası Haziran 2025’te tüm AB üye devletlerinde uygulanabilir hale geldi ve gereklilikleri devlet sitelerinin ötesine taşıyarak bankacılık uygulamalarını, e-ticaret platformlarını, SaaS ürünlerini ve daha fazlasını kapsayacak şekilde genişletti.

Rakamlar çarpıcı bir tablo çiziyor. Küresel nüfusun yaklaşık %16’sı — yaklaşık 1,3 milyar insan — bir tür engelle yaşıyor. Yalnızca Amerika Birleşik Devletleri’nde yetişkinlerin yaklaşık dörtte birinin bir engeli var. Bunlar uç örnek kullanıcılar değil. Bunlar, çoğu geliştiricinin aklına bile gelmeyen engellerle karşılaşan müşteriler, çalışanlar, öğrenciler ve vatandaşlar.

Hukuki riskin ötesinde, ölçülebilir bir iş gerekçesi de var. Erişilebilir web siteleri arama motorlarında daha iyi performans gösterir, çünkü ekran okuyuculara yardımcı olan aynı yapısal netlik — semantik başlıklar, açıklayıcı alt metin, temiz işaretleme — tarayıcılara da yardımcı olur. Kapsayıcı tasarım herkes için kullanılabilirliği tutarlı şekilde iyileştirir: altyazılar gürültülü ortamlardaki insanlara fayda sağlar, yüksek kontrast parlak güneş ışığında insanlara yardımcı olur ve klavye ile gezinme güç kullanıcılarına avantaj sağlar. Erişilebilirlik denetimi, tüm bu faydaları elde etme yolunda ilk adımdır.

Bir diğer önemli değişim: ADA Title II artık ABD eyalet ve yerel yönetim kurumları için web erişilebilirliğini açıkça zorunlu kılıyor ve DOJ, teknik standart olarak WCAG 2.1 Seviye AA’yı benimsedi. 50.000 veya daha fazla nüfusa hizmet veren kurumlar 26 Nisan 2026’ya kadar uyum sağlamak zorunda. Kamu sektörü müşterileriyle çalışıyorsanız veya düzenlemeye tabi sektörlerde faaliyet gösteriyorsanız, denetim artık isteğe bağlı değil — acil.

WCAG Erişilebilirlik Denetimi Tam Olarak Nedir?

Web erişilebilirlik denetimi, web sitenizin Web İçeriği Erişilebilirlik Yönergeleri’ne (WCAG) — W3C tarafından geliştirilen, dijital erişilebilirlik için uluslararası kabul görmüş teknik standarda — uyumunun sistematik bir değerlendirmesidir. Uygulamada bir denetim, engelli kullanıcıların içeriğinizi algılamasını, anlamasını, gezinmesini ve onunla etkileşime girmesini engelleyen belirli bariyerleri tespit eder. Bu bariyerleri WCAG başarı kriterleriyle eşleştirir, önem dereceleri atar ve bir iyileştirme yol haritası üretir.

WCAG şu anda 2023 sonlarında yayımlanan ve Mayıs 2025’te W3C tarafından web erişilebilirliği için en yüksek standart olarak resmen yeniden teyit edilen 2.2 sürümündedir. WCAG 2.1’e göre dokuz yeni başarı kriteri içerir; klavye odak görünürlüğü, minimum dokunma hedefi boyutları, sürükleme hareketine alternatifler ve tutarlı yardım mekanizmaları gibi alanları kapsar. Önemli bir nokta, WCAG 2.2’nin geriye dönük uyumlu olmasıdır — 2.2’yi karşılamak, 2.1 ve 2.0’ı da karşıladığınız anlamına gelir.

WCAG üç uyum seviyesine göre düzenlenmiştir. Seviye A en kritik bariyerleri kapsar — bu seviyedeki başarısızlıklar içeriği bazı kullanıcılar için tamamen kullanılamaz hale getirir. Seviye AA, ADA, Avrupa Erişilebilirlik Yasası ve Section 508 dahil olmak üzere dünya çapındaki çoğu erişilebilirlik yasası tarafından zorunlu tutulan hedeftir. Seviye AAA en yüksek çıtayı temsil eder ve genellikle yasal zorunluluktan ziyade hedef olarak görülür. Birisi sitesinin “WCAG uyumlu” olduğunu söylediğinde neredeyse her zaman WCAG 2.1 veya 2.2, Seviye AA’yı kasteder.

WCAG, genellikle POUR kısaltmasıyla hatırlanan dört temel ilke üzerine kuruludur: içerik Algılanabilir (kullanıcılar onu hissedebilir), Çalıştırılabilir (kullanıcılar onunla etkileşime girebilir), Anlaşılabilir (kullanıcılar onu kavrayabilir) ve Sağlam (yardımcı teknolojilerle güvenilir şekilde çalışır) olmalıdır. Her başarı kriteri bu dört ilkeden birine geri döner ve kapsamlı bir denetim, tümü için uyumu kontrol eder.

Denetimlerin Ortaya Çıkardığı En Yaygın Hatalar

Tespit edilen tüm erişilebilirlik hatalarının yaklaşık %96’sı yalnızca altı kategoriye girer. Neye bakacağınızı bilmek, denetim çabanızı önceliklendirmenin en hızlı yoludur:

• Düşük kontrastlı metin. Bu, tutarlı şekilde en yaygın hatadır. Ana sayfaların neredeyse %84’ünde, normal metin için WCAG 2 AA kontrast eşiği olan 4,5:1’in altında kalan metin bulunur. Denetçiler, TPGi Colour Contrast Analyser gibi araçlarla ön plan-arka plan renk oranlarını kontrol eder.
• Eksik alternatif metin. Tüm ana sayfa görsellerinin %16’sından fazlasında herhangi bir alt niteliği yoktur; bu da ekran okuyucu kullanıcılarının görsel içeriği anlamasının hiçbir yolu olmadığı anlamına gelir. Alt metni olmayan bağlantılı görseller özellikle zararlıdır — anlamsız gezinme hedeflerine dönüşürler.
• Boş bağlantılar. Görünür metni ve erişilebilir adı olmayan bağlantılar, bağlantının nereye gittiğini belirleyemeyen klavye ve ekran okuyucu kullanıcıları için çıkmazlar yaratır.
• Eksik form girdi etiketleri. Programatik olarak ilişkilendirilmiş etiketleri olmayan formlar, ekran okuyucu kullanıcıları için kullanılamazdır. Buna hem görünür etiketler hem de aria-label veya aria-labelledby kullanan gizli etiketler dahildir.
• Boş düğmeler. Erişilebilir adı olmayan yalnızca simge içeren düğmeler — gezinmede ve slider’larda yaygındır — görsel olmayan kullanıcıların düğmenin ne yaptığını anlamasını engeller.
• Eksik belge dili. <html> öğesindeki lang niteliği, ekran okuyuculara hangi dili kullanacaklarını söyler. Bunun yokluğu, metin okuma teknolojisine güvenen kullanıcılar için yanlış telaffuza ve yönelim bozukluğuna neden olur.

Denetimler tutarlı şekilde, en zararlı hataların aynı zamanda en kolay düzeltilebilenler olduğunu ortaya koyar. Düşük kontrast, eksik alt metin ve etiketlenmemiş form alanları çoğu zaman aylar değil, günler içinde giderilebilir.

Bu altı maddenin ötesinde kapsamlı bir denetim, eksik atla gezinme bağlantılarını (klavye kullanıcılarını her sayfada her başlık öğesini sekmeyle geçmeye zorlayan), hatalı başlık hiyerarşisini, odağı yanlış şekilde hapseden erişilemez modalleri ve diyalogları, altyazısız videoları, etiketli yapısı olmayan PDF’leri ve ARIA aracılığıyla erişilebilir rol ve durumları ortaya koymayan özel JavaScript bileşenlerini de yakalar.

Erişilebilirlik Denetimi Nasıl Yapılır: Adım Adım

Düzgün bir erişilebilirlik denetimi tek bir tarama değildir — otomatik araçları uzman insan yargısıyla birleştiren çok aşamalı bir süreçtir. Buna sistematik olarak şöyle yaklaşabilirsiniz:

Adım 1: Kapsamı Tanımlayın

Tek bir test bile çalıştırmadan önce neyi denetlediğinize karar verin. Büyük bir site için her sayfayı test etmek pratik değildir. Bunun yerine, W3C tarafından geliştirilen WCAG-EM (Website Accessibility Conformance Evaluation Methodology) yaklaşımını uygulayın: tüm benzersiz sayfa şablonlarını, tüm önemli kullanıcı yolculuklarını ve tüm farklı içerik türlerini kapsayan temsilci bir örneklem tanımlayın. Bir e-ticaret sitesi için örneklem; ana sayfa, kategori sayfası, ürün detay sayfası, sepet, ödeme akışı, hesap girişi, iletişim formu ve bir blog yazısını içerebilir. Dinamik durumların dahil olduğundan emin olun — açılmış menüler, form hata mesajları, modal diyaloglar ve yüklenmiş arama sonuçlarının tümü değerlendirilmelidir.

Adım 2: Otomatik Taramalar Çalıştırın

Otomatik araçlar, verimli herhangi bir denetimin temelidir. HTML’nizi hızlıca tarar, tartışmasız kural ihlallerini işaretler ve size temel bir sorun listesi verir. Temel araçlar şunlardır:

• axe DevTools (tarayıcı uzantısı veya CLI) — yaygın olarak kullanılır, düşük yanlış pozitif oranına sahiptir, CI/CD hatlarıyla entegre olur
• WAVE (WebAIM) — sayfaları hata simgeleriyle görsel olarak açıklama ekleyerek işaretler, bu da teknik olmayan ekip üyeleri için sezgiseldir
• Lighthouse (Chrome DevTools’a yerleşik) — performans ve SEO metriklerinin yanında bir erişilebilirlik puanı sağlar
• Colour Contrast Analyser (TPGi) — ekrandaki herhangi bir rengi seçer ve onu WCAG eşiklerine göre kontrol eder
• PAC 2024 — indirilebilir belgeler için özel PDF erişilebilirlik denetleyicisi

Kritik bir sınırlama: otomatik araçlar WCAG sorunlarının yalnızca %30 ila %40’ını tespit edebilir. Eksik nitelikler, geçersiz ARIA rolleri ve kontrast oranları gibi kural tabanlı hataları işaretlemede mükemmeldirler. Ancak alt metnin anlamlı olup olmadığını, bir formun mantıksal olarak yapılandırılıp yapılandırılmadığını veya bir kullanıcının bir görevi gerçekten tamamlayıp tamamlayamayacağını değerlendiremezler. Bu nedenle otomasyon Adım 2’dir, tüm denetim değil.

Adım 3: Manuel Uzman Testi

Bilgili bir insan — ideal olarak bir ekip — tarafından yapılan manuel test, denetimin derinliğinin belirlendiği yerdir. Buna şunlar dahildir:

• Yalnızca klavye ile gezinme. Farenin fişini çekin ve yalnızca Tab, Shift+Tab, Enter, Space ve ok tuşlarını kullanarak her temel kullanıcı yolculuğunu tamamlamaya çalışın. Her etkileşimli öğeye ulaşabiliyor musunuz? Odak göstergesi her zaman görünür mü? Odak herhangi bir bileşenin içinde kayboluyor mu?
• Ekran okuyucu testi. Windows’ta Chrome veya Firefox ile NVDA, macOS ve iOS’ta Safari ile VoiceOver kullanın. Başlıklara, işaret bölgelerine, bağlantılara ve formlara göre gezin. Sayfa görsel bağlam olmadan anlamlı mı? Tüm etkileşimli öğeler doğru şekilde duyuruluyor mu?
• Görsel ve bilişsel inceleme. Mantıksal yapı için başlık hiyerarşisini kontrol edin, hata mesajlarının açıklayıcı olduğunu ve doğru alanla ilişkilendirildiğini doğrulayın, zaman temelli medyanın altyazı ve transkript içerdiğinden emin olun ve talimatların yalnızca renk, şekil veya konuma dayanmadığını gözden geçirin.
• Kod incelemesi. HTML semantiğini, ARIA kullanımını, özel bileşenlerde odak yönetimini ve işaret bölgelerini inceleyin. Odağı hapsetmeyen bir modal veya her tuş vuruşunda tetiklenen bir ARIA canlı bölgesi yalnızca bu seviyede yakalanacaktır.

Adım 4: Gerçek Kullanıcılarla Yardımcı Teknoloji Testi

Altın standart — ve çoğu zaman en çok şey ortaya çıkaran aşama — her gün yardımcı teknolojilere güvenen gerçek kullanıcılarla test yapmaktır. Ekran okuyucu, anahtarlı erişim cihazları veya sesle kontrol yazılımı kullanan insanlar, uzman manuel testçilerin bile tam olarak kopyalayamadığı şekillerde gezinir. Değerlendirmenize engelli kullanıcıları dahil etmek, araçların ve kontrol listelerinin öngöremeyeceği gerçek dünya sürtünmelerini ortaya çıkarır.

Adım 5: Bulguları Belgeleyin ve Önceliklendirin

Ham bir hata listesi bir denetim raporu değildir — başlangıç noktasıdır. Faydalı bir denetim belgesi şunları belirtmelidir: etkilenen URL veya bileşen, ihlal edilen WCAG başarı kriteri, önem derecesi (kritik, yüksek, orta, düşük), etkilenen kullanıcılar üzerindeki etkisi ve uygulanabilir olduğunda kod örnekleriyle birlikte belirli iyileştirme rehberi. Öncelik, teknik kolaylıktan önce kullanıcı etkisine göre atanmalıdır. Ödemeyi engelleyen bozuk bir form etiketi, bir blog yan çubuğundaki optimal olmayan bir başlık seviyesinden daha acildir.

Adım 6: İyileştirin, Doğrulayın ve İzleyin

Düzeltmeler uygulandıktan sonra bunları doğrulayın — iyileştirmenin işe yaradığını varsaymayın. Her düzeltmeyi, ilk denetim sırasında kullanılan araç ve manuel kontrollerin aynı kombinasyonuyla yeniden test edin. Temel bir uyum düzeyine ulaştıktan sonra sürekli izleme devreye alın. Yeni içerik, CMS güncellemeleri ve üçüncü taraf betikleri her an gerilemelere neden olabilir. Erişilebilirliğe güvenlik gibi yaklaşın: sürdürdüğünüz bir şeydir, bir kez elde edip unuttuğunuz bir şey değil.

Otomatik Taramalar ve Tam Denetimler: Farkı Anlamak

Bu ayrım, özellikle hukuki bağlamda son derece önemlidir. Otomatik bir tarama, işlenmiş HTML’nize karşı kural tabanlı bir kontrol çalıştırır. Saniyeler veya dakikalar sürer ve tespit edilen ihlallerin bir listesini döndürür. Bariz, yüksek hacimli sorunları yakalamak ve yeni gerilemelerin yayına çıkmasını önlemek için CI/CD iş akışlarına entegre etmek açısından mükemmeldir. Erişilebilirlik araçları da dahil olmak üzere birçok katman ve widget ürünü, özellik setlerinin bir parçası olarak otomatik tarama panoları sunar ve bunlar gerçekten sürekli izleme için kullanışlıdır.

Buna karşılık tam bir denetim, sitenizi tüm geçerli WCAG başarı kriterlerine göre, otomatik tarama, manuel uzman incelemesi, ekran okuyucu testi ve yalnızca klavye ile gezinmenin birleşimiyle değerlendirir. Otomatik ve manuel yöntemleri birleştiren kapsamlı bir denetim, yalnızca otomasyonun %30–40’lık tavanına kıyasla erişilebilirlik sorunlarının %90’ından fazlasını ortaya çıkarabilir. Bir hukuki ihtar mektubu, tedarik gerekliliği veya düzenleyici soruşturmayla karşı karşıyaysanız, yalnızca tam bir denetim ihtiyaç duyduğunuz dokümantasyonu üretir.

Birçok kuruluş pratik bir hibrit strateji kullanır: otomatik taramalar, gerilemeleri erken yakalamak için CI/CD’de sürekli çalışır; tam manuel denetim ise yıllık olarak veya önemli site yeniden tasarımlarından sonra yapılır. Bu, kapsamlılık ile verimlilik arasında denge kurar ve uyumluluğu zaman içinde yönetilebilir kılar.

Hiçbir araç tek başına bir sitenin erişilebilirlik standartlarını karşılayıp karşılamadığını belirleyemez. Bir sitenin gerçekten erişilebilir olup olmadığını belirlemek için bilgili insan değerlendirmesi gereklidir. — W3C Web Accessibility Initiative

Denetim Sonuçlarıyla Ne Yapmalı: İyileştirme Planlaması

Tamamlanmış bir denetim, yalnızca eylemi tetiklediği sürece değerlidir. İyileştirme çalışmalarını nasıl önceliklendirdiğiniz, sorunları tespit etmek kadar önemlidir. İyileştirme önceliklendirmesi için pratik bir çerçeve şöyle görünür:

1. Kritik (hemen düzeltin): Kullanıcıların temel görevleri tamamlamasını tamamen engelleyen sorunlar — bozuk bir ödeme formu, erişilemez bir giriş modali, klavye ile ulaşılamayan bir gezinme menüsü. Bunlar en yüksek hukuki riski ve en büyük kullanıcı etkisini temsil eder.
2. Yüksek (mevcut sprint veya sürüm döngüsü içinde düzeltin): Engelli kullanıcılar için kullanılabilirliği önemli ölçüde zayıflatan ancak onları tamamen engellemeyen sorunlar — ürün görsellerinde eksik alt metin, gövde metninde düşük kontrast, arayüz genelinde etiketlenmemiş simge düğmeler.
3. Orta (planlanmış iyileştirme): Sürtünmeye neden olan ancak çözümleri olan sorunlar — tutarsız odak göstergeleri, eksik atla bağlantıları, optimal olmayan başlık hiyerarşisi.
4. Düşük (tanımlı sahibi olan bekleme listesi): Çoğu durumda kullanılabilirliği etkilemesi olası olmayan ancak en iyi uygulama iyileştirmeleri olan sorunlar — AAA düzeyi geliştirmeler, küçük ARIA ayrıntı iyileştirmeleri.

Tüm düzeltmeler tamamlanmadan önce bile iyileştirme planınızı ve zaman çizelgenizi belgeleyin. Düzenleyiciler ve mahkemeler, genellikle gösterilmiş, devam eden, iyi niyetli iyileştirmeyi eylemsizliğe kıyasla daha olumlu değerlendirir. Bir ihtar mektubu alırsanız, elinizde bir denetim raporu ve iyileştirme takvimi olması, hiçbir dokümantasyona sahip olmamaktan çok daha güçlü bir pozisyondur.

Accsible tarafından sunulan gibi katman widget’ları ve SDK araçları, iyileştirme aşamasında anlamlı bir rol oynayabilir. Geliştirme ekibiniz daha derin kod düzeyi iyileştirmeler üzerinde çalışırken, yaygın sorunların önemli bir kısmı için (özellikle kontrast, yazı tipi boyutu ve boşluk gibi görsel tercihler) anında düzeltmeler sunabilirler. Önemli olan, katmanların neyi iyi çözdüğünü anlamak ve onları kritik bariyerlerde kod düzeyi düzeltmelerin yerine değil, katmanlı bir stratejinin parçası olarak kullanmaktır.

Erişilebilirlik Denetimini Ne Sıklıkla Yapmalısınız?

Tek seferlik bir denetim, sitenizin belirli bir gündeki anlık görüntüsüdür. Web siteleri yaşayan ürünlerdir — içerik değişir, üçüncü taraf betikler güncellenir, bileşenler değiştirilir ve yeni özellikler yayına girer. Bunların her biri yeni erişilebilirlik bariyerleri getirebilir. Sürdürülebilir bir erişilebilirlik programı genellikle şöyle görünür:

• Sürekli otomatik tarama, CI/CD hattınıza veya bir izleme panosuna entegre edilerek gerilemeleri üretime ulaşmadan yakalar
• Üç aylık manuel nokta kontrolleri, yüksek trafikli ve yüksek riskli sayfalarda (ödeme, giriş, iletişim formları, kilit açılış sayfaları)
• Yıllık tam denetim, özellikle büyük yeniden tasarımlar veya platform geçişlerinden sonra, nitelikli erişilebilirlik uzmanları tarafından yürütülür
• Tasarım aşamasında denetim, yeni büyük bir özellik veya yeniden tasarım için — erişilebilirliği sonradan yamalamaktansa en baştan inşa etmek çok daha ucuzdur

En maliyet etkin yaklaşım, erişilebilirliği sola kaydırmaktır — onu, lansman sonrası bir uyumluluk egzersizi olarak görmek yerine tasarım ve geliştirme sürecine ilk günden entegre etmektir. WCAG gerekliliklerini anlayan geliştiriciler, sorunları kaynağında yakalar. Renk kontrastı ve dokunma hedefi boyutlarını bilen tasarımcılar, varsayılan olarak erişilebilir seçimler yapar. Böylece denetim, acil müdahaleden ziyade bir kalite kapısına dönüşür.

Temel Çıkarımlar

• Web sitelerinin çoğu WCAG’de başarısız oluyor. Ana sayfaların %95’inden fazlasında tespit edilebilir erişilebilirlik hataları var ve en yaygın altı hata — düşük kontrast, eksik alt metin, boş bağlantılar, eksik form etiketleri, boş düğmeler ve eksik belge dili — büyük çoğunluğu oluşturuyor. Bunların hepsi düzeltilebilir.
• Otomatik araçlar gerekli ama yeterli değil. Otomatik tarayıcılar en iyi ihtimalle WCAG sorunlarının %30–40’ını yakalar. Tam bir denetim, klavye testi, ekran okuyucu testi ve kod ile kullanıcı deneyimi akışlarının uzman insan incelemesini gerektirir.
• WCAG 2.2 Seviye AA hedeftir. ADA, Avrupa Erişilebilirlik Yasası, Section 508 ve dünya çapındaki diğer çoğu erişilebilirlik çerçevesi tarafından referans verilen standart budur. 2.2 AA’yı hedeflemek, otomatik olarak tüm alt sürümleri kapsadığınız anlamına gelir.
• İyileştirme bir öncelik çerçevesi gerektirir. Tamamen temel kullanıcı yolculuklarını engelleyen sorunlarla başlayın, ardından yüksek etkili, yüksek frekanslı sorunlar üzerinde çalışın. Her şeyi belgeleyin — denetim raporunuz ve iyileştirme planınız en iyi hukuki savunmanızdır.
• Erişilebilirlik süreklidir, bir kerelik değil. Sürekli otomatik izlemeyi periyodik manuel denetimlerle birleştirin ve erişilebilirliği en baştan tasarım ve geliştirme sürecinize kaydırın. Accsible gibi bir katman widget’ı, daha derin iyileştirmeler devam ederken boşlukları doldurabilir.